gmbapi : LCP de 5 à 1,9 seconde, réglé en un appel

 Power hour · gmbapi
LCP de 5 à 1,9 seconde, réglé en un appelUne entreprise de SEO local avec un site Next.js tout neuf, rapide sur desktop et lent sur mobile.
1,9sLCP dans CrUX, était à 5 s
150msINP sur mobile, était à 220 ms
700mstemps de réponse serveur, était à 3 s
0,00CLS dans CrUX, était à 0,08
Clientgmbapi, logiciel de SEO local
PlateformeReact, Next.js, CMS headless
ServicePower hour, août 2026
 Le client
Un nouveau site qui passait sur desktop et échouait sur mobilegmbapi est un éditeur de logiciel de SEO local, et un bon. En juillet 2026, ils ont migré de WordPress vers un nouveau site en React et Next.js sur un CMS headless. Sur desktop, les Core Web Vitals passaient. Sur mobile, le LCP, le FCP et l'INP échouaient.
Je connais Michel van Luijtelaar, qui la dirige, depuis 2021. Il m'a demandé de regarder son site WordPress en 2023, puis en 2025. En juillet 2026, il est revenu avec le nouveau.
 Ce que nous avons trouvé, ce que nous avons fait
La mort par mille coupuresIl n'y avait pas un seul gros problème. Ce n'est d'ailleurs presque jamais le cas. Nous avons enregistré le chargement d'une page mobile dans les DevTools, parcouru la trace du premier octet jusqu'au LCP, et corrigé les problèmes au fil de la discussion.
Ce qui n'allait pas
Ce que nous avons fait
TTFB
Le serveur mettait 3 secondes avant de renvoyer le premier octet. Chaque page était rendue à chaque requête et récupérait son contenu en direct depuis le CMS headless. Les en-têtes de cache indiquaient no-store : le CDN ne conservait donc jamais le HTML.
Les pages sont passées en rendu statique avec ISR, les requêtes vers le CMS ont été mises en cache et les en-têtes permettent au CDN de garder le HTML. Le temps de réponse serveur est passé à 700 ms : autant de gagné sur le FCP et le LCP avant même de toucher au reste.
LCPINP
Des tags et scripts analytics dans le head, des widgets tiers en haut de page et des composants rendus par le navigateur alors que le serveur pouvait tout aussi bien s'en charger. Tout ce JavaScript était utilisé ; il s'exécutait simplement trop tôt.
Les tags et les widgets attendent désormais que la page soit affichée, et ces composants viennent du serveur.
LCP
Le hero était en lazy loading. Il passait par next/image sans priority, le bloc CMS imposait loading="lazy" sur toutes les images, et quand le hero était un arrière-plan CSS, le navigateur le découvrait trop tard.
Le hero a reçu priority et fetchpriority="high", le bloc CMS a eu droit à une exception pour la première image, et l'arrière-plan CSS est devenu une vraie balise img avec un preload. Ensemble, cela a retiré 120 ms au LCP.
LCP
Deux feuilles de style, de 30 ko et 0,5 ko, que le premier écran attendait.
Toutes les deux réécrites à 15 ko, ce qui a encore fait gagner 100 ms.
LCP
Beaucoup de petits détails, aucun n'étant majeur en soi.
Nous avons continué à parcourir la trace pour les régler un par un au fil de la discussion.
Dans CrUX
C'est la courbe qu'on espère voir. Le LCP pour leurs visiteurs sur mobile est passé de 5,6 secondes au pire à 2,0, et le temps de réponse serveur de 4,2 à 0,8 seconde. Les deux courbes mettent des semaines à descendre, car chaque point inclut encore les journées lentes de sa fenêtre de 28 jours. Depuis août, le LCP se maintient entre 1,9 et 2,2 secondes.
2,5 s4,0 sFévMarAvrMaiJuinJuilAoûtSepOct3,8 s2,0 s5,6 sLCP sur mobile, p75
0,8 s1,8 sFévMarAvrMaiJuinJuilAoûtSepOct2,0 s0,76 s4,2 sTTFB sur mobile, p75
gmbapi.com dans CrUX, de janvier à octobre 2026. Chaque point correspond aux 28 jours précédant cette date. Le vert correspond à « bon », l'orange à « à améliorer » et le rouge à « médiocre ».
Suivi
Après l'appel, je leur ai donné accès à CoreDash pour qu'ils voient leurs visiteurs sur mobile par page et par release, et j'ai vérifié leur liste de tâches. Les chiffres en haut de page proviennent de CrUX, les propres field data de Google.
Une heure suffit quand les développeurs sont présents lors de l'appel et que les fixes sont légers. Les chantiers plus lourds vont dans les notes, les plus importants d'abord.
 Ce que nous avons appris
Ils soupçonnaient le JavaScript inutiliséUne hypothèse logique sur un nouveau site React. Mais la trace a placé le temps de réponse serveur et un hero en lazy loading tout en haut.
Un nouveau framework ne vous rend pas rapideIls venaient de migrer vers Next.js, avec tous ses réglages par défaut : next/image applique le lazy loading à chaque image tant qu'on ne lui passe pas priority, et leur hero en faisait partie.
 Une heure avec vos développeurs pendant l'appel : 350 €Venez avec votre développeur et votre page la plus lente. Nous la regardons ensemble et corrigeons ce que nous pouvons au fil de la discussion.
Réserver une power hourD'autres résultats sur ma page clients.
Core Web Vitals gmbapi : LCP de 5 à 1,9 seconde, réglé en un appel