Les images responsive de WordPress : srcset, tailles et formats modernes

WordPress gère les images adaptatives depuis plusieurs années sans qu'aucune intervention ne soit nécessaire : chaque image téléversée produit plusieurs tailles, et les balises insérées dans le contenu portent automatiquement la liste de ces fichiers. Ce fonctionnement par défaut couvre l'essentiel des besoins et il comporte deux défauts qui coûtent cher. Le premier est la génération de tailles jamais servies, qui encombre le stockage. Le second, plus grave, est une déclaration de largeur d'affichage presque toujours fausse, qui conduit les navigateurs à télécharger des fichiers deux à trois fois trop grands. Nous expliquons ici comment le mécanisme fonctionne réellement, comment corriger ces deux points et comment ajouter les formats modernes sans casser l'existant.

Comment WordPress produit ses images adaptatives

Le mécanisme repose sur trois éléments distincts qu'il faut savoir distinguer pour intervenir efficacement.

La génération des tailles au téléversement

Au moment où une image est déposée dans la bibliothèque, WordPress crée automatiquement plusieurs versions redimensionnées et les enregistre à côté du fichier d'origine. Le cœur du système en déclare quatre, le thème en ajoute généralement deux à cinq, et chaque extension peut en déclarer d'autres. Une installation courante produit ainsi entre huit et vingt fichiers par image. Cette génération est irréversible dans le sens où retirer une taille plus tard ne supprime pas les fichiers déjà créés. L'interface d'administration expose seulement les dimensions des quatre tailles du cœur, dans les réglages des médias, le reste se déclarant exclusivement dans le code.

La liste des fichiers proposés au navigateur

Lorsqu'une image est affichée, WordPress construit un attribut listant toutes les tailles disponibles avec leur largeur réelle en pixels. Le navigateur y trouve donc plusieurs candidats et il choisit celui qui correspond à son besoin. Cette liste est construite automatiquement à partir des tailles générées, sans intervention. Elle exclut les tailles recadrées dont le rapport diffère de l'original, ce qui explique que certaines tailles n'y apparaissent jamais. Elle constitue la partie du mécanisme qui fonctionne le mieux par défaut. Elle n'a généralement pas besoin d'être modifiée.

La déclaration de la largeur d'affichage

Le second attribut indique au navigateur quelle place l'image occupera dans la mise en page selon la largeur de la fenêtre. C'est lui qui permet au navigateur de calculer le fichier nécessaire. WordPress renseigne par défaut une valeur générique qui suppose l'image affichée sur toute la largeur de l'écran, plafonnée à la taille de l'image. Cette hypothèse est fausse dans la quasi totalité des cas, une image d'article étant affichée dans une colonne de sept cents pixels sur un écran qui en fait mille neuf cents. Le navigateur télécharge alors le plus gros fichier disponible. Corriger ce point est de loin l'intervention la plus rentable sur le sujet.

Le choix effectué par le navigateur

Le navigateur combine la largeur d'affichage déclarée et la densité de son écran pour déterminer la largeur de fichier nécessaire, puis retient le plus petit candidat qui la satisfait. Sur un téléphone à densité trois affichant l'image sur trois cent cinquante points, il lui faut donc mille cinquante pixels. Il peut choisir plus grand s'il dispose déjà d'un fichier en cache. Ce comportement explique que deux appareils identiques ne téléchargent pas toujours le même fichier. Il rend inutile une granularité très fine dans les tailles proposées. Trois à cinq largeurs bien espacées suffisent largement.

Le cas des images de mise en avant

L'image mise en avant d'un article est affichée par le thème, qui choisit lui même la taille demandée et construit les attributs. Un thème mal écrit demande une taille fixe sans liste de candidats, ce qui supprime tout le bénéfice du mécanisme. Vérifier le code source d'une page d'article révèle immédiatement ce défaut. La correction se fait dans le thème enfant, en utilisant la fonction d'affichage appropriée. Ce cas est fréquent sur les thèmes commerciaux anciens. Il concerne pourtant l'image la plus visible de la page.

Le cas des constructeurs de pages

Les constructeurs visuels génèrent leur propre code d'affichage et ne respectent pas toujours le mécanisme natif. Certains insèrent l'image en style de fond, ce qui interdit toute adaptation automatique. D'autres produisent bien les attributs mais avec une déclaration de largeur encore moins pertinente que celle par défaut. Contrôler le résultat sur les gabarits construits avec ces outils est indispensable. Les corrections passent généralement par les réglages de l'outil plutôt que par le code. Certaines situations n'ont malheureusement pas de solution propre.

Corriger la déclaration de largeur

C'est l'intervention qui produit le plus de gain et elle demande une demi journée sur un site de taille moyenne.

Relever les largeurs réelles de la mise en page

Pour chaque gabarit, il faut noter la largeur maximale du conteneur d'image et son comportement aux différentes largeurs d'écran. Ces valeurs se lisent dans la feuille de style ou se mesurent directement avec l'inspecteur du navigateur. Une image d'article occupe typiquement toute la largeur sur mobile, puis une colonne fixe au delà d'un seuil. Une vignette de liste occupe une fraction de la largeur, variable selon le nombre de colonnes affichées. Ce relevé prend une demi heure et il conditionne toute la suite. Il doit couvrir les trois ou quatre gabarits principaux.

Écrire la déclaration correspondante

La déclaration s'exprime comme une suite de conditions de largeur d'écran associées à des largeurs d'affichage. Une image d'article s'écrit typiquement comme occupant la totalité de la largeur en dessous d'un seuil, puis une valeur fixe au delà. La dernière valeur de la liste s'applique par défaut, sans condition. La syntaxe est simple et elle se vérifie facilement en observant le fichier réellement téléchargé. Une déclaration correcte divise couramment par deux le poids des images téléchargées sur ordinateur. Ce gain est immédiat et il ne dégrade rien.

Appliquer la correction par gabarit

WordPress propose un point d'accroche permettant de remplacer la valeur générée, dans lequel une condition sur le contexte détermine la déclaration retournée. Cette fonction se place dans le thème enfant et elle survit aux mises à jour. Elle doit distinguer au minimum les images de contenu, les images mises en avant et les vignettes de liste. Une vingtaine de lignes suffisent à couvrir un site classique. La logique doit rester lisible, car elle sera relue lors des évolutions de la mise en page. Un commentaire indiquant à quelle règle de style chaque valeur correspond facilite grandement cette relecture.

Vérifier le fichier réellement téléchargé

Le contrôle se fait dans l'onglet réseau du navigateur, en observant le nom et le poids du fichier image chargé. Comparer ce fichier à la taille d'affichage mesurée révèle immédiatement un écart. Le test doit être mené à plusieurs largeurs de fenêtre, en simulant un appareil mobile. Un fichier de mille quatre cents pixels chargé pour une image affichée sur trois cent cinquante signale une déclaration encore fausse. Cette vérification prend deux minutes par gabarit. Elle constitue le seul moyen fiable de valider la correction.

Traiter le cas des images en pleine largeur

Un bandeau occupant toute la largeur de l'écran nécessite une déclaration différente et des tailles générées plus grandes. Le traiter avec la même règle que les images d'article produit soit un bandeau flou, soit des fichiers surdimensionnés partout. Déclarer une taille dédiée pour ces images, avec sa propre règle, résout le problème. Ces images sont peu nombreuses et elles justifient ce traitement particulier. Elles constituent souvent l'élément déterminant de la mesure d'affichage principal. Les soigner produit un effet visible dans les audits.

Mesurer le gain obtenu

Le poids total des images d'une page, relevé avant et après, chiffre le résultat de façon incontestable. Une réduction de quarante à soixante pour cent est courante sur un site n'ayant jamais traité ce point. La mesure doit être faite sur les mêmes pages et dans les mêmes conditions de simulation. Documenter ces valeurs permet de démontrer le travail et de détecter une régression future. Cette trace prend deux minutes à constituer. Elle sert lors des discussions budgétaires suivantes.

Réduire le nombre de tailles générées

Une fois la déclaration corrigée, la question du nombre de fichiers produits mérite d'être posée.

Inventorier ce qui existe

Une fonction du cœur retourne la liste complète des tailles déclarées, cœur, thème et extensions confondus. L'afficher sur une page d'administration temporaire révèle l'ampleur du phénomène. Comparer cette liste aux tailles réellement servies, relevées dans les journaux d'accès, identifie les candidates à la suppression. Cette comparaison constitue la seule base solide pour décider. Elle prend une demi heure et elle évite les suppressions à l'aveugle. Elle réserve souvent des surprises sur les tailles ajoutées par des extensions oubliées.

Retirer les tailles inutiles

Les tailles déclarées par le thème ou les extensions se retirent par une déclaration dans le thème enfant, appliquée après leur enregistrement. Les tailles du cœur se désactivent en fixant leurs dimensions à zéro dans les réglages. Chaque retrait doit être suivi d'un contrôle visuel sur les gabarits concernés. Un retrait trop rapide casse un affichage sans que personne ne le remarque immédiatement. La progressivité coûte peu et évite les retours en arrière. La méthode générale de calibrage d'un jeu de tailles est développée dans notre article sur la manière de servir des images responsive sans multiplier les fichiers inutiles.

Déclarer ses propres tailles

Une fois le ménage fait, les tailles correspondant réellement aux largeurs d'affichage relevées se déclarent explicitement. Chaque déclaration précise les dimensions et le comportement de recadrage. Le recadrage produit un rapport fixe, utile pour les vignettes de liste, et il coupe une partie de l'image. Le redimensionnement conserve les proportions et produit des hauteurs variables. Mélanger les deux comportements dans un même contexte produit des mises en page irrégulières. Ce choix se fait par gabarit et il mérite un test sur des images de proportions variées.

Régénérer ou non les images existantes

Les nouvelles tailles ne s'appliquent qu'aux images téléversées ensuite. Une extension permet de régénérer l'ensemble de la bibliothèque, opération qui prend plusieurs heures sur un catalogue important. Elle n'est pas toujours nécessaire, les tailles existantes continuant de fonctionner. Sur un site où la performance des anciennes pages compte, elle se justifie. Elle doit être lancée en dehors des heures d'affluence, après sauvegarde, et surveillée. Un serveur mutualisé peut d'ailleurs interrompre le traitement, ce qui impose de le relancer par lots.

Limiter la taille du fichier d'origine

Un contributeur qui dépose une photographie de huit mille pixels crée un fichier de plusieurs mégaoctets, conservé indéfiniment. WordPress limite désormais la dimension maximale des images téléversées et cette valeur peut être ajustée. La fixer à deux mille cinq cents pixels couvre tous les usages d'un site de contenu. Cette limite s'applique à la version conservée comme originale, ce qui économise un volume considérable. Elle évite également les traitements de redimensionnement très longs qui font échouer le téléversement. Sa mise en place tient en trois lignes.

Organiser la bibliothèque

Un dossier de médias contenant cinquante mille fichiers ralentit les sauvegardes, les migrations et l'interface d'administration. Les méthodes d'organisation et de purge d'une bibliothèque volumineuse sont détaillées dans notre article sur la façon de gérer les médias d'un site de cinq mille images. La réduction du nombre de tailles générées constitue le levier principal sur ce volume. Elle s'accompagne utilement d'une suppression des images orphelines. Ces deux opérations se mènent ensemble. Elles produisent un gain durable sur l'exploitation du site.

Ajouter les formats modernes

Les formats récents divisent le poids par deux à qualité comparable et leur mise en place demande quelques précautions.

Ce que WordPress prend en charge nativement

Les versions récentes acceptent le téléversement direct des formats modernes et génèrent leurs tailles normalement. Une image déposée dans un format récent produira donc des dérivés dans ce même format. Cette approche simple convient aux nouveaux contenus et laisse les anciens inchangés. Elle suppose que les contributeurs convertissent leurs images avant dépôt, ce qui demande un outil et une consigne. Elle constitue le point de départ le plus simple. Elle ne traite pas la bibliothèque existante.

La conversion automatique par extension

Plusieurs extensions convertissent les images à la volée et servent le format adapté selon le navigateur. Elles produisent des fichiers supplémentaires, ce qui augmente le volume stocké tout en réduisant le volume servi. Ce compromis est généralement favorable, le stockage coûtant moins cher que la bande passante et le temps de chargement. La qualité de conversion varie sensiblement d'une extension à l'autre et mérite un test comparatif. Les caractéristiques de chaque format sont exposées dans notre article sur la compression des images en WebP et AVIF. Un essai sur une vingtaine d'images représentatives permet de trancher.

La négociation par le serveur

Une approche sans extension consiste à générer les versions modernes lors du téléversement et à laisser le serveur servir le bon format selon ce que le navigateur annonce accepter. Cette méthode évite tout traitement à l'affichage et elle demande une configuration serveur. Elle est la plus performante et la moins accessible sur un hébergement mutualisé. Elle présente également l'avantage de ne pas modifier le code des pages. Elle convient aux sites disposant d'une équipe technique. Sa mise en place prend une demi journée.

Le réglage de la qualité

Le taux de compression détermine le compromis entre poids et rendu, et la valeur par défaut est souvent trop généreuse. Une qualité de soixante-quinze à quatre-vingts produit un résultat visuellement indiscernable pour un poids nettement inférieur. Ce réglage mérite un test sur des images représentatives du site, notamment des photographies avec des dégradés. Les images comportant du texte ou des aplats supportent moins bien la compression et justifient un réglage distinct. Ce test prend un quart d'heure et il produit un gain permanent. Il est rarement effectué.

Vérifier la compatibilité

Les formats modernes sont désormais reconnus par tous les navigateurs courants, avec des écarts sur les versions très anciennes. Le mécanisme de repli, qui sert le format historique aux navigateurs qui ne comprennent pas l'autre, doit rester en place. Vérifier ce repli demande de tester avec un navigateur ancien ou de simuler l'absence de prise en charge. Une extension mal configurée peut servir un format non reconnu, produisant des images invisibles pour une petite partie du public. Ce contrôle est rapide et il évite un problème difficile à détecter. Il doit être refait après chaque changement d'extension.

Contrôler après chaque mise à jour

Une mise à jour de thème ou d'extension peut réintroduire des tailles, modifier la déclaration de largeur ou désactiver la conversion. Un contrôle rapide, consistant à vérifier le fichier téléchargé sur trois gabarits, détecte ces régressions. Cette vérification prend cinq minutes et elle peut figurer dans la liste des contrôles de mise à jour. Elle évite de perdre le bénéfice d'un travail effectué des mois plus tôt. Un contrôle automatisé, comparant le poids des images d'une page à une valeur de référence, remplit le même rôle sans intervention. Il se met en place en une demi journée et il protège durablement.