Resumability in JavaScript

Fast could mean a lot of things, but in this article, we are concerned with startup performance. From the moment the user clicks on a link to navigate to a page until the page is ready for interaction. This contrasts with the update performance of how long it takes to update the UI when the user interacts with the page. The startup performance is where we could see the most benefit to user experience.

Defining fast!

Google, for example, cares a lot about startup performance because startup performance influences the user experience. For this reason, Google has built Core-Web-Vital metrics (CWV) that objectively measure the site’s user experience. Google said it would use CWV metrics in its SEO ranking algorithm to encourage the industry to move in the right direction.

Finally, a lot of data shows that startup performance matters for conversions, and Google has compiled a list of studies that show exactly that.

We used to be fast

Believe it or not, the web used to be fast! Well, fast in the startup performance sense. It used to be that every interaction required a full round trip from the client to the server, and the client had no JavaScript. It is widely accepted that the fastest way to get pixels in front of the user on initial navigation is through static HTML. So, what happened?

Sending HTML renders the page fast, but without JavaScript, we have no interactivity. So, from the early days, we have used JavaScript to improve the user interactivity story. This culminated with jQuery, which to this day is one of the most used packages on the web. By adding JavaScript, we could have pages that load fast and then are interactive.

The problem with that approach is that there is a lot of code duplication. The backend is written in one language (PHP, Ruby, Java, etc.), and the interaction in another (JavaScript). The backend needs to render a user contact form, and a client needs to add an additional address to the form. This means that both the client and server need the ability to render the same thing. You can see how quickly things go out of sync, not to mention that the developer has to constantly switch back and forth and keep related code in a different language and probably different locations.

While the DX of the above is not the best, surprisingly, it produces excellent performance characteristics. To this day, it is how Amazon serves its site.

What the above tweet shows is that serving pages that way, while not the best DX, produces the best UX.

How we got slow

As described above, building sites by having a server render language and client render language is not ideal. If doing hybrid languages is hard, maybe we should do everything in just one language. Let’s move everything to JavaScript! This is the birth of Single Page Applications (SPA). The idea is simple: Serve a blank HTML that contains just enough to load JavaScript, then have the JavaScript render everything.

The SPA approach solves a lot of things from the DX perspective. Single language, single mental model, and it is easy enough to teach many developers quickly. So, the SPA took off. Now to be fair, the SPA has one thing going for it: Client-side interactions are fast, but not the startup performance.

At first, SPAs were small, so the startup performance was not too bad. The user would navigate to a page, would see a white screen, and a second later, the application would render. But over time, we kept adding more and more functionality to our applications. Animations, personalization, analytics, CSS in JS, component libraries, etc. Every time we added one of those features, the startup performance would get a bit worse because SPAs require that all of that code be present. Death by a thousand cuts. So, what started as a reasonable compromise quickly turned into an actual problem. Users had to wait too long on the white screen before the site would render.

Prerendering hack

To make the sites appear as if they had a better startup performance, people started prerendering the applications on the server. So instead of sending you a blank HTML that bootstrapped your application, we prerendered the application into HTML on the server (or build time) and sent the HTML snapshot of the application to the client. Then...