Qu'est-ce que le prerendering (prérendu) ?

Qu'est-ce que le prerendering ?

Le prerendering (prérendu) consiste à générer le HTML final d'une page avant la requête, généralement au moment du build, pour que le navigateur ou le robot d'exploration reçoive un balisage lisible plutôt qu'une coquille JavaScript vide. Une application monopage obtient ainsi un premier affichage plus rapide et un contenu indexable sans rendu à chaque requête. Dans cette fiche, le mot désigne ce sens « au build » ; il est proche de la génération de sites statiques et se situe entre le rendu côté client et le rendu côté serveur. Voir rendu pour tout le spectre.

Fonctionnement

Une étape de build exécute votre application pour une liste de routes, attend l'apparition du contenu et enregistre le HTML obtenu pour chaque URL. Un CDN sert ces fichiers. Dans le navigateur, la page s'affiche immédiatement, puis JavaScript prend le relais par l'hydratation. Si le contenu d'une route change souvent, la régénération statique incrémentale reconstruit les pages après un délai fixé ou à la demande, plutôt qu'à chaque déploiement.

Variantes et usages

• Prérendu au build. Un fichier HTML par route, produit pendant le build. Idéal pour les pages marketing, les blogs et la documentation. Limite : tout changement de contenu exige un nouveau build.
• Régénération. Les pages sont statiques mais rafraîchies après un délai ou à la demande. Idéal pour les catalogues et articles qui changent de temps en temps.
• Prérendu dynamique. Un service rend les pages pour les robots pendant que les internautes reçoivent l'application normale. Google qualifie le rendu dynamique de solution de contournement, non recommandée, et conseille plutôt le rendu côté serveur, le rendu statique ou l'hydratation. Il ne le considère généralement pas comme du cloaking tant que robots et utilisateurs reçoivent un contenu similaire.

L'autre sens : le prérendu dans le navigateur

Dans le navigateur, une règle prerender de la Speculation Rules API demande à un navigateur compatible de charger et d'exécuter, dans un onglet caché, la page suivante la plus probable pour que la navigation paraisse instantanée. C'est une autre technique, avec un autre objectif, décrite dans prefetch des ressources et chargement spéculatif. Selon MDN, elle est limitée par défaut à la même origine et déconseillée pour les pages dont les actions serveur ont des effets de bord, comme la déconnexion ou l'ajout au panier.

Pourquoi c'est important pour la performance et le SEO

• Premier affichage plus rapide. Le navigateur reçoit un balisage qu'il peut afficher sans attendre que JavaScript charge et rende le contenu, ce qui aide en général le Largest Contentful Paint.
• Contenu explorable. Les moteurs de recherche lisent le contenu dès la première réponse HTML.
• Peu coûteux à servir. Les fichiers statiques se mettent bien en cache sur un CDN et coûtent peu par requête.

Erreurs fréquentes

• Figer des données personnelles dans le HTML. Noms, paniers et préférences relèvent du code client après le chargement, jamais d'une page partagée par tous.
• Pages périmées. Un cache trop long ou un rebuild manquant laisse les utilisateurs devant un contenu ancien.
• Écarts d'hydratation. Des dates, identifiants aléatoires ou formats de langue qui diffèrent entre le build et le navigateur provoquent des avertissements et de nouveaux rendus.
• Métadonnées absentes. Titre, description, canonical et données structurées doivent aussi figurer dans le HTML prérendu.
• Prérendre des pages connectées. Utilisez le rendu serveur ou client pour tout ce qui varie selon l'utilisateur.

Tester les pages prérendues

Vérifiez la page telle que les utilisateurs la reçoivent : via votre CDN, depuis plusieurs régions, cache activé. La surveillance de la vitesse des pages de LoadFocus lance des audits Lighthouse planifiés et suit le Largest Contentful Paint et d'autres Core Web Vitals dans le temps. Si vous régénérez des pages à la demande, un test de charge montre si ce point d'accès tient sous le trafic. Plus de détails dans tests de charge des applications monopages.

Questions fréquentes : prerendering

Le prerendering est-il identique au SSR ?

Non. Le SSR rend à chaque requête, le prerendering rend à l'avance, au build ou selon un calendrier. Les deux envoient du HTML au navigateur, mais la fraîcheur et le cache diffèrent.

Est-ce la même chose que la génération de sites statiques ?

Le prérendu au build et la génération de sites statiques sont presque la même chose. Le terme sert aussi pour les services dynamiques et pour la fonction du navigateur : vérifiez donc ce que vise chaque source.

Google a-t-il encore besoin du prerendering ?

Google sait exécuter JavaScript, mais envoyer du HTML terminé est plus simple et plus fiable, et d'autres robots gèrent parfois moins bien JavaScript. Pour un nouveau projet, Google recommande le rendu serveur ou statique plutôt que le rendu dynamique.

Puis-je prérendre des pages pour des utilisateurs connectés ?

Non. Un contenu qui varie selon l'utilisateur ne doit pas figurer dans un HTML partagé. Rendez-le sur le serveur à chaque requête ou côté client après le chargement.