Vous avez ajouté un preload pour l'image hero, comme le recommandent tous les guides. Sur desktop, le Largest Contentful Paint s'est amélioré. Sur mobile, non, et PageSpeed signale maintenant qu'une image préchargée n'a pas été utilisée, ou le panneau réseau montre le hero téléchargé deux fois.
Le preload n'est pas faux en soi. Il vise un appareil, et c'est l'autre qui paie.
Pourquoi l'image LCP change avec l'écran
- Des mises en page différentes : sur desktop, l'image hero est le plus grand élément ; sur un téléphone, c'est le titre ou une image plus bas dans la colonne qui prend sa place.
- Des sections dupliquées : les page builders affichent souvent une section sur desktop et une autre sur mobile, chacune avec sa propre image, l'autre étant masquée.
- La direction artistique : une version recadrée, en portrait, du hero pour les téléphones.
- La même image, en tailles différentes : un seul fichier en plusieurs largeurs, dont le téléphone devrait télécharger une petite.
- Une image de fond : quand le hero est un fond CSS, le navigateur le découvre encore plus tard, un cas traité dans notre guide sur les heros en image de fond.
Trouver l'élément LCP sur chaque appareil
Lancez PageSpeed sur mobile et sur desktop, et ouvrez le diagnostic « Élément Largest Contentful Paint » dans chaque onglet. Ou enregistrez dans le panneau Performance des DevTools en émulation mobile : le marqueur LCP nomme l'élément. Faites-le pour les deux tailles ; ne supposez rien.
new PerformanceObserver(l => {
const e = l.getEntries().at(-1);
console.log('LCP', Math.round(e.startTime), e.element, e.url);
}).observe({ type: 'largest-contentful-paint', buffered: true });Les quatre erreurs qui gâchent le preload
1. Un seul preload pour tout le monde. Le hero desktop est préchargé pour tous les visiteurs. Les téléphones téléchargent une grande image qu'ils n'afficheront jamais, en haute priorité, en concurrence avec leur vrai LCP. Signature : l'avertissement « préchargée mais non utilisée » sur mobile.
2. Un preload sans le srcset de l'image. Le preload pointe vers un fichier, alors que la balise <img> choisit une autre largeur dans son srcset. Le navigateur télécharge les deux. Signature : la même image deux fois dans le panneau réseau, en deux tailles.
3. Un preload placé avant la balise viewport. Tant que le navigateur n'a pas lu <meta name="viewport">, un téléphone calcule la mise en page comme si l'écran faisait environ 980 pixels de large. Un preload responsive lu avant cette balise est résolu pour cette largeur, donc le téléphone récupère un candidat trop grand, puis le bon. Signature : un double téléchargement sur mobile uniquement.
4. L'image LCP est en lazy load. Un loading="lazy" sur le hero, souvent ajouté à toutes les images par un thème ou une extension, dit au navigateur d'attendre la mise en page avant de la récupérer. Signature : la requête de l'image démarre tard, après les feuilles de style.
Le correctif, cas par cas
Une image différente par appareil. Un preload chacun, séparés par une media query qui correspond au point de rupture de votre thème :
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="preload" as="image" href="/uploads/hero-mobile.webp"
media="(max-width: 768px)" fetchpriority="high">
<link rel="preload" as="image" href="/uploads/hero-desktop.webp"
media="(min-width: 769px)" fetchpriority="high">Même image, plusieurs largeurs. Un seul preload qui reprend le srcset de l'image en imagesrcset et son sizes en imagesizes, caractère pour caractère, pour que le navigateur choisisse deux fois le même candidat et ne le télécharge qu'une fois. Si le sizes de l'image est faux au départ, corrigez-le d'abord : notre guide sur srcset et sizes explique comment.
<link rel="preload" as="image" fetchpriority="high"
imagesrcset="/uploads/hero-480.webp 480w, /uploads/hero-960.webp 960w, /uploads/hero-1920.webp 1920w"
imagesizes="100vw">Sur l'image elle-même. Retirez loading="lazy", ajoutez fetchpriority="high", et conservez ses attributs width et height.
Les sections dupliquées du builder. La variante masquée ne devrait pas être téléchargée du tout. Une image masquée avec loading="lazy" n'est jamais récupérée ; sans cet attribut, elle l'est, à chaque visite.
Vérifier le résultat
- Panneau réseau, émulation mobile, cache désactivé : le hero apparaît une seule fois, tôt, à la largeur attendue.
- Pareil sur desktop.
- Aucun avertissement « préchargée mais non utilisée » dans aucun des deux onglets PageSpeed.
- Plusieurs tests par appareil, comparés par médiane, comme expliqué dans notre guide sur les données de labo et de terrain.
Avec Mantys Core
Mantys Core peut piloter toute votre couche de performance, cache inclus, ou cohabiter avec votre installation existante. Pour l'image LCP, il mesure au lieu de deviner :
L'image LCP est relevée sur de vrais rendus de chaque page, sur mobile et sur desktop, aux tailles qu'utilise le test de vitesse.
Quand les deux diffèrent, il émet un preload par appareil ; quand elles sont identiques, un seul preload qui reprend les srcset et sizes finaux de l'image.
Les preloads portent une priorité de récupération haute et sont placés juste après la balise viewport, avant les feuilles de style.
Les images au-dessus de la ligne de flottaison ne sont jamais en lazy load.
Le preload suit la page, page par page et appareil par appareil, sans que vous ayez à tenir une liste de heros.
En résumé
- L'élément LCP diffère souvent entre téléphone et desktop : vérifiez les deux.
- Un preload unique fait télécharger à un appareil une image qu'il n'affiche pas.
- Utilisez un preload par appareil, ou un seul preload avec les mêmes srcset et sizes que l'image.
- Placez-le juste après la balise viewport, et ne mettez jamais l'image LCP en lazy load.
- Vérifiez dans le panneau réseau que le hero n'est téléchargé qu'une fois, sur chaque appareil.
Commentaires
Vous butez sur un problème similaire ? Décrivez votre configuration et ce que vous observez. Nous lisons chaque commentaire et nous répondons.
Aucun commentaire pour l’instant. Partagez le premier votre cas.