vendredi 25 septembre 2026

À propos

Contact

Performance

Convertir ses images en WebP sur WordPress : le guide pratique complet

GD, Imagick, plugins de conversion, fallback pour les vieux navigateurs : voici comment passer vos images WordPress au format WebP sans rien casser.

Par Clément Hadrot • 26 août 2021 • 6 min de lecture • Aucun commentaire
Convertir ses images en WebP sur WordPress : le guide pratique complet

Le format WebP n’est pas une nouveauté : Google l’a introduit dès 2010, mais il a longtemps souffert d’un support navigateur trop fragmenté pour qu’on l’adopte sereinement sur des sites de production. Depuis la sortie de WordPress 5.8 en juillet dernier, la donne a changé : le cœur accepte désormais nativement l’upload de fichiers .webp dans la médiathèque, ce qui simplifie beaucoup les choses côté éditeur de contenu.

Reste que l’upload manuel ne suffit pas : la vraie valeur du WebP, c’est de convertir automatiquement toutes les images existantes et à venir, avec un filet de sécurité pour les navigateurs qui ne le comprennent pas encore. Ce tutoriel couvre les trois approches possibles — bibliothèque GD, Imagick, et plugins dédiés — avec leurs compromis respectifs.

Pourquoi le WebP fait une vraie différence de poids

Le format WebP utilise une compression avec ou sans perte plus efficace que le JPEG ou le PNG à qualité visuelle équivalente. Sur nos propres tests, menés sur une cinquantaine d’images photo (JPEG qualité 82) converties en WebP à qualité équivalente, on observe une réduction de poids moyenne d’environ 30 %, et jusqu’à 50 % sur des illustrations avec de larges aplats de couleur qui bénéficient aussi du support PNG-like sans perte du format.

Sur un site avec une bannière produit de 400 Ko en JPEG, on descend fréquemment sous les 280 Ko en WebP sans perte visible à l’œil nu. Multiplié par toutes les images d’une page produit ou d’un article riche en visuels, l’effet sur le temps de chargement et sur le LCP est loin d’être anecdotique.

Vérifier son support GD ou Imagick avant de se lancer

WordPress délègue le traitement des images à GD ou à Imagick, selon ce qui est disponible sur l’hébergement, via la classe WP_Image_Editor. Toutes les versions de ces bibliothèques ne savent pas encoder en WebP : GD ne l’a supporté qu’à partir de PHP 7.0 (avec libgd compilé avec le support WebP), et Imagick dépend de la version d’ImageMagick installée sur le serveur.

// À placer temporairement dans functions.php ou un mu-plugin pour vérifier le support
add_action( 'admin_notices', function() {
    if ( function_exists( 'imagewebp' ) ) {
        echo '<div class="notice notice-success"><p>GD supporte le WebP.</p></div>';
    } else {
        echo '<div class="notice notice-warning"><p>GD ne supporte pas le WebP sur cet hébergement.</p></div>';
    }
    if ( class_exists( 'Imagick' ) && in_array( 'WEBP', Imagick::queryFormats(), true ) ) {
        echo '<div class="notice notice-success"><p>Imagick supporte le WebP.</p></div>';
    }
} );

Sur un mutualisé bas de gamme, il n’est pas rare que ni l’un ni l’autre ne soit compilé avec le support WebP. Dans ce cas, mieux vaut passer par un plugin qui s’appuie sur une API de conversion externe plutôt que de forcer une génération côté serveur qui échouera silencieusement.

L'essentiel à retenir : WordPress 5.8 accepte enfin l'upload direct de fichiers .webp ; GD et Imagick permettent tous deux de générer du WebP côté serveur ; Un fallback reste indispensable pour Safari antérieur à la version 14

Générer automatiquement des versions WebP à l’upload

Si GD ou Imagick supporte le format, on peut accrocher la génération WebP directement sur le pipeline de création des tailles intermédiaires de WordPress, via le filtre wp_generate_attachment_metadata.

add_filter( 'wp_generate_attachment_metadata', function( $metadata, $attachment_id ) {
    $file = get_attached_file( $attachment_id );
    $editor = wp_get_image_editor( $file );

    if ( ! is_wp_error( $editor ) && $editor->supports_mime_type( 'image/webp' ) ) {
        $webp_path = preg_replace( '/\.(jpe?g|png)$/i', '.webp', $file );
        $editor->save( $webp_path, 'image/webp' );
    }

    return $metadata;
}, 10, 2 );

Cette approche crée un fichier .webp à côté de chaque original, sans toucher aux fichiers JPEG ou PNG existants. C’est la base sur laquelle on construit ensuite le mécanisme de fallback.

Les plugins qui font le travail à votre place

Écrire son propre pipeline de conversion a l’avantage de rester léger, mais pour la majorité des sites, un plugin dédié reste plus simple à maintenir dans la durée. Trois solutions reviennent régulièrement dans nos projets :

  • Imagify : conversion via API externe, génère des versions WebP en plus de compresser les originaux, avec quota gratuit mensuel
  • ShortPixel : fonctionnement similaire, avec une bonne gestion du fallback automatique via .htaccess
  • WebP Express : solution gratuite qui convertit localement (GD ou Imagick) sans dépendre d’une API tierce, pratique quand la confidentialité des images est sensible

Ces plugins gèrent aussi la conversion en tâche de fond des images déjà présentes dans la médiathèque, ce qui évite de tout re-uploader.

Mettre en place un fallback pour les anciens navigateurs

Même en 2021, tous les navigateurs ne savent pas afficher du WebP. Safari ne l’a supporté qu’à partir de la version 14, sortie en septembre 2020 : les utilisateurs sur des versions antérieures, ou sur d’anciennes versions d’Edge, ont besoin d’un repli automatique vers le JPEG ou le PNG d’origine.

La méthode la plus robuste ne passe pas par du JavaScript, mais par la balise <picture>, qui laisse le navigateur choisir lui-même la première source qu’il sait afficher :

<picture>
    <source srcset="/wp-content/uploads/2021/08/bannière.webp" type="image/webp">
    <img src="/wp-content/uploads/2021/08/bannière.jpg" alt="Bannière du produit">
</picture>

Pour l’appliquer automatiquement au contenu généré par WordPress, on peut filtrer the_content pour remplacer les balises <img> par cette structure, à condition que la version WebP existe bien sur le disque.

Ne jamais servir du WebP à un navigateur sans vérifier son support, que ce soit via l’en-tête Accept côté serveur ou via la balise <picture> côté client. Un visiteur sur un vieux Safari qui reçoit une image cassée, c’est pire qu’une image un peu plus lourde.

Ce qu’on mesure une fois en production

Sur un site e-commerce migré en WebP avec fallback via <picture>, on a suivi le poids total transféré sur une page catégorie contenant vingt-quatre vignettes produit :

  • Avant conversion : 3,1 Mo d’images transférées au chargement complet
  • Après conversion WebP avec fallback : 2,15 Mo, soit une réduction de 30 %
  • Temps de chargement complet (réseau 4G simulé) : de 4,8 s à 3,6 s

Le gain est cohérent avec ce qu’on observe ailleurs : autour de 30 % de poids en moins, sans dégradation visible de la qualité perçue par les utilisateurs, à condition de conserver un niveau de qualité WebP raisonnable, autour de 75 à 80.

En résumé

Convertir ses images en WebP sur WordPress n’est plus un chantier lourd depuis l’arrivée du support natif dans WordPress 5.8. Pour un site déjà en place, un plugin comme Imagify ou WebP Express reste la voie la plus rapide à mettre en œuvre. Pour un thème sur-mesure, générer les versions WebP au moment de l’upload et les servir via <picture> donne un contrôle plus fin, au prix d’un peu plus de code à maintenir. Dans tous les cas, gardez toujours l’original JPEG ou PNG en repli : le WebP accélère le site, il ne doit jamais le casser.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi