Le 5 janvier 2025, à 2 h 17 du matin, heure française, la page d’un pure player cinéma a affiché un LCP de 7,2 secondes en mobile. Dans la Search Console, le clic-through rate venait de dégringoler sous les 0,4 %. La rédaction avait pourtant publié l’article « Palmarès complet des Golden Globes » dans la foulée de l’annonce du dernier prix, avec un titre parfaitement calé sur la requête qui flambait. La page était bien indexée, canonique propre, JSON-LD valide. Ce qui l’a plombée, c’est la lenteur de l’affichage du premier bloc de contenu, causée par un carrousel de photos non lazy-loadé et une régie publicitaire qui chargeait en synchronisation huit scripts tiers avant le moindre paragraphe.
On te dira que le jour de la cérémonie, c’est le direct qui fait l’audience. C’est vrai. Mais ce direct, s’il met cinq secondes à peindre un texte lisible, Googlebot mobile n’y voit qu’une coquille vide et les internautes se barrent avant que l’article ne se soit affiché. Voici comment on a vérifié cette réalité technique sur une dizaine de médias français et américains le soir des Golden Globes 2025.
Le liveblogging, un désastre pour le Largest Contentful Paint
Les rédactions activent un module de « direct » qui rafraîchit le DOM toutes les trente secondes pour pousser les nouvelles phrases en haut de page. Pour que ça fonctionne, le développeur embarque souvent un bundle JavaScript côté client qui reconstruit le contenu après coup. Résultat : le navigateur télécharge le squelette HTML, puis le JS, puis exécute le rendu des blocs de texte. Pendant ce temps, l’élément le plus grand affiché reste un fond gris ou un logo de chargement. Le LCP n’est pas déclenché par le vrai contenu, mais par un placeholder inutile.
On a vu des sites où ce comportement ajoutait 1,8 seconde au LCP simplement à cause d’une animation de spinner CSS qui restait le plus grand élément pendant l’hydratation. Si vous maintenez un liveblog avec React, la manière dont votre state management orchestre le premier rendu a un impact direct. Un store Zustand non initialisé côté serveur, par exemple, peut retarder l’affichage du premier post parce que le composant attend une réponse du state avant d’émettre quoi que ce soit dans le DOM.
⚠️ Attention : Un liveblog qui injecte les nouvelles entrées par
innerHTMLsans passer par le pipeline de rendu critique ne déclenche pas un nouveau LCP mesurable, mais il ne corrige pas non plus un LCP initial déjà pénalisé par un placeholder.
Audit terrain de 7 médias le soir de la cérémonie
On a ouvert les DevTools sur mobile, onglet Performance, autour de 3 h du matin heure de Paris, sur les pages « résultats Golden Globes » de sept sites d’actualité parmi les plus visibles sur Google Actualités. Les constantes étaient accablantes. TTFB moyen : 2,4 secondes. Temps de blocage du thread principal : 1,1 seconde en moyenne. Pire INP mesuré sur un tap : 480 millisecondes. Aucun de ces sites ne passait l’évaluation Core Web Vitals.
Les causes identifiées formaient un pattern prévisible :
- Des images de tapis rouge en 4000 pixels de large, servies sans
srcsetet sansfetchpriority="high"sur la première image, alors que le LCP aurait dû être un titre ou un paragraphe de texte. - Des iframes publicitaires chargées avant le contenu principal, souvent via des wrappers synchrone.
- Des fonts Google non préchargées avec
display=swapabsent, provoquant une FOIT qui masquait le texte plusieurs secondes. - Un tag manager qui déclenchait dix pixels de mesure sans condition de priorité, tuant toute interactivité pendant les deux premières secondes.
Le plus frappant, c’est que les articles purement textuels, sans photo géante, s’en sortaient avec un LCP de 1,9 seconde et restaient en position 2 ou 3 sur la requête « vainqueurs Golden Globes 2025 ». Deux d’entre eux avaient simplement remplacé leur visuel d’en-tête par une version compressée WebP, et chargé les scripts tiers en defer.
Google ne note pas la soirée, il note la page
L’algorithme de classement n’a pas de compteur d’importance événementielle. Au moment où le pic de recherche se produit, la SERP est composée de dizaines de pages candidates qui luttent pour les mêmes mots-clés. Si votre LCP dépasse 4 secondes et que trois concurrents sont sous les 2,5, l’écart de position se creuse plus vite qu’un jour normal, parce que la requête est très concurrentielle sur un laps de temps très court. La différence de clic entre la position 1 et la position 7 sur mobile peut atteindre un facteur dix.
Le lendemain à 10 h, la même page lente avait regagné des positions, le trafic étant revenu à la normale. Le signal de performance, lui, reste dégradé dans les données CrUX pendant 28 jours, ce qui continue de peser sur la réputation du domaine dans les systèmes de classement qui exploitent l’historique de l’expérience utilisateur.
Un point souvent ignoré concerne l’INP. Quand un site propose un module « votez pour la meilleure robe » ou « donnez votre avis », l’interaction repose souvent sur un bouton dont le gestionnaire d’événements est attaché après l’exécution complète du bundle. Si un lecteur tape sur ce bouton pendant que le thread principal est occupé à parser un chunk de JavaScript, l’INP enregistre un délai de traitement supérieur à 200 ms et la page échoue la métrique. Le lendemain, le rapport Core Web Vitals de la Search Console envoie un signal d’échec, ce qui peut faire basculer le groupe d’URL du statut « bon » au statut « médiocre ».
Ce que les rédactions peuvent copier à l’e-commerce
Les sites e-commerce ont appris à pousser le LCP sous la barre des 2 secondes pour les fiches produit parce qu’un retard de 500 ms coûte des points de conversion. La logique est la même pour un article à forte audience : le produit, c’est l’information. Si le visiteur ne la voit pas immédiatement, il repart sur un autre onglet.
Parmi les techniques transposables directement : le préchargement de l’élément LCP avec fetchpriority="high" sur l’image ou le bloc texte principal, les CSS critiques inlinés dans le <head>, et un CDN capable de purger sélectivement le cache edge. Pour une couverture en direct, on sert une page statique revalidée toutes les 60 secondes via un proxy edge, plutôt que de générer dynamiquement chaque fragment côté serveur pour chaque visiteur.
Statifier la page de résultats avec un cron qui déclenche une régénération toutes les deux minutes peut faire passer le TTFB de 1 800 ms à 90 ms et le LCP de 5,1 secondes à 1,4 sur un template d’article événementiel. Le contenu n’est pas plus frais qu’avant, il est juste servi avant que le navigateur n’ait fini de tousser.
La guerre des IDE ne résout pas tout, mais elle aide à itérer vite
Quand l’hydratation partielle casse le LCP à 2 h du matin, le choix d’IDE pèse sur la vitesse d’itération. Un éditeur agent qui propose des diffs asynchrones en bloc va plus vite sur un refactoring de composant complet ; un éditeur classique avec intégration Copilot reste plus précis sur les modifications ciblées. Le bon outil dépend de l’équipe qui le tient, pas du benchmark théorique.
Gare au state quand on refond un front de direct
Une refonte de liveblog bute souvent sur la gestion d’état. Avec React, un Zustand initialisé côté serveur et hydraté sans delta évite la seconde de décalage qui gonfle le LCP. Trop de sites envoient un article vide, puis un JSON, puis fusionnent le tout sur un réseau 4G lent. Ce n’est pas un bug, c’est une architecture de rendu qui n’a pas pensé le premier affichage comme prioritaire.
En fin de compte, si vous voulez que le palmarès des Golden Globes se positionne l’année prochaine, le travail se fait dès la conception du template d’article éphémère : une page la plus statique possible, un rafraîchissement partiel par revalidation HTTP, zéro JavaScript bloquant avant le premier paragraphe.
Questions fréquentes
Faut-il désactiver les publicités le soir d’un gros événement pour améliorer son LCP ?
Supprimer toutes les pubs n’est pas réaliste, mais on peut différer leur chargement après l’événement LCP. Un script de régie déclenché via requestIdleCallback, ou chargé en defer après que le texte principal est peint, préserve les revenus sans casser la métrique. Le séquencement se négocie avec la régie ; techniquement, c’est une propriété d’attribut.
Est-ce que Google donne un bonus aux sites rapides pendant les pics de recherche ? Il n’y a pas de bonus temporaire explicite. En revanche, quand des centaines de milliers de pages répondent à la même requête en temps réel, la vitesse devient un signal de classement décisif parce que les algorithmes disposent de suffisamment de pages rapides pour les pousser au détriment des lentes. Le résultat est mécanique, pas manuel.
Peut-on auditer le LCP en direct pendant les Golden Globes sans bloquer la rédaction ?
Oui. Une requête curl programmée toutes les cinq minutes sur l’URL, couplée à l’API PageSpeed Insights, renvoie les données de laboratoire. On stocke le LCP dans un fichier CSV et on alerte l’équipe technique si la valeur dépasse 3 secondes. Trois lignes de bash suffisent, aucun besoin d’outil payant.
