Ces diables de WebP et AVIF : quand la promesse de performance écrase l'expérience dev

Ces diables de WebP et AVIF : quand la promesse de performance écrase l'expérience dev

On nous a vendu le WebP comme le sauveur, puis l'AVIF est arrivé, tel le messie ultime de l'image sur le web. Plus léger, plus rapide, plus beau, bla bla bla. Sur le papier, c'est génial, on gagne des précieux kilo-octets et nos audits Lighthouse explosent. Mais soyons honnêtes entre nous, développeurs : ces formats « nouvelle génération » sont parfois une plaie, une vraie petite épine dans le pied de notre quotidien. Et je ne parle pas seulement de la compatibilité navigateur, ça, c'est le problème facile à résoudre avec un bon <picture>. Non, je parle de la vraie vie, celle où on doit bosser avec ces formats au quotidien, les manipuler, les optimiser, et parfois, les débugger.

Le mythe du « simple » encodage : quand votre CI/CD pleure

Je me souviens d'un projet e-commerce il y a quelques mois. Le client, après avoir lu un article élogieux sur les gains de performance, voulait absolument tout passer en WebP. « Facile ! » me suis-je dit, avec ma naïveté de développeur senior qui a pourtant vu passer des vertes et des pas mûres. On avait une chaîne d'images assez classique : des uploads, un redimensionnement, et hop, on servait le tout. L'idée était d'ajouter une étape d'encodage WebP en plus du JPEG existant. Quoi de plus simple ?

Sauf que non. Ce n'est jamais simple. D'abord, il a fallu choisir l'outil. ImageMagick ? Sharp ? Libwebp direct ? Chacun avec ses quirks, ses dépendances, ses versions qui se marchent sur les pieds. On a opté pour Sharp, qui est une merveille de performance et de flexibilité, je le concède. Mais l'intégration dans notre pipeline de CI/CD, déjà un peu vieillissant, a été un enfer. Les conteneurs Docker qui gonflaient, les versions de Node.js qui ne collaient plus avec les binaires de libvips, les erreurs obscures de segmentation fault quand une image un peu trop exotique passait par là. On a passé des jours à débugger des trucs qui n'avaient rien à voir avec le code métier, juste pour que le sacro-saint WebP soit généré correctement.

Et l'AVIF, n'en parlons pas. C'est encore pire. Les librairies sont moins matures, les performances d'encodage sont souvent à la traîne, et la taille des binaires… Mon Dieu, la taille des binaires ! On parle de dizaines de mégaoctets de dépendances juste pour encoder un format d'image. Est-ce que le gain de quelques kilo-octets sur la bande passante justifie cette complexité et cette empreinte carbone sur nos serveurs de build ? Je me pose sérieusement la question.

Le cauchemar du développeur front : quand le devtools se moque de vous

Et puis il y a le côté développeur front. On nous dit de servir des WebP ou des AVIF, mais que se passe-t-il quand on doit débugger un problème d'affichage ? Vous avez déjà essayé d'ouvrir un WebP corrompu avec la plupart des éditeurs d'images ? Ou même de prévisualiser un AVIF dans votre système de fichiers sans installer un plugin obscur ? C'est le néant. Le néant absolu. On se retrouve à devoir re-convertir en JPEG ou PNG juste pour voir ce qui cloche. C'est une perte de temps monumentale.

Sans parler des outils de développement. Bien sûr, les navigateurs modernes affichent très bien ces formats. Mais quand vous êtes en train de bidouiller un CSS, de vérifier les dimensions d'une image, ou de débugger un lazy loading, avoir un aperçu direct et fiable est crucial. Et là, on se heurte parfois à des comportements étranges. Des images qui ne se chargent pas en local, des prévisualisations tronquées, des messages d'erreur cryptiques. Ça vous est déjà arrivé de passer vingt minutes à chercher une erreur CSS pour finalement réaliser que votre image WebP de test était corrompue et que le navigateur ne disait rien de pertinent ? Moi oui, et ça me hérisse le poil.

Le revers de la médaille de l'optimisation : le coût humain

Je suis le premier à prôner la performance. Un site rapide est un site plus agréable, plus accessible, et qui convertit mieux. Mais à quel prix ? Le temps que nous passons à intégrer, maintenir et débugger ces formats « optimisés » est un coût réel. Un coût en heures de développement, en frustration, et parfois, en qualité de vie. Ce n'est pas parce qu'un outil est techniquement supérieur qu'il est toujours le meilleur choix dans un contexte donné. L'équilibre entre la performance technique et l'expérience développeur est souvent ignoré, et c'est une erreur.

Je me souviens d'une discussion avec un junior qui se battait avec des images AVIF sur un projet. Il était à deux doigts de craquer, ne comprenant pas pourquoi « un simple format d'image » pouvait être si compliqué. Et je l'ai compris. On lui vend la simplicité d'utilisation côté client (un <picture> et c'est réglé), mais on oublie de lui dire le cauchemar que c'est parfois côté serveur et dans le pipeline de développement.

Alors, que faire ? Faut-il renoncer à ces formats ? Bien sûr que non. Le gain est réel et indéniable pour l'utilisateur final. Mais je pense qu'il est temps de pousser les éditeurs d'outils, les mainteneurs de librairies, et même les navigateurs, à améliorer l'expérience développeur autour de ces technologies. Il nous faut de meilleurs outils de débugging, des librairies d'encodage plus robustes et plus simples à intégrer, et des pipelines de CI/CD qui ne se transforment pas en champs de bataille à chaque nouvelle version.

N'oublions jamais que derrière chaque ligne de code, chaque optimisation, il y a un humain. Et cet humain a aussi le droit à une expérience de développement agréable. Sinon, à force de courir après les micro-optimisations, on risque de transformer notre passion en une corvée sans fin. Et ça, c'est une performance que personne ne devrait vouloir optimiser.

Et vous, quelles sont vos expériences avec ces formats d'image nouvelle génération ? Plutôt amour ou haine ? Dites-moi en commentaires, je suis curieux de savoir si je suis le seul à pester contre ces diables d'AVIF et de WebP !