1. What is Resumability?

Resumability is the process of building an app on the server serializing it into HTML and then resuming it on the client without needing to re-execute it again

2. How does Resumability work?


How does resumability work?

  1. First the client sends a get request to the server
  2. the server rebuilds (or plays) the app
  3. pauses it by serializing it into the HTML
  4. then sends the HTML back to the client
  5. the client resumes the app from where the server paused it
  6. when a user interacts with an element
  7. only that event handler is requested
  8. downloaded
  9. and executed

3. What are the Pros and Cons of Resumability?


  • instant start up time (FCP) and Time To Interactive (TTI)
  • JavaScript sent to the client scales with user interaction, not app size
  • avoid doing work on the server and repeating it on the client (hydration)
  • less JavaScript to download means lower data usage and better user experience


  • limited availability
  • delayed interaction if event handler not preloaded or high network latency

4. When should you use Resumability?

  • when fast Time To Interactive (TTI) is important
  • when you don't want the app to grow slower as it grows bigger
  • when you want client-side interactivity with SSR/SSG without hydration on the client

Perfect replacement for hydration, use everywhere except static sites

see also Progressive Hydration, Islands Architecture and React Server Components


Start here:

Understanding Resumability from the Ground Up
Resumability promises a constant boot time for your application, whereas the current hydration approach has no upper limit on the time it can take. Resumability allows for instant-on applications, and many case studies demonstrate that startup speed impacts your bottom line.
Resumability vs Hydration
Resumability is a faster alternative to Hydration. At first glance, it may seem like resumability and Hydration are the same. After all, both bring interactivity to your page. Defining Hydration to be just making a page interactive is so broad as it fails to be useful as it includes non-server-rende…
Why Efficient Hydration in JavaScript Frameworks is so Challenging
Hydration is the name given to the process in JavaScript frameworks to initializing the page in the…

In Depth:

Hydration is Pure Overhead
Why hydration is a workaround, not the solution.
Don’t blame the developer for what the frameworks did!
While some think it’s fun to blame developers for issues they’re not responsible for, we thought we’d clear the air about a complaint that keeps popping up. Site speed.
Our Current Frameworks are O(n); We Need O(1)
As the complexity of applications increases, the amount of JavaScript downloaded increases (on a typical framework). The only way we can continue building more complex web applications in the future is to lazy load on interaction, not on initial load.
Conquering JavaScript Hydration
That is an ambitious title for an article. An ambitious goal in general. Hydration, the process of…
The Qase for Qwik: Love At First TTI
The reasons why you should be looking at Qwik if you care about performant web apps.
WTF Is Code Extraction
Code extraction allows you to collocate client and server code in the same file. Let’s take this idea to 11.


Think Qwik | Concepts 📚 Qwik Documentation
No hydration, auto lazy-loading, edge-optimized, and fun 🎉!


Qwik has just the right amount of magic with Miško Hevery (JS Party #261)
A deep dive into Qwik, how it makes your apps fast by default, and the carefully calibrated amount of “magic” that makes it uniquely powerful.