Une image qui ne se charge qu'une fois presque à l'écran épargne au visiteur tout ce qui est sous la ligne de flottaison. Si le navigateur ignorait sa taille, la page saute à son arrivée — et le lecteur perd sa place, ou touche un lien qui s'est déplacé.

Indiquez toujours la largeur et la hauteur

<img src="/img/rack.webp" width="1600" height="900" alt="A server rack" loading="lazy" decoding="async">

Ce n'est pas la taille d'affichage. C'est le rapport d'aspect, et le navigateur en déduit exactement la place à réserver pendant que le fichier se télécharge encore. Avec width:100%;height:auto en CSS, l'image continue de se redimensionner normalement.

Ne différez jamais le haut de la page

loading="lazy" sur l'image d'en-tête retarde le plus grand élément à l'écran, qui est précisément la mesure de la vitesse ressentie. La règle est simple : tout ce qui est au-dessus de la ligne de flottaison se charge immédiatement, tout ce qui est en dessous se charge en différé.
<!-- hero: eager, and asked for early -->
<img src="/img/hero.webp" width="1600" height="900" alt="" fetchpriority="high">

Il en va de même pour les intégrations

Un iframe accepte lui aussi width, height et loading="lazy". Une vidéo intégrée laissée en chargement immédiat est souvent l'élément le plus lourd d'une page, et elle se trouve d'ordinaire sous la ligne de flottaison.

Et pour tout ce qu'un script fait apparaître

Un effet d'apparition au défilement qui part d'une opacité nulle montre une carte vide à quiconque n'a pas vu le script s'exécuter. Rendez l'état caché explicite — appliqué par le script une fois qu'il vit — pour que le contenu soit visible par défaut.

Vérifiez

Chargez la page avec le réseau bridé et regardez si quelque chose bouge après l'arrivée des images. Le Cumulative Layout Shift dans un passage Lighthouse met un chiffre sur la même chose — voir Mesurer honnêtement les Core Web Vitals.