Qu'est-ce que le Prerendering ?

Qu'est-ce que le prerendering ?

Le prerendering est la technique de générer du HTML entièrement rendu pour des URLs spécifiques à l'avance — au moment du build, à la demande au moment de la requête, ou planifié — pour que lorsqu'un navigateur ou un crawler demande la page il reçoive du markup prêt à peindre au lieu d'un shell SPA vide qui a besoin de JavaScript pour se peupler. Le prerendering se situe entre le Server-Side Rendering complet (SSR, qui rend à chaque requête) et le Client-Side Rendering pur (CSR, qui ne rend que dans le navigateur). Il résout le problème SEO + first-paint des applications single-page sans assumer la complexité opérationnelle de SSR.

La technique a plusieurs saveurs qui sont confondues dans la conversation. Le prerendering statique (build-time, aussi appelé SSG) génère un fichier HTML par route pendant le pipeline de build — les sorties vont à un CDN. Le prerendering dynamique (request-time, souvent via des services comme Prerender.io ou Rendertron) détecte le trafic des bots et sert un cache pré-rendu tandis que les utilisateurs réguliers obtiennent le SPA. Le prerendering hybride mélange les deux — pré-rendre les routes les plus visitées statiquement, se replier sur SSR ou CSR pour les routes long-tail.

Les trois stratégies de prerendering

1. Prerendering statique / SSG (build time)

Générer du HTML pour chaque route pendant le déploiement. Outils : getStaticProps de Next.js, Gatsby, Astro, adaptateur statique de SvelteKit, generate statique de Nuxt. Meilleur pour le contenu qui ne change pas par requête : pages marketing, blogs, docs, listings de catégories e-commerce. Limitation : rebuild requis pour les changements de contenu.

2. Prerendering dynamique (request-time, ciblé bots)

Le serveur détecte le User-Agent (Googlebot, Bingbot, crawlers sociaux) et les route vers un cache rendu par Chrome headless. Les utilisateurs réguliers obtiennent toujours le SPA. Outils : Prerender.io, Rendertron, Puppeteer personnalisé + cache. Meilleur pour : SPAs legacy que vous ne pouvez pas refactorer en SSR, mais avez besoin de SEO. Limitation : viole la préférence de Google pour la parité (humains vs. crawlers devraient voir le même contenu).

3. Incremental Static Regeneration (ISR)

Hybride : les pages sont statiques mais se régénèrent en arrière-plan après un TTL ou à la demande. Next.js, Astro et Nuxt 3 le supportent. Meilleur pour : contenu qui change occasionnellement (pages produit, articles d'actualité, listings). Combine la vitesse SSG avec la fraîcheur SSR.

Prerendering vs. SSR vs. CSR — quand utiliser lequel

Pourquoi le prerendering compte pour la performance + SEO

• TTFB / LCP plus rapides. Le HTML pré-rendu frappe le navigateur prêt à peindre. Pas de cycle téléchargement JS + exécution + fetch + render.
• Meilleurs scores Core Web Vitals. LCP mesure le plus grand paint above-fold. Le contenu pré-rendu peint généralement plus vite que le contenu monté par SPA. Bénéfice direct de signal de ranking.
• HTML crawlable. Les moteurs de recherche parsent le contenu du HTML initial, pas après l'exécution JavaScript. Supprime le risque de goulot de rendering dans le crawl en deux passes de Googlebot.
• Cache-friendly. Le HTML statique se cache partout — edges CDN, navigateur, proxies intermédiaires. Les réponses SSR sont généralement par utilisateur, ne peuvent pas être cachées aussi agressivement.
• Offline-friendly. Les pages pré-rendues peuvent être cachées par les service workers pour l'accès hors ligne.

Erreurs courantes de prerendering

• Pré-rendre du contenu personnalisé. Les données spécifiques à l'utilisateur (nom, préférences, panier) ne devraient pas être dans le HTML statique. Hydratez-les côté client après le mount.
• Contenu pré-rendu obsolète. Si votre TTL est trop long, les utilisateurs voient des infos périmées. Ajustez ISR / cache-control agressivement.
• Cloaking via prerendering dynamique. Servir à Googlebot une version entièrement rendue tandis que les utilisateurs obtiennent un shell lent peut violer les directives de cloaking de Google si le contenu diffère.
• Mismatchs d'hydratation. Le HTML pré-rendu et le rendu côté client doivent correspondre exactement, sinon React/Vue lance des avertissements + re-rend. Vérifiez le contenu non-déterministe (Date, IDs aléatoires, formatage spécifique à la locale).
• Bloat de build time. Pré-rendre statiquement 100 000 routes peut prendre des heures. Utilisez ISR pour la longue traîne ; statique pour le top 5 000.
• Oublier les métadonnées. Le prerendering devrait peupler title, meta description, og:image, JSON-LD — pas juste le contenu du body.

FAQ : Prerendering

Le prerendering est-il la même chose que SSR ?

Non. SSR rend à chaque requête (côté serveur), le prerendering rend à l'avance (build ou planifié). Les deux produisent du HTML pour le navigateur, mais avec différents trade-offs de caching + fraîcheur.

Google a-t-il encore besoin de prerendering en 2026 ?

Moins qu'avant — Googlebot exécute maintenant JavaScript. Mais : le rendering est la phase goulot du crawl de Google ; le HTML pré-rendu est indexé plus rapidement et plus fiablement. D'autres crawlers (Bingbot, réseaux sociaux, scrapers d'entraînement LLM) gèrent moins bien JS, donc le prerendering paie toujours.

Quelle est la différence entre prerendering et static site generation (SSG) ?

SSG est une forme de prerendering — spécifiquement la variante build-time. Le prerendering est le concept plus large qui couvre aussi les approches dynamiques et incrémentales.

Devrais-je utiliser Prerender.io ou reconstruire avec SSG ?

Prerender.io est une solution temporaire pour les SPAs legacy qui ne peuvent pas être refactorées. Si vous pouvez reconstruire sur Next.js, Astro ou SvelteKit avec leur SSG/ISR natif, c'est presque toujours la meilleure réponse à long terme.

Comment le prerendering affecte-t-il le temps de déploiement ?

Pour SSG avec des milliers de routes, le temps de build peut exploser (heures). Stratégies : builds parallèles, cacher les artefacts de build, ISR pour la longue traîne (ne construire que les routes top statiquement + régénérer le reste à la demande).

Puis-je pré-rendre des pages authentifiées ?

Ne le faites pas — l'état d'auth est par utilisateur, et servir le même HTML statique à tous les utilisateurs fuit des informations ou casse la personnalisation. Utilisez SSR ou CSR pour le contenu protégé par auth.

Comment LoadFocus se rapporte au prerendering

Le prerendering améliore LCP et TTFB, mais les gains n'apparaissent que si votre setup CDN + caching sert correctement le HTML pré-rendu. Les tests de vitesse de site web LoadFocus valident que les routes pré-rendues atteignent réellement les objectifs Core Web Vitals (LCP ≤2,5s, INP ≤200ms, CLS ≤0,1) en production. Les tests de charge valident que le flux de régénération (ISR, prerender dynamique) tient sous trafic — le mode d'échec courant est que le régénérateur est surchargé pendant les scénarios cache-stampede.