Mardi dernier, un fondateur de SaaS m’envoie un message Slack : « On vient de passer en App Router avec streaming, c’est censé être plus rapide, mais notre LCP sur mobile a doublé. On a raté quoi ? ». Ce qu’on a trouvé dans les traces réseau et les rapports CrUX illustre un problème plus large : les tendances de rendu les plus discutées du moment ne sont pas magiques. Appliquées sans comprendre comment Googlebot lit une page, elles cassent les signaux qu’elles étaient censées améliorer. Voici ce qu’on a mesuré sur une dizaine de projets ces derniers mois, et pourquoi la hype technique ne remplace jamais un suivi terrain.
Le streaming SSR accélère vos TTFB… et enterre votre LCP
Le principe est séduisant. Plutôt que d’attendre que le serveur génère la totalité du HTML, le streaming envoie des morceaux dès qu’ils sont prêts. Le TTFB chute mécaniquement, Google valide, et tout le monde applaudit la nouvelle architecture. Sauf que le Largest Contentful Paint ne se déclenche pas au premier octet reçu. Il se déclenche quand l’élément le plus grand de la zone visible est entièrement affiché.
Sur les sites que nous avons audités, le contenu principal, souvent une image produit ou un titre large, arrivait dans le troisième ou quatrième chunk. Avant cela, le navigateur recevait la coquille, le header, la navigation, parfois un bouton de CTA. Le LCP restait bloqué plusieurs centaines de millisecondes le temps que le flux livre enfin le morceau utile. Pire, dans les cas où on utilise <Suspense> côté serveur avec un fallback statique, Googlebot capture parfois une version intermédiaire sans l’élément de contenu, ce qui fausse l’évaluation de la page.
Pour une fiche produit e-commerce dont le LCP cible est 2,5 s, on a vu un passage de 2,1 s à 3,9 s après activation du streaming sans repriorisation des chunks. La solution n’est pas de désactiver la fonctionnalité, mais de forcer l’envoi prioritaire du contenu principal en amont, par exemple en utilisant priority dans les Server Components ou en déplaçant le stream critique hors des suspensions inutiles. Sans cette discipline, vous offrez à vos visiteurs un squelette rapide et un contenu lent, ce que la Search Console traduit par une baisse de la vitesse moyenne en champ.
⚠️ Attention : si vous activez le streaming, vérifiez que l’élément responsable du LCP n’est pas encapsulé dans un
<Suspense>avec une limite de chargement tardive. Chrome priorise les ressources, pas votre HTML fragmenté.
React Server Components : quand le rendu zéro JS dégrade l’INP
Le discours officiel : les RSC envoient moins de JavaScript, donc la page devient interactive plus vite. Dans les faits, l’INP ne mesure pas la quantité de JS, mais le délai entre l’interaction utilisateur et le traitement de son événement. Retirer du JS du bundle ne réduit pas mécaniquement ce délai si l’architecture multiplie les composants serveur qui nécessitent un appel réseau pour la moindre mise à jour.
On a mesuré l’INP d’un panier e-commerce dont les lignes étaient rendues côté serveur pour être « plus légères ». Chaque clic sur « augmenter la quantité » déclenchait une requête au serveur pour re-rendre la ligne complète. Résultat : un INP moyen de 360 ms, contre 140 ms avec une gestion locale de l’état via Zustand. Moins de JS, oui, mais plus de latence réseau, ce qui pèse directement sur l’interactivité perçue.
Le piège, c’est de croire qu’il suffit d’adopter la tendance pour gagner en performance. Sans analyse fine de chaque interaction utilisateur, vous déplacez simplement la dette technique du navigateur vers le réseau, et l’INP vous le rappelle dans les rapports CrUX.
Rendu à la périphérie : des promesses de latence, des réalités de crawl
Déployer ses fonctions sur la edge promet des TTFB sous les 100 ms partout dans le monde. La promesse tient quand l’utilisateur est proche du point de présence. Mais Googlebot, lui, crawle depuis certaines plages IP, principalement basées aux États-Unis. Si votre logique edge renvoie un contenu différent selon la géolocalisation ou que votre fonction edge la plus proche du bot est sous-provisionnée, le temps de réponse vu par Google varie fortement d’un crawl à l’autre.
On a suivi un site média dont le TTFB mesuré par le robot oscillait entre 110 ms et 820 ms selon l’heure de la journée, parce que la fonction edge qui assemblait les articles était déployée dans une seule région mal dimensionnée. Cette variabilité a entraîné une baisse du crawl budget alloué, visible dans les logs serveur en comparant le nombre de requêtes Googlebot avant et après migration.
📌 À retenir : le rendu edge n’est pas une baguette magique pour les signaux de classement. Si vous ne mesurez pas le TTFB côté bot (via l’API CrUX ou des agents de monitoring qui simulent Googlebot), vous naviguez à l’aveugle.
Partial Prerendering, l’indexation en suspens
Le Partial Prerendering (PPR) combine le pré-rendu statique d’une coquille et le remplissage dynamique du contenu restant au premier chargement. Le résultat visuel est bluffant pour un humain. Pour un moteur de recherche dont le budget de rendu JavaScript n’est pas infini, c’est une coquille vide qui traîne dans les caches.
Plusieurs sites Next.js 14 utilisant PPR pour leurs fiches produit ont observé une chute d’indexation sur Google Image Search, car les images principales n’apparaissaient qu’après exécution du JavaScript côté client. Googlebot mobile les voit parfois, mais pas systématiquement. Et dans tous les cas, le contenu textuel n’est pas présent dans le HTML initial, ce qui oblige le moteur à dépenser du budget de rendu supplémentaire pour reconstituer la page. À grande échelle, ça dilue le crawl des autres URLs.
Le remède immédiat consiste à pré-générer le contenu critique en amont, quitte à limiter le PPR aux zones non essentielles. Le piège du « tout dynamique » est de sacrifier la découvrabilité pour un confort de développement.
State management : un levier sous-estimé pour vos Core Web Vitals
On parle beaucoup de frameworks et de rendu, rarement de ce qui se passe dans le navigateur après le chargement. Pourtant, un INP dégradé trouve souvent sa source dans une cascade de re-rendus provoqués par une gestion d’état globale trop bavarde.
Migrer d’un state manager lourd à une librairie comme Zustand a réduit le temps de traitement des événements de 40 % sur un tableau de bord SaaS que nous avons accompagné. La raison : Zustand évite les abonnements larges et limite les re-rendus au strict nécessaire, ce qui diminue le travail du thread principal lors des interactions. Moins de JS exécuté par clic, c’est un INP qui respire.
Bien sûr, d’autres facteurs jouent. Mais quand on parle de performances web, on ne peut pas s’arrêter à la couche de rendu. L’architecture interne d’une application, y compris la gestion d’état, contribue directement aux mesures de terrain que Google agrège via Chrome User Experience Report.
Mesurer avant, pendant, après : la seule tendance qui vaille
Les nouveautés techniques arrivent plus vite que la capacité des équipes à les auditer. C’est normal. Ce qui l’est moins, c’est d’adopter un nouveau pattern de rendu sans instrumenter ses Core Web Vitals avant la migration, puis de se fier uniquement à un audit Lighthouse ponctuel. Lighthouse simule, les données de terrain condamnent.
Disposer d’un monitoring continu qui compare le LCP, l’INP et le TTFB en champ avant et après chaque déploiement permet d’identifier précisément ce qui a cassé. Sur une migration vers l’edge, on a par exemple isolé un ralentissement du TTFB de 170 ms lié à une configuration DNS non optimisée. Sans la courbe de monitoring, on aurait cherché dans le code de l’application pendant des jours.
L’automatisation du suivi technique offre aussi un garde-fou contre l’engouement pour les tendances. Plutôt que de se demander « est-ce que cette techno est à la mode ? », on se demande « est-ce qu’elle améliore les métriques mesurées sur nos utilisateurs réels ? ». La réponse est souvent différente de ce que laissent entendre les annonces de conférences. Pour creuser l’écart entre le discours et les faits, j’ai comparé les deux outils de code assisté par IA les plus populaires pour automatiser la détection de régressions de performance directement dans la CI, Claude Code et Cursor. L’un et l’autre permettent de générer des assertions Lighthouse en pull request, mais leur intégration dans un pipeline de monitoring Core Web Vitals n’est pas équivalente.
Questions fréquentes
Est-ce que l’edge computing améliore toujours les Core Web Vitals ?
Non. L’edge réduit la latence réseau pour les utilisateurs proches des points de présence, mais peut dégrader le TTFB vu par Googlebot si la fonction edge est éloignée du robot ou sous-provisionnée. La variabilité géographique introduite par l’edge exige un monitoring spécifique côté bot pour ne pas perdre en crawl budget.
Faut-il éviter les React Server Components pour préserver son INP ?
Pas nécessairement. Les RSC réduisent le JavaScript envoyé, ce qui est favorable à l’INP si les interactions restent locales. Le risque apparaît quand une interaction banale (clic sur un bouton, saisie) déclenche systématiquement un aller-retour serveur. Il est alors plus efficace de traiter l’état dans le navigateur avec une librairie légère.
Comment vérifier que le streaming ne décale pas mon LCP ?
Ouvrez les DevTools, onglet Performances, et examinez la timeline de parsing HTML lors d’un chargement ralenti (throttling 3G). Si l’élément LCP n’apparaît qu’en fin de flux, vous devez réorganiser vos composants pour le placer dans les premiers chunks envoyés.
