« Élément de plus grand contenu visuel : 4,8 secondes » — c’est ce qu’affichait le rapport Lighthouse généré sur la page carte des vins d’un domaine viticole, bien au-delà du seuil de 2,5 secondes recommandé pour un LCP jugé satisfaisant. La page présentait un carrousel en tête de contenu, faisant défiler automatiquement des photos de bouteilles et d’étiquettes, avant d’afficher la liste détaillée des cuvées disponibles.
Ce que le LCP mesure exactement
Le LCP, ou temps d’affichage du plus grand élément visible, correspond au moment où le plus grand bloc de contenu visible dans la zone d’écran immédiatement affichée termine son rendu. Sur cette page, cet élément était systématiquement la première image du carrousel : une photographie large occupant une bonne partie de la largeur de la page, juste sous le titre.
Le carrousel, construit avec une bibliothèque JavaScript tierce, chargeait ses images de façon asynchrone après l’exécution du script d’initialisation, retardant d’autant l’affichage de la première image par rapport à un simple <img> présent directement dans le HTML initial.
Diagnostic détaillé
L’inspection du réseau a montré que l’image du carrousel ne commençait à se charger qu’après l’exécution complète du script de la bibliothèque de carrousel, elle-même chargée après les autres ressources de la page. Ajoutée à cela, l’image ne précisait aucune dimension explicite dans son balisage, obligeant le navigateur à recalculer la mise en page une fois l’image chargée, ce qui retardait encore la stabilisation visuelle de l’élément.
Le correctif : dimensionner et prioriser
Deux changements ont réglé l’essentiel du problème. D’abord, sortir la première image du carrousel du chargement asynchrone géré par le script, pour la placer directement dans le HTML avec ses dimensions explicites :
<img
src="cave-etiquettes-2022.jpg"
width="1200"
height="675"
fetchpriority="high"
alt="Cuvées du domaine, cave de vieillissement"
>
L’attribut fetchpriority="high" indique explicitement au navigateur de prioriser le chargement de cette image par rapport aux autres ressources de la page, un signal particulièrement utile pour l’élément qui deviendra le plus grand contenu visible. Les images suivantes du carrousel, elles, restent chargées en différé par le script, puisqu’elles ne sont pas visibles au premier affichage.
Ce que ce correctif ne traite pas
Le décalage de mise en page, mesuré par le CLS, est un indicateur distinct qui n’entrait pas dans le périmètre de cette intervention : le carrousel présentait par ailleurs un comportement stable à ce niveau, sans saut visuel notable pendant son défilement automatique.
Résultats mesurés
Après déploiement, le LCP de la page carte des vins est passé de 4,8 secondes à 1,6 seconde en moyenne sur les mesures de terrain collectées sur quatre semaines, un résultat cohérent avec la suppression du délai d’attente lié au script de carrousel. Le reste de la page, inchangé, n’a montré aucune régression sur les autres indicateurs suivis.
- Sortir la première image visible d’un chargement dépendant d’un script tiers.
- Toujours préciser
widthetheightsur une image susceptible de devenir le LCP. - Réserver
fetchpriority="high"à l’élément réellement déterminant pour l’affichage initial, pas à toutes les images de la page.
Un carrousel n’est jamais coupable en tant que tel : c’est presque toujours la façon dont sa première image est chargée qui détermine son impact sur le LCP.
Reproduire ce diagnostic sur un autre carrousel
La méthode reste transposable à n’importe quel carrousel, quelle que soit la bibliothèque utilisée pour le construire : ouvrir l’onglet réseau des outils de développement, identifier le moment exact où la première image commence à se charger par rapport au reste des ressources de la page, puis vérifier si ce chargement dépend de l’exécution complète d’un script JavaScript avant de démarrer. Un délai de plusieurs centaines de millisecondes entre le début du chargement de la page et le début du chargement de cette image constitue un signal fort qu’un correctif de ce type s’impose.
Le domaine viticole a également profité de cette intervention pour revoir la compression des images suivantes du carrousel, non déterminantes pour le LCP mais dont le poids cumulé pesait sur le temps de chargement total de la page, un chantier distinct mené en parallèle sans lien direct avec le correctif principal décrit ici.
En résumé
Un carrousel dont la première image dépend d’un script tiers chargé tardivement pénalise directement le LCP, quel que soit par ailleurs le soin apporté au reste de la page. Extraire cette image du chargement asynchrone, lui donner des dimensions explicites et la prioriser avec fetchpriority a suffi, dans ce cas, à ramener le LCP largement sous le seuil recommandé.
