L'aube des applications SPA à page unique
Le modèle SPA (Single Page Application) a gagné en popularité au cours des dernières années. C'est compréhensible, cette approche donne un certain profit en termes de rapidité, de qualité de service et crée la base de nouveaux modèles de développement web client.
Comme tout le monde, je pense, le sait bien, SPA fonctionne à l'intérieur du navigateur et ne nécessite pas de rechargement de page pendant l'utilisation.
Bonne idée! Mais, bien sûr, il y a des pièges.
Parmi les cas les plus courants (si vous suivez un tutoriel sur react ou vue), la page principale index.html contient un fichier HTML presque vide avec un petit nombre de CSS, JavaScript, polices, etc. qui sont globaux pour l'ensemble du projet.
Et c'est le problème:
- Lors du rendu initial, l'utilisateur devra attendre que toute la base de code et toutes les ressources soient chargées (bien sûr, il y a des exceptions, et vous pouvez implémenter le chargement dynamique des blocs dits js / css, mais c'est une autre histoire)
- Certains robots d'exploration ou analyseurs qui ne peuvent pas attendre le chargement des requêtes asynchrones verront simplement toutes les pages vierges
Eh bien, vous avez l'idée:
<!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>
Rendu côté serveur SSR
Contrairement au rendu côté client (CSR), qui utilise le navigateur pour restituer tout le contenu de l'application et récupérer les données des API et autres, SSR utilise ... le serveur. Autrement dit, tous les mêmes rendus et récupération de données sont traités par le serveur (NodeJS utilisant Express, Next, Vue SSR, Nuxt ou autre ...), puis la réponse avec le balisage HTML, les styles, les scripts et les données reçues de l'API, envoyé au navigateur.
Ainsi, vous pouvez profiter de deux approches: vitesse / SEO et interactivité / UX.
Alors, qu'est-ce que l'hydratation / réhydratation?
La réhydratation est une sorte de pont entre SSR et CSR.
Il existe un indicateur des performances de la page Web comme First Contentful Paint (FCP) - grossièrement traduit, cela ressemblera à un `` premier rendu significatif '' - le moment où le navigateur a commencé à afficher du texte, des images (y compris l'arrière-plan). Ce sont les premiers éléments que l'utilisateur verra sur la page. Lorsque vous créez un rapport avec Lighthouse dans Chrome, sous l'onglet Performances, vous verrez immédiatement cette statistique.
Le temps passé à générer du contenu sur le serveur sera le temps de First Contentful Paint.
Immédiatement après cela, JavaScript côté client commence l'exécution pour créer une application client à part entière (dans la plupart des cas, les frameworks populaires sont virtual dom et une interface de liaison pour la gérer).
À ce stade, il n'est pas nécessaire de restituer l'intégralité du DOM sur le client, mais il est nécessaire d'ajouter les événements manquants, les méthodes et, dans certains cas, les éléments qui n'ont pas été rendus sur le serveur.
C'est ce processus que l'on appelle hydratation / réhydratation. Une description un peu plus détaillée peut être trouvée dans le Guide Vue SSR (qui est également en russe), mais, en conséquence, avec certaines fonctionnalités de ce cadre particulier.
Performance
Mais dans cette partie, quelques problèmes apparaissent. La réhydratation a un certain inconvénient - c'est le temps avant l'interaction ou Time to Interactive, qui peut être vu dans le même, connu de nous, Lighthouse Chrome. Même si vous avez tout organisé parfaitement côté serveur et que la page a un premier rendu rapide du contenu, l'utilisateur ne pourra interagir avec elle qu'après la réhydratation CSR, qui est parfois assez lente. C'est un gros inconvénient en termes d'UX
Un autre indicateur du délai maximal de première entrée potentiel est le premier délai d'entrée (FID) - l'une des mesures de performance des pages Web qui décrit le temps écoulé depuis le moment où l'utilisateur a commencé à interagir avec la page Web, c.-à-d. e. a cliqué sur un lien, un bouton ou utilise un contrôle basé sur JavaScript jusqu'à ce que le navigateur Web puisse répondre à l'interaction (telle que définie par mozilla).
Et le temps de réhydratation affecte directement cet indicateur. Et plus il y a de composants et de logique sur votre page, plus cet indicateur augmente rapidement.
Une solution est la charge paresseuse pour l'hydratation.
Un exemple d'implémentation d'une approche similaire dans Vue SSR / NuxtJS est le package vue-lazy-hydrration(dans le référentiel npm), qui implémente l'hydratation uniquement dans la partie visible de la fenêtre du navigateur et «hydrate» le reste uniquement si la page est défilée. Des recommandations pour l'utilisation de ce package ont également été trouvées sur habr dans le tutoriel Nous créons une boutique en ligne sur Nuxt.js , pour laquelle l'auteurAntonMoskalchenkoJe veux exprimer ma gratitude particulière. Dans son article, Lighthouse Chrome a atteint 100% de performances.