Blog · Ce que révèle l'audit gratuit
Les téléphones téléchargent vos images de bureau
Pourquoi une image principale de 2,6 Mo atteint un téléphone qui n'a besoin que de 33 Ko, comment srcset et sizes laissent le navigateur choisir, quand vous avez vraiment besoin de l'élément picture, ce que WebP vous apporte, et où les thèmes WordPress défont en silence le travail que WordPress a déjà fait pour vous.
Ce qui se passe réellement
Sur un site que nous avons audité ce mois-ci, l'image principale de la page d'accueil était un WebP de 1920 par 1080 pesant 2,6 Mo. Sur un téléphone, cette image s'affiche sur environ 390 pixels de large. Le téléphone télécharge les 2,6 Mo, décode deux millions de pixels, puis en peint à peu près 4 %.
La même photo, redimensionnée aux 800 pixels qu'un téléphone haute densité utilise réellement, pèse 33 Ko. Même photographie, même qualité sur cet écran, 98 % de moins à télécharger. Sur une connexion cellulaire, c'est la différence entre une page qui apparaît d'un coup et un espace blanc pendant deux ou trois secondes.
C'est aussi pourquoi la mesure appelée Largest Contentful Paint en souffre. L'image principale est généralement le plus gros élément de la page, la page ne semble donc pas chargée tant qu'elle n'est pas arrivée, et elle ne peut pas arriver tant que chaque octet n'est pas là.
Quand vous avez besoin de l'élément picture
srcset gère une image en plusieurs tailles. L'élément picture gère deux problèmes différents. Le premier est la direction artistique : un cadrage paysage large sur ordinateur et un cadrage portrait serré sur téléphone, parce que le même cadrage ne fonctionne pas dans les deux formes. Le second est le format de secours : proposer AVIF aux navigateurs qui le comprennent, WebP aux autres, et un JPEG comme plancher.
Afficher le code Masquer le code HTML, 7 lignes
<picture>
<source media="(max-width: 700px)" type="image/avif" srcset="/img/hero-phone.avif" />
<source media="(max-width: 700px)" type="image/webp" srcset="/img/hero-phone.webp" />
<source type="image/avif" srcset="/img/hero-1200.avif 1200w, /img/hero-1920.avif 1920w" sizes="60vw" />
<source type="image/webp" srcset="/img/hero-1200.webp 1200w, /img/hero-1920.webp 1920w" sizes="60vw" />
<img src="/img/hero-1200.jpg" width="1920" height="1080" alt="Volunteers planting trees along the river trail" />
</picture>La plupart des sites n'en ont pas besoin. Si un seul cadrage fonctionne partout et que vous servez du WebP, un simple img avec srcset est le bon outil, et il est bien plus facile à maintenir correct. Passez à picture quand vous avez un vrai problème de direction artistique ou que vous ajoutez AVIF.
Formats : WebP maintenant, AVIF quand vous le pouvez
WebP est pris en charge par tous les navigateurs qu'utilisent vos visiteurs et pèse typiquement 25 à 35 % de moins qu'un JPEG de même qualité visuelle. AVIF est encore plus léger mais plus lent à encoder, il a donc du sens pour la poignée d'images qui comptent le plus, avec WebP derrière.
Le format ne remplace pas la taille. L'image de 2,6 Mo ci-dessus était déjà en WebP. Elle faisait simplement 1920 pixels de large et était encodée à une qualité que personne ne peut voir. La taille d'abord, puis le format, puis la qualité.
Priorité et paresse
Deux attributs terminent le travail. L'image principale, la seule au-dessus de la ligne de flottaison, reçoit fetchpriority="high" pour que le navigateur la récupère avant les feuilles de style et les scripts qui feraient autrement la queue devant elle. Tout ce qui se trouve sous la ligne de flottaison reçoit loading="lazy" pour n'être téléchargé que lorsque le visiteur s'en approche.
L'erreur courante est d'appliquer loading="lazy" aussi à l'image principale, généralement parce qu'une extension l'ajoute à toutes les images. Charger paresseusement le plus grand élément visible rend la page plus lente, pas plus rapide, et Lighthouse le dira.
Là où WordPress aide, et là où les thèmes le défont
WordPress génère plusieurs tailles de chaque fichier téléversé et écrit automatiquement srcset et sizes dans les balises d'image depuis la version 4.4. Depuis la 6.1, il peut générer du WebP à côté de l'original. Pour les images placées via l'éditeur, le travail est fait pour vous.
C'est avec les images principales que cela dérape. Beaucoup de thèmes et de constructeurs de pages (Elementor, WPBakery et d'autres) sortent l'image principale comme image d'arrière-plan CSS, ou référencent directement l'original en taille réelle, et aucune des deux voies ne porte de srcset. Une image principale posée en arrière-plan ne peut pas du tout être adaptative au sens décrit ici ; elle doit devenir un vrai img, ou le thème a besoin d'une variante mobile.
L'autre fuite courante est une extension qui retire ou réécrit les balises d'image, ou un thème qui demande la taille nommée full pour chaque vignette. L'indice est le même dans tous les cas : affichez le code source de la page, trouvez l'image principale et cherchez un attribut srcset. S'il n'y est pas, le navigateur n'a aucun choix à faire.
Vérifiez votre propre site en une minute
Ouvrez votre page d'accueil sur un téléphone, ou dans un navigateur de bureau avec l'émulation mobile activée et le panneau réseau ouvert, filtré sur les images. Triez par taille. Si la première entrée dépasse 300 Ko, cette image est celle à corriger en premier. L'audit gratuit de ce site exécute la même vérification sur votre page d'accueil et présente la plus grosse image et son économie en langage clair.
Si vous êtes client, c'est une petite tâche dans le cadre du forfait pour l'image principale d'un gabarit, et un projet à prix fixe si toute la médiathèque doit être réencodée. Dans les deux cas, ouvrez une demande et nous commencerons par l'image qui coûte le plus.