Dimension Core/Dash : Type d'élément (LCP)
Corrigez le Largest Contentful Paint en filtrant le trafic en fonction du type d'élément architectural.
Trusted by market leaders · Client results
Dimension : Ressource : Type d'élément LCP (lcpet)
La dimension Type d'élément (LCP) (lcpet) catégorise le nœud du Largest Contentful Paint dans l'une des quatre classes architecturales : text, image, background-image, ou video.
Alors que la dimension Attribution Element identifie le nœud DOM exact, la dimension Type d'élément dicte votre stratégie d'ingénierie de haut niveau. Le LCP est la somme de quatre intervalles de temps : TTFB, Load Delay, Load Time, et Render Delay. Le Type d'élément vous indique lequel de ces intervalles nuit à votre score, vous permettant de sélectionner le bon protocole d'optimisation sans deviner.
Optimiser les Core Web Vitals par type d'élément LCP
Après avoir amélioré le TTFB, qui est indépendant du type d'élément LCP, vous devez adopter une approche différente pour optimiser le LCP en examinant votre type d'élément LCP.
1. Texte
Lorsque CoreDash signale le texte comme Type d'élément, la bande passante des ressources réseau statiques est rarement le goulot d'étranglement. Le texte réside directement dans le document HTML, ce qui signifie que le contenu est disponible immédiatement après la réponse initiale du serveur (TTFB). Si votre LCP est lent ici, le problème est presque exclusivement un Render Delay.
Pour corriger cela, concentrez-vous entièrement sur le Critical Rendering Path. Le navigateur est probablement bloqué et ne peut pas afficher le texte en raison de lourds calculs CSS ou de JavaScript synchrone dans le <head>. De plus, vérifiez votre stratégie de chargement des polices ; si vous n'utilisez pas font-display: swap ou optional, le navigateur masque artificiellement le texte (FOIT) en attendant le téléchargement du fichier de police.
2. Image (<img>)
Ce type déclenche le pipeline complet des ressources : découverte, téléchargement et décodage. Contrairement au texte, un LCP d'image dépend fortement du Load Delay et du Load Time. Vous luttez ici contre la physique et la latence du réseau, votre objectif est donc de rendre la ressource plus légère et détectable plus tôt.
L'optimisation ici nécessite une gestion stricte des ressources. Assurez-vous que la balise <img> existe dans la source HTML initiale (Server-Side Rendering) pour minimiser le Load Delay. Ajoutez fetchpriority="high" et supprimez strictement tout attribut loading="lazy", car ceux-ci retardent la requête du navigateur. Enfin, traitez le Load Time en diffusant des formats de nouvelle génération (AVIF/WebP) et en utilisant srcset pour éviter que les appareils mobiles ne téléchargent des fichiers de la taille d'un ordinateur de bureau.
3. Image d'arrière-plan
Cette classification signale une inefficacité architecturale. Étant donné que l'image est définie dans le CSS (par exemple, background-image: url(...)), le navigateur ne peut pas découvrir l'URL avant d'avoir entièrement téléchargé et analysé vos feuilles de style. Cela crée un Load Delay massif car le Preload Scanner est effectivement aveugle à la ressource.
La seule correction d'ingénierie robuste est la refactorisation. Déplacez la ressource visuelle du CSS vers une balise HTML <img> standard pour exposer immédiatement l'URL au navigateur. Si vous ne pouvez pas refactoriser le balisage, vous devez utiliser <link rel="preload"> dans l'en-tête du document pour forcer la découverte précoce, bien que cela représente souvent une charge de maintenance par rapport à l'utilisation d'un élément d'image natif.
4. Vidéo
Lorsque l'élément LCP est une vidéo, le navigateur mesure le temps d'affichage de l'image de couverture (poster) ou de la première image (en cas de lecture automatique). Cela se comporte de manière similaire au type Image, mais est souvent plus lourd en raison de la taille de fichier des ressources vidéo.
Traitez cela strictement comme une tâche d'optimisation d'image. Assurez-vous qu'un attribut poster léger est présent dans le HTML afin que le navigateur n'ait pas à télécharger des segments vidéo pour afficher le premier pixel. Compressez l'image poster de manière aussi agressive que vous le feriez pour une image LCP standard.
Workflow : trouver les problèmes de LCP en fonction du type d'élément LCP
Le Type d'élément LCP n'est ni statique ni identique pour chaque visiteur. Il change fréquemment en fonction de l'appareil de l'utilisateur, révélant des défauts fondamentaux dans le responsive design.
Utilisez le filtre Device Form Factor de CoreDash pour comparer les Types d'éléments entre Mobile et Desktop. Vous constaterez souvent que les utilisateurs Desktop obtiennent un LCP d'image (par exemple, une Hero Banner), tandis que les utilisateurs Mobile obtiennent un LCP de texte. Cela confirme que votre mise en page CSS mobile pousse la Hero Banner en dessous de la ligne de flottaison ou la réduit de manière si significative qu'un paragraphe de texte devient l'élément le plus « grand » (Largest).
Si vous optimisez l'image hero pour améliorer le LCP mobile dans ce scénario, vous perdez votre temps. Le navigateur ne prend même pas l'image en compte. Vous devez soit ajuster la mise en page pour ramener l'image dans la vue principale, soit vous concentrer sur l'optimisation du rendu du texte (polices/CSS) pour les utilisateurs mobiles.
