Le LCP d'une page d'article : image de couverture ou bloc de texte

L'indicateur mesurant le plus grand affichage de contenu retient un élément précis de la page, celui qui occupe la plus grande surface visible au moment où il apparaît. Sur une page d'article, deux candidats se disputent ce rôle : l'image de couverture, quand elle existe, et le premier bloc de texte substantiel. La distinction n'a rien d'académique, puisque les corrections à apporter n'ont aucun rapport entre elles. Identifier lequel des deux est retenu, et pourquoi il change parfois d'une visite à l'autre, constitue la première étape de tout travail sur cet indicateur.

Comment l'élément est choisi

Le mécanisme de sélection est documenté et il surprend souvent, notamment parce qu'il ne correspond pas à l'intuition de ce qui est important sur la page. Comprendre la règle évite de corriger un élément qui n'est pas celui mesuré. La définition et les seuils de cet indicateur sont rappelés dans notre article sur le problème de LCP dans la Google Search Console.

La surface visible décide

Le navigateur retient l'élément dont la surface visible dans la fenêtre est la plus grande, parmi une liste de types éligibles. Une image de couverture occupant la moitié de l'écran l'emporte donc sur un paragraphe. Un bandeau très large mais très plat peut en revanche perdre face à un bloc de texte de plusieurs lignes. Cette comparaison porte sur la surface effectivement affichée et non sur les dimensions réelles du fichier. Une image de trois mille pixels réduite à quatre cents à l'écran compte pour quatre cents, ce qui n'empêche évidemment pas son poids de peser sur le délai.

Les types éligibles

Sont pris en compte les images, les vidéos avec leur image de remplacement, les éléments portant une image de fond et les blocs de texte. Les éléments purement décoratifs et les images de fond répétées sont exclus. Cette liste explique pourquoi une icône, même mise en avant, n'est jamais retenue. Elle explique aussi pourquoi un bandeau construit par image de fond peut devenir l'élément mesuré sans que personne ne s'y attende. Ce cas est particulièrement pénalisant, comme nous le verrons plus loin.

Le bloc de texte comme candidat

Un bloc de texte est traité comme un tout, ce qui signifie qu'un long paragraphe ou un ensemble de paragraphes contigus peut représenter une surface considérable. Sur un article sans image en tête, c'est presque toujours le premier bloc de contenu qui est mesuré. Le titre principal, plus court, l'emporte rarement. Cette configuration est fréquente sur les blogs techniques et elle change complètement la nature de la correction à apporter. Beaucoup d'interventions échouent parce qu'elles traitent une image alors que le texte est mesuré.

La mesure évolue pendant le chargement

L'élément retenu n'est pas figé : le navigateur enregistre un candidat, puis le remplace si un élément plus grand apparaît ensuite. La valeur finale correspond au dernier candidat avant la première interaction de l'utilisateur. C'est la raison pour laquelle un texte affiché rapidement peut être remplacé par une image arrivant deux secondes plus tard. Cette dynamique explique la plupart des mesures qui paraissent incohérentes. Elle explique aussi qu'un visiteur qui clique immédiatement obtienne une valeur plus favorable qu'un visiteur qui attend.

Pourquoi l'élément change selon les visites

Deux visiteurs peuvent obtenir un élément différent selon la taille de leur fenêtre, leur vitesse de connexion et le moment où ils interagissent avec la page. Sur mobile, l'image de couverture occupe souvent tout l'écran ; sur un grand écran, le texte peut la dépasser en surface. Cette variabilité impose de regarder la distribution des mesures plutôt qu'un cas isolé. Elle justifie aussi de traiter les deux candidats plutôt que de parier sur l'un. Les corrections apportées au texte profitent de toute façon à l'ensemble de la page, ce qui rend l'effort rarement perdu.

Le seuil à atteindre

La valeur retenue est celle du soixante quinzième centile des visites réelles, ce qui signifie que trois visiteurs sur quatre doivent être sous le seuil pour que la page soit conforme. Cette formulation compte : améliorer la médiane sans toucher aux cas lents ne change rien au résultat. Le travail porte donc sur les visites les plus défavorables, connexions lentes et appareils modestes. C'est un déplacement de perspective que les tests menés depuis un bureau ne facilitent pas. Une connexion de fibre et un ordinateur récent donnent toujours des mesures excellentes, quelle que soit la qualité réelle de la page.

Identifier l'élément mesuré

Le diagnostic prend quelques minutes et il évite de corriger au hasard, ce qui est la façon la plus courante d'aborder ce sujet.

Les outils du navigateur

L'onglet de performance des outils de développement signale l'élément retenu et l'instant où il a été enregistré. Un survol permet de le localiser directement dans la page. C'est la méthode la plus rapide et elle porte sur les conditions de votre poste, généralement bien plus favorables que celles des visiteurs. Elle donne l'élément, ce qui est l'information recherchée, sans donner la valeur représentative. C'est exactement l'usage qu'il faut en faire : identifier, puis mesurer ailleurs.

Les outils en ligne

Les analyseurs de performance affichent également l'élément retenu, avec une capture le mettant en évidence. Ils simulent une connexion mobile lente, ce qui rapproche des conditions réelles sans les reproduire exactement. Leur intérêt principal tient au détail des ressources et à la chronologie fournie. Ils constituent le bon outil pour comprendre pourquoi l'élément arrive tard. La chronologie affichée montre en particulier si le retard vient de la découverte de la ressource ou de son téléchargement.

La mesure sur données réelles

Une bibliothèque légère permet de collecter l'indicateur dans le navigateur des visiteurs, avec le sélecteur de l'élément retenu. C'est la seule façon de connaître la distribution réelle et la répartition entre image et texte. Elle demande un point de collecte et une attention à ce qui est conservé, la mesure étant associée à une visite. Nous ne sommes pas juristes et ce point mérite un avis compétent selon la configuration retenue. Techniquement, une collecte ne conservant que le sélecteur et la valeur, sans identifiant de visiteur, réduit fortement le périmètre concerné.

Tester en conditions dégradées

La limitation de bande passante proposée par les outils du navigateur change fréquemment l'élément retenu, une image lente laissant le texte l'emporter. Ce test révèle donc les deux candidats et il indique lequel domine selon les conditions. Il prend deux minutes et il devrait précéder toute intervention. Il évite notamment d'optimiser une image alors que le texte est mesuré chez la majorité des visiteurs. Une limitation à une connexion mobile lente reproduit assez fidèlement les conditions du quart le plus défavorisé.

Vérifier plusieurs largeurs

Le passage d'une largeur mobile à une largeur bureau modifie les surfaces relatives et parfois l'élément retenu. Un contrôle à trois largeurs, mobile, tablette et bureau, couvre les cas usuels. Cette vérification prend une minute et elle explique des écarts autrement incompréhensibles entre les rapports mobile et ordinateur, que l'on attribue souvent à tort à un problème de mesure. Elle conduit parfois à traiter deux éléments différents selon le format. Dans ce cas, la priorité va au format majoritaire dans les statistiques du site, presque toujours le mobile.

Distinguer la page du gabarit

Un article dont l'image de couverture est particulièrement lourde constitue un cas isolé ; un problème présent sur tous les articles relève du gabarit. Tester trois articles différents tranche immédiatement cette question. La correction porte sur le gabarit lorsque le problème est structurel, ce qui profite à l'ensemble du site. C'est la distinction qui détermine l'ampleur du travail. Un problème de gabarit se corrige une fois, un problème de contenu demande une consigne éditoriale et un rattrapage sur l'existant.

Quand c'est l'image

Le cas le plus fréquent sur les sites éditoriaux comportant une couverture. Les corrections sont bien identifiées et leur effet est immédiat.

Réduire le poids

Une couverture servie en trois mille pixels de large sur un écran de quatre cents pèse dix fois ce qu'elle devrait. Le redimensionnement à la taille réellement affichée, avec des variantes selon la largeur d'écran, produit le gain le plus important. Une extension de conversion automatise ce travail sur l'existant en une opération. La conversion vers un format moderne ajoute une réduction supplémentaire de trente à cinquante pour cent, sujet développé dans notre article sur les images WebP et AVIF et la compression sur le web.

Ne pas la charger en différé

Le chargement différé appliqué à une image visible dès l'ouverture retarde sa découverte et dégrade mécaniquement l'indicateur. Cette erreur est extrêmement fréquente, les extensions appliquant le différé à toutes les images sans distinction. Le contrôle consiste à regarder si l'attribut de report figure sur la couverture dans le code source de la page. L'image de couverture doit être explicitement exclue, ce qui se règle par un attribut. Cette correction est celle qui produit le plus gros gain pour le moins d'effort, comme nous l'expliquons dans notre article sur le lazy loading et son intérêt en référencement.

La précharger

Une directive de préchargement indique au navigateur de télécharger l'image en priorité, avant d'avoir analysé toute la feuille de style. Le gain se compte en centaines de millisecondes sur les pages où l'image est déclarée tardivement. Elle doit être réservée à cette seule image, précharger plusieurs ressources annulant le bénéfice recherché. Le préchargement est un mécanisme de priorité, et tout prioriser revient à ne rien prioriser. La déclaration doit préciser les variantes lorsque plusieurs tailles existent, faute de quoi le navigateur télécharge une image qu'il n'utilisera pas.

Éviter l'image de fond

Une couverture déclarée en image de fond dans une feuille de style n'est découverte qu'après analyse de cette feuille, ce qui la retarde systématiquement. Elle ne peut pas non plus être préchargée aussi simplement ni servie en variantes selon la largeur. Passer à une véritable balise d'image, positionnée par le style, règle l'ensemble de ces points. C'est une reprise de gabarit qui vaut largement l'effort. Elle demande de revoir le positionnement, l'image ne se comportant pas de la même façon selon qu'elle est en fond ou en contenu.

Réserver la place

Déclarer les dimensions de l'image évite le décalage de mise en page lors de son arrivée, ce qui améliore un autre indicateur. Ce point n'agit pas directement sur l'élément mesuré et il accompagne naturellement la correction. Les attributs de largeur et de hauteur suffisent, le style se chargeant de l'adaptation. Leur absence est un défaut classique des gabarits anciens. Les ajouter est sans risque, à condition que le style prévoie une hauteur automatique pour préserver les proportions.

Servir depuis le bon endroit

Une image servie depuis un domaine tiers impose une connexion supplémentaire avant tout téléchargement. Sur la couverture, ce coût s'ajoute directement au délai mesuré. Servir depuis le domaine du site, ou au minimum préconnecter au domaine tiers, supprime cette pénalité. Ce détail se vérifie dans l'onglet réseau en quelques secondes. Il concerne particulièrement les sites employant un service externe de traitement d'images.

Quand c'est le texte

Le cas des articles sans couverture, ou lus sur grand écran. Les corrections n'ont rien à voir avec les précédentes et elles sont souvent plus simples.

Le blocage par la police

Un texte dont la police n'est pas encore chargée reste invisible pendant un court délai, ce qui retarde son enregistrement comme élément affiché. Le réglage du comportement d'affichage pendant le chargement supprime ce blocage, en montrant immédiatement le texte dans une police de repli. Ce seul réglage suffit fréquemment à ramener la mesure sous le seuil. Il coûte une ligne dans la déclaration de police. Le remplacement de police produit en contrepartie un léger décalage visuel, qui se réduit par un réglage des métriques de la police de repli.

Le blocage par la feuille de style

Le navigateur n'affiche aucun texte tant qu'il n'a pas traité les feuilles de style bloquantes. Sur un site chargeant plusieurs fichiers volumineux, ce délai domine tout le reste. Extraire les règles nécessaires à l'affichage initial et les placer en ligne, en chargeant le reste ensuite, résout ce point. Cette technique demande une automatisation pour rester à jour, un style critique périmé produisant un affichage initial incorrect.

Le temps de réponse du serveur

Lorsque le texte est l'élément mesuré, la mesure se rapproche du temps de réponse du serveur augmenté du traitement de la feuille de style. Un serveur lent devient alors le facteur dominant, et aucune optimisation de ressources ne le compensera. Le cache de page est la réponse habituelle et la plus efficace, puisqu'elle supprime purement et simplement le temps de construction de la page. C'est souvent à cette occasion que l'on découvre un temps de réponse largement supérieur à ce qu'on imaginait. Le mesurer par gabarit, plutôt qu'en moyenne, oriente immédiatement vers la bonne page.

Le contenu produit par script

Un article dont le texte est injecté par du JavaScript n'existe pas tant que le script n'a pas tourné, ce qui décale l'ensemble. Sur un site construit côté navigateur, le rendu côté serveur des pages principales est la seule réponse structurelle. Cette évolution représente un chantier et elle règle simultanément plusieurs problèmes. Elle mérite d'être envisagée dès que le décalage constaté dépasse la seconde. Les cadres applicatifs modernes la proposent nativement, ce qui a fortement réduit son coût ces dernières années.

Les scripts bloquants en tête

Un script déclaré sans attribut de report, dans l'en tête du document, arrête l'analyse du document jusqu'à son exécution. Le texte n'apparaît qu'après. Ajouter les attributs appropriés, ou déplacer ces scripts, produit un gain immédiat et sans risque dans la quasi totalité des cas. Ce défaut concerne surtout les scripts ajoutés à la main au fil des années, notamment les balises de mesure copiées depuis une documentation ancienne.

La taille du bloc mesuré

Un chapeau très court suivi d'une publicité peut faire que le bloc mesuré soit minuscule, ce qui donne une mesure excellente sans que la page soit rapide. Cette situation n'est pas un problème en soi et elle rend l'indicateur peu représentatif de l'expérience réellement vécue par le lecteur. Il vaut mieux le savoir avant de se féliciter d'un chiffre obtenu pour de mauvaises raisons. Les autres indicateurs prennent alors le relais pour juger la page. La stabilité visuelle et la réactivité aux interactions donnent dans ce cas une image nettement plus fidèle de l'expérience réelle. Ils méritent d'être lus ensemble plutôt que successivement, une page qui affiche vite mais bouge pendant le chargement produisant une impression bien pire qu'une page légèrement plus lente et parfaitement stable.