« On a compressé toutes les images en WebP, et le LCP ne bouge pas. » C'est sans doute la phrase que j'entends le plus souvent quand un site arrive avec un problème de vitesse. La conversion des images est devenue le réflexe par défaut (un bon réflexe, d'ailleurs), mais elle ne règle qu'une partie du problème. Le Largest Contentful Paint, ce moment où le plus gros élément visible de la page s'affiche enfin, dépend d'une chaîne entière que le format d'image ne touche qu'en surface.
Cet article est le retour terrain de ce qui fait réellement bouger l'aiguille du LCP, une fois que le WebP est déjà en place. Quatre leviers concrets qui pèsent souvent plus lourd que la compression : ne pas lazy-loader l'élément LCP, le prioriser avec fetchpriority et preload, neutraliser le CSS et les polices qui bloquent le rendu, et soigner le temps de réponse du serveur. Avec, à la fin, les réglages spécifiques à WordPress.
Le WebP allège l'image. Mais si le navigateur la découvre trop tard, la télécharge en dernier, ou attend un CSS de 300 Ko avant d'afficher quoi que ce soit, votre LCP reste à 4 secondes. La vitesse perçue est une affaire de priorités, pas seulement de poids.
Avant tout : identifier le vrai élément LCP
On ne peut pas optimiser ce qu'on n'a pas identifié. La première erreur consiste à supposer quel est l'élément LCP au lieu de le mesurer. Sur une page d'accueil, c'est souvent l'image de héros ; sur un article, ce peut être le visuel d'en-tête, un bloc de texte volumineux ou même le titre H1. Le panneau Performance de Chrome DevTools et l'extension Web Vitals affichent précisément quel nœud est retenu comme LCP, et à quel instant il s'affiche.
Cette étape change tout, parce qu'elle redirige l'effort. Inutile d'optimiser dix images si l'élément mesuré est un bandeau d'arrière-plan en CSS, ou un titre qui attend le chargement d'une police web. Avant de toucher quoi que ce soit, je mesure sur données terrain, pas seulement en laboratoire, car le LCP officiel de Google se lit au 75e centile des visites réelles. C'est tout l'enjeu d'un suivi sérieux des Core Web Vitals et de leur impact SEO : agir sur la bonne page, sur le bon élément.
Ne jamais lazy-loader l'image LCP
Voici le contre-sens le plus coûteux que je corrige sur le terrain. Pour gagner en performance, beaucoup de sites, et la plupart des extensions WordPress « tout-en-un », activent le lazy-loading sur toutes les images, sans distinction. Le chargement différé est une excellente technique… pour les images situées sous la ligne de flottaison, celles qu'on ne voit qu'en scrollant. Mais appliqué à l'image LCP, il produit l'effet inverse : on demande explicitement au navigateur de retarder le chargement de l'élément précis que Google chronomètre.
La règle est binaire. L'image principale visible au premier écran doit être chargée en priorité (attribut loading="eager", jamais loading="lazy"), et tout ce qui se trouve en dessous peut, lui, être différé. Sur les sites que je reprends, retirer le lazy-loading de la seule image de héros fait souvent gagner une seconde entière de LCP, sans rien changer d'autre. C'est le réglage le plus rentable du lot : zéro développement, un attribut à corriger.
fetchpriority et preload : dire au navigateur ce qui compte
Par défaut, le navigateur attribue les priorités de téléchargement selon ses propres heuristiques, et il se trompe souvent sur l'image LCP, qu'il considère comme une ressource ordinaire à charger au fil de l'eau. Deux outils permettent de lui forcer la main.
Le premier, fetchpriority="high", se place directement sur la balise de l'image LCP : il indique au navigateur de la télécharger avant les ressources concurrentes. Le second, preload, déclaré dans le <head>, demande au navigateur de commencer à récupérer l'image très tôt, avant même d'avoir fini d'analyser le HTML, particulièrement utile quand l'image LCP est appelée tardivement, en CSS d'arrière-plan ou via un slider. Combinés, ces deux leviers déplacent l'image LCP en tête de file. À l'inverse, je dé-priorise volontairement ce qui n'a pas besoin de l'être (bannières secondaires, scripts tiers, widgets), pour libérer la bande passante au bon moment.
Le CSS bloquant, frein silencieux du LCP
On parle beaucoup d'images, rarement de CSS, et c'est pourtant souvent là que tout se joue. Une feuille de style est, par nature, une ressource bloquante pour le rendu : tant qu'elle n'est pas téléchargée et analysée, le navigateur n'affiche rien. Un thème WordPress chargé d'extensions peut empiler plusieurs centaines de kilo-octets de CSS, dont 90 % ne servent pas à la page en cours. Résultat : le navigateur attend ce gros fichier avant de peindre le moindre pixel, et le LCP s'effondre.
La parade tient en deux mouvements. D'abord, extraire le CSS critique, le strict nécessaire à l'affichage du premier écran, et l'injecter en ligne (inline) dans le <head>, pour que le navigateur peigne immédiatement, sans attendre de fichier externe. C'est exactement la logique du « critical CSS » que vous voyez à l'œuvre dans le code source de ce site. Ensuite, différer le reste du CSS pour qu'il se charge sans bloquer le rendu. Le même raisonnement vaut pour le JavaScript : tout script non essentiel au premier affichage doit être chargé en defer ou async.
Les polices web, fausses innocentes
Quand l'élément LCP est un titre ou un bloc de texte, la police web devient déterminante. Sans précaution, le navigateur attend le téléchargement du fichier de police avant d'afficher le texte (le fameux « texte invisible »), ce qui retarde le LCP. Deux réglages suffisent : font-display: swap, pour afficher d'abord une police système puis basculer, et le preload de la police principale utilisée au-dessus de la ligne de flottaison. On limite aussi le nombre de graisses chargées au strict nécessaire.
Le LCP commence côté serveur : le TTFB
Tous ces leviers front-end supposent que le HTML arrive vite. Si le serveur met 800 millisecondes à répondre (le TTFB, Time To First Byte), vous avez déjà brûlé un tiers de votre budget LCP avant que la moindre image ne se charge. Sur WordPress, le TTFB se dégrade vite : requêtes de base de données non mises en cache, extensions gourmandes, hébergement mutualisé saturé. La mise en cache de pages (servir du HTML statique plutôt que de régénérer la page à chaque visite), un bon CDN et un hébergement à la hauteur règlent l'essentiel.
| Levier LCP | Gain typique observé | Effort |
|---|---|---|
| Retirer le lazy-loading de l'image LCP | 0,5 à 1,2 s | Très faible (1 attribut) |
| fetchpriority="high" + preload de l'image LCP | 0,3 à 0,8 s | Faible |
| CSS critique inline + différer le reste | 0,4 à 1,5 s | Moyen |
| font-display: swap + preload police | 0,2 à 0,6 s | Faible |
| Cache de pages + CDN (TTFB) | 0,3 à 1 s | Moyen |
| Conversion WebP/AVIF (rappel) | 0,1 à 0,4 s | Faible |
L'erreur la plus coûteuse
Empiler des extensions de performance qui se contredisent. J'ai vu des WordPress avec trois plugins de cache et d'optimisation actifs en même temps : l'un lazy-loadait l'image de héros que l'autre tentait de précharger, le troisième minifiait un CSS déjà différé. Résultat net : un LCP pire qu'avec aucune optimisation. Une seule extension bien réglée (souvent WP Rocket suffit), pilotée à la main sur les bons paramètres, bat toujours une accumulation de réglages automatiques qui s'annulent.
WordPress : où agir concrètement
Sur WordPress, ces leviers se traduisent en réglages précis. Une extension de cache sérieuse gère la mise en cache de pages, le différé du CSS/JS et le preload. Encore faut-il l'exclure de la mauvaise cible : il ne faut jamais laisser le lazy-loading global s'appliquer à l'image de héros, ni différer le CSS critique du premier écran. La plupart des bons outils permettent d'exclure manuellement l'image LCP du chargement différé et d'ajouter son preload : c'est ce réglage fin, et non l'installation par défaut, qui fait la différence.
Les constructeurs de pages (Elementor, Divi et consorts) ajoutent leur propre couche de CSS et de DOM, et compliquent l'identification de l'élément LCP, un sujet que j'ai détaillé dans mon retour sur les Core Web Vitals avec les page builders WordPress. La démarche reste la même : mesurer le vrai élément LCP, le prioriser, alléger ce qui bloque autour. Et parce que la vitesse n'est pas qu'une affaire de Google, elle est aussi un levier direct de conversion : chaque seconde gagnée sur le LCP se lit dans le taux de rebond et le taux de transformation, bien au-delà du seul classement.
Au creuset : distiller la milliseconde
Optimiser le LCP, ce n'est pas empiler les plugins ni convertir une image de plus. C'est suivre une chaîne, du serveur au pixel, et retirer un à un les obstacles qui retardent l'affichage de l'élément qui compte. On mesure le vrai LCP, on le charge en priorité au lieu de le différer, on lui ouvre la voie en neutralisant le CSS et les polices qui bloquent, et on s'assure que le serveur répond vite. Le WebP n'est qu'un maillon ; la vitesse perçue se forge dans l'ordre des priorités.
Fait dans cet ordre, un LCP sous les 2,5 secondes cesse d'être un coup de chance pour devenir un résultat reproductible. Si vous voulez auditer concrètement ce qui ralentit vos pages (et trier les optimisations qui rapportent de celles qui s'annulent), tout est détaillé sur ma page expertise WordPress, où je relie performance technique, référencement naturel et conversion dans une même logique.
Faire passer votre LCP sous les 2,5 secondes
J'audite la chaîne complète de chargement de vos pages (élément LCP, priorités de téléchargement, CSS bloquant, TTFB), et je vous remets un plan d'optimisation priorisé, du gain le plus rentable au plus technique.