Core/Dash Dimension : Element Type (LCP)
Corrigez le Largest Contentful Paint en filtrant le trafic basé sur le type d'élément architectural.
Trusted by market leaders · Client results
Dimension : Ressource : Element Type LCP (lcpet)
La dimension Element Type (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 exactement le nœud du DOM, la dimension Element Type dicte votre stratégie d'ingénierie de haut niveau. LCP est la somme de quatre intervalles de temps : TTFB, Load Delay, Load Time et Render Delay. Le Element Type vous indique lequel de ces intervalles détériore votre score, vous permettant de sélectionner le bon protocole d'optimisation sans deviner.
Optimiser les Core Web Vitals par Element Type (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 Element Type, 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 le Render Delay.
Pour corriger cela, concentrez-vous entièrement sur le chemin critique de rendu (Critical Rendering Path). Le navigateur est probablement bloqué pour peindre le texte par de lourds calculs CSS ou du JavaScript synchrone dans la balise <head>. De plus, vérifiez votre stratégie de chargement de 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 image dépend fortement du Load Delay et du Load Time. Vous vous battez contre la physique et la latence du réseau ici, donc votre objectif est de rendre l'asset plus léger et découvrable plus tôt.
L'optimisation ici nécessite une gestion stricte des assets. 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, attaquez-vous au Load Time en servant 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 de fond (Background Image)
Cette classification signale une inefficacité architecturale. Parce que l'image est définie en 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 à l'asset.
La seule correction d'ingénierie robuste est le refactoring. Déplacez l'asset visuel du CSS vers une balise HTML standard <img> 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 une découverte précoce, bien que cela soit souvent un fardeau de maintenance par rapport à l'utilisation d'un élément 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 l'affiche (poster) ou de la première image (si la lecture est automatique). Cela se comporte de manière similaire au type Image mais est souvent plus lourd en raison de la taille du fichier des assets vidéo.
Traitez ceci 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 rendre le premier pixel. Compressez l'image de l'affiche aussi agressivement 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 Element Type (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 failles fondamentales dans le design responsive.
Utilisez le filtre Device Form Factor de CoreDash pour comparer les Element Types entre Mobile et Desktop. Vous constaterez souvent que les utilisateurs de Desktop obtiennent un LCP d'image (par exemple, une Hero Banner), tandis que les utilisateurs de Mobile obtiennent un LCP de texte. Cela confirme que votre mise en page CSS mobile pousse la Hero Banner sous la ligne de flottaison ou la réduit si considérablement qu'un paragraphe de texte devient l'élément le plus "Largest" (grand).
Si vous optimisez l'image héros (hero image) pour améliorer le LCP mobile dans ce scénario, vous gaspillez vos efforts. Le navigateur ne compte même pas l'image. Vous devez soit ajuster la mise en page pour ramener l'image dans la vue principale, soit déplacer votre attention sur l'optimisation du rendu du texte (polices/CSS) pour les utilisateurs mobiles.
