Progressive Hydration

1 minRendering
Progressive Hydration

I have started reading about progressive hydration used for server-side rendering.

When the clients are receiving the .js files, they need to be loaded, processed and executed. That means, it can take a while for the specific components of the DOM to be fully interactive. We might have a button on the page, but it isn’t interactive instantly. That can be very frustrating for the user.

Instead of doing the hydration for the whole page, we can determine what content needs to be hydrated first. This way we can request only the JavaScript we need. We not only get fast First Contentful Paint with server-side rendering (lesser JavaScript), but we also get faster Time To Interactive.

We can, with progressive hydration, hydrate components based on specific criterias. This could be when the component is visible in the viewport. The HTML and CSS is already loaded, so there will be no jumps or flashing components.

This approach reduces the amount of JavaScript needed to make the pages interactive.

What are the downsides? πŸ˜ƒ