Optimiser les images WordPress : WebP, AVIF, Gutenberg et performances

Optimiser les images WordPress : Un site WordPress peut être parfaitement développé, utiliser un hébergement performant et disposer d’un système de cache efficace, tout en restant lent à afficher. La raison est parfois beaucoup plus simple qu’on ne l’imagine : des images trop volumineuses, mal dimensionnées ou chargées au mauvais moment.

Une photographie de plusieurs mégaoctets affichée sur un téléphone, une image à la une chargée inutilement en pleine résolution ou une galerie composée de fichiers non optimisés peuvent augmenter considérablement les données transférées aux visiteurs.

Pourtant, WordPress possède déjà plusieurs mécanismes capables d’améliorer la gestion des images : génération de différentes tailles, affichage responsive, chargement différé et prise en charge de formats modernes.

Depuis WordPress 7.1, une évolution supplémentaire permet même d’effectuer certaines opérations de traitement directement dans le navigateur de l’utilisateur, lorsque les conditions techniques sont réunies.

Dans ce guide, nous allons comprendre le fonctionnement de ces mécanismes, apprendre à préparer correctement les images, examiner les avantages et limites de WebP et AVIF, puis construire une méthode de vérification reproductible.

L’objectif n’est pas d’obtenir artificiellement un score parfait dans un outil de mesure, mais de rendre le site réellement plus efficace pour ses visiteurs.

1. Pourquoi les images peuvent-elles ralentir WordPress ?

Lorsqu’un visiteur ouvre une page, son navigateur doit récupérer plusieurs ressources.

Le document HTML constitue le point de départ. Le navigateur télécharge ensuite les feuilles de style, les scripts, les polices et les images nécessaires à l’affichage.

Toutes ces ressources n’ont pas le même poids ni la même importance.

Une icône peut ne représenter que quelques kilo-octets. Une photographie issue d’un appareil récent peut occuper plusieurs mégaoctets.

Une image affichée en petit n’est pas nécessairement légère

Imaginons une photographie de 6000 × 4000 pixels pesant 8 Mo.

Elle est insérée dans un article WordPress, puis affichée dans une colonne de 700 pixels de largeur.

Visuellement, elle semble adaptée à la page.

Mais si le navigateur reçoit le fichier original, il doit malgré tout télécharger ses 8 Mo.

Réduire les dimensions d’affichage avec du CSS ne réduit pas automatiquement le poids du fichier téléchargé.

Cette distinction est fondamentale.

Il faut séparer trois notions :

Notion	Signification	Exemple
Dimensions intrinsèques	Nombre de pixels du fichier	6000 × 4000
Dimensions d’affichage	Espace occupé dans la page	700 × 467
Poids du fichier	Quantité de données à transférer	8 Mo

Une optimisation efficace agit sur les dimensions réellement nécessaires, le format d’encodage et le poids final.

Pourquoi les utilisateurs mobiles sont-ils particulièrement concernés ?

Un ordinateur connecté à une connexion rapide peut télécharger plusieurs mégaoctets sans que le délai soit immédiatement perceptible.

Sur un téléphone, les conditions peuvent être différentes.

Le visiteur peut disposer d’une connexion instable, d’un appareil moins puissant ou d’une quantité limitée de données mobiles.

Le navigateur doit également décoder les images et les intégrer à la page.

Une image mal optimisée peut donc pénaliser à la fois le téléchargement et le travail nécessaire à son affichage.

2. Comprendre JPEG, PNG, WebP et AVIF

Avant d’optimiser une image, il faut comprendre les principales différences entre les formats.

Tous ne répondent pas aux mêmes besoins.

JPEG : un format encore parfaitement utilisable

JPEG est particulièrement adapté aux photographies.

Il utilise une compression avec perte, ce qui signifie que certaines informations visuelles sont supprimées pour réduire le poids du fichier.

Lorsque le niveau de compression est raisonnable, cette perte peut rester peu perceptible.

JPEG demeure donc pertinent, notamment lorsqu’une compatibilité très large est recherchée.

En revanche, il ne prend pas en charge la transparence comme PNG, WebP ou AVIF.

PNG : utile pour les images nécessitant une conservation précise

PNG utilise une compression sans perte.

Il convient notamment aux images comportant des zones transparentes, à certains graphiques et à des visuels nécessitant une conservation exacte des pixels.

Pour une photographie complexe, un fichier PNG peut être beaucoup plus lourd qu’un JPEG ou un format moderne équivalent.

Il serait donc inefficace de convertir systématiquement toutes les photographies en PNG.

WebP : un compromis intéressant

WebP prend en charge la compression avec perte et sans perte.

Il permet également de gérer la transparence.

Pour de nombreuses photographies et illustrations destinées au Web, il peut produire des fichiers plus légers qu’un JPEG ou un PNG, à qualité visuelle comparable.

Cela ne signifie pas qu’un fichier WebP sera systématiquement plus petit.

Le résultat dépend du contenu, de l’encodeur et des paramètres de compression.

AVIF : une autre possibilité d’optimisation

AVIF repose sur une technologie de compression plus récente.

Il peut offrir une excellente efficacité, notamment pour certaines photographies.

Cependant, son encodage peut nécessiter davantage de ressources et sa prise en charge côté serveur dépend de l’environnement utilisé.

Le choix doit donc tenir compte des capacités de traitement, du navigateur et de la qualité réellement obtenue.

Tableau comparatif

Format	Photographies	Transparence	Compression	Usage courant
JPEG	Oui	Non	Avec perte	Photographies classiques
PNG	Possible, souvent lourd	Oui	Sans perte	Graphiques, transparence
WebP	Oui	Oui	Avec ou sans perte	Images Web optimisées
AVIF	Oui	Oui	Avec ou sans perte	Images modernes optimisées
SVG	Non adapté aux photographies	Oui	Vectoriel	Logos, pictogrammes

Attention à SVG : il s’agit d’un format vectoriel pouvant contenir des éléments actifs. Son utilisation dans WordPress exige une politique de validation adaptée. Il ne faut pas autoriser arbitrairement tous les fichiers SVG téléversés par les utilisateurs.

Quel format choisir ?

Pour un site éditorial classique, WebP constitue souvent un bon point de départ.

AVIF mérite d’être évalué lorsqu’il apporte une réduction supplémentaire du poids sans dégradation visuelle gênante.

PNG reste utile lorsque la fidélité exacte des pixels est importante.

Le meilleur choix n’est donc pas celui qui possède systématiquement le fichier le plus petit, mais celui qui offre un équilibre acceptable entre qualité, poids, compatibilité et maintenance.

3. Comment WordPress gère-t-il les images ?

WordPress ne se contente pas d’enregistrer un fichier dans sa bibliothèque de médias.

Lorsqu’une image est ajoutée, il peut générer plusieurs versions adaptées à différents usages.

La génération de tailles intermédiaires

Une image de grande taille peut notamment produire des variantes correspondant aux dimensions configurées dans WordPress.

Ces paramètres sont accessibles dans :

Réglages > Médias

On y retrouve les dimensions des miniatures, des images moyennes et des grandes images.

Les thèmes et extensions peuvent également déclarer des tailles supplémentaires.

Le résultat exact dépend de la configuration du site et du mécanisme de traitement disponible.

À quoi servent srcset et sizes ?

Depuis WordPress 4.4, le CMS prend en charge les images responsives en générant notamment les attributs HTML srcset et sizes.

Ces attributs permettent au navigateur de choisir une ressource adaptée à l’espace d’affichage et à la densité de pixels de l’écran.

Prenons cet exemple pédagogique :

<img
  src="paysage-800.webp"
  srcset="
    paysage-400.webp 400w,
    paysage-800.webp 800w,
    paysage-1200.webp 1200w
  "
  sizes="(max-width: 768px) 100vw, 800px"
  width="800"
  height="533"
  alt="Paysage de montagne reflété dans un lac"
>

Le navigateur dispose ici de trois versions.

Il peut sélectionner celle qui correspond le mieux aux dimensions d’affichage et aux caractéristiques de l’appareil.

Cet exemple illustre le mécanisme HTML. Les noms des fichiers sont fictifs et doivent correspondre à des ressources réellement disponibles.

Dans un site WordPress standard, il n’est généralement pas nécessaire d’écrire manuellement ces attributs. Le CMS les génère pour les images dont il connaît les tailles disponibles. WordPress Developer Resources

4. WordPress 7.1 : une évolution importante du traitement des images

WordPress 7.1, publié le 19 août 2026, introduit une évolution technique intéressante : le traitement de certaines images directement dans le navigateur.

Au 23 octobre 2026, la dernière version publiée dans la branche 7.1 est WordPress 7.1.3, datée du 6 octobre 2026. WordPress.org

Comment fonctionnait principalement le traitement auparavant ?

Dans le fonctionnement traditionnel, l’utilisateur envoyait son image au serveur.

Le serveur utilisait ensuite des bibliothèques comme GD ou Imagick pour effectuer les opérations nécessaires.

Ces opérations pouvaient notamment comprendre :

• Le redimensionnement.
• La rotation.
• La génération des miniatures.
• La compression.
• Certaines conversions de format.

Le traitement consommait donc des ressources du serveur.

Sur un hébergement limité, l’importation de grandes images pouvait provoquer des délais ou des erreurs liées à la mémoire disponible.

Que change WordPress 7.1 ?

Lorsque les conditions techniques sont réunies, le navigateur peut effectuer certaines opérations avant de transmettre les fichiers au serveur.

WordPress utilise notamment WebAssembly et une version adaptée de libvips.

Cette approche permet de déplacer une partie du travail de traitement vers l’appareil de l’utilisateur.

Le serveur reçoit alors les fichiers et les différentes tailles générées.

Est-ce disponible sur tous les navigateurs ?

Non.

La documentation officielle indique que le traitement complet côté navigateur est disponible sous certaines conditions avec les navigateurs Chromium récents, notamment Chrome et Edge à partir de la version 137.

Le mécanisme dépend également de capacités techniques précises et des ressources de l’appareil.

Sur Firefox et Safari, le traitement traditionnel côté serveur reste utilisé pour ce pipeline. Certaines fonctions particulières, notamment liées aux images HEIC, disposent de comportements spécifiques.

Pourquoi cette précision est-elle importante ?

Parce qu’il serait incorrect d’affirmer que WordPress 7.1 traite désormais toutes les images localement, sur tous les navigateurs et dans toutes les circonstances.

Le système prévoit un repli vers le serveur lorsque le traitement côté navigateur n’est pas disponible.

Il faut également distinguer deux notions.

Le traitement local dans le navigateur signifie que certaines opérations sont effectuées sur l’appareil de l’utilisateur.

L’hébergement local ou souverain signifie que les fichiers et les services sont conservés dans une infrastructure maîtrisée.

Le traitement côté navigateur ne signifie donc pas que les images ne seront jamais envoyées au serveur WordPress.

Les fichiers destinés à être publiés sont toujours transmis à l’installation WordPress.

Les conséquences pour les développeurs

Cette évolution nécessite une attention particulière lorsqu’une extension personnalise le traitement des médias.

Certains hooks liés à la génération des images continuent de fonctionner, mais leur ordre ou leur contexte d’exécution peut différer.

D’autres hooks propres au traitement serveur ne sont pas exécutés lorsque l’opération a lieu dans le navigateur.

Les extensions qui ajoutent des filigranes, génèrent des miniatures spécifiques ou synchronisent des médias vers un stockage externe doivent donc être testées avec les deux méthodes de traitement.

La documentation officielle explique précisément ces différences. WordPress Developer Resources

5. Tutoriel pratique : optimiser une image avant son importation

Nous allons maintenant appliquer une méthode accessible, sans installation obligatoire d’une extension WordPress.

Étape 1 — Identifier les images les plus importantes

Commencez par sélectionner une page représentative de votre site.

Il peut s’agir de la page d’accueil, d’un article contenant plusieurs photographies ou d’une page de services.

Identifiez notamment :

• L’image principale visible dès l’ouverture.
• Les images à la une.
• Les photographies présentes dans les articles.
• Les images utilisées dans les galeries.
• Les arrière-plans de grande taille.

Ne cherchez pas immédiatement à convertir toute la médiathèque.

Il est préférable de comprendre les besoins réels d’une page avant d’engager une optimisation massive.

Étape 2 — Mesurer la situation initiale

Avant de modifier les fichiers, effectuez une première mesure.

L’outil PageSpeed Insights permet d’analyser une page sur mobile et sur ordinateur.

Il combine des diagnostics de laboratoire avec des données d’utilisation réelle lorsque celles-ci sont disponibles.

Les résultats peuvent notamment mettre en évidence des ressources volumineuses ou des problèmes de chargement. Google for Developers

Notez les informations suivantes :

Mesure	Avant optimisation	Après optimisation
Poids de l’image principale	À mesurer	À mesurer
Poids total des images transférées	À mesurer	À mesurer
Largest Contentful Paint	À mesurer	À mesurer
Cumulative Layout Shift	À mesurer	À mesurer
Nombre de requêtes d’images	À mesurer	À mesurer

Cette méthode permet de comparer des résultats observés plutôt que de supposer qu’une conversion améliore automatiquement le site.

Étape 3 — Déterminer les dimensions utiles

Supposons qu’une image soit destinée à occuper une largeur maximale de 800 pixels dans un article.

Il n’est pas toujours nécessaire de conserver un fichier de 6000 pixels de largeur pour cet usage.

Une variante plus grande peut néanmoins être utile pour les écrans à forte densité de pixels.

Il faut donc tenir compte de la largeur réellement affichée et de la densité d’affichage souhaitée.

Il n’existe pas une dimension universelle convenant à toutes les images WordPress.

Pour une image à la une, les dimensions dépendent également du thème et des différents emplacements dans lesquels elle sera utilisée.

Étape 4 — Préparer le fichier

Avant l’importation, vérifiez :

1. Le cadrage de l’image.
2. Ses dimensions.
3. Son orientation.
4. Son format.
5. Son poids.
6. Sa qualité visuelle après compression.
7. Les éventuelles métadonnées à conserver ou supprimer.

Un fichier peut être optimisé avec un logiciel local, sans utiliser de service cloud.

Cette approche peut être particulièrement intéressante pour les documents confidentiels ou les photographies qui n’ont pas vocation à être transmises à une plateforme externe.

Étape 5 — Comparer plusieurs encodages

À partir de la même image, préparez éventuellement trois variantes :

• Une version JPEG.
• Une version WebP.
• Une version AVIF.

Comparez leur poids, mais également les détails visibles.

Examinez les zones sombres, les dégradés, les contours, les textures et les éventuels textes intégrés.

Une compression trop importante peut produire des défauts visibles.

Le fichier le plus petit n’est pas automatiquement le meilleur.

Étape 6 — Choisir un nom de fichier compréhensible

Un nom descriptif facilite l’organisation de la médiathèque.

Par exemple :

installation-wordpress-local.webp

est généralement plus compréhensible que :

IMG_20261023_084512.webp

Le nom du fichier ne remplace toutefois pas le texte alternatif, le contexte de la page ou la qualité du contenu éditorial.

Il doit rester descriptif et éviter l’accumulation artificielle de mots-clés.

6. Importer correctement une image dans Gutenberg

Ouvrez un article dans l’éditeur WordPress.

Ajoutez un bloc Image.

Vous pouvez importer un nouveau fichier ou sélectionner un élément déjà présent dans la médiathèque.

Comprendre les champs disponibles

WordPress permet d’associer plusieurs informations à une image.

Champ	Utilité
Titre média	Identifier le fichier dans la médiathèque
Texte alternatif	Transmettre la signification de l’image lorsqu’elle ne peut pas être perçue visuellement
Légende	Afficher une information visible sous l’image
Description	Fournir des informations complémentaires dans la médiathèque
Résolution	Choisir la taille d’image utilisée dans le bloc

Ces champs ne sont pas interchangeables.

Le texte alternatif : une question d’accessibilité

Le texte alternatif doit dépendre du rôle de l’image dans son contexte.

Pour une photographie informative, il peut décrire brièvement ce qu’elle montre.

Pour une image utilisée comme bouton ou comme lien, il doit plutôt communiquer l’action ou la destination.

Une image purement décorative peut nécessiter un attribut alternatif vide.

Il serait donc incorrect d’imposer un texte descriptif à toutes les images sans distinction.

Le W3C propose un arbre de décision officiel pour choisir le traitement approprié. W3C

Pourquoi éviter les textes alternatifs artificiels ?

Un texte comme :

« WordPress WebP AVIF SEO optimisation images performance vitesse référencement »

n’explique pas réellement l’image.

Il accumule des expressions destinées aux moteurs de recherche au détriment de l’utilisateur.

Un texte alternatif doit avant tout transmettre une information utile.

Choisir la résolution dans le bloc

Dans les réglages du bloc Image, WordPress permet de sélectionner une résolution, selon les variantes disponibles.

Pour une image affichée dans une colonne étroite, une taille intermédiaire peut être suffisante.

Pour une photographie occupant toute la largeur d’un écran, une résolution supérieure peut être nécessaire.

Il faut ensuite vérifier le fichier réellement téléchargé par le navigateur, car les attributs responsives peuvent influencer cette sélection.

La documentation officielle détaille les réglages du bloc Image, les résolutions et les métadonnées disponibles. WordPress.org

7. Le chargement différé : utile, mais pas partout

Le chargement différé, ou lazy loading, consiste à reporter le téléchargement de certaines ressources jusqu’au moment où elles deviennent nécessaires.

Ce mécanisme est particulièrement intéressant pour les images situées loin dans une page.

Un long article contenant plusieurs photographies n’a pas nécessairement besoin de télécharger toutes les images dès son ouverture.

Exemple HTML

<img
  src="illustration.webp"
  width="800"
  height="450"
  loading="lazy"
  decoding="async"
  alt="Illustration d'un environnement de développement"
>

L’attribut loading="lazy" indique au navigateur que le chargement peut être différé.

L’attribut decoding="async" fournit une indication sur le décodage de l’image.

Pourquoi ne faut-il pas appliquer lazy loading à toutes les images ?

Parce qu’une image importante, visible immédiatement à l’ouverture de la page, doit généralement être chargée rapidement.

Si l’image principale est différée, cela peut augmenter le délai nécessaire pour afficher le contenu visuel le plus important.

Google recommande explicitement d’éviter le chargement différé de l’image responsable du Largest Contentful Paint. web.dev

Le rôle de fetchpriority

L’attribut HTML fetchpriority permet de donner une indication de priorité au navigateur.

Par exemple :

<img
  src="image-principale.webp"
  width="1600"
  height="900"
  fetchpriority="high"
  alt="Présentation visuelle du site"
>

Cette indication peut être pertinente pour une image principale clairement identifiée.

Mais il ne faut pas appliquer fetchpriority="high" à toutes les images.

Cela ferait perdre son intérêt au mécanisme de priorité.

WordPress gère déjà plusieurs optimisations

Le noyau WordPress possède des mécanismes qui déterminent les attributs de chargement selon le contexte.

Ils peuvent notamment gérer loading, decoding et fetchpriority.

Il est donc préférable d’inspecter le HTML réellement généré avant d’ajouter des règles personnalisées.

Une intervention manuelle non maîtrisée pourrait entrer en conflit avec les optimisations natives. WordPress Developer Resources

8. Les Core Web Vitals : comprendre ce que l’on mesure

Les Core Web Vitals sont des indicateurs destinés à évaluer certains aspects de l’expérience utilisateur.

Trois mesures sont particulièrement importantes.

LCP — Largest Contentful Paint

Le LCP mesure le moment auquel le plus grand élément de contenu éligible devient visible.

Il peut s’agir d’une grande image, d’un bloc de texte ou d’un autre élément admissible.

Pour une bonne expérience, Google recommande un LCP inférieur ou égal à 2,5 secondes, mesuré au 75e percentile des chargements.

Une image principale trop lourde peut contribuer à dégrader cet indicateur.

CLS — Cumulative Layout Shift

Le CLS mesure l’instabilité visuelle de la page.

Imaginons qu’un visiteur commence à lire un paragraphe.

Une image située au-dessus apparaît soudainement et pousse le texte vers le bas.

Ce déplacement peut être pris en compte dans le CLS.

L’indicateur recommandé est inférieur ou égal à 0,1.

Déclarer correctement les dimensions des images permet au navigateur de réserver l’espace nécessaire et peut limiter certains déplacements.

INP — Interaction to Next Paint

L’INP évalue la réactivité de la page aux interactions.

Le seuil recommandé pour une bonne expérience est de 200 millisecondes ou moins.

L’optimisation des images peut réduire certains travaux de décodage ou de rendu, mais l’INP dépend aussi fortement du JavaScript et des tâches exécutées par le navigateur.

Il serait donc trompeur de promettre qu’une conversion WebP améliorera systématiquement l’INP.

Les trois indicateurs sont décrits dans la documentation officielle Web Vitals. web.dev

9. Peut-on automatiser la conversion des images dans WordPress ?

Oui, mais il faut distinguer plusieurs méthodes.

Première approche : préparer les images avant leur importation

C’est la méthode la plus simple à comprendre.

Le rédacteur prépare son fichier, choisit son format et l’importe dans WordPress.

Elle ne nécessite pas d’extension supplémentaire.

Elle convient particulièrement aux sites disposant d’un volume raisonnable de publications.

Deuxième approche : utiliser une extension spécialisée

Certaines extensions peuvent automatiser la compression, la conversion et la génération de formats modernes.

Il faut cependant examiner leur fonctionnement réel.

Certaines travaillent directement sur le serveur.

D’autres utilisent un service distant.

D’autres encore modifient les URL des images ou les règles de distribution.

Avant de choisir une extension, vérifiez notamment :

• Où les images sont traitées.
• Si les fichiers originaux sont conservés.
• Comment les anciennes images sont converties.
• Comment les URL sont modifiées.
• Si la restauration est possible.
• Si le traitement fonctionne avec les images des thèmes et extensions.
• Si plusieurs mécanismes de conversion risquent d’entrer en conflit.

Une extension ne doit pas être installée uniquement parce qu’elle promet un pourcentage élevé de compression.

Troisième approche : utiliser les filtres WordPress

Pour les développeurs, WordPress propose le filtre image_editor_output_format.

Il permet de définir des correspondances entre formats d’entrée et de sortie.

L’exemple suivant demande à WordPress d’utiliser WebP comme format de sortie pour les images JPEG traitées par le mécanisme concerné :

<?php
/**
 * Exemple pédagogique : conversion JPEG vers WebP.
 * À tester dans une extension dédiée ou un environnement local.
 */

add_filter(
    'image_editor_output_format',
    static function ( $formats ) {
        $formats['image/jpeg'] = 'image/webp';

        return $formats;
    }
);

Que fait exactement ce code ?

Il ajoute une règle de conversion au tableau des formats utilisés par le moteur de traitement.

Il ne convertit pas automatiquement tous les fichiers historiques de la médiathèque.

Il ne garantit pas non plus que chaque serveur possède les capacités nécessaires pour générer du WebP.

Le comportement doit être vérifié dans l’environnement réel, notamment lorsque WordPress utilise le traitement côté navigateur ou son mécanisme de repli côté serveur.

La documentation officielle confirme l’existence et l’utilisation de ce filtre. WordPress Developer Resources

Pourquoi ne pas modifier directement les fichiers du noyau WordPress ?

Parce que les modifications risqueraient d’être écrasées lors d’une mise à jour.

Un développement spécifique doit être placé dans un emplacement approprié, par exemple une extension dédiée.

Pour une fonctionnalité indépendante de l’apparence du site, une extension est généralement plus pertinente qu’une modification du thème.

10. Les images déjà présentes dans la médiathèque

C’est un problème fréquent sur les sites anciens.

Un site peut contenir plusieurs années de photographies importées sans stratégie d’optimisation.

Faut-il toutes les convertir immédiatement ?

Pas nécessairement.

Commencer par un inventaire

Il faut identifier les images réellement utilisées et celles qui sont responsables des transferts les plus importants.

Une ancienne image de grande taille présente dans la médiathèque, mais jamais affichée, n’a pas le même impact qu’une photographie lourde présente sur la page d’accueil.

Prévoir une sauvegarde

Avant une conversion massive, sauvegardez les fichiers et la base de données.

Certaines méthodes peuvent modifier les fichiers physiques, leurs métadonnées ou les références utilisées dans les contenus.

Une conversion réussie sur une image ne garantit pas que l’ensemble de la médiathèque pourra être traité sans difficulté.

Tester les miniatures et les liens

Après conversion, vérifiez notamment :

• Les images dans les articles.
• Les images à la une.
• Les galeries.
• Les pages utilisant des blocs de couverture.
• Les images intégrées par des extensions.
• Les éventuels liens directs vers les fichiers originaux.

Si le site utilise un cache ou un réseau de distribution, il peut également être nécessaire de purger les ressources anciennes.

Une nouveauté de WordPress 7.1 ne signifie pas une conversion rétroactive

Le traitement côté navigateur introduit dans WordPress 7.1 concerne principalement le processus de traitement des médias.

Il ne faut pas en déduire que toute une médiathèque historique sera automatiquement convertie en AVIF ou WebP après une mise à jour.

Les opérations sur les anciens fichiers doivent être préparées et vérifiées séparément.

11. Métadonnées EXIF : performance et confidentialité

Une photographie peut contenir des informations invisibles dans l’image affichée.

Ces informations sont appelées métadonnées.

Elles peuvent notamment renseigner sur l’appareil utilisé, la date de prise de vue ou, dans certains cas, la localisation.

Pourquoi faut-il les examiner ?

Pour deux raisons principales.

La première concerne le poids du fichier : certaines métadonnées occupent de l’espace supplémentaire.

La seconde concerne la confidentialité.

Une photographie destinée à un site public ne devrait pas divulguer involontairement des informations de localisation sensibles.

Faut-il supprimer toutes les métadonnées ?

Pas systématiquement.

Certaines informations, comme les profils colorimétriques, peuvent être utiles pour préserver le rendu des couleurs.

D’autres peuvent être nécessaires dans des contextes professionnels ou documentaires.

La bonne méthode consiste à déterminer quelles métadonnées doivent être conservées et lesquelles peuvent être supprimées.

Les mécanismes de traitement WordPress 7.1 possèdent également des paramètres relatifs à la conservation des métadonnées lors de la génération des images. WordPress Developer Resources

12. Image à la une, image de contenu et image Open Graph

Une même image peut être utilisée dans plusieurs contextes.

Mais ces contextes ne possèdent pas nécessairement les mêmes dimensions.

L’image à la une

Elle sert généralement à représenter un article dans le thème WordPress.

Selon le thème, elle peut apparaître dans les archives, les listes d’articles et les pages individuelles.

L’image insérée dans le contenu

Elle accompagne une explication.

Son texte alternatif et sa légende doivent être adaptés à ce qu’elle apporte réellement au lecteur.

L’image Open Graph

Elle est destinée notamment aux aperçus de partage sur les réseaux sociaux.

Un format de 1200 × 630 pixels constitue une cible couramment utilisée pour préparer ce type de visuel.

Il faut cependant vérifier le résultat dans les plateformes concernées, car les recadrages et les conditions d’affichage peuvent varier.

Pourquoi prévoir des marges de sécurité ?

Lorsqu’un visuel contient une signature, un texte ou un élément graphique important, celui-ci ne doit pas être placé trop près des bords.

Un recadrage automatique pourrait le supprimer.

Pour ATOOLPHA, une petite signature discrète intégrée au visuel permet de conserver une identification éditoriale sans transformer l’image en publicité.

13. Vérifier les résultats après optimisation

Une fois les modifications effectuées, il faut mesurer à nouveau la page.

Mais attention à une erreur fréquente : comparer deux résultats obtenus dans des conditions très différentes.

Les bonnes conditions de comparaison

Essayez de conserver :

• La même URL.
• Une configuration de cache comparable.
• Le même type d’appareil simulé.
• Des conditions de mesure aussi proches que possible.
• Un nombre suffisant de mesures pour limiter les variations.

Une seule mesure ne suffit pas toujours à établir une amélioration réelle.

Comprendre les données de laboratoire et les données réelles

PageSpeed Insights présente deux catégories d’informations.

Les données de laboratoire proviennent d’un test simulé.

Les données réelles, lorsqu’elles sont disponibles, représentent les expériences observées auprès d’utilisateurs.

Ces dernières peuvent porter sur une période de 28 jours.

Il est donc normal qu’une amélioration technique récente ne soit pas immédiatement visible dans toutes les statistiques d’utilisation réelle.

Un exemple de comparaison

Imaginons qu’une image de 2,4 Mo soit remplacée par une version de 420 Ko.

La réduction de poids serait d’environ 82,5 %.

Ce résultat pourrait réduire les données transférées pour cette ressource.

Mais il ne permet pas, à lui seul, d’affirmer que le LCP sera amélioré de 82,5 %.

Le temps de chargement dépend également de nombreux autres facteurs : serveur, cache, réseau, HTML, CSS, JavaScript et priorité des ressources.

Une réduction de poids est une mesure. Une amélioration de l’expérience utilisateur doit être vérifiée séparément.

14. Les erreurs les plus fréquentes

Convertir toutes les images sans vérifier leur qualité

Une conversion massive peut produire des artefacts ou altérer certaines images.

Il faut contrôler les résultats, notamment pour les logos, les illustrations techniques et les graphiques.

Installer plusieurs extensions qui effectuent la même conversion

Deux systèmes modifiant simultanément les formats, les miniatures ou les URL peuvent créer des conflits.

Une architecture simple et compréhensible facilite la maintenance.

Supprimer immédiatement les originaux

Conserver temporairement les originaux permet de revenir en arrière si une conversion produit un résultat incorrect.

La politique de conservation doit néanmoins tenir compte du stockage disponible et des exigences de confidentialité.

Charger toutes les images avec une priorité élevée

La priorité doit être réservée aux ressources qui en ont réellement besoin.

Appliquer les mêmes attributs à toutes les images peut dégrader le comportement du navigateur.

Ignorer l’accessibilité

Une image légère n’est pas nécessairement accessible.

Le texte alternatif, la lisibilité, le contraste et le contexte restent importants.

Ne tester que la page d’accueil

Une optimisation peut fonctionner sur une page et provoquer un problème sur une autre.

Les archives, les articles, les galeries et les pages utilisant des composants particuliers doivent également être vérifiés.

15. Construire une méthode de maintenance durable

L’optimisation des images ne devrait pas être une opération exceptionnelle réalisée uniquement lorsqu’un site devient lent.

Elle peut être intégrée à la méthode de publication.

Étape	Contrôle recommandé
Préparation	Vérifier les dimensions et le cadrage
Compression	Comparer qualité et poids
Importation	Contrôler le fichier enregistré
Métadonnées	Examiner confidentialité et informations utiles
Gutenberg	Choisir la résolution adaptée
Accessibilité	Rédiger un texte alternatif pertinent
Performance	Vérifier le chargement réel
Publication	Contrôler les versions mobile et ordinateur
Maintenance	Surveiller les régressions

Cette démarche peut être appliquée manuellement, puis progressivement automatisée lorsque le volume de publication le justifie.

Elle permet de conserver la maîtrise des fichiers et de limiter les dépendances techniques inutiles.

Conclusion — Une image optimisée est une image adaptée à son usage

L’optimisation des images WordPress ne se résume pas à convertir tous les fichiers en WebP ou en AVIF.

Elle consiste à comprendre ce que le visiteur doit réellement télécharger, à quel moment et pour quel usage.

WordPress dispose déjà de mécanismes importants : tailles intermédiaires, images responsives, gestion des priorités et chargement différé.

WordPress 7.1 apporte une évolution supplémentaire en permettant, sous certaines conditions, de déplacer une partie du traitement vers le navigateur.

Ces fonctionnalités ne dispensent cependant pas d’une méthode de travail.

Le développeur doit connaître les contraintes du serveur. Le rédacteur doit préparer correctement ses fichiers. L’administrateur doit vérifier les résultats et préserver la possibilité de revenir en arrière.

Un site performant n’est pas nécessairement celui qui utilise le plus grand nombre d’extensions d’optimisation. C’est celui dont les ressources sont adaptées aux besoins réels de ses utilisateurs.

En matière de performance comme de sécurité, la méthode reste la même : mesurer, comprendre, intervenir et vérifier.

ATOOLPHA — Comprendre avant d’agir.

Documentation officielle

Les références suivantes permettent d’approfondir les mécanismes présentés dans ce guide :

WordPress Developer — Responsive Images

Documentation des images responsives

WordPress Developer — Client-Side Media Processing

Traitement des images dans WordPress 7.1

WordPress Developer — Image Output Format

Filtre image_editor_output_format

WordPress.org — Image Block

Documentation du bloc Image

WordPress.org — Media Settings

Paramètres de la médiathèque

Google — PageSpeed Insights

Comprendre les mesures PageSpeed

W3C — Web Accessibility Initiative

Choisir correctement le texte alternatif d’une image