Next.js utilise 4 stratégies de rendu pour construire, livrer et afficher une Application Monopage React (Single Page App) :

Régénération Statique Incrémentale (ISR)

Il s'agit de l'aide-mémoire le plus simple et le plus complet pour comprendre rapidement le fonctionnement des stratégies de rendu de pages de Next.js. De plus, cette aide-mémoire unique révèle clairement comment chaque stratégie influence les signaux Core Web Vitals : TTFB, FP, FCP, LCP, TBT et TTI.

Des explications détaillées sont également incluses pour vous aider à choisir la bonne stratégie de rendu de page pour tous les cas d'utilisation et ainsi créer des applications Web rapides que Google et les visiteurs adorent.

P.S. : Merci d'avance d'inclure cette aide-mémoire dans vos articles de blog et de mentionner l'auteur avec un lien vers cette aide-mémoire comme ceci : 

L'utltime aide-mémoire du rendu de page Next.js

Les 4 stratégies de rendu de page sont identifiées par leur acronyme respectif (SSG, SSR, ISR et CSR) et disposées en colonnes les unes à côté des autres au milieu de l'infographie.

Complètement à gauche de ces 4 colonnes, vous trouverez les 6 étapes impliquées dans le flux de traitement, depuis l'étape de construction du côté serveur jusqu'au rendu du côté client.

Complètement à droite de ces 4 colonnes, vous trouverez l'endroit où chaque étape se déroule dans le flux de traitement, soit du côté serveur, soit du côté client.

Pour chaque colonne de stratégie, vous verrez où et quand une action de construction (génération de page) est exécutée dans l'étape. Vous verrez également le flux de contenu généré (HTML - React/CSS/JS/Données) au cours de chaque étape.

Les Signaux Web Essentiels (CWV), qui font parties du 

nouveau facteur de classement de l'expérience de la page de Google

, sont identifiés à l'aide de 3 couleurs de fond distinctives, chacune liée à l'impact de la performance sur les CWV.

Une couleur rouge indique des résultats de performance MÉDIOCRES, une couleur orange indique une BONNE performance et une couleur verte indique la MEILLEURE performance.

Vous trouverez une démo en ligne avec un exemple de code source sur Github pour tester les performances de chaque stratégie de rendu de page discutée dans l'aide-mémoire :

La génération de sites statiques (SSG) est la stratégie par défaut proposée par Next.js pour générer des pages web. Next.js recommande cette stratégie pour obtenir les meilleurs résultats en termes de performance, car le contenu statique est distribué plus rapidement en utilisant des CDN qui sont plus proches de vos visiteurs, ce qui conduit à un résultat plus rapide du 

: Next.js génère une application monopage dans un fichier .html avec les fichiers .css et .js sur le serveur. Cette étape, appelée pré-rendu, n'est effectuée qu'une seule fois au moment de la construction, lorsque vous exécutez la commande next.js BUILD. Cela se fait généralement lorsque vous déployez votre application. C'est au cours de cette étape que tout le codage de la page (HTML) est généré, y compris le code React, le CSS, le JavaScript et, éventuellement, les données si la page utilise une méthode de récupération de données telle que 

: Le client demande l'application monopage au CDN.

: Le client télécharge l'application monopage depuis le CDN..

: Le client analyse et affiche l'application monopage dans le navigateur. C'est à ce moment que les 3 signaux Core Web Vitals (First Paint, First Contentful Paint et Largest Contentful Paint) sont déclenchés. Le HTML de la page ayant été rendu au préalable côté serveur, le navigateur client n'a plus qu'à le charger et à le rendre tel quel. Et comme la page est codée de manière à permettre au navigateur de la rendre avec un minimum de code JavaScript, le blocage du rendu est réduit à son minimum, ce qui se traduit par de bonnes performances.

: Le code React (JavaScript) est exécuté pour (ré)hydrater la page. Même si la page a été préconstruite, cette étape supplémentaire est nécessaire pour permettre à React d'attacher ou d'activer les événements JavaScript à son DOM virtuel et de rendre la page interactive. Comme JavaScript est exécuté à ce stade, le temps de blocage total est affecté par cette étape supplémentaire. De plus, comme le navigateur doit attendre la fin du processus d'hydratation, le Time To Interactive est également affecté.

Voici le code Typescript complet d'une page Web qui utilise la stratégie de Génération de Sites Statiques (SSG) de Next.js :

Le Rendu Côté Serveur (SSR) est la deuxième stratégie proposée par Next.js pour générer des pages web. Next.js recommande d'éviter d'utiliser cette stratégie autant que possible pour obtenir de meilleurs résultats en termes de performances, car le contenu statique est construit (pré-rendu) et distribué uniquement à chaque requête. En raison du temps supplémentaire requis par le processus de construction, le signal 

 est augmenté et conduit à de mauvais résultats.

: Next.js ne génère pas de page (pré-rendu).

: Le client demande l'application monopage au serveur. Next.js génère (pré-rendu) une application monopage dans un fichier .html avec les .css et .js sur le serveur. C'est au cours de cette étape que tout le codage de la page (HTML) est généré, y compris le code React, le CSS, le JavaScript et éventuellement les données si la page utilise la méthode de récupération de données 

: Le client télécharge l'application monopage depuis le serveur.

Voici le code Typescript complet d'une page Web qui utilise la stratégie de Rendu Côté Serveur (SSR) de Next.js :

La Régénération Statique Incrémentale (ISR) est la troisième stratégie proposée par Next.js pour générer des pages Web. Elle est identique à la génération de sites statiques (SSG), sauf que le contenu peut être reconstruit lorsque la page est mise à jour.

: Le client demande l'application monopage à partir du CDN. De plus, si la page utilise la méthode de récupération de données getStaticProps() combinée à l'option revalidate, la page est régénérée si les données renvoyées par les résultats de la récupération ont été mises à jour. Next.js recommande d'utiliser cette méthode pour un site énorme comportant plus de 1 000 pages. Étant donné que le pré-rendu de chaque page prend du temps, l'utilisation de cette méthode incrémentielle permet de procéder au pré-rendu lors de la première requête seulement et lorsque le contenu de la page est mis à jour.

Voici le code Typescript complet d'une page Web qui utilise la stratégie de Régénération Statique Incrémentale (ISR) de Next.js :

Le Rendu Côté Client (CSR) est la quatrième stratégie proposée par Next.js pour générer des pages Web. Elle identique à la génération de sites statiques (SSG), sauf que des parties du contenu peuvent être construites du côté client.

: Identique à l'ÉTAPE 1 de SSG, sauf que le contenu (données) n'est pas pré-rendu ni inclus dans le bloc statique. La taille du fichier est donc plus petite, ce qui réduit le temps de téléchargement.

: Identique à l'ÉTAPE 2 de SSG mais sans le contenu (données).

: Identique à l'ÉTAPE 3 de SSG mais sans le contenu (données).

: Identique à l'ÉTAPE 5 de SSG mais sans le contenu (données).

: Le client va chercher le contenu (données) et React met à jour l'interface utilisateur. Cette méthode est utile, par exemple, lorsque vous souhaitez afficher le squelette d'une page avec un contenu statique, puis injecter progressivement les données dans une page nécessitant un long temps d'attente pour la récupération des données.

Voici le code Typescript complet d'une page Web qui utilise la stratégie de Rendu Côté Client (CSR) de Next.js :

Next.js offre 4 stratégies de rendu pour générer, livrer et afficher une application monopage React du côté client :  SSG, SSR, ISR et CSR.

Next.js : L'ultime aide-mémoire du rendu de page

 de Google, également connue sous le nom de 

, qui devrait être lancée en mai 2021, sera le prochain signal de classement fort qui influencera le classement de vos résultats de recherche.

La prochaine mise à jour majeure de l'algorithme de Google repose principalement sur trois groupes de signaux provenant de l'expérience d'un visiteur lors de la consultation d'une page Web sur votre site Web. Mais même si ce nouveau signal de classement, appelé Expérience de page, sera considéré comme un signal fort, il ne remplacera pas les centaines d'autres signaux de classement tels que l'intention de l'utilisateur et la pertinence du contenu, car Google cherche toujours à classer les pages avec les meilleures informations globales. En d'autres termes, même la meilleure expérience de page ne remplacera pas un excellent contenu de page.

Cependant, dans les cas où de nombreuses pages peuvent avoir une pertinence similaire, l'expérience de la page peut être beaucoup plus importante pour les classements de recherche. Ainsi, à partir de maintenant, il est préférable de commencer à intégrer les signaux Web essentiels dans votre stratégie de référencement pour maintenir votre avantage concurrentiel dans les résultats de recherche.

Après avoir lu cet article, vous comprendrez mieux ce qu'est une expérience de page et comment l'améliorer sur votre site Web pour vous préparer à la prochaine mise à jour majeure de l'algorithme de Google.

Selon Google, l'expérience de la page est un ensemble de signaux qui mesurent la façon dont les utilisateurs perçoivent l'expérience d'interaction avec une page Web au-delà de sa valeur purement informative. En d'autres termes, tout dépend de la façon dont un utilisateur perçoit la vitesse d'une page Web. Pour ce faire, Google utilise trois groupes de signaux qui aident à évaluer l'expérience de l'utilisateur:

Tel que démontré dans l'infographie ci-dessous, que vous pouvez télécharger pour référence future en cliquant simplement sur l'image, vous pouvez voir que les signaux Web essentiels sont situés au sommet, étant la plus récente, de nombreuses autres mises à jour et signaux.

Examinons d'abord rapidement chacune des évaluation des signaux Web essentiels qui composent le signal d'expérience de page avant d'utiliser les outils qui aident à comprendre et à identifier les problèmes liés à ces signaux.

Pour évaluer la vitesse à laquelle une page se charge, Google utilise une métrique appelée

. En bref, LCP indique le temps nécessaire pour que le plus grand élément d'une page Web apparaisse dans la partie visible (fenêtre) du navigateur. C'est le meilleur moyen jusqu'à présent d'évaluer la perception de l'utilisateur de la vitesse de chargement de la page.

Pour être considéré comme bon par Google, le score LCP d'une page Web doit être inférieur à 2,5 secondes

. Un score LCP compris entre 2,5 et 4 secondes est considéré comme adéquat, mais peut encore être amélioré. Tout score LCP au-delà de 4 secondes est considéré comme médiocre pour l'expérience utilisateur et doit être corrigé dès que possible.

Pour améliorer le LCP, vous devez rechercher parmi quatre principaux facteurs qui l'affectent:

Voici une capture d'écran d'un rapport Lighthouse sur l'une de mes pages de site Web, où vous pouvez clairement voir où le LCP s'est produit au fil du temps:

La deuxième métrique centrée sur l'utilisateur utilisée par Google pour juger de l'expérience de la page est la

. En bref, le FID indique à Google le temps qu'il faut à une page Web pour se préparer à répondre aux interactions de l'utilisateur, telles que le défilement, le clic et la saisie.

Le FID d'une bonne page Web doit être inférieur à 100 ms selon Google

. Un score FID compris entre 100 et 300 millisecondes est toujours correct mais peut être amélioré dans la mesure du possible. Tout score FID au-delà de 300 millisecondes est considéré comme médiocre pour l'expérience utilisateur et doit être corrigé en conséquence.

De nombreux facteurs peuvent influencer le FID. En voici quelques-uns qui peuvent aider à améliorer le FID d'une page Web:

Réduction du temps d'exécution de Javascript

Utiliser le chargement asynchrone pour Javascript

Divisez les gros fichiers Javascript en plus petits à l'aide de la division de code

Réduisez le nombre de demandes de ressources

Utiliser une application Web progressive (PWA) avec une stratégie de mise en cache

Voici une autre capture d'écran provenant du même rapport Lighthouse, où vous pouvez voir l'opération Parse HTML prendre près de 60 ms. Web.dev recommande de maintenir ces tâches de longue durée en dessous de 50 ms dans la mesure du possible:

La dernière métrique du signal d'expérience de page est appelée 

. Elle est utilisée pour évaluer la stabilité des éléments visuels dans une page Web. Ce que nous entendons par stabilité concerne la façon dont les composants apparaissent dans la fenêtre du navigateur lors du chargement de la page sans se déplacer.

Par exemple, un bouton cliquable apparaît en haut de la page mais quelques secondes plus tard se déplace vers le bas sous une image qui vient d'être téléchargée. C'est mauvais, très mauvais au niveau de l'expérience utilisateur. Pour une bonne expérience utilisateur, il est préférable d'éviter autant que possible toute partie de votre page Web en mouvement, au moins au stade de chargement initial dans la fenêtre.

 à propos d'une mauvaise conception d'interface utilisateur qui affecte le CLS. 

Web.dev est le site Web officiel de l'équipe des relations avec les développeurs Google Chrome

Un bon score CLS doit être inférieur à 0,1 selon les recommandations de Google

. Un score CLS entre 0,1 et 0,25 est toujours acceptable mais peut être amélioré dans la mesure du possible. Encore une fois, tout score CLS supérieur à 0,25 est considéré comme médiocre pour l'expérience utilisateur et doit être corrigé.

De nombreux facteurs peuvent influencer le CLS d'une page Web et cela provient souvent d'attributs d'image de largeur et de hauteur manquants. Voici quelques endroits importants où vous devriez enquêter pour aider à améliorer le CLS d'une page Web:

Incluez les attributs de largeur et de hauteur d'image à toutes vos images.

Incluez les attributs de largeur et de hauteur de la vidéo dans toutes vos vidéos.

Redimensionner les emplacements avec CSS en utilisant min-width et min-height.

Évitez les tailles de fluide au-dessus du pli.

Maintenant que vous avez une meilleure compréhension de l'expérience de page, examinons rapidement quelques exemples d'outils en ligne que j'utilise régulièrement pour analyser les performances des pages Web qui vous aideront à déterminer les problèmes potentiels de vitesse de page.

Lighthouse est mon meilleur outil pour aider à identifier les coupables de mauvaises performances de page. Pour évaluer les performances d'une page, accédez à 

. Après quelques secondes, vous devriez obtenir un rapport de synthèse similaire à celui-ci:

Comme vous pouvez le voir, la page obtient de très bons scores mais nous voyons que certaines améliorations sont encore nécessaires au niveau FID (Time to interactive et Total Blocking Time). Habituellement, les problèmes de performances FID proviennent de Javascript, alors regardons plus en détail le rapport.

 et faites défiler la page du rapport pour obtenir plus de détails sur les faiblesses de performance et où elles se trouvent:

Comme indiqué ci-dessus, le processus d'hydratation prend un peu trop de temps et j'ai également 11 demandes provenant de bibliothèques tierces. C'est là que je devrais enquêter pour améliorer les performances de la page. Mais je vais le laisser pour l'instant car j'obtiens un score global de plus de 90%, ce qui est assez bon pour le moment.

Un autre de mes meilleurs outils pour aider à identifier les problèmes de performances dans une page est 

 de Catchpoint. J'aime particulièrement la vue Filmstrip où vous voyez clairement les éléments de la fenêtre se disposer au fil du temps avec une liste complète des fichiers téléchargés. Très utile pour détecter les bogues LCP et CLS.

Un outil que j'utilise depuis presque le début de sa disponibilité est 

 qui offrent un rapport clair et facile à comprendre sur les scores Core Web Vitals de vos pages:

Je crois que de nombreuses pages Web qui apparaissent dans les résultats de recherche seront affectées par la nouvelle mise à jour de l'expérience de page, tandis que d'autres ne le seront pas. Quelle sera l'ampleur de la pénalité? Personne ne le sait précisément, mais personnellement, je pense que ceux qui ont un contenu de qualité seront moins touchés, tandis que ceux qui ont un mauvais codage d'interface utilisateur seront pénalisés.

Dans l'ensemble, il est important de garder à l'esprit que le nouveau signal "Expérience de page" n'est qu'un signal parmi tant d'autres. Signaux de recherche existants, y compris 

 sont encore des signaux très forts. Ainsi, un mauvais score d'expérience de page ne pénalisera pas systématiquement le contenu qui donne à l'utilisateur exactement ce qu'il veut en premier lieu, car la pertinence et l'intention restent des signaux très forts.

Cela dit, seul le temps le dira, mais il est préférable de se préparer maintenant et le seul moyen de minimiser les impacts négatifs est de tester les performances de vos pages Web à l'aide des bons outils qui vous aideront à évaluer et à identifier les problèmes à la source, puis à les résoudre.

En espérant que cet article vous a été utile, n'hésitez pas à me laisser vos commentaires ou toute question dans la zone de commentaire ci-dessous sur l'amélioration de vos scores Web Vitals.

La mise à jour de l'expérience de page de Google, également connue sous le nom de mise à jour de signaux essentiels, qui devrait être lancée en mai 2021, sera le prochain signal de classement fort qui influencera le classement de vos résultats de recherche.

Prêt pour la mise à jour de l'expérience de page Google?

D'après l'étude la plus complète à ce jour de Google, 95 % des déploiements réels de politique de sécurité du contenu (CSP) sont contournés et 99,34 % des hôtes dotés de politiques CSP utilisent des politiques qui n'offrent aucun avantage contre XSS.

C'est pourquoi Google suggère que le modèle de désignation de la confiance en spécifiant des listes blanches d'URL à partir desquelles les scripts peuvent s'exécuter soit remplacé par une approche basée sur des nonces et des hachages, déjà définis par la spécification CSP et disponibles dans les principales implémentations de navigateurs. D'où le nom CSP strict.

Dans le cadre d'une Single Page App (SPA) comme le framework Next.js React, nous devons utiliser un CSP basé sur Hashed afin d'intégrer correctement un CSP strict qui offrira une réelle protection contre les attaques CSS.

Selon la complexité de votre application, l'intégration d'une politique de sécurité du contenu basée sur le hachage peut être triviale et nécessiter de nombreuses manipulations de code. C'est pourquoi je suis venu créer un package sur NPM spécialement conçu pour Next.js afin de permettre aux développeurs d'intégrer un CSP strict en un clin d'œil avec seulement quelques lignes de code.

 est un générateur de politique de sécurité stricte du contenu basé sur le hachage pour Next.js qui s'intègre facilement dans le fichier 

 de votre application Next.js. Une fois en production, il injectera automatiquement les hachages dans la balise méta de la politique de sécurité du contenu et se protégera contre XSS une fois déployé et mis en cache sur le CDN.



Voici un exemple de _document.tsx avec une intégration basique de next-strict-csp :


Une fois mis en production, vous obtiendrez une balise méta de politique de sécurité du contenu qui ressemble à ceci:


Avec un CSP strict, vous devez également hacher vos scripts en ligne. Cela pourrait être facilement réalisé avec next-strict-csp en intégrant vos scripts en ligne dans un tableau comme celui-ci dans _document.tsx:


Une fois en ligne, vos hachages de scripts en ligne seront injectés dans la balise méta de la politique de sécurité du contenu comme ceci :

J'espère que vous avez apprécié next-strict-csp et n'hésitez pas à laisser un commentaire pour me dire ce que vous en pensez.

Comment déployer une politique de sécurité de contenu (CSP) stricte avec Next.js

next-strict-csp

Dernier mot

Commentaires:

Partagez:

Autres articles

Next.js : L'ultime aide-mémoire du rendu de page

Prêt pour la mise à jour de l'expérience de page Google?