Améliorer les Core Web Vitals : l'ordre qui aide vraiment

Activer un plugin de cache est la première étape, et souvent la seule qui soit franchie. Ensuite, la valeur affiche « À améliorer » et y reste. La raison : les trois indicateurs mesurent trois choses différentes, et le cache n'aide vraiment que pour l'une d'elles.

Les trois valeurs, en une phrase chacune

L'ordre en découle : d'abord les images, puis les scripts, puis la mise en page. Le cache agit surtout sur le temps de réponse du serveur — donc sur une partie du LCP, et presque pas sur l'INP.

Étape 1 : la plus grande image

Sur la plupart des pages, l'image d'en-tête est l'élément candidat au LCP. Trois mesures aident immédiatement, dans cet ordre :

1. Réduire l'image à la taille réellement nécessaire — une photo de 4000 pixels de large dans une zone de 1200 pixels de large est la cause isolée la plus fréquente.
2. La convertir dans un format moderne (WebP ou AVIF), avec une solution de repli pour les anciens navigateurs.
3. NE PAS la charger en lazy-load. L'image tout en haut doit être chargée immédiatement — ici, le lazy-load dégrade la valeur au lieu de l'améliorer.

Vérifiez où la conversion a lieu. Certains plugins envoient pour cela vos images à un service de l'éditeur. Qui ne le souhaite pas a besoin d'un outil qui convertit en local — le premier passage prend alors plus de temps, mais rien ne sort de chez vous.

Étape 2 : le JavaScript

L'INP est la valeur pour laquelle le cache n'aide pas. Il mesure le temps dont le navigateur a besoin pour réagir à un clic — et ce qui le bloque, ce sont les scripts qui travaillent précisément à ce moment-là.

Le levier le plus efficace, c'est la suppression : un slider que personne n'utilise ; une fenêtre de chat sur chaque page ; trois familles de polices dont deux passent inaperçues. Ce n'est qu'ensuite que defer, le regroupement et le report jusqu'à la première interaction valent la peine.

Étape 3 : supprimer les sauts

• Chaque image a besoin de width et height dans le balisage — le navigateur réserve alors l'espace
• Placer les contenus intégrés dans un conteneur de hauteur fixe
• Servir les polices en local et les piloter avec font-display, au lieu de les charger depuis l'extérieur
• Intégrer bannières de cookies et barres d'information de façon qu'elles recouvrent le contenu au lieu de le décaler

Ensuite seulement : cache, Minify, préchargement

Un cache de pages évite de générer la page — c'est beaucoup quand le serveur est lent, et peu quand il est rapide. Minify économise des octets et c'est la cause la plus fréquente de pages cassées après une optimisation. Le préchargement est un ordre, pas une demande : trop de préchargements évincent précisément ce dont on a besoin en premier.

Activez les options Minify une par une et vérifiez à chaque fois une page avec formulaire, le panier et une page avec vidéo. Qui active tout d'un coup doit, en cas d'erreur, chercher parmi dix interrupteurs.

Bien mesurer

Il faut distinguer deux types de mesures. Un test en laboratoire mesure dans des conditions fixes et convient bien pour comparer l'avant et l'après. Les données de terrain proviennent de vrais visiteurs, avec de vrais appareils et de vraies connexions — ce sont elles qui déterminent comment Google évalue la page.

D'où ces règles : toujours mesurer dans les mêmes conditions, trois fois plutôt qu'une, et savoir que les données de terrain mettent des semaines à refléter un changement. Qui regarde au bout d'une heure sans rien remarquer n'a pas trop peu optimisé, mais regardé trop tôt.

Quand le plugin n'aide plus

Il existe une limite au-delà de laquelle aucun plugin de cache ne peut plus rien : un constructeur de pages surchargé avec trente scripts, un hébergeur avec une charge de base élevée, un thème qui charge tout sur chaque page. Si la réponse du serveur est déjà lente sans contenu, le plugin n'y est pour rien.

Questions fréquentes