Le lazy loading natif de WordPress : quand il nuit aux Core Web Vitals

Depuis plusieurs versions, WordPress ajoute automatiquement l'attribut de chargement différé sur les images qu'il produit. L'intention est bonne : ne pas télécharger ce que le visiteur ne voit pas économise de la bande passante et accélère l'affichage initial. Le problème est que ce comportement s'applique sans discernement, y compris à l'image de couverture placée en haut de la page, celle qui détermine précisément la mesure d'affichage du contenu principal. Différer cette image ajoute une étape avant son téléchargement et retarde la mesure de plusieurs centaines de millisecondes. Nous expliquons ici comment le mécanisme fonctionne, comment identifier les images à exclure et comment corriger le comportement sans extension supplémentaire. L'intervention se chiffre en quelques dizaines de lignes dans un thème enfant et elle produit l'un des gains de performance les plus francs disponibles sur une installation courante.

Comment le mécanisme fonctionne

Comprendre ce que WordPress fait exactement permet d'intervenir au bon endroit plutôt que d'empiler les correctifs.

L'attribut ajouté automatiquement

Toute image insérée par les fonctions natives reçoit un attribut indiquant au navigateur qu'elle peut être chargée plus tard. Le navigateur décide alors lui même du moment, généralement lorsque l'image approche de la zone visible. Ce mécanisme est intégré aux navigateurs et il ne demande aucun script, ce qui constitue son principal avantage sur les solutions par extension. Les enjeux généraux de cette technique sont détaillés dans notre article sur le lazy loading et ses effets sur le SEO. Le comportement est fiable et bien pris en charge. Le problème ne vient pas du mécanisme mais de son application indifférenciée. Le navigateur ne peut pas deviner qu'une image donnée est celle qui compte : il applique la consigne reçue. La responsabilité de la distinction revient donc entièrement au site.

La règle appliquée par WordPress

Les versions récentes tentent d'exclure automatiquement la première image de la page, en partant du principe qu'elle est probablement la plus visible. Cette heuristique fonctionne dans les cas simples et elle échoue régulièrement. Un logo dans l'en-tête, une icône décorative ou une image de widget peuvent être comptés comme première image, ce qui laisse l'image de couverture différée. Le comportement dépend donc entièrement de la structure du gabarit. Vérifier ce que fait réellement le site est indispensable, l'automatisme ne pouvant pas être supposé correct. Ce contrôle prend deux minutes : afficher le code source d'une page d'article, chercher la balise de l'image de couverture et regarder les attributs qu'elle porte. Le résultat est sans ambiguïté et il évite de raisonner sur des suppositions. Il faut le refaire sur chaque gabarit, les structures différant d'un type de page à l'autre.

Le coût du report

Une image différée n'est découverte qu'après l'analyse de la mise en page, ce qui retarde son téléchargement de plusieurs centaines de millisecondes. Sur une connexion mobile, ce retard s'ajoute à celui du téléchargement lui même. L'image de couverture étant très souvent l'élément qui détermine la mesure d'affichage du contenu principal, ce retard se reporte intégralement sur l'indicateur. Les origines de dégradation de cette mesure sont exposées dans notre article sur le problème de LCP. Le gain d'un côté produit donc une perte plus importante de l'autre. C'est un cas typique d'optimisation appliquée au mauvais endroit. L'économie réalisée porte sur une image que le visiteur allait voir de toute façon, tandis que le coût porte sur l'indicateur le plus surveillé. Le bilan est nettement négatif sur la quasi totalité des gabarits d'article.

Le cas des images de fond

Une image déclarée en style de fond n'est pas concernée par cet attribut, qui ne s'applique qu'aux balises d'image. Elle est en revanche découverte tardivement, après le chargement de la feuille de style. Le résultat est comparable et la correction diffère, puisqu'il faut alors recourir au préchargement. Distinguer les deux situations avant d'agir évite de chercher un attribut qui n'existe pas. Le contrôle se fait en inspectant l'élément dans le navigateur. Il oriente immédiatement vers la bonne correction. Lorsque c'est possible, remplacer une image de fond décorative par une balise d'image classique simplifie durablement la situation, puisque tous les mécanismes d'adaptation redeviennent disponibles. Cette bascule demande un ajustement de style et elle en vaut souvent la peine.

L'interaction avec les extensions

Beaucoup d'extensions de performance proposent leur propre mécanisme de chargement différé, par script. Lorsqu'elles cohabitent avec le mécanisme natif, les deux s'appliquent et produisent des comportements imprévisibles. La règle consiste à n'en conserver qu'un, de préférence le natif qui ne demande aucun script. Désactiver la fonction équivalente dans l'extension supprime une source de conflits. Cette vérification figure rarement dans les procédures d'installation. Elle explique plusieurs comportements erratiques signalés sur les forums, notamment des images qui ne s'affichent jamais ou qui apparaissent avec un retard important. Le diagnostic consiste à désactiver la fonction dans l'extension et à observer si le comportement redevient normal. Ce test prend une minute.

La priorité de chargement

Un attribut complémentaire permet d'indiquer au navigateur qu'une image est importante et doit être téléchargée en priorité. Les versions récentes de WordPress l'appliquent à l'image jugée principale, avec la même heuristique imparfaite. Cet attribut et l'attribut de report sont mutuellement exclusifs sur une même image. Vérifier lequel est appliqué à l'image de couverture constitue le contrôle décisif. Une image portant l'attribut de report alors qu'elle est visible immédiatement signale le problème à corriger. Ce diagnostic se fait dans le code source de la page, sur une session anonyme et non depuis l'administration. Une image portant les deux attributs simultanément signale un conflit entre le cœur et une extension. Dans ce cas, l'un des deux mécanismes doit être désactivé avant d'aller plus loin.

Identifier les images à exclure

La correction suppose de savoir précisément quelles images doivent conserver le chargement différé et lesquelles doivent en être exemptées.

Repérer l'élément déterminant

Les outils d'audit indiquent quel élément constitue le plus grand contenu affiché dans la zone visible. Cette information doit être relevée gabarit par gabarit, l'élément variant selon le type de page. Sur un article, il s'agit généralement de l'image de couverture ou du titre. Sur une page de liste, il peut s'agir de la première vignette. Ce relevé prend cinq minutes par gabarit et il oriente entièrement la correction. Sans lui, on corrige au hasard. Il faut également noter que cet élément peut changer selon la largeur d'écran : un titre sur mobile, une image sur ordinateur. Relever les deux cas donne une image complète et évite une correction qui n'améliore qu'une partie du trafic.

Distinguer par position

Toute image susceptible d'apparaître dans la zone visible au chargement doit être exclue du report. Cette zone varie selon la taille de l'écran, ce qui impose de raisonner sur le cas le plus défavorable. Sur mobile, elle correspond aux six cents premiers pixels environ. Une image placée plus bas peut sans risque conserver le report. Cette règle de position est plus fiable que le comptage d'images pratiqué par l'automatisme. Elle demande de connaître la structure du gabarit, ce qui se lit en une inspection rapide. Une marge de sécurité est préférable : exclure une image qui aurait pu être différée coûte peu, différer une image visible coûte cher. En cas de doute, l'exclusion est le choix prudent.

Le logo et les éléments d'en-tête

Le logo est toujours visible immédiatement et il ne doit jamais être différé. Il est également léger, ce qui rend le report doublement inutile. Les icônes de réseaux sociaux et les éléments décoratifs de l'en-tête relèvent du même traitement. Ces éléments sont souvent produits par le thème, ce qui impose d'intervenir à un autre endroit que pour les images de contenu. Les traiter en vectoriel intégré supprime purement et simplement la question. Cette solution est préférable lorsqu'elle est possible, le format vectoriel intégré au document ne déclenchant aucune requête et s'affichant instantanément. Elle règle simultanément la question du report, celle du poids et celle du rendu sur écran à forte densité.

Les vignettes de la première rangée

Sur une page de liste, les deux ou trois premières vignettes apparaissent immédiatement et doivent être exclues. Les suivantes bénéficient légitimement du report. Cette distinction demande de compter la position dans la boucle d'affichage, ce qui se code en quelques lignes. Elle produit un gain sensible sur les pages d'archive, souvent négligées dans les optimisations. Le nombre à exclure dépend de la mise en page et du nombre de colonnes. Une vérification visuelle sur mobile tranche la question : ouvrir la page, ne pas faire défiler, et compter les vignettes visibles. Ce nombre constitue la valeur à retenir dans la boucle d'affichage. Sur une grille de trois colonnes, il s'agit généralement des trois premières.

Les images dans le contenu

Une image insérée par le rédacteur au début d'un article peut se trouver dans la zone visible sur un écran de bureau. Les traiter toutes comme différées est acceptable si l'image de couverture est correctement exclue, celle-ci étant l'élément déterminant. Sur un gabarit sans image de couverture, la première image du contenu prend ce rôle et doit être exclue. Cette configuration existe sur certains thèmes et elle mérite un contrôle spécifique. Le comportement diffère alors complètement. Il faut donc raisonner par gabarit et non globalement. Un tableau listant chaque gabarit avec son élément déterminant et les exclusions à appliquer constitue le document de travail de toute cette intervention. Il tient sur une demi-page et il sert lors de chaque évolution du site.

Les images hors écran malgré tout

Un carrousel dont seule la première diapositive est visible ne doit exclure que celle-ci. Un onglet dont le contenu est masqué au chargement ne doit rien exclure. Ces cas particuliers sont fréquents sur les pages construites avec un constructeur visuel. Ils demandent une vérification manuelle plutôt qu'une règle générale. Le contrôle consiste à observer les téléchargements dans l'onglet réseau au chargement de la page. Une image téléchargée alors qu'elle est invisible signale une exclusion excessive. L'inverse, une image visible dont le téléchargement démarre tardivement, signale une exclusion manquante. Ces deux symptômes se lisent dans la même vue en cascade, ce qui rend le contrôle rapide.

Corriger le comportement

Plusieurs points d'intervention existent et le choix dépend de l'endroit où l'image est produite.

Le filtre sur les attributs

WordPress expose un filtre permettant de modifier les attributs de chaque image avant leur écriture. Une condition sur le contexte permet de retirer l'attribut de report et d'ajouter celui de priorité haute. Cette intervention se place dans le thème enfant et elle survit aux mises à jour. Elle constitue la méthode la plus propre pour les images produites par les fonctions natives. Une vingtaine de lignes couvrent les cas courants d'un site de contenu. La logique doit rester lisible pour être maintenue. Une bonne pratique consiste à écrire une fonction dédiée par gabarit plutôt qu'une longue suite de conditions imbriquées. Le code reste alors compréhensible six mois plus tard, y compris par quelqu'un d'autre.

La désactivation globale

Il est possible de désactiver entièrement le mécanisme natif par un filtre, puis de le réappliquer manuellement là où il est utile. Cette approche donne un contrôle total et elle impose de traiter tous les cas soi même. Elle se justifie sur un site où la structure est complexe et où l'automatisme se trompe systématiquement. Sur un site classique, elle représente plus de travail que de bénéfice. Le choix entre correction ciblée et reprise complète dépend du nombre de cas problématiques. Deux ou trois exceptions plaident pour la correction ciblée. Au delà d'une dizaine, la reprise complète devient plus simple à raisonner et à maintenir. Ce seuil se constate rapidement en dressant la liste des cas problématiques.

L'image mise en avant

La fonction d'affichage de l'image mise en avant accepte des attributs supplémentaires, ce qui permet de traiter le cas sans filtre global. Cette intervention se fait dans le gabarit du thème enfant, à l'endroit où l'image est appelée. Elle est la plus lisible et la plus facile à maintenir. Elle suppose que le thème permette de surcharger ce gabarit, ce qui est le cas des thèmes bien construits. Sur un thème commercial ne le permettant pas, le filtre global reste la solution. La différence de robustesse est faible. Le principal critère de choix reste la lisibilité pour la personne qui reprendra le site. Une correction visible à l'endroit où l'image est appelée se comprend immédiatement, un filtre global demande de savoir où chercher.

Le préchargement complémentaire

Retirer le report ne suffit pas toujours, notamment lorsque l'image est déclarée en style de fond. Une déclaration de préchargement, limitée à cette seule image et conditionnée au gabarit, complète alors la correction. Elle doit rester unique, plusieurs préchargements annulant l'effet de priorité. Cette technique se combine bien avec le retrait du report sur les images en balise. Elle demande une déclaration dans l'en-tête de la page. Son efficacité se vérifie dans l'ordre de téléchargement, l'image devant apparaître parmi les toutes premières requêtes. Si elle reste en milieu de liste, c'est que la déclaration entre en concurrence avec d'autres préchargements. Réduire leur nombre rétablit l'effet recherché.

Le lien avec les tailles servies

Corriger le report sans corriger la déclaration de largeur d'affichage produit un gain partiel : l'image démarre plus tôt et elle reste trop lourde. Les deux corrections se complètent et doivent être menées ensemble. Le mécanisme complet est détaillé dans notre article sur les images responsive de WordPress. Traiter les deux points lors de la même intervention économise du temps. Le gain cumulé dépasse largement la somme des deux pris isolément. C'est le chantier image le plus rentable sur une installation courante, devant la conversion aux formats modernes et devant l'installation de toute extension d'optimisation. Il demande une demi journée et il ne coûte aucun abonnement.

Vérifier après correction

Le contrôle consiste à consulter le code source et à confirmer que l'image de couverture ne porte pas l'attribut de report et porte celui de priorité. L'onglet réseau confirme ensuite que son téléchargement démarre parmi les premiers. Une mesure d'audit avant et après chiffre le gain obtenu. Ces trois vérifications prennent cinq minutes et elles constituent la validation complète. Elles doivent être refaites sur chaque gabarit corrigé. Documenter les valeurs permet de détecter une régression future. Un tableau à trois colonnes, gabarit, valeur avant, valeur après, suffit amplement. Il sert de preuve du travail accompli et de référence lors du prochain contrôle.

Maintenir le résultat

Ces corrections sont fragiles face aux évolutions du site et quelques précautions les préservent.

Contrôler après chaque mise à jour

Une mise à jour du cœur, du thème ou d'une extension peut modifier le comportement ou l'ordre des filtres. Un contrôle rapide, consistant à vérifier les attributs de l'image de couverture sur trois gabarits, détecte la régression. Cette vérification prend deux minutes et elle mérite une place dans la liste des contrôles de mise à jour. Elle évite de perdre silencieusement le bénéfice du travail effectué. Un contrôle automatisé remplirait le même rôle sans intervention. Il se développe en une demi journée et il consiste simplement à récupérer trois pages, à chercher les attributs attendus et à alerter en cas d'écart. Ce contrôle peut être déclenché après chaque déploiement, ce qui supprime entièrement le risque de régression silencieuse.

Surveiller les mesures de terrain

Les données réelles confirment le gain avec quelques semaines de décalage, sur la fenêtre d'observation habituelle. Suivre l'évolution de la mesure d'affichage principal sur les gabarits corrigés valide la démarche. Une absence d'amélioration signale que l'élément déterminant n'était pas celui que l'on croyait. Cette information est précieuse et elle oriente vers un autre chantier. Le suivi mensuel suffit largement. Il s'inscrit dans le suivi général des indicateurs d'expérience.

Documenter les exceptions

Chaque exclusion doit être accompagnée d'un commentaire indiquant l'élément concerné et la raison. Sans cette trace, une personne intervenant plus tard retirera la correction en pensant simplifier. Le commentaire doit mentionner le gabarit et le gain mesuré. Il tient en deux lignes et il change la maintenabilité du site. Cette documentation se place directement dans le code, à côté de la correction. Elle y reste utile bien plus longtemps qu'un document séparé.

Former les contributeurs

Les personnes qui publient doivent savoir que l'image de couverture a un statut particulier et qu'une image très lourde y produit un effet démesuré. Une consigne simple sur les dimensions et le poids maximal suffit à éviter les dérives. Un contrôle automatique au téléversement complète utilement la consigne. Ces deux mesures évitent de refaire régulièrement le même travail de correction. Elles s'inscrivent dans la formation initiale à l'outil. Elles prennent un quart d'heure à expliquer.

Revoir lors des refontes

Un changement de thème ou de mise en page modifie complètement quel élément est déterminant. Les corrections en place deviennent alors inadaptées, voire contre-productives. Une revue de ces réglages doit figurer dans la liste des tâches de toute refonte. Elle prend une heure et elle évite de reconduire des exclusions devenues inutiles. Cette revue est l'occasion de vérifier également les tailles générées et la déclaration de largeur. Les trois sujets se traitent naturellement ensemble.

Ne pas empiler les solutions

La tentation d'installer une extension supplémentaire pour corriger un comportement se solde généralement par des conflits. Une correction de quelques lignes dans le thème enfant est plus robuste, plus rapide et plus facile à diagnostiquer qu'une extension de plus. Cette règle vaut bien au delà du sujet traité ici. Elle constitue probablement le conseil le plus utile à donner sur la performance d'une installation courante. Chaque extension retirée améliore la situation. Chaque extension ajoutée demande une justification.