Core Web Vitals pour un site de contenu : les vrais leviers

Notre page d’accueil a obtenu 99 au test de performance mobile de Lighthouse le 7 octobre 2026 (médiane de 3 passages), avec un Largest Contentful Paint de 1 605 ms, et une page de guide a obtenu 100 et affiché son plus grand élément en 1 513 ms. Ces chiffres viennent d’un site en HTML statique, avec des polices locales, une seule feuille de style et aucun script tiers sur les pages de guide. C’est la leçon principale de ce guide : sur un site de contenu, les Core Web Vitals se jouent surtout sur ce que l’on refuse d’ajouter.

Les trois seuils, et ce que Google ne dit pas

Chacune des trois métriques a un seuil fixe : ce sont les chiffres que publie web.dev.

Google les juge au 75e centile des chargements de page, séparément pour le mobile et l’ordinateur. Concrètement, trois visites sur quatre doivent afficher le plus grand élément en 2,5 s ou moins pour que la page réussisse sur le LCP. Un passage rapide sur votre propre ordinateur portable prouve peu, car le quart des visites situé du côté lent est celui qui décide.

La documentation de Google dit que ces métriques sont alignées sur ce que ses systèmes de classement cherchent à récompenser. Elle ne dit pas quel poids elles pèsent face à la pertinence du contenu, et personne en dehors de Google ne peut fournir ce chiffre. Notre lecture : passer les seuils, puis s’arrêter, parce que la vitesse ne remplace pas une page qui répond à la requête.

Deux sortes de données existent. Les données de terrain viennent de vrais visiteurs et alimentent le rapport Core Web Vitals de la Search Console. Les données de laboratoire, issues d’outils comme Lighthouse, viennent d’une visite simulée et servent au débogage. Un site récent avec peu de trafic peut n’avoir aucune donnée de terrain à montrer : le laboratoire est donc le point de départ de la plupart des petits sites.

Nos chiffres, et jusqu’où s’y fier

Voici les résultats Lighthouse mobile de deux pages de ce site, mesurés le 7 octobre 2026.

La page d’accueil a obtenu 96, 99 et 100 sur les 3 passages, avec un Total Blocking Time de 0 ms dans 2 d’entre eux et de 174 ms dans le dernier ; la page de guide a obtenu 100 à chaque fois. Le TBT est une métrique de laboratoire souvent utilisée comme substitut de la réactivité, mais ce n’est pas l’INP. Notre serveur envoie le premier octet d’une page de guide en environ 85 ms (médiane de 7 requêtes curl depuis notre machine, connexion comprise). Les deux pages se décalent à peine, 0,002 et 0,000 face au budget de 0,1. Une page avec une photo d’en-tête et des polices web est l’endroit où nous regarderions d’abord si ce chiffre augmentait.

Pour obtenir des chiffres comparables sur vos propres pages, lancez Lighthouse en ligne de commande, ce qui facilite la comparaison de passages répétés :

npx lighthouse https://example.com/ --only-categories=performance --form-factor=mobile --view

Lisez ces résultats comme des résultats de laboratoire. Le profil mobile de Lighthouse simule un téléphone et un réseau plus lents, et un passage par défaut sur un chargement de page ne mesure pas du tout l’INP, puisque l’INP exige de vraies interactions. Ces chiffres disent que nos pages sont légères. Ils ne disent pas que des visiteurs sur des téléphones lents réussissent au 75e centile, et nous n’avons aucun rapport de terrain à citer.

Six leviers pour un site fait d’articles

1. Faites arriver l’image principale en premier. Sur beaucoup de pages d’article, le plus grand élément est l’image d’en-tête ou le premier titre, et Lighthouse nomme l’élément qu’il a mesuré dans son audit du LCP. Donnez à l’image principale fetchpriority="high", ne la chargez pas en différé et proposez plusieurs largeurs pour qu’un téléphone ne télécharge pas le fichier prévu pour l’ordinateur. Nos images d’en-tête suivent ce schéma, et le balisage figure dans le guide SEO des images.
2. Donnez des dimensions à chaque image. Les attributs width et height, ou un aspect-ratio en CSS, permettent au navigateur de réserver la boîte avant l’arrivée du fichier. C’est le remède classique au décalage de mise en page causé par les images.
3. Servez les polices depuis votre propre domaine. Un hébergeur de polices sur un autre domaine coûte une résolution DNS et une nouvelle connexion avant que le texte puisse utiliser la police. Nous intégrons Inter et Fraunces à la compilation et les servons depuis notre propre chemin /_astro/ avec font-display: swap. Swap affiche le texte tout de suite dans une police de repli mais peut le déplacer quand la police web arrive ; une @font-face de repli avec une valeur size-adjust réduit l’écart. Les fichiers de police sont découpés par écriture : un visiteur ne récupère que les sous-ensembles dont les caractères de la page ont besoin.
4. Livrez peu de JavaScript. Nos pages sont du HTML statique généré à la compilation, et nos pages de guide ne chargent aucun script tiers pour le moment. L’INP dépend d’un fil principal libre quand quelqu’un touche l’écran, et chaque script d’analyse, de chat, de test ou de consentement lui fait concurrence. Mesurez une page avant et après en avoir ajouté un, et renoncez à ceux que vous ne pouvez pas justifier.
5. Réservez la place de ce qui arrive tard. Annonces, contenus intégrés, bannières de consentement et tout ce qu’un script insère exigent une hauteur minimale ou une position en superposition. Le CSS des emplacements d’annonces se trouve dans notre guide du placement des annonces, et il compte doublement : une annonce tardive est le décalage classique, et un script d’annonce est un script tiers.
6. Répondez vite et mettez en cache. Un fichier statique servi par nginx a peu à faire, et notre temps de réponse d’environ 85 ms en témoigne. Compressez le texte, mettez en cache longtemps les ressources à empreinte, et revalidez le HTML pour que les modifications apparaissent tout de suite. Limitez les redirections à un seul saut, car chaque saut en plus est un aller-retour avant le premier octet ; le guide HTTPS montre la chaîne en une étape.

Voici la partie utile de notre configuration nginx :

gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css application/javascript application/json image/svg+xml application/xml;

# Dans le bloc server : le HTML est revalidé à chaque visite
add_header Cache-Control "no-cache" always;

# Les ressources à empreinte ne changent jamais sous le même nom
location /_astro/ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Une règle de nginx vaut la peine d’être connue ici : les directives add_header ne sont héritées du niveau supérieur que si le niveau courant n’en définit aucune. C’est pourquoi le bloc location des ressources peut définir son propre Cache-Control sans hériter du no-cache du bloc server. La même règle fait aussi disparaître les en-têtes de sécurité définis au niveau du serveur, un piège que détaille notre guide des en-têtes de sécurité.

Par où commencer, et quand s’arrêter

Ouvrez PageSpeed Insights sur une page d’article typique, sur l’onglet mobile. S’il affiche des données de terrain, lisez-les d’abord, car c’est ce que Google évalue, puis lisez les résultats de laboratoire en dessous. Corrigez les problèmes les moins coûteux dans cet ordre : poids, dimensions et priorité des images ; polices ; scripts. Aucun ne demande une refonte.

Relancez le test de laboratoire et comparez le résultat aux trois seuils, pas à 100. Laissez ensuite du temps au rapport de la Search Console. Les données de terrain se construisent à partir de vraies visites : une correction n’y apparaît qu’après que des visiteurs ont chargé les pages corrigées, et un site au trafic modeste peut attendre un moment.

Arrêtez-vous quand les trois métriques sont bonnes. Google ne donne aucune pondération : la différence entre 95 et 100 ne vaut pas une journée de travail, et la même journée passée à mieux faire répondre une page à sa requête (vérification de l’intention de recherche) a plus de chances de compter. Notre vérificateur SEO rapporte, pour n’importe quelle page, le temps de réponse du serveur, le poids du HTML, la compression du texte, les dimensions des images et les scripts externes, ce qui couvre les causes de laboratoire des problèmes ci-dessus.