Dimension Core/Dash : Urls
Isolez et corrigez les goulots d'étranglement de performance des Core Web Vitals par Urls spécifiques
Trusted by market leaders · Client results
Dimension : Page & Navigation : URLs (u)
La dimension Type d'élément (LCP) (lcpet) classe le nœud du Largest Contentful Paint dans l'une des quatre catégories 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 protocole d'optimisation correct 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 élément LCP.
1. Text
Lorsque CoreDash signale du 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 le Render Delay.
Pour corriger cela, concentrez-vous entièrement sur le Critical Rendering Path. Le navigateur est probablement empêché d'afficher le texte par de lourds calculs CSS ou du 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 image dépend fortement du Load Delay et du Load Time. Vous combattez ici la physique et la latence réseau ; votre objectif est donc de rendre l'asset plus léger et découvrable plus tôt.
L'optimisation nécessite ici 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, traitez le Load Time en servant des formats de nouvelle génération (AVIF/WebP) et en utilisant srcset pour empêcher les appareils mobiles de télécharger des fichiers de taille desktop.
3. Background Image
Cette classification signale une inefficacité architecturale. Parce que l'image est définie dans le CSS (ex : background-image: url(...)), le navigateur ne peut découvrir l'URL qu'après 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.
Le seul correctif d'ingénierie robuste est le refactoring. Déplacez l'asset visuel du CSS vers une balise HTML <img> standard pour exposer l'URL au navigateur immédiatement. 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 une charge de maintenance par rapport à l'utilisation d'un élément image natif.
4. Video
Lorsque l'élément LCP est une vidéo, le navigateur mesure le temps d'affichage de l'image poster ou de la première frame (si 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 assets 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 aussi agressivement que vous le feriez pour une image LCP standard.
Workflow : trouver les problèmes LCP basés sur le type d'élément LCP
Le Type d'élément LCP n'est ni statique ni le même pour chaque visiteur. Il change fréquemment selon 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 image (ex : une bannière Hero), tandis que les utilisateurs Mobile obtiennent un LCP texte. Cela confirme que votre mise en page CSS mobile pousse la bannière Hero sous la ligne de flottaison ou la réduit si significativement qu'un paragraphe de texte devient l'élément "le plus grand".
Si vous optimisez l'image hero pour améliorer le LCP mobile dans ce scénario, vous gaspillez vos efforts. Le navigateur ne comptabilise 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 vers l'optimisation du rendu du texte (polices/CSS) pour les utilisateurs mobiles.
