Notes de l'équipe sur l'artisanat, les formats et les petites décisions derrière un bon résultat.
Comment une seule image se convertit dans le navigateur, et ce qui change pour plusieurs
Quand vous déposez un JPEG sur la page, le navigateur lit le fichier en mémoire et décode les données compressées en pixels bruts avec son lecteur JPEG intégré. Il dessine ensuite ces pixels sur une surface hors écran et demande à la plateforme de les écrire en WebP. Chaque étape se passe dans le navigateur, sur votre propre matériel, donc aucun octet ne traverse le réseau. Lors de nos tests, un JPEG de 17 Ko en 1024 sur 768 finit en environ 54 millisecondes, et une photo de 116 Ko en 3840 sur 2160 prend environ 550 millisecondes. Quand vous convertissez plusieurs images à la fois, le travail passe sur notre serveur, qui les encode ensemble et renvoie un seul téléchargement dont le lien est supprimé en environ 2 heures.
Ce qu'il advient de l'EXIF et des métadonnées
Les fichiers JPEG peuvent traîner de vraies charges de métadonnées. L'EXIF enregistre le modèle d'appareil, les coordonnées GPS, la vitesse d'obturation et l'orientation. Les champs IPTC tiennent le copyright et la légende. Les paquets XMP suivent l'historique des retouches, et les profils ICC couvrent le travail en couleur gérée. La conversion ici n'en garde rien. Le WebP final est un fichier propre ne contenant que les pixels visibles. C'est le comportement normal des outils d'image qui dessinent via le navigateur, identique sur Chromium, Firefox et WebKit. Pour la plupart des publications web, laisser tomber les métadonnées est un atout: cela rogne quelques octets et empêche le GPS ou des données personnelles de fuiter dans une image publique. S'il vous faut conserver un champ précis, l'orientation étant le cas habituel, pivotez la photo d'abord ou passez par un éditeur conscient des métadonnées avant de convertir. Ne comptez pas sur cet outil pour un travail d'archivage où les métadonnées d'origine doivent survivre intactes.
WebP face au JPEG: en quoi la compression diffère
Le JPEG découpe une image en blocs de 8 sur 8 et applique une transformée en cosinus discrète pour traduire le détail spatial en données de fréquence, puis quantifie plus durement les hautes fréquences. Le WebP emprunte un schéma de prédiction à la vidéo VP8: chaque bloc est deviné à partir de ses voisins déjà décodés, et seul l'écart restant est stocké. Cela laisse en général moins d'artefacts en blocs à taille de fichier égale, surtout sur les dégradés doux et les teints de peau où la grille du JPEG peut surgir en mosaïque visible. Sur des photos à haute qualité, au-dessus de q80, l'oeil attrape rarement la différence, mais l'avantage de taille tient bon. À qualité plus basse, sous q60, l'avance du WebP s'élargit et le caractère des artefacts change. Le WebP se fond en un flou plus doux tandis que le JPEG montre ses blocs caractéristiques. Aucun ne gagne sur chaque image. Les sujets très texturés comme le feuillage se compressent parfois à peu près pareil dans les deux formats.
Les Core Web Vitals et l'argument pour le WebP
Le Largest Contentful Paint, ou LCP, mesure la vitesse à laquelle le plus grand élément visible finit de se charger dans la fenêtre. Sur la plupart des pages marketing, cet élément est une photo d'en-tête. Google a confirmé que les Core Web Vitals agissent comme facteur de classement dans la recherche. Quand l'en-tête est un JPEG de 300 Ko, il peut pousser le LCP au-delà du seuil de 2,5 secondes sur une connexion mobile moyenne. Convertissez la même photo en WebP d'environ 180 Ko et le LCP peut regagner la zone verte sans autre changement sur la page. L'économie de 25 à 34 pour cent se cumule sur chaque image de la page. Une page portant six JPEG totalisant 1,2 Mo peut perdre 300 à 400 Ko en passant au WebP, ce qui accélère directement le premier rendu significatif sur les liens lents. Les CDN qui gèrent la négociation de contenu servent le WebP aux navigateurs compatibles d'eux-mêmes, donc plus aucune corvée par image une fois les originaux en place.
La prise en charge du WebP en 2026 et les manques
En 2026, le WebP se décode dans Chrome depuis la version 17, Firefox depuis la 65, Edge depuis la 18, Opera depuis la 11.10, et Safari depuis la version 14 sur iOS 14 et macOS Big Sur. D'après caniuse.com, la couverture mondiale cumulée pour le décodage WebP dépasse 97 pour cent du trafic navigateur. Le reliquat tient surtout d'Internet Explorer 11, de Safari 13 sur macOS Catalina et d'une longue traîne de très vieux navigateurs Android. Pour presque tout projet public, servir le WebP à tous est sans risque. Quand la couverture totale est l'objectif, l'élément HTML picture vous laisse citer une source WebP et un repli JPEG dans une même balise. Le navigateur saisit le premier format qu'il sait lire. Les CDN dotés d'optimisation d'image négocient le format automatiquement à partir de l'en-tête Accept envoyé par le navigateur, donc servir à travers eux n'exige aucun test manuel par navigateur.
Quand ne pas utiliser le WebP
Le WebP est le bon choix pour la diffusion web vers des navigateurs modernes, mais le mauvais à quelques endroits courants. Le travail d'impression réclame la couleur CMJN, que le WebP ne porte pas, donc le JPEG et le TIFF restent la norme pour la presse. Les clients de messagerie sont inégaux: Gmail et Apple Mail affichent le WebP, mais Outlook sous Windows non. Le partage de fichiers et les places de marché varient aussi. Google Drive, Dropbox et GitHub montrent le WebP sans souci. En revanche, beaucoup de plateformes sociales, d'agences de banque d'images et de systèmes e-commerce recompressent les images entrantes en JPEG en interne, ce qui rend l'étape WebP inutile. La prise en charge côté éditeurs reste irrégulière: Lightroom, Capture One et Affinity Photo ouvrent le WebP, mais bien des extensions et préréglages d'export choisissent encore le JPEG par défaut. Pour tout flux qui fait passer les images par des systèmes tiers que vous ne contrôlez pas, gardez un master JPEG et ne convertissez en WebP qu'à l'ultime couche de diffusion.
