WebP ou AVIF sur WordPress : quel format choisir et comment convertir vos images sans plugin

Vous avez sans doute déjà lu qu’il fallait « passer au WebP », puis qu’il fallait « passer à l’AVIF », parfois dans le même article. Et pourtant, la plupart des sites WordPress que j’audite servent encore des JPEG sortis tout droit de l’appareil photo, faute d’avoir tranché.

Le choix n’a rien de mystérieux. Je vous explique ce qui sépare vraiment les deux formats, ce que WordPress sait faire sans extension, comment convertir vos nouveaux envois avec un filtre officiel, quoi faire de la médiathèque existante, et comment vérifier que le visiteur reçoit bien le format prévu.

WebP ou AVIF : ce qui les sépare vraiment

Les deux formats font le même travail que le JPEG, avec une compression plus moderne. Ils gèrent tous les deux la transparence, et peuvent donc aussi remplacer bien des PNG. La différence se joue sur trois critères.

Le poids. L’AVIF descend plus bas que le WebP à qualité visuelle égale. L’équipe du cœur de WordPress l’annonce, dans sa note technique sur l’arrivée de l’AVIF en version 6.5, jusqu’à 50 % plus léger qu’un JPEG équivalent. C’est leur chiffre, pas le mien : le gain réel dépend énormément de la photo, et je vous montre plus bas comment mesurer le vôtre.

La compatibilité. Selon caniuse.com, le WebP est lu par 97,18 % des navigateurs en usage et l’AVIF par 96,35 %. L’écart vient surtout des anciens Safari : l’AVIF n’est pris en charge qu’à partir de Safari 16.4 sur Mac (16.0 sur iPhone) et d’Edge 121. Un visiteur sur un vieux Mac non mis à jour verra une image cassée si vous ne lui servez que de l’AVIF.

Le coût de fabrication. C’est le critère que tout le monde oublie. Encoder un AVIF demande nettement plus de calcul qu’un WebP. Sur un site qui envoie trois images par semaine, on s’en moque. Sur une boutique qui importe cent photos produits d’un coup, ça pique. Et WordPress 7.1 a déplacé ce coût sur votre ordinateur, j’y reviens plus bas.

Ce que WordPress fait tout seul (et ce qu’il ne fait pas)

Sachez que WordPress accepte le WebP depuis la version 5.8 (juin 2021) et l’AVIF depuis la version 6.5 (2024). Vous pouvez donc envoyer directement un fichier .webp ou .avif dans la médiathèque. WordPress en tire ses tailles intermédiaires (miniature, moyenne, grande) dans le même format que l’original.

Ce qu’il ne fait pas, c’est la conversion. Par défaut, un JPEG envoyé produit des tailles intermédiaires en JPEG. La seule conversion active d’origine concerne les photos HEIC des iPhone, transformées en JPEG. Pour obtenir du WebP ou de l’AVIF à partir de vos JPEG, il faut le demander explicitement.

Depuis WordPress 7.1, la donne change en partie : le redimensionnement, la compression et la conversion se font dans votre navigateur, via une version WebAssembly de la bibliothèque libvips, et non plus sur le serveur. Je l’ai détaillé dans mon bilan de WordPress 7.1. Ce traitement ne fonctionne que sous Chrome et Edge 137 ou plus récents. Avec Firefox, Safari, un appareil de 2 Go de mémoire ou moins, une connexion très lente (2G) ou le mode économie de données, WordPress repasse automatiquement par le serveur.

Vérifier que votre serveur sait écrire l’AVIF

Le traitement côté navigateur ne vous dispense pas de ce contrôle, puisque WordPress retombe sur le serveur dès que le navigateur ne suit pas. Le serveur, lui, s’appuie sur Imagick ou GD, et l’un comme l’autre doivent avoir été compilés avec le format voulu. Pour le savoir en deux minutes :

1. Ouvrez Outils > Santé du site, puis l’onglet Infos.
2. Dépliez la section Traitement des médias.
3. Repérez la ligne Éditeur actif : elle indique si WordPress utilise Imagick ou GD.
4. Dans la liste des formats pris en charge par cet éditeur (ligne Formats de fichier ImageMagik pris en charge pour Imagick, telle qu’affichée par WordPress, ou Formats de fichier GD pris en charge pour GD), cherchez WEBP et AVIF.

Si l’AVIF manque, inutile de forcer : demandez à votre hébergeur une version de PHP dont Imagick ou GD gère ce format, ou restez au WebP, présent presque partout. Au passage, Imagick peut se montrer gourmand en mémoire sur de grandes photos. Si vos envois échouent avec un message de mémoire épuisée, voyez mon guide sur l’erreur « Allowed memory size exhausted ».

Convertir vos nouveaux envois avec un filtre officiel

Pas la peine d’installer une extension lourde pour cette étape. WordPress fournit depuis la version 5.8 le filtre image_editor_output_format, qui associe un format d’entrée à un format de sortie. Concrètement, vous lui dites : « chaque fois qu’on m’envoie un JPEG, fabrique les tailles intermédiaires en WebP ».

Le plus propre consiste à créer une petite extension « indispensable » (must-use plugin en anglais), chargée automatiquement et impossible à désactiver par erreur. Faites d’abord une sauvegarde, ma méthode est dans le guide pour sauvegarder un site WordPress. Créez ensuite par FTP le fichier wp-content/mu-plugins/format-images.php (le dossier mu-plugins est à créer s’il n’existe pas) avec ce contenu :

<?php
/**
 * Plugin Name: Format de sortie des images
 * Description: Fabrique les tailles intermédiaires des JPEG en WebP.
 */

// Associe le type d'entrée (JPEG) au type de sortie voulu (WebP).
// Pour l'AVIF, remplacez 'image/webp' par 'image/avif'.
add_filter( 'image_editor_output_format', function ( $formats ) {
	$formats['image/jpeg'] = 'image/webp';
	return $formats;
} );

Deux remarques sur ce code. La fonction renvoie le tableau reçu en le complétant, ce qui préserve la conversion HEIC vers JPEG que WordPress y place par défaut depuis la version 6.7. Et j’ai volontairement laissé les PNG de côté : une capture d’écran pleine de texte s’en sort parfois mieux en PNG qu’en compression avec perte.

Bonne nouvelle pour WordPress 7.1 : la documentation officielle confirme que le traitement dans le navigateur respecte ce filtre. Votre réglage s’applique donc quel que soit le chemin emprunté. Votre fichier d’origine, lui, reste conservé dans son format, car WordPress en a besoin pour régénérer les tailles plus tard.

La contrainte de l’AVIF depuis WordPress 7.1

Si vous choisissez l’AVIF, gardez en tête que l’encodage se fait désormais sur la machine de la personne qui envoie l’image. Sur un portable récent, ça passe. Sur un vieil ordinateur de rédaction, l’import d’une série de photos peut traîner, et WordPress limite de toute façon le traitement à deux images simultanées. Je n’ai pas chronométré moi-même ces temps, et je me méfie des mesures qui circulent sans préciser la taille des fichiers ni la machine. Si la médiathèque devient pénible, le filtre wp_client_side_media_processing_enabled renvoie tout le traitement au serveur :

// À ajouter dans le même fichier : rend le traitement des images au serveur.
add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );

Et la médiathèque existante ?

Le filtre ne touche que les images envoyées après son ajout. Pour les anciennes, la commande WP-CLI wp media regenerate refabrique les tailles intermédiaires, en appliquant votre nouveau format :

# Régénère les tailles de toutes les images, sans supprimer les anciens fichiers
wp media regenerate --skip-delete --yes

L’option --skip-delete n’est pas décorative. Vos articles publiés contiennent l’adresse des anciennes tailles en dur, du genre photo-1024x683.jpg. Sans cette option, WP-CLI supprime ces fichiers et vos articles affichent des images cassées. Avec elle, rien ne casse, mais ces anciens articles continuent de servir leurs JPEG : seuls les contenus créés ensuite profitent du nouveau format.

C’est là qu’une extension garde un intérêt. Modern Image Formats, publiée par l’équipe Performance de WordPress, génère de l’AVIF ou du WebP, peut servir une version de repli en JPEG aux navigateurs qui ne suivent pas, et se règle dans Réglages > Médias. Soyons clairs : je ne l’ai pas testée sur ce site, je vous la signale parce qu’elle vient de l’équipe du cœur et qu’elle annonce une compatibilité avec WordPress 7.1.3, pas parce que je la recommande les yeux fermés. Une conversion déléguée à votre hébergeur ou à un CDN d’images est l’autre voie, sans rien toucher à la médiathèque.

Vérifier le format réellement servi

Ne vous fiez pas à l’extension du fichier. Certains caches et CDN servent du WebP derrière une adresse en .jpg, et l’inverse arrive aussi. Ce qui compte, c’est le type annoncé par le serveur. Voici comment je contrôle :

1. Ouvrez un article récent dans Chrome, appuyez sur F12 et allez dans l’onglet Réseau.
2. Filtrez sur Img, puis rechargez la page.
3. Lisez la colonne Type : elle affiche webp, avif ou jpeg, quelle que soit l’adresse. La colonne Taille vous donne le poids transféré.

Pour une image précise, la ligne de commande donne la même réponse :

# Affiche l'en-tête Content-Type renvoyé pour l'image
curl -sI https://votresite.fr/wp-content/uploads/2026/10/photo-1024x683.webp | grep -i content-type

Pour mesurer le gain, comparez le poids des images d’une même page avant et après, sur deux ou trois articles représentatifs. C’est ce chiffre-là, le vôtre, qui doit guider la suite, pas un pourcentage lu ailleurs. Les autres leviers de vitesse sont dans mon guide pour optimiser la vitesse d’un site WordPress.

Ce que je ferais à votre place

Pour un blog, un site vitrine ou un site d’association, je prends le WebP sans hésiter. Il couvre la quasi-totalité des visiteurs, il se fabrique vite, et le gain sur le JPEG est déjà net. L’AVIF devient intéressant sur un site très chargé en photos, si votre serveur le gère, si vous acceptez des imports plus lents et si une version de repli existe pour les vieux Safari.

Trois actions pour cette semaine : vérifiez les formats pris en charge dans Santé du site, posez le filtre WebP dans un mu-plugin après une sauvegarde, puis contrôlez la colonne Type de l’onglet Réseau sur votre prochain article. Le reste de la méthode (dimensions, compression, texte alternatif) est dans mon guide pour optimiser les images sur WordPress. Et si je ne devais garder qu’un conseil : redimensionnez vos photos avant l’envoi, car une image de 4 000 pixels reste trop lourde dans n’importe quel format.