Les images représentent souvent la part la plus lourde d’une page WordPress. La réponse habituelle consiste à augmenter la compression, au risque de dégrader les visuels. Le principal gaspillage vient pourtant d’images trop grandes, servies dans un format inadapté ou chargées avant d’être utiles.
Mesurer avant de compresser
Une image de 2400 pixels n’a aucun intérêt dans une carte affichée sur 420 pixels. Le navigateur peut la réduire visuellement, mais il doit tout de même télécharger le fichier d’origine. Sur mobile, ce décalage consomme des données et retarde l’affichage sans améliorer le résultat perçu.
L’analyse doit distinguer l’image principale visible au chargement, les images placées plus bas et les petits éléments d’interface. Une image susceptible de devenir le Largest Contentful Paint exige une priorité différente. À l’inverse, charger trop tôt toutes les illustrations d’un article ralentit la page pour une ressource que le lecteur ne verra peut-être jamais.
Le navigateur sait choisir si WordPress lui donne le choix
WordPress crée plusieurs tailles lors de l’import et génère les attributs srcset et sizes. Le navigateur peut alors sélectionner un fichier adapté à la largeur et à la densité de l’écran. Ce mécanisme perd son intérêt si le thème appelle systématiquement l’image originale ou si les tailles déclarées ne correspondent pas à la mise en page.
WebP offre généralement un bon rapport entre poids et qualité pour la photographie et les compositions riches. AVIF peut aller plus loin, mais son intérêt dépend de la chaîne de production, du support et du temps d’encodage. Le choix du format ne dispense jamais de dimensionner correctement l’image.
Une chaîne d’image simple et contrôlable
La meilleure optimisation reste celle que l’équipe peut appliquer à chaque publication. Un processus court évite les fichiers surdimensionnés et limite le recours à des extensions qui retraitent toute la médiathèque.
- Recadrer l’image au ratio réellement utilisé par le thème.
- Limiter la largeur originale à la plus grande taille d’affichage utile.
- Exporter en WebP avec une qualité visuelle contrôlée sur écran.
- Conserver les dimensions width et height dans le HTML afin d’éviter les décalages.
- Réserver le chargement différé aux images situées hors du premier écran.
Contrôler le terrain, pas seulement Lighthouse
Lighthouse révèle des fichiers mal dimensionnés et donne une estimation des économies possibles. Les données CrUX et Search Console indiquent ensuite ce que vivent les visiteurs réels. Les deux lectures se complètent : le laboratoire aide au diagnostic, le terrain confirme l’effet sur des appareils et des connexions variés.
Le poids total ne raconte pas tout. Une page peut contenir plusieurs mégaoctets d’images sans pénaliser son premier affichage si les ressources hors écran sont différées. À l’inverse, un seul visuel principal mal priorisé peut détériorer le LCP malgré un poids total raisonnable.
Le lazy loading n’est pas une règle universelle
L’attribut loading=lazy convient aux images éloignées du haut de page. Appliqué à l’image principale, il peut retarder le téléchargement de la ressource que le navigateur devrait demander en priorité. La présence du mot lazy ne garantit donc pas une amélioration.
Une extension d’optimisation peut automatiser la conversion et la compression. Elle ne corrige pas un thème qui appelle la mauvaise taille, un carrousel qui télécharge dix images ou une bibliothèque qui conserve plusieurs traitements redondants. Le diagnostic doit précéder l’ajout d’un outil.
La qualité visuelle et la vitesse ne s’opposent pas. Une image adaptée à son emplacement peut être plus nette, plus légère et plus stable qu’un original affiché au hasard.
Sources et lectures
Votre situation
Vos images ralentissent-elles réellement votre site ?
Nous auditons le thème, les tailles générées et le chemin de chargement avant de recommander une modification ou une extension.