Cette page a été traduite par l'API Cloud Translation.

Questions fréquentes

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

WebP est une méthode de compression avec et sans perte qui peut être utilisée sur un grand nombre d'images photo, translucides et graphiques trouvées sur le Web. Le degré de compression avec pertes est réglable afin que l'utilisateur puisse choisir le compromis entre taille de fichier et qualité d'image. WebP atteint généralement une compression en moyenne 30% supérieure à celle des JPEG et JPEG 2000, sans perte de qualité d'image (voir Étude comparative).

Le format WebP vise principalement à créer des images plus petites et de meilleure qualité qui contribuent à accélérer le Web.

Quels sont les navigateurs Web compatibles de manière native 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 sur des navigateurs compatibles avec le format WebP.

Compatibilité avec pertes WebP
- Google Chrome (ordinateur de bureau) 17 ou version ultérieure
- Google Chrome pour Android version 25 ou ultérieure
- Microsoft Edge 18 ou version ultérieure
- Firefox 65 ou version ultérieure
- Opera 11.10 ou version ultérieure
- Navigateur Web natif, Android 4.0 ou version ultérieure (ICS)
- Safari 14 ou version ultérieure (iOS 14 ou version ultérieure, macOS Big Sur+)
Compatibilité avec les versions alpha et sans perte de WebP
- Google Chrome (ordinateur de bureau) 23 ou version ultérieure
- Google Chrome pour Android version 25 ou ultérieure
- Microsoft Edge 18 ou version ultérieure
- Firefox 65 ou version ultérieure
- Opera 12.10 ou version ultérieure
- Navigateur Web natif, Android 4.2 ou version ultérieure (JB-MR1)
- Lune pâle 26+
- Safari 14 ou version ultérieure (iOS 14 ou version ultérieure, macOS Big Sur+)
Compatibilité avec les animations WebP
- Google Chrome (ordinateur et Android) 32 ou version ultérieure
- Microsoft Edge 18 ou version ultérieure
- Firefox 65 ou version ultérieure
- Opera 19 ou version ultérieure
- Safari 14 ou version ultérieure (iOS 14 ou version ultérieure, macOS Big Sur+)

Voir également :

Comment déterminer si le navigateur est compatible avec WebP ?

Vous devez diffuser des images WebP uniquement aux clients qui peuvent les afficher correctement et utiliser les anciens formats pour les clients qui ne peuvent pas les afficher. Heureusement, plusieurs techniques permettent de détecter la compatibilité WebP, côté client et côté serveur. Certains fournisseurs CDN proposent une détection de la compatibilité WebP dans le cadre de leur service.

Négociation de contenu côté serveur avec les en-têtes d'acceptation

Il est courant que les clients Web envoient un en-tête de requête "Accept", 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 en toute sécurité des images WebP, ce qui simplifie considérablement la négociation du contenu. Pour en savoir plus, consultez les liens suivants.

Moderniseur

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 accepte un élément <picture>, qui vous permet de répertorier plusieurs cibles d'images alternatives par ordre de priorité, de sorte qu'un client demande la première image candidate qu'elle peut afficher correctement. Consultez cette discussion sur HTML5 Rocks. L'élément <picture> est compatible avec d'autres navigateurs en permanence.

Dans votre propre JavaScript

Une autre méthode de détection consiste à tenter de décoder une très petite image WebP utilisant une fonctionnalité particulière et à vérifier qu'elle fonctionne. 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 compatibilité avec WebP doit de préférence être placé dans la fonction de rappel.

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

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

Comment convertir mes fichiers image personnels au format WebP ?

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

Si vous devez convertir de nombreuses images, vous pouvez utiliser l'interface système de votre plate-forme pour simplifier l'opération. Par exemple, pour convertir tous les fichiers jpeg d'un dossier, procédez comme suit:

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é d'image WebP ?

Actuellement, vous pouvez afficher des fichiers WebP en les convertissant dans un format courant utilisant une compression sans perte, telle que PNG, puis afficher les fichiers PNG dans n'importe quel navigateur ou lecteur d'images. Pour vous faire rapidement une idée de la qualité WebP, consultez la galerie de ce site qui propose des comparaisons de photos côte à côte.

Comment obtenir le code source ?

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

Quelle est la taille maximale d'une image WebP ?

WebP est compatible avec le format 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 de couleur le format WebP prend-il en charge ?

Conformément au flux de bits VP8, le WebP avec pertes fonctionne exclusivement avec un format d'image Y'CbCr 4:2:0 8 bits (souvent appelé YUV420). Pour en savoir plus, consultez la section 2, Présentation du format de la RFC 6386, le Guide sur le format et le décodage des données VP8.

Lossless WebP fonctionne exclusivement avec le format RVBA. Consultez la spécification de bitstream WebP sans perte.

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

Oui, généralement lors de la conversion d'un format avec pertes vers WebP sans perte ou inversement. Cela est principalement dû à la différence de l'espace colorimétrique (YUV420 vs ARVB) et à la conversion entre eux.

Il existe trois situations typiques:

Si l'image source est au format ARVB sans perte, le sous-échantillonnage spatial vers YUV420 introduira de nouvelles couleurs plus difficiles à compresser que les couleurs d'origine. Cette situation 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 la même manière qu'un fichier JPEG avec pertes), peut augmenter la taille du fichier.
Si la source est au format avec pertes, l'utilisation de la compression WebP sans perte pour capturer la nature avec pertes de la source entraîne généralement un fichier plus volumineux. Cela n'est pas particulier pour WebP et peut se produire lors de la conversion d'une source JPEG au format WebP ou PNG sans perte, par exemple.
Si la source est au format avec pertes et que vous essayez de la compresser en tant qu'élément WebP avec pertes 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 un fichier WebP de qualité 95, le fichier sera généralement plus volumineux, même si les deux formats présentent des pertes. Il est souvent impossible d'évaluer la qualité de la source. Il est donc recommandé 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 une taille de fichier donnée à l'aide de l'option -size de l'outil cwebp ou de 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 source WebP sans perte n'est pas sujette à de telles surprises de taille de fichier.

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

WebP n'offre pas d'actualisation de décodage progressive ou entrelacée au sens JPEG ou PNG. Cela risque de exercer 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 au décodage de la référence trois fois.

WebP propose également un décodage incrémentiel, où tous les octets entrants disponibles du flux de bits sont utilisés pour essayer de générer un échantillon de ligne affichable le plus rapidement possible. Cela permet à la fois d'économiser de la mémoire et du processeur, et de repeindre 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 de décodage avancé.

Comment utiliser les liaisons Java libwebp dans mon projet Android ?

WebP est compatible avec les liaisons JNI aux interfaces d'encodeur et de décodeur simples dans le répertoire swig/.

Créez la bibliothèque dans Eclipse:

Assurez-vous d'avoir installé le plug-in ADT avec les outils NDK et que votre chemin NDK est correctement défini (Preferences > Android > NDK).
Créez un projet: File > New > Project > Android Application Project (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 build.
Ouvrez les propriétés du projet et 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 : La définition de NDK_TOOLCHAIN_VERSION=4.8 améliore généralement les performances de compilation 32 bits.
Ajoutez swig/libwebp.jar au dossier du projet libs/.
Compilez votre projet. Cette opération entraîne la création de 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 créé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éé sous la forme d'une DLL qui exporte l'API libwebp. Ces fonctions peuvent ensuite être importées en C#.

Compilez libwebp.dll. WEBP_EXTERN sera correctement défini 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 WebP animé par rapport au GIF animé

WebP est compatible avec les couleurs RVB 24 bits avec un canal alpha 8 bits, par rapport aux couleurs 8 bits et alpha 1 bit de GIF.
WebP est compatible avec la compression avec et sans perte. En fait, une seule animation peut combiner des images avec et sans perte. GIF prend uniquement en charge 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 réelles, une source de plus en plus populaire d'images animées.
WebP nécessite moins d'octets que GIF¹. Les GIF animés convertis en WebP avec pertes sont 64% plus petits, tandis que les WebP sans perte sont 19% plus petits. Ce point est particulièrement important sur les réseaux mobiles.
WebP prend moins de temps à décoder en présence de la recherche. Dans Blink, le défilement ou la modification d'onglets peuvent masquer et afficher des images, ce qui met en pause les animations, puis les fait passer à un autre point. Une utilisation excessive du processeur, qui entraîne l'abandon de frames par les animations, peut également obliger le décodeur à avancer dans l'animation. Dans ces scénarios, le WebP animé prend 0,57 fois plus de temps de décodage total² que le GIF, ce qui réduit les à-coups lors du défilement et accélère la récupération en cas de pics d'utilisation du processeur. Cela est dû à deux avantages du format WebP par rapport au GIF:
- Les images WebP stockent des métadonnées indiquant si chaque image contient du code alpha, ce qui élimine la nécessité de décoder la trame pour effectuer cette détermination. Cela permet d'identifier plus précisément les frames précédents dont dépend une image donnée, ce qui réduit le décodage inutile des images précédentes.
- Tout comme un encodeur vidéo moderne, l'encodeur WebP ajoute de manière heuristique des images clés à intervalles réguliers (ce qui n'est pas le cas de la plupart des encodeurs GIF). Cela améliore considérablement la recherche dans les longues animations. Pour faciliter l'insertion de tels images sans augmenter considérablement la taille de celles-ci, WebP ajoute un indicateur de méthode de combinaison pour chaque image, en plus de la méthode de suppression des images utilisée par GIF. Cela permet à une image clé de dessiner comme si la totalité de l'image avait été effacée pour la couleur d'arrière-plan, sans forcer l'image précédente à être en taille réelle.

Inconvénients du WebP animé par rapport aux GIF animés

En l'absence de recherche, le décodage en ligne droite de WebP sollicite davantage le processeur que le GIF. Le WebP avec pertes prend 2,2 fois plus de temps de décodage que le GIF, tandis que le WebP sans perte prend 1,5 fois plus.
La prise en charge de WebP n'est pas aussi répandue que la prise en charge des GIF, qui est en réalité universelle.
L'ajout de la compatibilité WebP aux navigateurs augmente l'empreinte du code et la surface d'attaque. Dans Blink, il s'agit d'environ 1 500 lignes de code supplémentaires (y compris la bibliothèque demux WebP et le décodeur d'image WebP Blink). Notez que ce problème pourrait être résolu à l'avenir si WebP et WebM partagent un code de décodage plus commun, ou si les fonctionnalités de WebP sont intégrées à WebM.

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

Il peut être judicieux à long terme de prendre en charge des formats vidéo dans la balise <img>. Toutefois, cela pose problème maintenant, car WebM dans <img> peut remplir le rôle proposé de WebP animé:

Pour décoder une image qui repose sur des images précédentes, WebM nécessite 50% de mémoire en plus par rapport au WebP animé pour contenir le nombre minimal d'images précédentes³.
La compatibilité des conteneurs et des codec vidéo est considérablement selon les navigateurs et les appareils. Pour faciliter le transcodage automatique de contenu (par exemple, pour les proxys d'économie de bande passante), les navigateurs doivent ajouter des en-têtes d'acceptation indiquant les formats compatibles avec leurs tags d'image. Même si ce n'est pas suffisant, les types MIME tels que "video/webm" ou "video/mpeg" n'indiquent toujours pas la compatibilité avec le codec (par exemple, VP8 ou VP9). En revanche, le format WebP est effectivement figé, et si les fournisseurs qui l'envoient acceptent de diffuser le WebP animé, le comportement de WebP dans tous les UA doit être cohérent. De plus, comme l'en-tête d'acceptation "image/webp" est déjà utilisé pour indiquer la compatibilité avec WebP, aucune nouvelle modification de l'en-tête d'acceptation n'est nécessaire.
La pile vidéo de Chromium est optimisée pour offrir une lecture fluide et suppose qu'une ou deux vidéos sont lues à la fois. Par conséquent, l'implémentation consomme beaucoup de ressources système (threads, mémoire, etc.) afin d'optimiser la qualité de la lecture. Une telle mise en œuvre ne s'adapte pas bien à de nombreuses vidéos simultanées et doit être repensée pour être adaptée aux pages Web comportant beaucoup d'images.
WebM n'intègre actuellement pas toutes les techniques de compression de WebP. Par conséquent, cette image est compressée de manière beaucoup plus efficace avec WebP qu'avec les autres solutions:

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

² Les délais de décodage ont été calculés à l'aide de la dernière version de libwebp et de ToT Blink à partir du 08/10/2013, à l'aide d'un outil d'analyse comparative. "Décoder le temps avec la recherche" est calculé comme suit : "Décoder les cinq premières images, effacer le cache du tampon de frames, décoder les cinq images suivantes, etc.".

³ WebM conserve en mémoire quatre cadres de référence YUV, chaque cadre stockant (largeur + 96) x (hauteur + 96) pixels. Pour YUV 4:2:0, nous avons besoin de 4 octets tous les 6 pixels (soit 3/2 octets par pixel). Ces trames de référence utilisent donc 4*3/2*(width+96)*(height+96) octets de mémoire. En revanche, WebP n'aurait besoin que de la trame précédente (en RVBA) disponible, ce qui correspond à 4*width*height octets de mémoire.

⁴ Le rendu WebP animé nécessite Google Chrome version 32 ou ultérieure