Quand WordPress 5.5 est sorti en août 2020, l’ajout du lazy-load natif sur les images est passé presque inaperçu dans les notes de version, coincé entre l’auto-update des extensions et le nouveau XML Sitemaps intégré. Pourtant, dix mois plus tard, avec le recul de plusieurs dizaines de sites passés sous notre supervision, c’est probablement le changement qui a eu le plus d’impact silencieux sur les temps de chargement de nos clients. Sans plugin, sans ligne de configuration, sans que personne ne s’en aperçoive : toutes les images du contenu ont commencé à se charger différemment du jour au lendemain.
Ce retour d’expérience n’est pas une simple présentation de la fonctionnalité. On a eu le temps de la voir tourner en production, de constater ce qui marche bien, et surtout de tomber sur les deux ou trois cas où elle fait plus de mal que de bien. Voici ce qu’on a appris, avec les chiffres qu’on a pu mesurer sur nos propres projets.
Ce que WordPress 5.5 a changé concrètement
Avant WordPress 5.5, le lazy-loading des images demandait systématiquement un plugin comme a3 Lazy Load ou une bibliothèque JavaScript type lazysizes. Depuis la version 5.5, WordPress ajoute automatiquement l’attribut loading="lazy" sur les balises <img> générées dans le contenu, dans les widgets d’image et sur les avatars, via la fonction wp_filter_content_tags(). Le navigateur se charge ensuite lui-même de différer le chargement des images situées hors du viewport initial, sans JavaScript additionnel.
Concrètement, sur un article de blog classique avec cinq ou six images, seules la ou les images visibles au premier écran sont chargées immédiatement ; les suivantes ne sont récupérées que lorsque l’utilisateur s’approche d’elles en scrollant. C’est le navigateur qui décide de la marge de déclenchement, WordPress se contente de poser l’attribut.
Comment fonctionne le filtre wp_lazy_loading_enabled
Le comportement par défaut n’est pas gravé dans le marbre. WordPress expose le filtre wp_lazy_loading_enabled, qui reçoit le nom de la balise HTML concernée et le contexte d’appel, et qui permet d’activer ou de désactiver l’attribut au cas par cas.
// Désactiver le lazy-load uniquement sur les images du thème (balises <img> hors contenu)
add_filter( 'wp_lazy_loading_enabled', function( $default, $tag_name, $context ) {
if ( 'the_content' !== $context ) {
return false;
}
return $default;
}, 10, 3 );On s’en sert régulièrement pour retirer le lazy-load des logos, des images de header ou de tout élément qu’on sait toujours visible au chargement. Le troisième paramètre $context est précieux : il indique d’où vient l’appel (the_content, the_post_thumbnail, widget_text_content, etc.), ce qui évite de désactiver le filtre trop largement.
Le cas qui fait mal : l’image héro en lazy-load
C’est le piège qu’on a rencontré sur près d’un tiers des sites audités depuis la sortie de la 5.5. Beaucoup de thèmes injectent l’image mise en avant d’un article directement dans le flux via the_content ou via une balise <img> classique de template, sans distinction particulière. Résultat : WordPress lui colle loading="lazy" même quand cette image occupe tout le premier écran, ce qui retarde son chargement au lieu de l’accélérer.
Le souci, c’est que le navigateur ne peut savoir qu’une image sera visible immédiatement qu’après avoir calculé la mise en page, et sur une image en lazy-load, il attend en pratique un signal de proximité avant même de lancer la requête réseau. Sur une image qui sert de Largest Contentful Paint (LCP), c’est-à-dire souvent la bannière ou l’illustration principale de l’article, ce délai se répercute directement sur la métrique.
Notre parade est devenue systématique sur les thèmes que nous développons : on retire le lazy-load de la première image du contenu ou de l’image mise en avant lorsqu’elle est utilisée comme header visuel.
// Retirer loading="lazy" sur la première image d'un article
add_filter( 'wp_get_attachment_image_attributes', function( $attr, $attachment, $size ) {
static $is_first = true;
if ( is_singular() && $is_first ) {
unset( $attr['loading'] );
$is_first = false;
}
return $attr;
}, 10, 3 );L’impact mesuré sur le LCP
Sur cinq sites clients où l’on a appliqué ce correctif entre février et mai 2021, on a comparé les rapports Lighthouse avant/après avec la même méthodologie (test en local, réseau simulé, cinq passages moyennés) :
- Site vitrine avec une bannière pleine largeur : LCP passé de 2,9 s à 2,71 s, soit environ 190 ms gagnés
- Blog d’actualité avec image mise en avant en tête d’article : gain de 150 ms en moyenne
- Site e-commerce avec carrousel d’images produit : gain plus modeste, autour de 90 ms, car l’image du carrousel était déjà préchargée via
rel="preload"
La moyenne sur nos mesures tourne autour de 180 ms de LCP gagnés rien qu’en excluant l’image du premier écran du lazy-load automatique. Ce n’est pas énorme dans l’absolu, mais ça suffit régulièrement à faire basculer un score Lighthouse de la zone orange à la zone verte, et ça compte dans l’évaluation des Core Web Vitals que Google a commencé à intégrer comme signal de classement en mai 2021.
Ce qu’on retient sur le terrain
Passé ce piège de l’image héro, le lazy-load natif tient largement ses promesses sur le reste de la page. Pour les articles longs et les pages riches en médias, le gain sur le poids initial transféré est net : on observe souvent une réduction de 30 à 50 % du volume d’images chargées au premier affichage sur les pages avec beaucoup de contenu sous la ligne de flottaison.
Notre règle depuis WordPress 5.5 : on garde le lazy-load natif activé partout par défaut, et on ne le désactive qu’explicitement pour les images dont on est certain qu’elles seront visibles dès le chargement. Jamais l’inverse.
Autre point utile : le lazy-load natif fonctionne aussi sur les <iframe> depuis la 5.7, sortie en mars 2021, ce qui couvre les vidéos YouTube ou Vimeo embarquées et allège encore le chargement initial des pages qui en contiennent plusieurs.
Les cas où on le désactive complètement
- Sites avec une seule image par page, systématiquement visible au chargement
- Galeries en lightbox où toutes les vignettes doivent être prêtes avant l’ouverture
- Contextes où un script tiers de lazy-loading (type lazysizes) est déjà en place, pour éviter les conflits entre les deux mécanismes
En résumé
Le lazy-load natif de WordPress 5.5 est une bonne nouvelle sans configuration à faire dans l’immense majorité des cas : il réduit le poids initial des pages sans qu’on ait à installer quoi que ce soit. Mais il n’est pas magique, et son application aveugle sur l’image la plus importante de la page peut dégrader la métrique même qu’on cherche à améliorer.
Notre conseil après dix mois d’usage réel : auditez systématiquement votre LCP après la mise à jour vers 5.5 ou une version ultérieure, identifiez l’élément qui sert de référence pour cette métrique, et utilisez le filtre wp_lazy_loading_enabled ou l’attribut loading="eager" pour l’exclure si besoin. Le reste, laissez WordPress s’en occuper.
