En 2021, j'avais un client WooCommerce à Birmingham, une boutique d'articles de maison avec environ 4 000 photos de produits, tous d'énormes JPEG pris avec un Canon DSLR et téléchargés sans aucun traitement. Son Largest Contentful Paint était à 7,2 secondes. Brutal. J'ai converti le lot en WebP avec Squoosh CLI, relancé Lighthouse, et j'ai ramené le LCP à 2,8 secondes en une seule après-midi. Le client a pleuré. Franchement.Squoosh CLI, re-ran Lighthouse, and got LCP down to 2.8 seconds in a single afternoon. The client cried. Genuinely.
Mais voilà : cette même astuce aurait très peu aidé un autre client avec lequel je travaillais le mois suivant, un site de portfolio de photojournalisme où la fidélité des couleurs et les exports de qualité impression comptaient vraiment. WebP était le mauvais choix là. J'ai utilisé JPEG avec des paramètres d'export Lightroom agressifs à la place, et l'écart de performance était négligeable parce que les images étaient déjà correctement dimensionnées.
Parlons-en correctement. Pas « WebP est toujours meilleur » et pas « JPEG est un classique pour une raison ». La vraie réponse est plus situationnelle que l'un ou l'autre camp ne l'admet.
---
Qu'est-ce qui est vraiment différent sous le capot
JPEG existe depuis 1992. Il utilise la compression par transformée en cosinus discrète, ce qui est brillant pour les photographies mais commence à s'effondrer aux ratios de compression élevés car cela introduit ces artefacts de blocage familiers. La plupart des développeurs web le savent.
WebP a été lancé par Google en 2010 et utilise un modèle de codage prédictif emprunté au codec vidéo VP8. En résumé : il modélise les relations spatiales entre les pixels de manière plus intelligente, ce qui signifie qu'il peut compresser plus de qualité dans moins d'octets. Selon les propres recherches de Google, les images WebP sans perte sont 26% plus petites que les PNG, et WebP avec perte est 25-34% plus petit que les JPEG comparables à qualité équivalente.Google's own research, WebP lossless images are 26% smaller than PNGs, and lossy WebP is 25-34% smaller than comparable JPEGs at equivalent quality.
Ces chiffres se vérifient en pratique. Généralement.
Où l'écart apparaît réellement
Les économies de 25-34% tendent à se matérialiser sur les photographies naturelles avec des dégradés lisses, les photos de produits sur fond blanc et les images de style de vie. L'écart diminue considérablement sur les détails haute fréquence : les textures de tissu serré, le feuillage dense, les motifs architecturaux avec beaucoup de répétition. J'ai testé cela avec les comparaisons côte à côte d'ImageMagick plusieurs fois. Sur certains clichés très détaillés, la différence de taille tombe en dessous de 10%, et parfois WebP perd même à la même qualité.ImageMagick side-by-side comparisons plenty of times. On certain highly detailed shots, the size difference drops to under 10%, and sometimes WebP even loses at the same quality setting.
---
Support navigateur en 2026 : est-ce encore une question ?
Honnêtement, le support navigateur était le vrai argument pour rester avec JPEG en 2018. Internet Explorer. Safari étant lent à adopter. Tout ça.
C'est du passé. Can I Use place le support global de WebP à plus de 97% à ce stade. Safari a ajouté le support complet dans la version 14 en 2020. IE est mort et enterré. Il n'y a pas de segment d'audience significatif qui ne peut pas recevoir une image WebP en 2026.Can I Use puts global WebP support at over 97% at this point. Safari added full support in version 14 back in 2020. IE is dead and buried. There's no meaningful audience segment that can't receive a WebP image in 2026.
Le seul cas limite que j'encounter encore : si vous servez des images en tant que pièces jointes e-mail ou les incorporez dans des exports PDF générés côté serveur, certains anciens pipelines de rendu ne supportent pas WebP. C'est tout. Pour tout ce qui est distribué par navigateur, le débat sur le support est terminé.
---
Core Web Vitals : où le choix du format fait vraiment la différence
LCP (Largest Contentful Paint) est la métrique Core Web Vitals la plus directement affectée par le format d'image. Elle mesure le temps qu'il faut pour que le plus grand élément visible se charge. Si cet élément est une image (et c'est généralement le cas sur les sites marketing et e-commerce), alors le format, la taille et la méthode de livraison comptent énormément.
Voici une analyse pratique des cas où j'ai vu le choix du format faire une réelle différence :
- Images héros : ce sont presque toujours l'élément LCP. Si votre héros est un JPEG de 1,2 Mo à 1920px de large, la conversion en WebP à qualité 82 vous amènera régulièrement à 380-450 Ko sans perte de qualité visible. These are almost always the LCP element. If your hero is a 1.2MB JPEG at 1920px wide, converting to WebP at quality 82 will routinely get you to 380-450KB without visible quality loss.
- Grilles d'images de produits : beaucoup de petites images se chargeant simultanément. Les économies constantes de 25%+ du WebP se cumulent ici. Grille plus rapide = blocage total inférieur sur mobile. Lots of small images loading simultaneously. WebP's consistent 25%+ savings compound here. Faster grid = lower total blocking on mobile.
- Images intégrées dans les articles de blog : réellement peu d'impact. Un JPEG de 200 Ko par rapport à un WebP de 140 Ko au milieu d'un article de 3 000 mots ne va pas changer votre LCP. Genuinely low impact. A 200KB JPEG versus a 140KB WebP in the middle of a 3,000-word article isn't moving your LCP.
- Icônes et logos : non. Utilisez SVG. Je dois le dire à chaque fois. Neither. Use SVG. I have to say this every single time.
- Miniatures dans les pages d'archives : WebP gagne ici, surtout quand vous chargez 20-30 miniatures dans une grille. C'est là que les économies d'octets s'accumulent rapidement. WebP wins here, especially when you're loading 20-30 thumbnails in a grid. That's where byte savings stack up fast.
Seahawk avait un projet fintech l'année dernière où le site marketing avait 14 images au-dessus de la ligne de flottaison en rotation dans un carrousel héros. De la folie, mais le client insistait. La conversion des 14 de JPEG en WebP à qualité 80 et leur livraison via le CDN Cloudflare a fait chuter leur LCP de 4,1 à 2,3 secondes sur mobile. Le carrousel était toujours une mauvaise idée, mais au moins il se chargeait rapidement.
---
La question AVIF
Chaque fois que j'écris sur WebP, quelqu'un me pose la question sur AVIF. C'est compréhensible.
AVIF est l'étape suivante. Il est basé sur le codec vidéo AV1, produit des fichiers encore plus petits que WebP (souvent 20 à 30 % plus petits sur les photographies), et gère correctement le contenu HDR. Le support navigateur est maintenant solide pour Chrome, Firefox et Safari. Le problème, c'est la vitesse d'encodage. AVIF est lent à encoder, vraiment lent. Faire passer une conversion par lot de 4 000 images de produits à travers AVIF sur un VPS vous prendra beaucoup de temps. WebP est beaucoup plus rapide à produire.Browser support is now solid for Chrome, Firefox, and Safari. The problem is encoding speed. AVIF is slow to encode, meaningfully slow. Running a batch conversion of 4,000 product images through AVIF on a VPS will take you a long time. WebP is significantly faster to produce.
Ma réflexion actuelle : utilisez WebP comme format de diffusion par défaut. Si vous construisez un site à fort trafic où les gains de compression AVIF supplémentaires justifient le surcoût d'encodage, servez AVIF aux navigateurs qui le supportent avec WebP en secours. L'élément <picture> avec <source type="image/avif"> gère cela sans aucun JavaScript.<picture> element with <source type="image/avif"> handles this without any JavaScript.
Ne laissez pas la paralysie AVIF vous garder sur JPEG. WebP est le bon choix pragmatique en ce moment.
---
Mon flux de travail réel pour choisir un format
Après 9 ans et plus de 12 000 sites, c'est à peu près ma façon de réfléchir :
- Est-ce une photographie ou une image photoréaliste ? Commencez par WebP lossy avec une qualité de 80 à 85. Comparez avec JPEG à une qualité de 75. Prenez le plus petit qui passe le test du coup d'œil. Start with WebP lossy at quality 80-85. Compare against JPEG at quality 75. Take the smaller one that passes the squint test.
- C'est un graphique, un logo ou une illustration avec des couleurs plates ? SVG si possible, PNG sinon. WebP sans perte est une option mais rarement la meilleure. SVG if possible, PNG if not. WebP lossless is an option but rarely the best one.
- C'est une capture d'écran avec du texte ? PNG. Toujours PNG. JPEG et WebP introduisent tous deux des artefacts autour des bords du texte qui ont l'air terribles. PNG. Always PNG. JPEG and WebP both introduce artefacts around text edges that look terrible.
- Est-ce servie via un CDN moderne qui effectue la négociation de format automatiquement ? Si vous êtes sur Cloudflare avec Polish activé, ou si vous utilisez Cloudinary, ou Imgix, alors honnêtement vous n'avez pas besoin de vous en soucier beaucoup. Ils détecteront le navigateur et serviront le format optimal. Laissez les outils gérer ça. If you're on Cloudflare with Polish enabled, or using Cloudinary, or Imgix, then honestly you don't need to worry much. They'll detect the browser and serve the optimal format. Let the tooling handle it.
- C'est un site WordPress ? Installez ShortPixel ou Imagify et configurez-les pour convertir à l'upload. C'est fait. Vous n'avez pas besoin de gérer ça manuellement du tout. Install ShortPixel or Imagify and configure them to convert on upload. Done. You don't need to manually manage this at all.
Un mot sur les paramètres de qualité
Une qualité 80 ce n'est pas une qualité 60. Je vois des développeurs définir la qualité WebP à 60 parce que « c'est toujours mieux que JPEG » et ensuite se demander pourquoi les clients se plaignent de photos de produits ternes. Faites correctement votre QA visuelle. Je fais passer chaque décision de format par Squoosh dans le navigateur, en basculant entre l'original et la sortie avec l'outil de vue partagée. Ça prend 3 minutes par type d'image et ça évite les disputes avec les clients.
---
Quand JPEG est Encore la Bonne Réponse
Je vais le dire clairement parce que je ne vois pas assez de gens le dire : JPEG n'est pas obsolète.
Si vous construisez un site où les images seront téléchargées et ré-éditées (portfolios photographiques, imagerie de stock, bibliothèques d'actifs de presse), JPEG reste sensé. C'est universellement supporté dans chaque application d'édition d'image sur Terre. La qualité d'export WebP dans des outils comme Photoshop s'est améliorée dramatiquement, mais l'écosystème autour de JPEG pour les flux de travail de post-traitement est simplement plus mature.
De plus, si vos images sont déjà bien optimisées en JPEG (disons, moins de 100 KB pour une image de 800 px de large), la conversion en WebP ne vous économise que 15-20 KB. Ce n'est pas rien, mais ce n'est pas worth the engineering time si vous faites la conversion manuellement. Choisissez vos batailles.
Et si vous imprimez. Évidemment. WebP est un format web. Ne l'utilisez pas pour quoi que ce soit qui finit sur papier.
---
Outils pratiques à connaître
Ce sont les outils que j'utilise réellement, pas une liste gonflée :
- [Squoosh](https://squoosh.app/) : Basé sur le navigateur, aucune installation, brillant pour les comparaisons ponctuelles et trouver le bon réglage de qualité avant d'automatiser quoi que ce soit. Browser-based, no install, brilliant for one-off comparisons and finding the right quality setting before automating anything.
- Squoosh CLI : Conversion par lot depuis le terminal. Je l'utilise pour les migrations au niveau du projet. Batch conversion from the terminal. I use this for project-level migrations.
- ShortPixel : Meilleur plugin WordPress pour la conversion automatisée à l'upload. Le réglage lossy est sensé par défaut. Best WordPress plugin for automated conversion on upload. The lossy setting is sensible out of the box.
- Cloudflare Polish : Si vous êtes déjà sur Cloudflare Pro, activez-le. Il convertit et compresse à la périphérie automatiquement. Zéro code requis. If you're already on Cloudflare Pro, turn this on. It converts and compresses at the edge automatically. Zero code required.
- Cloudinary : Le choix pour les opérations éditoriales ou e-commerce plus grandes où vous avez besoin de négociation de formats, de dimensionnement réactif et de livraison CDN en tant que service géré. The choice for larger editorial or e-commerce operations where you need format negotiation, responsive sizing, and CDN delivery as a managed service.
- ImageMagick : conversion en ligne de commande pour les workflows côté serveur. Plus lent que Squoosh CLI mais plus flexible pour les pipelines scriptés. Command-line conversion for server-side workflows. Slower than Squoosh CLI but more flexible for scripted pipelines.
---
FAQ
WebP est-il toujours plus léger que JPEG ?
Non. J'aimerais que les gens arrêtent de dire ça. Sur les images très détaillées, haute fréquence (pensez : photographie macro de textures rugueuses, prises architecturales densément détaillées), la différence de taille peut être négligeable ou même inversée selon les paramètres de l'encodeur. Testez vos images spécifiques plutôt que de supposer.
Dois-je conserver le JPEG original si je convertis en WebP ?
Oui. Gardez toujours vos fichiers originaux. WebP est un format de livraison, pas un format d'archivage. Si vous gérez un site WordPress avec ShortPixel, le plugin conserve l'original par défaut. Ne changez pas ce paramètre.
La conversion en WebP va-t-elle nuire à mon SEO d'images ?
Non. Google indexe les images WebP sans aucun problème. Assurez-vous que votre texte alternatif est descriptif et que vos noms de fichiers sont sensés. Le format n'a aucun effet sur le classement des images de recherche.
Qu'en est-il de l'élément `<picture>` par rapport à la simple livraison directe de WebP ?
Si 97 % ou plus de vos utilisateurs supportent WebP, servir WebP directement via une balise <img> n'a rien de problématique. L'élément <picture> avec des fallbacks source avait du sens quand Safari était le dernier récalcitrant. Maintenant, il est surtout utile pour le pattern AVIF-avec-fallback-WebP que j'ai mentionné plus tôt.<img> tag is fine. The <picture> element with source fallbacks made sense when Safari was the holdout. Now it's mainly useful for the AVIF-with-WebP-fallback pattern I mentioned earlier.
Le format d'image affecte-t-il le CLS (Cumulative Layout Shift) ?
Le format en lui-même, non. Mais si vous convertissez des images sans définir d'attributs explicites width et height (ou sans utiliser aspect-ratio en CSS), vous aurez un décalage de mise en page quel que soit le format. C'est l'une des erreurs les plus courantes que je vois lors de migrations de format en masse. Corrigez vos dimensions.width and height attributes (or using aspect-ratio in CSS), you'll get layout shift regardless of format. This is one of the most common mistakes I see when people do bulk format migrations. Fix your dimensions.
---
Les décisions sur les formats semblent anodines. Elles ne le sont pas. J'ai vu une simple après-midi d'optimisation d'images faire passer un site de « échec aux Core Web Vitals » à « succès » et améliorer significativement les taux de conversion pour mes clients e-commerce. WebP est le bon choix par défaut en 2026 pour pratiquement tous les navigateurs livrant des photographies. Mais c'est un défaut, pas une règle. Comprenez pourquoi vous faites ce choix, testez avant d'automatiser, et conservez vos fichiers originaux.