Questions fréquentes

Qu'est-ce que WebP ? Pourquoi l'utiliser ?

WebP est une méthode de compression avec et sans pertes qui peut être utilisée sur une grande variété d'images photographiques, translucides et graphiques disponibles sur le Web. Le degré de compression avec perte est réglable, ce qui permet à l'utilisateur de choisir le compromis entre la taille du fichier et la qualité de l'image. WebP permet généralement d'obtenir une compression moyenne 30 % supérieure à celle de JPEG et JPEG 2000, sans perte de qualité d'image (consultez l'étude sur WebP avec pertes et l'étude sur WebP sans pertes et le canal alpha).

Le format WebP vise essentiellement à créer des images plus petites et plus esthétiques qui peuvent contribuer à rendre le Web plus rapide.

Quels navigateurs Web sont compatibles avec WebP ?

Les webmasters qui souhaitent améliorer les performances de leur site peuvent facilement créer des alternatives WebP optimisées pour leurs images actuelles et les diffuser de manière ciblée aux navigateurs compatibles avec WebP.

Compatibilité avec le format WebP avec perte
- Google Chrome (ordinateur) 17+
- Google Chrome pour Android version 25 ou ultérieure
- Microsoft Edge 18+
- Firefox 65 ou version ultérieure
- Opera 11.10 ou version ultérieure
- Navigateur Web natif, Android 4.0+ (ICS)
- Safari 14+ (iOS 14+, macOS Big Sur+)
Prise en charge des formats WebP avec ou sans perte et du canal alpha
- Google Chrome (ordinateur) 23 ou version ultérieure
- Google Chrome pour Android version 25 ou ultérieure
- Microsoft Edge 18+
- Firefox 65 ou version ultérieure
- Opera 12.10 ou version ultérieure
- Navigateur Web natif, Android 4.2+ (JB-MR1)
- Pale Moon 26 ou version ultérieure
- Safari 14+ (iOS 14+, macOS Big Sur+)
Compatibilité avec les animations WebP
- Google Chrome (ordinateur et Android) 32 ou version ultérieure
- Microsoft Edge 18+
- Firefox 65 ou version ultérieure
- Opera 19+
- Safari 14+ (iOS 14+, macOS Big Sur+)

Voir également :

Comment puis-je détecter la compatibilité du navigateur avec WebP ?

Vous devez diffuser des images WebP uniquement aux clients qui peuvent les afficher correctement, et revenir aux anciens formats pour les clients qui ne le peuvent pas. Heureusement, il existe plusieurs techniques pour détecter la compatibilité WebP, à la fois côté client et côté serveur. Certains fournisseurs de CDN proposent la détection de la compatibilité WebP dans leurs services.

Négociation de contenu côté serveur via les en-têtes Accept

Il est courant que les clients Web envoient un en-tête de requête "Accept" (Accepter) indiquant les formats de contenu qu'ils sont prêts à accepter en réponse. Si un navigateur indique à l'avance qu'il "acceptera" le format image/webp, le serveur Web sait qu'il peut envoyer des images WebP en toute sécurité, ce qui simplifie considérablement la négociation de contenu. Pour en savoir plus, consultez les liens suivants.

Modernizr

Modernizr est une bibliothèque JavaScript qui permet de détecter facilement la compatibilité des fonctionnalités HTML5 et CSS3 dans les navigateurs Web. Recherchez les propriétés Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha et Modernizr.webp.animation.

Élément `<picture>` HTML5

HTML5 est compatible avec un élément <picture>, qui vous permet de lister plusieurs cibles d'image alternatives par ordre de priorité, de sorte qu'un client demande la première image candidate qu'il peut afficher correctement. Consultez cette discussion sur HTML5 Rocks. L'élément <picture> est compatible avec de plus en plus de navigateurs.

Dans votre propre code JavaScript

Une autre méthode de détection consiste à tenter de décoder une très petite image WebP qui utilise une fonctionnalité particulière et à vérifier si l'opération a réussi. Exemple :

// check_webp_feature:
//   'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
//   'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

Notez que le chargement des images est non bloquant et asynchrone. Cela signifie que tout code qui dépend de la prise en charge de WebP doit de préférence être placé dans la fonction de rappel.

Pourquoi Google a-t-il publié WebP en Open Source ?

Nous sommes profondément convaincus de l'importance du modèle Open Source. WebP étant Open Source, tout le monde peut travailler avec ce format et suggérer des améliorations. Grâce à vos commentaires et suggestions, nous pensons que le format WebP deviendra encore plus utile au fil du temps.

Comment puis-je convertir mes fichiers d'images personnelles au format WebP ?

Vous pouvez utiliser l'utilitaire de ligne de commande WebP pour convertir vos fichiers image personnels au format WebP. Pour en savoir plus, consultez Utiliser WebP.

Si vous avez de nombreuses images à convertir, vous pouvez utiliser le shell de votre plate-forme pour simplifier l'opération. Par exemple, pour convertir tous les fichiers JPEG d'un dossier, essayez la commande suivante :

Windows :

> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )

Linux / macOS :

$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done

Comment puis-je évaluer moi-même la qualité des images WebP ?

Actuellement, vous pouvez afficher les fichiers WebP en les convertissant dans un format courant utilisant la compression sans perte, tel que PNG. Vous pouvez ensuite afficher les fichiers PNG dans n'importe quel navigateur ou visionneuse d'images. Pour vous faire une idée rapide de la qualité WebP, consultez la galerie de ce site pour comparer des photos côte à côte.

Comment obtenir le code source ?

Le code du convertisseur est disponible dans la section des téléchargements de la page du projet Open Source WebP. Le code du décodeur léger et la spécification VP8 sont disponibles sur le site WebM. Consultez la page Conteneur RIFF pour connaître les spécifications du conteneur.

Quelle est la taille maximale d'une image WebP ?

WebP est compatible avec le flux binaire VP8 et utilise 14 bits pour la largeur et la hauteur. Les dimensions maximales d'une image WebP sont de 16 383 x 16 383 pixels.

Quels espaces colorimétriques sont compatibles avec le format WebP ?

Comme le flux binaire VP8, le format WebP avec perte fonctionne exclusivement avec un format d'image Y'CbCr 4:2:0 8 bits (souvent appelé YUV420). Pour en savoir plus, veuillez consulter la section 2, Format Overview (Présentation du format) du document RFC 6386, VP8 Data Format and Decoding Guide (Guide sur le format de données et le décodage VP8).

Le format WebP sans perte fonctionne exclusivement avec le format RGBA. Consultez la spécification du flux de bits WebP sans perte.

Pourquoi mon fichier WebP sans perte est-il différent de l'original ?

Les fonctions de l'API Simple Encoding (WebPEncodeLosslessRGB(), WebPEncodeLosslessBGR(), WebPEncodeLosslessRGBA(), WebPEncodeLosslessBGRA()) utilisent les paramètres par défaut de la bibliothèque. Pour le format sans perte, cela signifie que la qualité "exacte" est désactivée. Les valeurs RVB dans les zones entièrement transparentes (c'est-à-dire les zones dont les valeurs alpha sont égales à 0) seront modifiées pour améliorer la compression. Pour éviter cela, utilisez WebPEncode() et définissez WebPConfig::exact sur 1. Consultez la documentation de l'API Advanced Encoding.

Une image WebP peut-elle devenir plus grande que son image source ?

Oui, généralement lors de la conversion d'un format avec pertes en WebP sans pertes ou inversement. Cela est principalement dû à la différence d'espace colorimétrique (YUV420 vs ARGB) et à la conversion entre ces deux espaces.

Voici trois situations typiques :

Si l'image source est au format ARGB sans perte, le sous-échantillonnage spatial en YUV420 introduira de nouvelles couleurs plus difficiles à compresser que celles d'origine. Cela peut généralement se produire lorsque la source est au format PNG avec peu de couleurs : la conversion au format WebP avec pertes (ou, de même, au format JPEG avec pertes) peut entraîner une taille de fichier plus importante.
Si la source est au format avec perte, l'utilisation de la compression WebP sans perte pour capturer la nature avec perte de la source entraînera généralement un fichier plus volumineux. Ce problème n'est pas spécifique à WebP et peut se produire lors de la conversion d'une source JPEG aux formats WebP ou PNG sans perte, par exemple.
Si la source est au format avec perte et que vous essayez de la compresser en WebP avec perte avec un paramètre de qualité plus élevé. Par exemple, si vous essayez de convertir un fichier JPEG enregistré avec une qualité de 80 en fichier WebP avec une qualité de 95, vous obtiendrez généralement un fichier plus volumineux, même si les deux formats sont avec perte. Il est souvent impossible d'évaluer la qualité de la source. Il est donc conseillé de réduire la qualité WebP cible si la taille du fichier est systématiquement plus importante. Une autre possibilité consiste à éviter d'utiliser le paramètre de qualité et à cibler plutôt une taille de fichier donnée à l'aide de l'option -size dans l'outil cwebp ou l'API équivalente. Par exemple, cibler 80 % de la taille du fichier d'origine peut s'avérer plus robuste.

Notez que la conversion d'une source JPEG en WebP avec pertes ou d'une source PNG en WebP sans pertes ne présente pas ce type de surprise concernant la taille du fichier.

Le format WebP est-il compatible avec l'affichage progressif ou entrelacé ?

WebP n'offre pas d'actualisation progressive ou entrelacée du décodage au sens de JPEG ou PNG. Cela risque de mettre trop de pression sur le processeur et la mémoire du client de décodage, car chaque événement d'actualisation implique un passage complet dans le système de décompression.

En moyenne, le décodage d'une image JPEG progressive équivaut à trois fois le décodage d'une image de base.

WebP propose également un décodage incrémentiel, où tous les octets entrants disponibles du flux de bits sont utilisés pour essayer de produire une ligne d'échantillon affichable le plus rapidement possible. Cela permet d'économiser de la mémoire et du processeur, et de réduire les efforts de redessin sur le client, tout en fournissant des repères visuels sur l'état du téléchargement. La fonctionnalité de décodage incrémentiel est disponible via l'API Advanced Decoding.

Comment utiliser les liaisons Java libwebp dans mon projet Android ?

WebP inclut la prise en charge des liaisons JNI aux interfaces d'encodeur et de décodeur simples dans le répertoire swig/.

Compiler la bibliothèque dans Eclipse :

Assurez-vous d'avoir installé le plug-in ADT ainsi que les outils NDK, et que votre chemin NDK est correctement défini (Préférences > Android > NDK).
Créez un projet : Fichier > Nouveau > Projet > Projet d'application Android.
Clonez ou décompressez libwebp dans un dossier nommé jni dans le nouveau projet.
Ajoutez swig/libwebp_java_wrap.c à la liste LOCAL_SRC_FILES.
Effectuez un clic droit sur le nouveau projet, puis sélectionnez Android Tools > Add Native Support… (Outils Android > Ajouter une compatibilité native…) pour inclure la bibliothèque dans votre compilation.
Ouvrez les propriétés du projet, puis accédez à C/C++ Build > Behaviour (Compilation C/C++ > Comportement). Ajoutez ENABLE_SHARED=1 à la section Build (Incremental build) pour compiler libwebp en tant que bibliothèque partagée.

Remarque : En général, le paramètre NDK_TOOLCHAIN_VERSION=4.8 améliore les performances de compilation 32 bits.
Ajoutez swig/libwebp.jar au dossier du projet libs/.
Compilez votre projet. Cela créera libs/<target-arch>/libwebp.so.
Utilisez System.loadLibrary("webp") pour charger la bibliothèque au moment de l'exécution.

Notez que la bibliothèque peut être compilée manuellement avec ndk-build et le Android.mk inclus. Dans ce cas, certaines des étapes décrites ci-dessus peuvent être réutilisées.

Comment utiliser libwebp avec C#?

WebP peut être créé en tant que fichier DLL qui exporte l'API libwebp. Ces fonctions peuvent ensuite être importées en C#.

Créez libwebp.dll. Cela définira correctement WEBP_EXTERN pour exporter les fonctions de l'API.
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

Ajoutez libwebp.dll à votre projet et importez les fonctions souhaitées. Notez que si vous utilisez l'API simple, vous devez appeler WebPFree() pour libérer les tampons renvoyés.

[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride,
                                 float quality_factor, out IntPtr output);
[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPFree(IntPtr p);

void Encode() {
  Bitmap source = new Bitmap("input.png");
  BitmapData data = source.LockBits(
      new Rectangle(0, 0, source.Width, source.Height),
      ImageLockMode.ReadOnly,
      PixelFormat.Format32bppArgb);
  IntPtr webp_data;
  const int size = WebPEncodeBGRA(data.Scan0,
                                  source.Width, source.Height, data.Stride,
                                  80, out webp_data);
  // ...
  WebPFree(webp_data);
}

Pourquoi utiliser le format WebP animé ?

Avantages du format WebP animé par rapport au format GIF animé

WebP est compatible avec les couleurs RVB 24 bits et le canal alpha 8 bits, contrairement au format GIF qui utilise des couleurs 8 bits et un canal alpha 1 bit.
WebP est compatible avec la compression avec et sans pertes. En fait, une même animation peut combiner des frames avec et sans pertes. Le format GIF n'est compatible qu'avec la compression sans perte. Les techniques de compression avec pertes de WebP sont bien adaptées aux images animées créées à partir de vidéos du monde réel, une source d'images animées de plus en plus populaire.
WebP nécessite moins d'octets que GIF¹. Les GIF animés convertis au format WebP avec pertes sont 64 % plus petits, tandis que ceux convertis au format WebP sans pertes sont 19 % plus petits. Ce point est particulièrement important sur les réseaux mobiles.
WebP prend moins de temps à décoder en cas de recherche. Dans Blink, le défilement ou le changement d'onglet peuvent masquer et afficher des images, ce qui entraîne la mise en pause des animations, puis leur avance rapide à un autre point. Une utilisation excessive du processeur entraînant une perte de frames dans les animations peut également obliger le décodeur à rechercher des frames ultérieurs dans l'animation. Dans ces scénarios, le temps de décodage total des images WebP animées est 0,57 fois supérieur² à celui des GIF, ce qui réduit les saccades lors du défilement et permet une récupération plus rapide après les pics d'utilisation du processeur. Cela est dû à deux avantages de WebP par rapport à GIF :
- Les images WebP stockent des métadonnées indiquant si chaque frame contient un canal alpha, ce qui évite d'avoir à décoder le frame pour le déterminer. Cela permet de déduire plus précisément les frames précédents dont dépend un frame donné, ce qui réduit le décodage inutile des frames précédents.
- Comme un encodeur vidéo moderne, l'encodeur WebP ajoute de manière heuristique des images clés à intervalles réguliers (ce que la plupart des encodeurs GIF ne font pas). Cela améliore considérablement la recherche dans les longues animations. Pour faciliter l'insertion de telles images sans augmenter considérablement la taille de l'image, WebP ajoute un indicateur de méthode de fusion pour chaque image en plus de la méthode de suppression d'image utilisée par GIF. Cela permet à un keyframe de dessiner comme si l'image entière avait été effacée à la couleur d'arrière-plan sans forcer le frame précédent à être en taille réelle.

Inconvénients du format WebP animé par rapport au format GIF animé

En l'absence de recherche, le décodage en ligne droite de WebP est plus gourmand en ressources processeur que celui de GIF. Le format WebP avec pertes prend 2,2 fois plus de temps à décoder que le format GIF, tandis que le format WebP sans pertes prend 1,5 fois plus de temps.
La prise en charge du format WebP n'est pas aussi répandue que celle du format GIF, qui est pratiquement universelle.
L'ajout de la prise en charge de WebP aux navigateurs augmente l'empreinte du code et la surface d'attaque. Dans Blink, cela représente environ 1 500 lignes de code supplémentaires (y compris la bibliothèque de démultiplexage WebP et le décodeur d'images WebP côté Blink). Notez que ce problème pourrait être réduit à l'avenir si WebP et WebM partageaient un code de décodage plus commun, ou si les capacités de WebP étaient incluses dans celles de WebM.

Pourquoi ne pas simplement prendre en charge WebM dans <img> ?

À long terme, il peut être judicieux de prendre en charge les formats vidéo dans la balise <img>. Toutefois, le faire maintenant, avec l'intention que WebM dans <img> puisse remplir le rôle proposé pour WebP animé, pose problème :

Lors du décodage d'un frame qui repose sur des frames précédents, WebM nécessite 50 % de mémoire en plus que WebP animé pour contenir le nombre minimal de frames précédents³.
La compatibilité avec les codecs et les conteneurs vidéo varie considérablement selon les navigateurs et les appareils. Pour faciliter le transcodage automatique du contenu (par exemple, pour les proxys permettant d'économiser de la bande passante), les navigateurs devraient ajouter des en-têtes Accept indiquant les formats compatibles avec leurs balises d'image. Même cela peut être insuffisant, car les types MIME tels que "video/webm" ou "video/mpeg" n'indiquent toujours pas la compatibilité du codec (par exemple, VP8 par rapport à VP9). En revanche, le format WebP est effectivement figé. Si les fournisseurs qui l'utilisent acceptent d'utiliser WebP animé, le comportement de WebP sur tous les UA devrait être cohérent. De plus, comme l'en-tête Accept "image/webp" est déjà utilisé pour indiquer la compatibilité avec WebP, aucun nouvel en-tête Accept n'est nécessaire.
La pile vidéo Chromium est optimisée pour une lecture fluide et suppose qu'une ou deux vidéos seulement sont lues à la fois. Par conséquent, l'implémentation consomme de manière agressive les ressources système (threads, mémoire, etc.) pour maximiser la qualité de lecture. Une telle implémentation ne s'adapte pas bien à de nombreuses vidéos simultanées et devrait être repensée pour être utilisée avec des pages Web contenant de nombreuses images.
WebM n'intègre pas actuellement toutes les techniques de compression de WebP. Par conséquent, cette image se compresse beaucoup mieux avec WebP qu'avec les autres formats :

¹ Pour toutes les comparaisons entre les GIF animés et les WebP animés, nous avons utilisé un corpus d'environ 7 000 images GIF animées sélectionnées au hasard sur le Web. Ces images ont été converties au format WebP animé à l'aide de l'outil "gif2webp" avec les paramètres par défaut (créé à partir de la dernière arborescence source libwebp au 08/10/2013). Les nombres comparatifs correspondent aux valeurs moyennes de ces images.

² Les temps de décodage ont été calculés à l'aide de la dernière version de libwebp + ToT Blink au 08/10/2013 à l'aide d'un outil de benchmark. Le temps de décodage avec recherche est calculé comme suit : "Décodez les cinq premières images, effacez le cache du tampon d'images, décodez les cinq images suivantes, et ainsi de suite".

³ WebM conserve quatre trames de référence YUV en mémoire, chaque trame stockant (largeur+96)*(hauteur+96) pixels. Pour YUV 4:2:0, nous avons besoin de quatre octets pour six pixels (ou 3/2 octets par pixel). Ces images de référence utilisent donc 4*3/2*(width+96)*(height+96) octets de mémoire. WebP, en revanche, n'aurait besoin que du frame précédent (en RGBA), soit 4*width*height octets de mémoire.

⁴ Le rendu des fichiers WebP animés nécessite Google Chrome version 32 ou ultérieure.

Questions fréquentes Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.