Network Waterfalls

I wanted to share an interesting performance improvement I found at work that was 100% client-side! The video below sums it up pretty well - the video on left is before, and video on right is after. The hardest part of this whole thing was figuring out split screen-recording and triggering a page refresh on both windows at the same time 😂

This is our most common path in the app - reviewing documents in the docviewer. It’s also the most complicated part of the app, with a mixture of backbone and react (“Reactbone” ❤️) and lots of data flowing around. It turns out there was a bit of unnecessary dependent data-fetching going on. One word I’ve heard for this is a “network waterfall”. This is best understood if I share the network requests before and after:

See how the requests are a bit more “pushed” to the left and initiated sooner? The time difference is because we now start fetching all the data as soon as we can. The problem was somewhat easy to spot once I dug into it, but this had sat in the legacy backbone code for years! The critical path (the results and facet_stats endpoint in requests above) didn’t actually need to wait for the other request to resolve. This led to a dramatic performance improvement for free!

Typically, the performance improvements won’t be as dramatic as in this example. But remembering network waterfalls is still important to optimize any web app. In general, just thoroughly looking through the network tab in devtools is my preferred way to grok an app for the first time.