On croit volontiers qu’un LCP lent se règle en compressant les images. C’est le réflexe le plus fréquent, et il fait perdre du temps : on passe une matinée à optimiser un visuel pendant que le vrai coupable est ailleurs. Le LCP (Largest Contentful Paint) mesure le temps que met le plus gros élément visible à s’afficher, et passé 2,5 secondes, l’utilisateur perçoit la lenteur quand Google, lui, le note. Avant de retoucher la moindre image, il faut donc savoir quel élément porte réellement cet indicateur, et dans quel ordre s’attaquer aux causes.

Première étape, identifier l’élément. C’est presque toujours l’image du hero, parfois un gros bloc de titre. L’audit intégré au navigateur vous le désigne au surlignage près. Tant que vous ne le tenez pas, vous optimisez à l’aveugle, et c’est exactement ainsi qu’on perd une demi-journée sur le mauvais fichier.

Un LCP au-delà de 2,5 secondes a presque toujours trois causes (un serveur lent, des ressources qui bloquent le rendu, une image trop lourde) qu’il faut traiter dans cet ordre, parce que le premier rend les autres invisibles.

1. Serveur lent (TTFB)

2. Ressources bloquantes

3. Image trop lourde

LCP sous 2,5 s

Vient ensuite le tri des causes, qui se résume à trois suspects qu’il faut prendre dans le bon ordre. Le serveur d’abord. Si le HTML met une seconde à partir, tout le reste démarre déjà en retard, et aucune correction côté affichage ne rattrapera ce retard. On regarde le TTFB, le temps jusqu’au premier octet : quand il grimpe, le problème est en base ou côté serveur, pas dans le navigateur. Aller compresser une image avec un TTFB à 1,2 s, c’est se tromper de chantier. Une fois le serveur dégagé, on s’occupe des ressources qui bloquent le rendu : du CSS ou du JavaScript posé sur le chemin critique repousse l’affichage d’autant. La parade : différer le JavaScript qui n’est pas requis pour le premier rendu, mettre le CSS critique en ligne. Et retirer ce qui ne sert qu’en dessous de la ligne de flottaison. Reste enfin l’image, et c’est seulement là, une fois les deux premiers points réglés, qu’elle mérite votre attention. On la sert au format moderne, à la taille réellement affichée, et on la marque comme prioritaire au chargement.

Si vous me demandez ce que je préfère, c’est ne pas avoir le problème du tout. Un hero typographique, titre et fond en CSS sans grande image au-dessus de la ligne de flottaison, s’affiche quasi instantanément : le LCP devient un faux problème par construction et vous n’avez plus aucun fichier lourd à prioriser. C’est mon réflexe sur les sites que je conçois de zéro. Mais le plus important reste de mesurer chez les bonnes personnes. Le seul LCP qui compte est celui des gens qui chargent vraiment la page, sur leur téléphone, sur leur réseau du moment, pas celui de votre machine en fibre avec le cache chaud. Un score synthétique magnifique pendant que le terrain stagne à 4 secondes, ça arrive plus souvent qu’on ne l’imagine.

Un cas récent résume tout ça. Site vitrine, hero en PNG de 2,8 Mo livré pleine résolution pour finir affiché en 600 px de large. Le réflexe du client avait été de demander une compression de l’image, et il n’avait pas tort sur le principe : repassée en WebP correctement dimensionnée, elle tombait à 90 Ko environ, et le LCP gagnait plus d’une seconde sur mobile sans toucher une ligne de back. Sauf que la donnée de terrain restait au rouge. En creusant, le TTFB partait à 1,4 s sur les pages non mises en cache, et c’est lui qui plombait le score réel. L’image n’était que la moitié visible du problème. On a fini par traiter le cache serveur en premier, puis l’image : c’est l’ordre qui a fait la différence, pas chaque correction prise isolément.

À lire aussi