The Dawn of Single Page SPA Applications
The Single Page Application (SPA) model has grown in popularity over the past few years. It is understandable, this approach gives a certain profit in terms of speed, quality of service and creates the basis for new patterns of client web development.
As everyone, I think, is well aware, SPA works inside the browser and does not require page reloading during use.
Great idea! But, of course, there are pitfalls.
Among the most common cases (if you take any tutorial on react or vue), the main index.html page contains an almost empty HTML file with a small number of links, global for the entire project, CSS, JavaScript, fonts, etc.
And this is the problem:
- During the initial rendering, the user will have to wait for the entire codebase and all resources to be loaded (of course, there are exceptions, and you can implement dynamic loading of so-called js / css chunks, but that's another story)
- Some crawlers or parsers that can't wait for asynchronous requests to load will just see all pages blank
Well, you get the idea:
<!DOCTYPE html>
<html>
<head>
<title>My first SPA app</title>
<script src="https://cdn__"></script>
</head>
<body>
<div id="app"></div>
<script>
...
,
...
</script>
</body>
</html>
Server side rendering SSR
Unlike Client Side Rendering (CSR), which uses the browser to render all application content and retrieve data from APIs and the like, SSR uses ... the server. That is, all the same rendering and data retrieval is processed by the server (NodeJS using Express, Next, Vue SSR, Nuxt or whatever ...), and then the response with HTML markup, styles, scripts and the received data from the API, sent to the browser.
Thus, you can take advantage of two approaches: speed / SEO and interactivity / UX.
So, what is hydration / rehydration?
Rehydration is a kind of bridge between SSR and CSR.
There is such an indicator of web page performance as First Contentful Paint (FCP) - roughly translated, it will sound like 'first significant rendering' - the time when the browser began to display any text, images (including background). These are the first elements that the user will see on the page. When you create a report with Lighthouse in Chrome, under the performance tab, you will immediately see this metric.
The time spent generating content on the server will be First Contentful Paint time.
Immediately after that, client-side JavaScript begins execution to create a full-fledged client application (in most cases, popular frameworks are virtual dom and a binding interface for managing it).
At this point, there is no need to re-render the entire DOM on the client, but it is necessary to add the missing events, methods, and in some cases, elements that were not rendered on the server.
It is this process that is called hydration / re-hydration. A slightly more detailed description can be found in the Vue SSR Guide (which is also in Russian), but, accordingly, with some features of this particular framework.
Performance
But in this part, some problems appear. Rehydration has a certain drawback - it is the time before interaction or Time to Interactive, which can be seen in the same Lighthouse Chrome we know. Even if you have organized everything perfectly on the server side and the page has a fast first render of the content, the user will only be able to interact with it after the CSR rehydration, which is sometimes quite slow. This is a big disadvantage in terms of UX.
Another indicator of Max Potential First Input Delay is the first input delay (FID) - one of the web page performance metrics that describes the time elapsed since the user first started interacting with the web page, i.e. e. clicked on a link, button, or uses a JavaScript-based control until the web browser can respond to the interaction (as defined by mozilla).
And the time of rehydration directly affects this indicator. And the more components and logic there are on your page, the faster this indicator increases.
One solution is lazy load for hydration.
An example of implementing a similar approach in Vue SSR / NuxtJS is the vue-lazy-hydration package(in the npm repository), which implements hydration only in the visible part of the viewport of the browser and "hydrates" the rest only if the page is scrolled. Recommendations for using this package were also found on habr in the tutorial We create an online store on Nuxt.js , for which the authorAntonMoskalchenkoI want to express my special gratitude. In his article, Lighthouse Chrome achieved 100% Performance.