WebP

WebP est un format d’image développé par Google en 2010 et standardisé en 2018. Prend en charge la compression avec et sans perte dans le même format, l’alpha complet (transparence) et l’animation. Compresse 25-35 % plus petit que JPG à qualité visuelle équivalente.

Support navigateurs en 2026 : ~97 % mondialement. Safari a été le dernier grand récalcitrant, ajoutant WebP dans la version 14 (septembre 2020). Les 3 % restants sont les anciennes versions d’Android, les derniers IE11 et les navigateurs embarqués.

Le mode avec perte de WebP est basé sur VP8 (le codec vidéo ouvert de Google, utilisé par la vidéo WebM). Il utilise la prédiction par blocs et la transformation similaire à H.264, appliquée à une seule trame. Le résultat : une compression nettement meilleure que la DCT de 1992 du JPG.

Utilisation pratique :

• Pour le nouveau contenu web : WebP en premier, fallback JPG via <picture>.
• Pour remplacer les JPG existants : réduction facile de 25-35 % de la taille, sans régression qualitative.
• Pour remplacer les PNG avec alpha : WebP sans perte + alpha est considérablement plus petit que PNG (souvent 30-50 % de la taille).
• vs AVIF : AVIF est encore plus petit (~20 % plus petit que WebP à qualité équivalente) mais encode 10-100× plus lentement et a un support navigateur plus limité (~93 % en 2026). WebP est le défaut plus sûr.

Convertissez n’importe quelle image en WebP dans votre navigateur via nos convertisseurs d’images.

L’histoire de l’acquisition On2 — pourquoi WebP existe : Google a acquis On2 Technologies en février 2010 spécifiquement pour le codec vidéo VP8, puis a publié VP8 en open source sous une licence permissive de type BSD. WebP a été annoncé huit mois plus tard comme format d’image fixe dérivé d’une seule image clé VP8. Le prix d’acquisition était de 124,6 M$ — payé en partie pour fournir une alternative sans brevet à HEIF/HEIC, dont le pool de licences était incompatible avec le déploiement à l’échelle des navigateurs. La même logique stratégique a produit VP9, AV1 et finalement AVIF.

L’asymétrie du curseur de qualité : le curseur de qualité avec perte de WebP va de 0 à 100 comme celui du JPG, mais les courbes sont différentes — qualité 80 en WebP est visuellement équivalente à environ qualité 90 en JPG pour une taille de fichier nettement plus petite. L’encodeur WebP sans perte ignore entièrement le drapeau de qualité ; à la place, un paramètre de méthode -m (0-6) échange le temps d’encodage contre une compression plus serrée. Des outils comme cwebp (l’encodeur de référence), sharp (Node.js) et squoosh (navigateur) exposent tous ces paramètres. Pour les pipelines de construction automatisés, qualité 75-80 avec perte est le point idéal typique ; pour les icônes et graphiques où l’alpha compte, sans perte avec méthode 6 est le point idéal. Connexe : AVIF, sans perte, avec perte. Référence : Google — WebP, A new image format for the Web.

Exemple concret

Prenons une photo hero 1920×1080, originellement un JPG de 480 Ko à qualité 85. Convertissons en WebP à qualité 80 avec cwebp : cwebp -q 80 hero.jpg -o hero.webp → ~320 Ko, une réduction de 33 % à qualité visuellement indistinguable. Convertissons la même source en PNG sans perte : ~3,2 Mo. Imaginons maintenant que la même source nécessite un détourage en canal alpha pour un rendu produit. Enregistrez en PNG-24 avec alpha : ~1,8 Mo. Enregistrez en WebP sans perte : ~650 Ko (une réduction de 64 %). Sur une page e-commerce typique avec 30 images produit, passer les sources JPG/PNG en WebP peut réduire la charge d’images de ~6 Mo à ~3 Mo — améliorant directement le LCP (Largest Contentful Paint) de 1-2 secondes sur une connexion 3G, ce qui alimente directement les Core Web Vitals et le classement SEO.

Quand et pourquoi c’est important

La charge d’images est généralement le plus grand contributeur au poids des pages mobiles, et les Core Web Vitals (LCP spécifiquement) sont un facteur de classement Google documenté. L’optimisation de performance la moins coûteuse pour tout site à forte densité d’images est d’ajouter un élément <picture> avec des sources WebP et AVIF aux côtés de fallbacks JPG — Next.js moderne (next/image), Astro, Eleventy et Nuxt le font automatiquement. Les quelques situations où WebP n’est pas la bonne réponse : quand l’asset sera édité en aval (utilisez un master sans perte), quand le public cible est sur des navigateurs ne le supportant pas (très vieux Android, certains webviews embarqués — fournissez un fallback JPG/PNG), et quand l’image est une photographie pour l’impression (utilisez TIFF ou le RAW original). Pour tout le reste servi à un navigateur web moderne en 2026, WebP-ou-AVIF devrait être le défaut et JPG un fallback patrimonial. Référence : web.dev — Serve images in WebP formats.