Quelqu'un a t-il déjà abandonné le format .jpg ?

[elji]

Je mesure de temps à autre le poids de mes pages dans les tests de vitesse, et cela me dit que je devrais changer le format de mes images.
Ce sont toutes des .jpg, bien allégées, parce que j'utilise ce format depuis très longtemps, mais on me suggère d'adopter les nouveaux formats .webp ou .avif.

Quelqu'un l'a t-il déjà fait ? Pour quel gain ?

 

[Dr DLP]

Le gain en termes de temps de chargement des pages est très significatif, particulièrement sur mobile.
Je n'utilise plus que du webp, et du png si de la haute qualité est requise (pas mal de perte avec webp quand même), rien entre les deux.

 

[emualliug]

Certains sites utilisent WepP, rarement avec un abandon total du JPEG, ils tirent parti de la possibilité de fournir une image sous plusieurs formats.

Personnellement, je ne cède pas à cette "mode". Le JPEG est un format parfaitement répandu, un standard de facto qui existe depuis près de 30 ans. Bien sûr, il n'est pas parfait, c'est un format de compression avec perte, il ne gère pas le canal alpha, ne gère pas non plus les images animées, etc. Ces trois derniers défauts ne sont cependant pas dirimants pour des photographies (l'essentiel des illustrations), et pour les deux premiers, le PNG fait bien le travail lorsque c'est nécessaire.

Dans l'absolu, un format qui offre une meilleure compression représente un avantage, mais un nouveau format a aussi des inconvénients. Pour que le ratio en vaille la peine, il faut que le gain de taille soit significatif, avec WebP, ce n'est pas le cas. Cette étude sur les gains de taille est intéressante : le gain de WebP est entre 3 et 17 % (par rapport à un JPEG "classique" de qualité d'environ 85%), ce qui n'est pas si phénoménal que ça. Il est plus important sur les petites images (là où il est le moins nécessaire).

Comparé à mozjpeg, le gain relatif est moindre encore, et WebP apparaît moins efficace que mozjpeg sur une image de 1500 px (-3% par rapport à du JPEG classique, là où mozjpeg offre du -6%). Avantage considérable de mozjpeg, ce n'est pas un format différent du JPEG, juste un autre algorithme de compression, la compatibilité n'est donc pas un problème.

Si le gain de rapidité est une nécessité, il y a d'autres choses à privilégier. D'abord servir l'images en différentes dimensions pour s'adapter aux différents écrans. Mettre en place un lazyloading. Et songer au taux de compression du JPEG, les gains de taille peuvent êtres très importants pour une perte de qualité relativement faible, aux alentours de 60-70%, l'image reste assez bonne, largement suffisante pour une illustration. AVIF sera peut être une alternative plus intéressante, les gains sont en tout cas plus substantiel, de l'ordre de 25%, mais est-ce suffisant pour se lancer ?

Pour un gain aussi faible, je ne vois pas l'intérêt d'alourdir tous les navigateurs à venir d'un codec pour lire le WebP. Et je devrais ajouter aux navigateurs tous les logiciels de lecture d'image, qui sont aujourd'hui loin de tous lire le WebP. C'est aussi une galère côté site internet, même si on peut servir différents formats, cela oblige à convertir et stocker autant de version de l'image (multiplié par le nombre de dimensions).

Bref, je ne vois aucun intérêt au WebP, sinon celle de Google de "pousser" un format et leur navigateur par cet intermédiaire.

Mozilla avait pris une position radicale en 2011 en refusant d'intégrer WebP à Firefox, malheureusement suicidaire en l'état des parts de marché actuelles. Mais elle était sensée : ne pas promouvoir la multiplication des formats sans qu'ils apportent une véritable plus-value.

 

[WebRankInfo]

Merci pour cette réponse détaillée.

j'ai regardé vite fait l'étude et je ne comprends pas la méthode. Chaque format a ses propres réglages. Le poids final dépend de l'algo mais aussi de ces réglages. Quel intérêt de comparer à réglages différents ?

Ce qu'il faut faire, c'est calculer la perte de qualité image entre l'original et chaque algo. Et comparer la qualité à poids égal, ou le poids à qualité égale.

PS : au final, je doute vraiment que ça change tant que ça en termes SEO...

 

[emualliug]

Ce qu'il faut faire, c'est calculer la perte de qualité image entre l'original et chaque algo. Et comparer la qualité à poids égal, ou le poids à qualité égale.

Oui, tu as tout à fait raison, c'est ce qui rend les comparaisons aussi difficiles et douteux les arguments d'autorité du style "gagnez 30% sur le poids de votre image".

C'est pour ça que cette étude compare le "structural similarity index measure (SSIM)" entre l'image compressée et l'image d'origine, et que les réglages de chaque compression sont faits pour essayer d'avoir un SSIM similaire ; en l'occurence un SSIM cible de 0.0044, mais ça varie forcément un peu.

Cela reste difficile d'en tirer une conclusion définitive valable dans tous les cas de figure, parce que par exemple, on voit que WebP est un peu meilleur que mozjpeg pour les images de 500 et 1000px, mais un peu moins bon sur 1500px. Qu'en serait-il si la qualité cible était meilleure ? ou moins bonne ? l'écart serait-il plus ou moins important ?

 

[WebRankInfo]

Merci pour ce détail. à l'époque où la compression d'images était mon métier (ce n'est pas une blague), toutes nos études étaient basées sur le PSNR. Intéressant de voir ce nouvel indicateur.

 

[elji]

Merci beaucoup pour cette étude. je vois donc que c'est le format .avif qui est la plus intéressant.
Je vais faire des tests. Si peux alléger mes images de 20%, c'est valable.
Il faut aussi que je vérifie si .avif est bien accepté partout. C'est le grand avantage du .jpg, on sait qu'il est lisible sur tout OS, et tout navigateur.

 

[Just Aware]

Cela fait 2 ans qu'on est passé en webp sur tous nos site et aucun soucis de compatibilité, gros gain de place et chargement.

 

[emualliug]

83,97 % des utilisateurs d'après caniuse. Pas supportée par Edge notamment (version 114, du 2 juin 2023). Ça fait des trous non négligeables.

Il faut aussi voir les performances, notamment à l'encodage, d'après l'article cité, c'est encore très lent (il évoque plusieurs minutes pour une grosse image).

Ce qui est sûr, c'est qu'on ne peut pas se baser que sur AVIF, et que ça implique les inconvénients visés ci-avant, dont un quasi-doublement du volume des images sur le serveur, ce qui implique un une augmentation significative de toutes les sauvegardes complète, notamment, en poids comme en temps.

20 % de gain, c'est très notable en terme de poids, mais pas forcément en terme de temps de chargement de la page, car finalement la réduction ne porte que sur le temps de transfert. J'ai fait un test sans valeur scientifique aucune sur une page qui met 3500 ms à se charger. Sur ce temps là, 600 ms sont consacrés au temps de réception de l'image, si je le réduis de 20 % le gain est de 122ms, soit 3,5 % du temps total de chargement de la page. Cette page d'exemple contenait peu d'images, mais s'il y en avait eu beaucoup plus, le résultat ne serait pas forcément très différent, car les images peuvent être chargées en parallèle, ce qui fait que le temps total de chargement n'est pas si impacté que cela (c'est le temps que met la plus longue des images). Si je voulais faire une économie sur cette page, il vaudrait mieux supprimer un ou deux CSS (par exemple en les fusionnant), afin de réduire le temps d'attente (380ms environ, le temps de chargement étant en lui-même négligeable).

 

[emualliug]

En écrivant ces messages et ce faisant quelques recherches, j'apprends l'existence de JPEG-XL, qui se veut le JPEG du futur, l'intention du groupe de travail étant d'avoir un format qui dure aussi longtemps que le JPEG original.

Il y a quelques fonctionnalités prometteuses. Cloudinary a publié un article en comparant JPEG-WL à WebP et AVIF. Parmis les aspects intéressants : la conversion sans perte de JPEG vers JPEG-XL (ce qui n'est pas possible vers les autres formats), et le fait que le format soit standardisé par l'ISO.

AVIF est limité en taille, comme la plupart des formats, mais la limite est plus proche de ce qui est utilisé en pratique sur le web (3840 × 2160). J'ai l'impression qu'il n'y a pas de chargement progressif à la manière du JPEG sur WebP ou AVIF.

Par contre, la prise en charge par les navigateurs est quasi nulle, en cours de test sous Safari, mais c'est tout.

 

[rick38]

Plus que WebP (au lieu de JPG) et SVG (au lieu des PNG) pour ma part.

WebP est supporté par tous les navigateurs, donc aucun problème.

AVIF non, pas encore assez supporté.

 

[colonies]

Si vous n’êtes pas encore passé à un nouveau format, il peut être intéressant d’attendre de voir ce qui va se passer avec JXL. Adopté par Safari pour la prochaine version, rejeté par Google qui depuis est sous le feu des critiques (et encore plus depuis qu’Apple à indiqué qu’ils allaient supporter JXL), et Firefox… on ne sait pas trop ce qu’ils font.

AVIF est très lent à encoder, et ses gains sont très variables par rapport à JPEG. En lossless, il est mauvais et arrive à faire pire que PNG.
WebP offre un gain faible, sauf pour les photos PNG avec transparence : on peut utiliser du lossy avec alpha, et ça change tout. Même en lossless, il offre un bon gain par rapport à PNG.
JXL est le plus performant sur tout : lossy, lossless. De plus il permet de recompresser les JPEG sans perte, l’encodeur est rapide, il permet le chargement progressif, bref, c’est vraiment un bon format pensé pour les images, alors que WebP et AVIF sont des dérivés de formats vidéo.

Il est quand même bon de proposer des alternatives AVIF pour les grosses images les plus importantes afin de s’entraîner à gérer plusieurs formats pour une image.

 

[colonies]

Merci pour ce détail. à l'époque où la compression d'images était mon métier (ce n'est pas une blague), toutes nos études étaient basées sur le PSNR. Intéressant de voir ce nouvel indicateur.

Sur les indicateurs de qualité :

https://twitter.com/x/status/1580502569238962177

 

[elji]

Un problème d'avif est que mes logiciels actuels ne permettent pas d'enregistrer directement à ce format. Il faudrait que je continue à enregistrer en jpg, et après que je convertisse en avif. Cela fait perdre du temps...

J'ai vu aussi que Xnview, un bon petit soft dont je me sers au quotidien ne sait pas lire l'avif. Je vais donc oublier ce format pour le moment.

Vais faire des tests avec webp que 2 personnes ici disent utiliser...

 

[colonies]

Un problème d'avif est que mes logiciels actuels ne permettent pas d'enregistrer directement à ce format. Il faudrait que je continue à enregistrer en jpg, et après que je convertisse en avif. Cela fait perdre du temps...

J'ai vu aussi que Xnview, un bon petit soft dont je me sers au quotidien ne sait pas lire l'avif. Je vais donc oublier ce format pour le moment.

Vais faire des tests avec webp que 2 personnes ici disent utiliser...

WebP c’est un format qui se dirige vers la porte de sortie.

Au passage, convertir des JPG en WebP ou AVIF n’a pas de sens. Il faut partir d’une image lossless, ou changer de format en réduisant les dimensions de l’image. Par exemple passer un JPG de 3000x3000 à un AVIF de 1000x1000, ça ok.
Ou bien si tu pars de JPG de très bonne qualité (par ex 95%) pour produire des AVIF de qualité "80%", c’est ok aussi.
Mais sinon, tu vas empiler deux types de compression lossless, et c’est vraiment pas une chose à faire. C’est pour ça que JXL est aussi intéressant, permettant de gagner environ 15-20% sur les fichiers JPG, sans qu’aucun pixel ne change.

 

[Furtif]

Ce sont toutes des .jpg, bien allégées, parce que j'utilise ce format depuis très longtemps, mais on me suggère d'adopter les nouveaux formats .webp ou .avif.

Quelqu'un l'a t-il déjà fait ? Pour quel gain ?

Tout ça c'est de la masturbation intellectuelle, je n'ai vu aucune différence entre le JPG et le Webp, la seule différence c'est que j'ai perdu mon temps a passer a Webp pour un résultat nul....

Le seul avantage du Webp est pour les boites qui vendent des solutions logicielles immobilier qui ont des contrats avec amazon et consors pour heberger leurs fichiers images. Ces boites compressent comme des gorets les images envoyées par les agences immo au prix d'une perte colorimetrique, il n'y a pas de miracle reduire le poids d'une image ça se paye...

D'un autre coté quand tu vois que les agents immo balancent des images de 4 Mo je peux comprendre le souci des prestataires en terme d'occupation espace disque.

Au debut j'envoyais a mes clients des images ultras optimisées en jpg en terme de poids, et elles etaient encore passées a la moulinettes du Webp pour un resultat final médiocre en terme de qualité.

Donc maintenant je me casse plus la téte a compresser les images, je me contente de les convertir en jpg.... ca oscille entre 600 Ko a 1,5 Mo selon le cliché. Et au final ca reste tres acceptable une fois passé a la moulinette du Webp par les prestataires....

 

[rick38]

Ca permet surtout d'avoir un avertissement en moins dans PageSpeed, allez, avouez pourquoi on délaisse le JPG

 

[elji]

WebP c’est un format qui se dirige vers la porte de sortie.

Au passage, convertir des JPG en WebP ou AVIF n’a pas de sens. Il faut partir d’une image lossless, ou changer de format en réduisant les dimensions de l’image. Par exemple passer un JPG de 3000x3000 à un AVIF de 1000x1000, ça ok.
Ou bien si tu pars de JPG de très bonne qualité (par ex 95%) pour produire des AVIF de qualité "80%", c’est ok aussi.
Mais sinon, tu vas empiler deux types de compression lossless, et c’est vraiment pas une chose à faire. C’est pour ça que JXL est aussi intéressant, permettant de gagner environ 15-20% sur les fichiers JPG, sans qu’aucun pixel ne change.

100% de mes images de départ sont des .jpg, soit de mon smartphone, soit parce qu'on me les envoie comme cela. J'ai pas vu un bmp depuis 10 ans.
100% de mes images sont recadrées et réduites, entre 400 et 800 pixels, et c'est après cela que je choisis le format d'enregistrement. Dans mon logiciel, je peux choisir jpg, gif, png, webp ou bien d'autres encore, mais pas avif.

Je n'avais jamais entendu l'idée que webp était sur la tangente. Qui dit cela ?

Ca permet surtout d'avoir un avertissement en moins dans PageSpeed, allez, avouez pourquoi on délaisse le JPG

C'est clair que le Pagespeed qui m'a donné l'idée, je suis très satisfait du jpg.

 

[colonies]

Je n'avais jamais entendu l'idée que webp était sur la tangente. Qui dit cela ?

Les personnes qui s'intéressent aux formats d'image et qui ont testé longuement les différents formats.
Le seul intérêt de WebP, en l'absence de JXL, c'est qu'il est meilleur pour les images lossless. Sinon, AVIF est vraiment meilleur et il n'y a aucune raison de lui préférer WebP.
Il y a bien Edge et quelques navigateurs chinois (UC, QQ...) qui ne supportent pas encore AVIF, mais si on veut rester compatible "tous navigateurs", ça ne vaut pas le coup d'avoir un duo JPG/WebP qui sont trop proches. JPG/AVIF, ça a déjà plus de sens.

100% de mes images de départ sont des .jpg, soit de mon smartphone, soit parce qu'on me les envoie comme cela. J'ai pas vu un bmp depuis 10 ans.

Dans mon logiciel, je peux choisir jpg, gif, png, webp ou bien d'autres encore, mais pas avif.

Quel est ton workflow, au juste ? Quand tu dois ajouter une photo, tu ouvres un logiciel sur ton ordi, tu redimensionnes, tu sauvegardes et tu met en ligne ?
Ou bien tu as un CMS et tu envoies l'image qui est redimensionnée par le serveur ?
C'est quoi ton logiciel dont tu parles ?

Ce dont je parle, c'est de traitements d'images faits automatiquement : redimensionner / sauvegarder en plusieurs formats, c'est une ligne de commande ou un programme qui applique toujours le même traitement à tout ce qui est dans un dossier contenant les photos originales (non redimensionnées, jamais converties dans un autre format). Les conversions sont toujours effectuées coté serveur.

 

[Rincevent72]

Pour ma part, je garde toujours une image en jpg (feature) et toutes les autres en webp. WebP permet d éviter une pénalité sur pagespeed mais n'est pas bien géré sur certaines plateformes (réseaux sociaux par exemple). Je fais donc une sorte de compromis...

 

[rick38]

AVIF n'est même pas supporté par Discord, si c'est pour ne pas avoir d'image quand on partage son site sur les réseaux sociaux, autant garder le JPG ou WebP.

 

[elji]

Les personnes qui s'intéressent aux formats d'image et qui ont testé longuement les différents formats.
Le seul intérêt de WebP, en l'absence de JXL, c'est qu'il est meilleur pour les images lossless. Sinon, AVIF est vraiment meilleur et il n'y a aucune raison de lui préférer WebP.
Il y a bien Edge et quelques navigateurs chinois (UC, QQ...) qui ne supportent pas encore AVIF, mais si on veut rester compatible "tous navigateurs", ça ne vaut pas le coup d'avoir un duo JPG/WebP qui sont trop proches. JPG/AVIF, ça a déjà plus de sens.



Quel est ton workflow, au juste ? Quand tu dois ajouter une photo, tu ouvres un logiciel sur ton ordi, tu redimensionnes, tu sauvegardes et tu met en ligne ?
Ou bien tu as un CMS et tu envoies l'image qui est redimensionnée par le serveur ?
C'est quoi ton logiciel dont tu parles ?

Ce dont je parle, c'est de traitements d'images faits automatiquement : redimensionner / sauvegarder en plusieurs formats, c'est une ligne de commande ou un programme qui applique toujours le même traitement à tout ce qui est dans un dossier contenant les photos originales (non redimensionnées, jamais converties dans un autre format). Les conversions sont toujours effectuées coté serveur.

Le traitement d'images automatique, cela ne vaut rien. Chaque image a ses propres caractéristiques, il faut toujours recadrer, parfois corriger les niveaux, et c'est une par une, avec un logiciel de retouche d'images. J'en ai trouvé un qui permette d'enregistrer en .avif, c'est paint.net. Un gratuit en plus, mais comme il y a des problèmes de compatibilité, j'ai déjà décidé d'oublier ce format.

Pour webp, mes tests ne sont pas concluants. C'est pas plus léger qu'en jpg.

 

[colonies]

Le traitement d'images automatique, cela ne vaut rien.

Bah non. Si tu retouches toutes les images toi-même, tu peux les sauvegarder en lossless, et c'est le serveur qui se chargera des opérations comme le redimensionnement et l'enregistrement.
Personnellement, je conserve les originaux tels quels. Recadrer une image, par exemple, se fait sur le serveur avec les coordonnées du cadre. Par exemple si je veux des carrés en sortie, j'ai les coordonnées des carrés (qui peuvent être du 1528x1528 sur une photo, 1300x1300 sur une autre...). Et si aujourd'hui mon site affiche des images qui sont envoyées au navigateur en 500x500, peut-être que dans un an je voudrai des photos de 750x750. Je n'aurai qu'à changer les paramètres d'export au lieu de tout refaire à la main.

Pour ce cas précis, tu peux aussi le faire en enregistrant les formats carrés dans un dossier, et faire un traitement par lot de ce dossier pour redimensionner/choisir le format de sortie. Il n'y a aucune différence entre ça et toi qui fait Fichier > Ouvrir > double-clic > Image > Redimensionner > 500x500 > Fichier > Enregistrer > JPEG > Qualité 80% > Enregistrer sous > ...
Si tu as des centaines d'images et que tu ne prévois pas les changements, chaque évolution fait perdre un temps fou.

 

[elji]

OK, dans cette hypothèse, un traitement automatisé serait appréciable, mais je n'imagine pas pour quelle raison je changerais à l'avenir le format de mes images. Il y a quelques années, j'avais pas mal d'images en 390 px de largeur, et je suis passé en 430px, mais je n'ai pas modifié les anciennes images sur les vieux articles. Ce n'est pas gênant.

Un point détestable du traitement automatique est que cela nivelle la qualité. 50 ou 80%, c'est mieux de faire image par image, même si je ne fais à chaque fois.

Pour revenir au sujet, j'ai revu les paramètres sur mon logiciel, et effectivement le webp est plus léger que le jpg !

 

[eldk]

Bonjour,

Quelques infos sur le format webp : https://github.com/webmproject/libwebp .

Pour ma part, sur plusieurs sites, pour des images uploader en .jpg, .png par les visiteurs, ou, gestionnaires de contenu, et donc, pas toujours optimisées correctement, l'utilisation de ce format permet de diminuer l'utilisation de bande passante de 25 à 35% .

Le gain peut être conséquent, sur certaines images, "publiées vite fait et telles que reçues" par les rédacteurs (+ de 50 %) ... Dans ce cas, il s'agit d'une "assurance" contre les images "géantes".

Ces chiffres sont une moyenne depuis 8 ans environ - progressivement, la plupart des navigateurs sont devenus webp compatibles - y compris Edge, qui est maintenant construit sur une base Chromium.

Cordialement,

Eric

 

[elji]

Pour aider à ma reflexion, j'ai regardé mes sites concurrents. Les gros sites, et ils sont tous toujours en jpg.

 

[Mickael28800]

Effectivement beaucoup de sites proposent encore le format jpg. Personnellement je suis passé en webp car comme précisé plus haut, ce format est aujourd'hui accepter par tous les navigateurs

 

[elji]

Oui, j'ai trouvé un autre site comparable au mien qui est passé au webp, mais c'est un petit concurrent. Les gros restent fidèles au jpg.

 

[kartyr]

Tout dépend de la nature des images.

Rien qu'avec la SVG, on peut faire pas mal de belles choses, et ça se compresse super bien en gz ou br.

Pour le reste, perso je suis passé en WebP il y a quelques temps, parce que j'ai des effets de transparence, chose impossible avec le JPEG et le PNG était trop lourd.

Après, je me prépare à passer l'AVIF , puis au JPEG XL, dans les années à venir, au fur et à mesure de l'évolution de la compatibilité avec les navigateurs.

WebP : 96.76% https://caniuse.com/webp
AVIF : 83.95% https://caniuse.com/avif
JPEG XL : 0.03% https://caniuse.com/jpegxl

A noter que j'ai des images qui sont générées dynamiquement , même si elles sont mises en cache , après la première génération, WebP est, à l'heure actuelle, beaucoup plus rapide que l'AVIF (PHP)

 

[colonies]

A noter que j'ai des images qui sont générées dynamiquement , même si elles sont mises en cache , après la première génération, WebP est, à l'heure actuelle, beaucoup plus rapide que l'AVIF (PHP)

Qu'est-ce que tu veux dire ? Une fois l'image générée, il n'y a pas de différence coté serveur (et tu ne devrais plus avoir besoin de passer par PHP), à moins que tu aies un problème de configuration serveur (une compression à la volée inutile comme gz ou br sur les AVIF par le serveur web ?). Ou alors c'est juste parce qu'AVIF est plus lent à décoder par le navigateur, mais ça ne concerne pas le serveur.

 

[kartyr]

Qu'est-ce que tu veux dire ? Une fois l'image générée, il n'y a pas de différence coté serveur (et tu ne devrais plus avoir besoin de passer par PHP), à moins que tu aies un problème de configuration serveur (une compression à la volée inutile comme gz ou br sur les AVIF par le serveur web ?)

Dans mon cas, particulier, c'est parce que le contenu des images est différent d'un utilisateur à l'autre, et ce contenu change toutes les 10 minutes. Donc, le cache ne sert que pour 10 minutes max (normalement, il ne doit pas servir, car le navigateur est supposé faire le taf, mais on ne sait jamais).

ps: à propos du AVIF, il n'est pas encore supporté par Edge, et Googlebot, ce qui peut être un critère à prendre en compte.

 

[drphilgood]

bonjour
moi aussi je suis passé au webp (avec un remplacement auto par jpg ou png au cas ou le visiteur n'a pas de matos à jour)

 

[elji]

Bon, c'est fait. Je suis passé au webp en début de mois. J'ai des pages avec une dizaine d'images, elles sont un peu plus légères. Les visiteurs sur mobile devraient apprécier.

 

[poupilou]

Passer au webp ou pas c'est une première question, mais définir la bonne taille de l'image que l'on va proposer à l'internaute en fonction de sa taille d'écran en est une autre !

A quoi ça sert de proposer une image webp de 1500x1500 à un mobinaute si la taille de son écran est de 375px ?

Comment gérer à la fois le format de l'image (jpg, webp, avif, etc...) et sa taille en fonction des breakpoints css ?

D'après ce site, il faudrait écrire le code ci-dessous :

<picture>
    <source
       type="image/webp"
        media="(min-width: 1000px)"
        srcset="
            /images/image-336x240.webp 1x
            /images/image-672x480.webp 2x
        "
    />
    <source
       type="image/jpeg"
        media="(min-width: 1000px)"
        srcset="
            /images/image-336x240.jpg 1x
            /images/image-672x480.jpg 2x
        "
    />
    <source
       type="image/webp"
        media="(min-width: 600px)"
        srcset="/images/image-480x600.webp 2x"
    />
    <source
       type="image/jpeg"
        media="(min-width: 600px)"
        srcset="/images/image-480x600.jpg 2x"
    />
    <source
       type="image/webp"
        media="(min-width: 416px)"
        srcset="/images/image-1070x416.webp 2x"
    />
    <source
       type="image/jpeg"
        media="(min-width: 416px)"
        srcset="/images/image-1070x416.jpg 2x"
    />
    <source
       type="image/webp"
        srcset="/images/image-622x416.webp"
    />
    <img
        alt="Description de l'image"
        src="/images/image-622x416.jpg"
        loading="lazy"
    />
 </picture>

Une vraie usine à gaz tout ça

Quelles solutions utilisez vous pour gérer à la fois le format de l'image et sa taille ?

 

[colonies]

Pour ce qui concerne le type, tu peux rewriter en fonction de ce que le navigateur déclare supporter, ça permet déjà de limiter la taille du code.
https://stackoverflow.com/questions/56100014/how-to-serve-webp-images-using-htaccess

 

[poupilou]

Merci pour ta réponse colonies.

Avec le code ci-dessous placé dans le htaccess, ça détectera si le navigateur internet de l'internaute accepte ou pas le format webp et si oui ça remplacera les urls se terminant par jpg ou png par webp.

<Files *.webp>
    Header set Vary "Accept-Encoding"
    AddType "image/webp" .webp
    AddEncoding webp .webp
</Files>

RewriteCond %{HTTP:Accept} image/webp
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule ^(.*)$ $1.webp [L]

Pour des raisons de praticités, je voudrais créer et mettre mes images webp dans un répertoire spécifique qui se nommerait /webp/ et qui se situerait dans ../images/webp/. Quelle règle dois-je écrire pour que ça rewritte une image qui est située dans ../images/mon_image.jpg en ../images/webp/mon_image.webp ?

 

[drphilgood]

Je mesure de temps à autre le poids de mes pages dans les tests de vitesse, et cela me dit que je devrais changer le format de mes images.
Ce sont toutes des .jpg, bien allégées, parce que j'utilise ce format depuis très longtemps, mais on me suggère d'adopter les nouveaux formats .webp ou .avif.

Quelqu'un l'a t-il déjà fait ? Pour quel gain ?

Bonjour,
çà fait an que je suis passé au webp, mais il faut avancer et tant pis pour ceux qui vivent encore au siècle dernier. D'autant plus que tous les systèmes et navigateurs modernes et récents (2021 et +) supportent le webp.
safari, chrome, firefox, opera, brave, edge OK.
Un seul format d'image c'est plus facile a gérer.

 

[poupilou]

J'ai essayé ce code ci-dessous dans mon fichier htaccess mais ça ne marche pas, les images qui s'affichent sont toujours en .jpg

<Files *.webp>
    Header set Vary "Accept-Encoding"
    AddType "image/webp" .webp
    AddEncoding webp .webp
</Files>

RewriteCond %{HTTP:Accept} image/webp
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule ^(.*)$ $1.webp [L]

Mes images (jpg et webp) sont dans mon répertoire images qui est à la racine de mon site. J'ai donc essayé ces règles ci-dessous mais ça ne marche pas non plus :

<Files *.webp>
    Header set Vary "Accept-Encoding"
    AddType "image/webp" .webp
    AddEncoding webp .webp
</Files>

RewriteCond %{HTTP:Accept} image/webp
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule ^images/(.*)$ /images/$1.webp [L]

Voyez vous une erreur dans mon code ?

 

[poupilou]

J'ai remplacé manuellement dans le code html d'une de mes pages une image jpg par du webp et l'image s'affiche parfaitement bien, c'est donc pas un souci de format ou de type d'image.

Je pige pas, qu'est-ce qui va pas dans la règle de mon htaccess ?

 

[artoflog]

https://htaccess.madewithlove.com/

 

[elji]

Je déconseille vivement le format .webp puisqu'il m'a ajouté plus d'une centaines d'erreurs dans la GSC (comme si je n'en avais déjà pas assez ?). Je suis revenu au .jpg, et il n'y a plus d'erreurs.

Pour les images de différentes dimensions, c'est un autre sujet.

 

[Just Aware]

On est passé au Webp unique depuis 2 ans et aucun soucis, ni pour les internautes, ni avec gsc.

 

[poupilou]

https://htaccess.madewithlove.com/

Merci pour cet outil que je ne connaissais pas et qui est très utile.

D'après les tests que j'ai pu faire avec cet outil, le code ci-dessous me rewritte bien les images jpg en webp :

RewriteCond %{HTTP:Accept} image/webp
RewriteCond %images/webp/{REQUEST_FILENAME}.webp -f
RewriteRule images/(.+)\.(jpe?g|png|gif)$ /images/webp/$1.webp [L]

Mais l'outil m'indique 2 erreurs :

1) RewriteCond %{HTTP:Accept} image/webp
We could not check this condition because the variable to check against is unknown.

2) RewriteCond %{REQUEST_FILENAME}.webp -f
Unsupported TestString: %{REQUEST_FILENAME}.webp

Je déconseille vivement le format .webp puisqu'il m'a ajouté plus d'une centaines d'erreurs dans la GSC (comme si je n'en avais déjà pas assez ?). Je suis revenu au .jpg, et il n'y a plus d'erreurs.

Merci pour ton retour mais que faire ? Certains ont l'air satisfait du format webp et pas d'autres, c'est assez déconcertant tout ça ?

Certes on voit bien que Google (via son outil PageSpeed Insights) pousse les websmaters à migrer leurs images vers du webp mais est-ce la solution idéale ? D'autant plus que pour bien faire, il faudrait idéalement proposer à l'internaute 2 à 3 types d'images différents (jpg, webp, avif) dans plusieurs tailles différentes (format mobile et desktop), c'est une vraie usine à gaz à mettre en place tout ça, non ?

 

[poupilou]

On est passé au Webp unique depuis 2 ans et aucun soucis, ni pour les internautes, ni avec gsc.

As-tu testé tes pages avec l'outil PageSpeed Insights ?

 

[Just Aware]

oui bien sur, on est a 100%, mobile et desktop, il n'y a pas de question à se poser pendant 107 ans, on passe au webp sans se soucier de redirection ou quoi d'autres.

 

[colonies]

oui bien sur, on est a 100%, mobile et desktop, il n'y a pas de question à se poser pendant 107 ans, on passe au webp sans se soucier de redirection ou quoi d'autres.

Et tu comptes passer quand à AVIF ou à JPEG XL avec ta technique ?
Tu gardes les formats originaux, au moins ? Ou tu fais tout "sans te poser de question" et tu verras bien comment ça se passera ?

 

[Just Aware]

Alors je fait du web depuis plus de 20 ans et j'en vis très bien, donc oui je me pose des questions en permanence, je test, je cherche, j'optimise.
J'ai passé 6 mois à étudier le passage au webp et cela fait maintenant 2 ans que j'y suis passé.
Donc oui c'est étudié avec précision et oui ça marche très bien, aussi bien du coté internaute que référencement, avec un gain de rapidité important.
De gros site y sont passé ensuite, comme doctolib pour ne citer qu'un exemple, tu vas aussi dire que ce sont des charlots ?

 

[colonies]

C’est très intéressant mais ça ne répond pas à mes questions.

 

[Just Aware]

Non pour le moment pour avif et jpeg xl mais pourquoi pas si ça devient la référence.
Non je ne garde pas les formats originaux.

 

[colonies]

Non pour le moment pour avif et jpeg xl mais pourquoi pas si ça devient la référence.
Non je ne garde pas les formats originaux.

AVIF est déjà largement supporté, c'est déjà une référence.

Je ne sais pas quel est le cycle de vie de tes images, mais si elles sont là pour rester longtemps et que tu affiches à tes visiteurs le format le plus grand que tu as, tu devrais vraiment conserver les originaux.
Si tu pars de JPG pour du WebP, tu dégrades la qualité des images et si tu repasses en AVIF ou JPEG XL, tu as encore une dégradation... alors que de JPEG à AVIF, tu n'as qu'une dégradation, et que JPEG XL peut recompresser les JPEG sans aucune détérioration graphique.
De plus WebP lossy, encode les couleurs sur 8 bits et en YCbCr 4:2:0, ce qui fait que les couleurs bavent un peu et perdent en vivacité si ce sont, par exemple, des photos prises avec des téléphones pas trop anciens.
Essaye de réencoder ça en WebP, par exemple : https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png (il y en a d'autres ici : https://webkit.org/blog-files/color-gamut/)
C'est parce que WebP est déjà un vieux format arrivé avant la démocratisation de DCI-P3, alors qu'AVIF et JPEG XL sont arrivés dans un mode où la HDR était déjà bien présente.

Bref, de toute façon, le web doit être progressif et doit toujours essayer d'être accessible au plus grand nombre. D'un autre coté, si tu attends qu'une techno soit vraiment dispo pour 99% des gens, tu peux souvent attendre TRES longtemps.
Personnellement, je sers du JPEG XL, AVIF, WebP et JPEG pour mes images les plus vues (comme les grandes images de header de rubrique). Pour les mobiles, c'est du JPEG ou AVIF (très bien dans ce cas). Dans d'autres cas, je n'ai que PNG/JPEG ou WebP. Et parfois (pour des contenus envoyés par les utilisateurs), si un utilisateur envoie un WebP, je ne génère pas une version JPEG d'emblée, mais si un navigateur ne supportant pas WebP passe par là, je lui envoie une version recompressée à la volée en JPEG.
Alors c'est sûr, c'est un peu plus compliqué que de tout convertir et basta, mais d'un autre coté je supporte toujours 100% des navigateurs, les plus récents ont des images avec une meilleur fidélité et un chargement plus rapide, et quand je change d'avis, je peux repartir des originaux.

 

[Just Aware]

De toute façon, les vieux navigateurs ne supportent pas grand chose en css, dès que tu fait des truc originaux, ton site s'affiche mal, donc les images ne sont plus trop importantes.
Je travaille pour 95% des internautes, ceux qui ne veulent pas se mettre à la page, c'est leur choix et ils ne voient pas beaucoup de site actuels.
Je ne vais pas monter une usine à gaz pour quelques visiteurs égarés.
Et je ne veux pas passer 50% de mon développement et pénaliser les 95% sous prétexte qu'une poignée ne se met pas à jour.
Donc j'ai fait mon choix.
Quand 95% pourront voir un nouveau format d'image sans soucis, j'upgraderais mais ce n'est pas encore le cas.

 

[Just Aware]

La question initiale était: qui a abandonné le format jpeg. J'ai juste donné mon témoignage, je ne détiens pas la vérité, ce n'est qu'un avis et ce que j'ai fait.

 

[poupilou]

Une chose tout de même à garder en tête, le format webp a été créée par Google, de même que PageSpeed Insights et c'est ce même outil qui prône, incite fortement au passage au format webp.

Personnellement je ne suis pas le toutou de Google, j'ai d'ailleurs dégagé de mes sites tous les plugins de cette société (Analytics, Adsense, etc...) car ils sont parfois incompatibles entre eux. Par exemple, quand vous faites une analyse avec PageSpeed Insights de votre site, avec Analytics installé, vous verrez parfois que la requête http vers Analytics bloquent le premier rendu de votre site, c'est un putain de comble, non ?

Ou bien si vous diffusez sur votre site des Adsenses, certaines annonces flottantes masquent le haut de votre site et donc masquent votre menu sur mobile, c'est pas très bon pour l'expérience utilisateur tout ça, non ? Ils ne sont pas capables de rendre compatibles leurs différents outils entre eux, les neuneux d'ingénieurs de chez gogoles.

Donc pour moi méfiance avec le format webp parce que comme disait mon grand père : il ne faut pas mettre tous ses oeufs dans le même panier

 

[LaurentW]

avant de se fixer sur un format d'image ou de compression, je pense qu'il faut bien réfléchir à comment intégrer les images sur un site. J'utilise toujours le jpg parce que c'est plus pratique pour moi mais je m'assure de proposer plusieurs tailles d'images pour ne pas charger des images inutilement grandes et lourdes, je charge toutes les images en différés en m'assurant bien que le conteneur soit déjà à la bonne taille pour éviter les problèmes de CLS. Avec ces 3 méthodes, le choix du type d'image est presque secondaire.

Avec ça, tout est dans le vert (même pour le mobile) dans Page Insight mais aussi Webpagetest.org

 

[poupilou]

je m'assure de proposer plusieurs tailles d'images

Merci pour ta réponse, quelles sont les différentes tailles d'images jpg que tu proposes ?

 

[emualliug]

Les tailles d'images à retenir dépendent du site.

Par exemple, pour une image qui s'affichera sur toute la largeur de l'écran, je prends 1200px de large, 1080px, 828px et 478px. Mais pour une image dans un cadre, ça va dépendre de la taille max qu'elle est susceptible d'avoir suivant les différents breaking points du CSS.

Pour optimiser la taille du point de vue de temps de chargement dans un objectif SEO, il faut essayer de se caler sur la taille du contenu tel qu'obtenu par Googlebot (en desktop et surtout en mobile).

 

[LaurentW]

Merci pour ta réponse, quelles sont les différentes tailles d'images jpg que tu proposes ?

J'utilise 150, 300, 768, 1024, 1400, 1920, 2500
Ca peut paraitre overkill c'est un choix que j'ai fait en fonction de mes besoins. Le tout est automatisé, cela ne me prend pas plus de temps. Ca prend clairement plus de place mais j'ai assez d'espace de stockage pour de nombreuses années.

 

[colonies]

J'utilise 150, 300, 768, 1024, 1400, 1920, 2500
Ca peut paraitre overkill c'est un choix que j'ai fait en fonction de mes besoins. Le tout est automatisé, cela ne me prend pas plus de temps. Ca prend clairement plus de place mais j'ai assez d'espace de stockage pour de nombreuses années.

Et tu compresses tout avec la même qualité ? Quand c'est pour un écran HiDPI, tu peux augmenter nettement le taux de compression.
Pour le mobile, j'envoie du @3x en qualité JPEG... 30 (et en qualité AVIF 45 - ce sont les taux pour ImageMagick). Les écrans avec un device-pixel-ratio de 3 existent depuis un bon moment, maintenant : https://iosref.com/res

 

[LaurentW]

la partie automatisée compresse avec le même taux de compression (8/12) mais c'est au niveau de l'image de base quand je la prépare dans Photoshop que parfois j'adapte la compression en fonction des besoins.

 

[poupilou]

il faut essayer de se caler sur la taille du contenu tel qu'obtenu par Googlebot

Comment tu fais cela ?

J'utilise 150, 300, 768, 1024, 1400, 1920, 2500

Ca veux dire que tu as autant de breaking point css que tu as de tailles d'images, c'est bien cela ?

Comment gérez vous l'affichage de la bonne taille de l''image en fonction de la taille d'écran de l'internaute : via les breaking point css, en javascript, ou autres ?

Pour le mobile, j'envoie du @3x en qualité JPEG

Comment tu fais cela ? Via le srcset et le sizes de la balise <img> ?

 

[emualliug]

Comment tu fais cela ?

https://support.google.com/webmasters/thread/201318671?hl=en&msgid=201343102

La deuxième solution, qui repose sur https://search.google.com/test/mobile-friendly?hl=en est malheureusement en toute fin de vie.

Pour résumer, à l'heure actuelle 412px (mais faut tenir compte de la densité de pixels).

autant de breaking point css que tu as de tailles d'images

Dans l'idée, mais pas systématiquement. Par exemple pour une image utilisée dans des cadres calés sur une grid, il faut voir les breaking point effectivement utilisés et voir à chaque breaking point la taille maximale occupée par l'image. La taille la plus large n'est pas nécessairement occupée pour l'écran le plus large, parce que par exemple, dans ce cas, il y aura plusieurs cadres les uns à côté des autres et ils seront chacun moins large que sur un écran plus petit mais où le cadre occupera toute la largeur.

Comment gérez vous l'affichage de la bonne taille de l''image en fonction de la taille d'écran de l'internaute : via les breaking point css, en javascript, ou autres ?

Pour choisir le bon fichier, avec l'attribut srcset dans la balise <img>. L'élément <img> prenant sa dimension suivant l'élément qui le contient (ce qui ne dispense pas de préciser les attributs width et height pour le ratio).

 

[colonies]

Comment tu fais cela ? Via le srcset et le sizes de la balise <img> ?

En fait j'ai un site adaptatif, donc j'ai une version spéciale mobiles, et les mobiles reçoivent tous une version @3x. Donc dans mon cas, je n'ai même pas de srcset, c'est un src avec choix du format d'encodage en fonction des headers.

 

[poupilou]

La deuxième solution, qui repose sur https://search.google.com/test/mobile-friendly?hl=en est malheureusement en toute fin de vie.

Qu'est-ce qui est en fin de vie : Lighthouse ?

Est-il possible de créer une fonction php qui se chargerait de détecter la taille de l'écran de l'internaute, de tester s'il accepte du wepb et d'écrire ensuite la balise image <img> en fonction des paramètres récoltés ?

Du style :

CreateImage('$name_image','$width_image','$height_image','$alt_image','$title_image','$css_image');

 

[colonies]

C'est le navigateur qui demande ce dont il a besoin, pas le serveur qui lui envoie ce qu'il croit que le navigateur devrait afficher. C'est une mauvaise approche de vouloir écrire une balise HTML en essayant de deviner ce dont il a besoin.

Quant au format webp, tu ne peux pas faire ce test avec PHP pour les requêtes venant de Safari, qui n'envoie les headers Accept pour les formats d'images que pour les requêtes liées à des balises <img>.
Le document. ne reçoit que:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Mais une requête dans une balise <img> avec le même Safari reçoit :
Accept: image/webp,image/avif,image/jxl,image/heic,image/heic-sequence,video/*;q=0.8,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
C'est pour ça que l'approche de rewrite depuis Apache fonctionne.

 

[poupilou]

Merci pour ces précisions colonies.

Pas si facile ces problématiques de compatibilités d'affichage d'images

Donc en conclusion, si l'on veut rewritter rapidement nos anciennes images jpg, gif en webp on passe par une règle dans le fichier htaccess et en ce qui concerne la taille des images on est obligé de passer par ce type de code avec les breaking css :

<picture>
    <source
       type="image/webp"
        media="(min-width: 1000px)"
        srcset="
            /images/image-336x240.webp 1x
            /images/image-672x480.webp 2x
        "
    />
    <source
       type="image/webp"
        media="(min-width: 600px)"
        srcset="/images/image-480x600.webp 2x"
    />
    <source
       type="image/webp"
        media="(min-width: 416px)"
        srcset="/images/image-1070x416.webp 2x"
    />
    <source
       type="image/webp"
        srcset="/images/image-622x416.webp"
    />
    <img
        alt="Description de l'image"
        src="/images/image-622x416.jpg"
        loading="lazy"
    />
 </picture>

Voyez vous une autre solution (moins chronophage) pour proposer les bonnes tailles d'images ?

 

[emualliug]

Qu'est-ce qui est en fin de vie : Lighthouse ?

Non, l'outil vers lequel j'avais fait un lien et qui permettait de voir le résultat tel qu'interprété par le navigateur mobile, soit en donnant une URL soit le code de la page.

L'outil arrivait à expiration le 1er décembre 2023, jour de mon message, et était encore accessible ce jou-là. La page qui traite de Lightouse est une redirection depuis le lien que j'ai donné.

 

[poupilou]

Petite question : comment on indique la taille de l'image (width et height) qui doit être retourné si l'on utilise le code ci-dessus <picture> avec l'élément html <source> ?

Si le navigateur de l'internaute accepte les images webp et si son écran est < à 416px, l'image affichée sera "images/image-622x416.webp", mais quelles sont les dimensions (width et height) de cette image, quel est le titre, quel est le alt de cette image webp ?

D'après le https://www.w3schools.com/tags/att_width.asp, l'attribut width ne peut être utiliser que pour les éléments <canvas>, <embed>, <iframe>, <img>, <input>, <object>, <video>.

 

[emualliug]

Il faut indiquer les dimensions dans la balise <img> au sein de ton <picture>.

Pour fournir des tailles différentes d'une même image, je préfère utiliser l'attribut srcset au sein d'une balise <img> plutôt que la balise <picture>, notamment pour s'affranchir des attributs media. Tu laisses le navigateur choisir l'image suivant celle dont il a besoin.

Édit : un billet stackoverflow à ce sujet https://stackoverflow.com/a/31848856

 

[poupilou]

Merci emualliug.

Si les dimensions width et height sont indiquées uniquement pour la balise <img> et que l'on utilise l'attribut srcset, comment indiquer les dimensions de l'image de substitution qui sera chargée par le srcset ?

 

[poupilou]

Peut-on proposer 2 ou 3 types d'images (jpg, webp, gif) avec la balise <img> avec l'attribut srcset sans passer par les balises <picture> et <source> ?

Si je crée les 3 tailles d'images ci-dessous, est-ce que ce sera suffisant pour satisfaire à la grande majorité des tailles d'écran ?

large.jpg (1024 × XX pixels)
medium.jpg (640 × XX pixels)
small.jpg (320 × XX pixels)

 

[emualliug]

Si les dimensions width et height sont indiquées uniquement pour la balise <img> et que l'on utilise l'attribut srcset, comment indiquer les dimensions de l'image de substitution qui sera chargée par le srcset

Les dimensions sont surtout importantes pour permettre au navigateur de déterminer la taille de l'emplacement de l'image sans avoir à la charger. Dans la plupart des contextes "modernes", la largeur dépend de ce qui contient l'image (la largeur est rarement fixe), et les dimensions de l'image sont importantes pour le ratio (et donc calculer la hauteur en connaissant la largeur).

Je pense que l'idée est que le ratio reste le même. Notons que ce n'est pas une obligation, et que même, au contraire, il serait tout à fait justifier dans un <picture> d'avoir des images de ratio différent.

En tout cas c'est ce que donne la doc MDN, en tout cas en langue anglaise (par repris dans la traduction française) :
The <img> element serves two purposes:

1. It describes the size and other attributes of the image and its presentation.
2. It provides a fallback in case none of the offered <source> elements are able to provide a usable image.

Peut-on proposer 2 ou 3 types d'images (jpg, webp, gif) avec la balise <img> avec l'attribut srcset sans passer par les balises <picture> et <source>

Je ne pense pas, pour des images de format différent il faudra passer par un élément <picture>, avec un élément <source> pour chaque type (sauf celui de fallback), en renseignant bien l'attribut type="image/webp" (par exemple), et en fournissant les différentes dimensions dans un srcset.

Pour le fallback (par hypothèse, le jpg classique), on le laissera dans un élément <img> au sein du <picture> avec ses différentes dimensions dans le srcset et sa dimension "préférée" (généralement la plus grande) dans le src.

 

[Jojo23M]

Très intéressantes toutes les réponses.

 

[elji]

Je mets ici le lien qu'on m'avait donné sur une autre discussion, afin de répéter ma mise en garde.

https://www.searchenginejournal.com...s-webp-image-indexing-confusion/485844/#close

J'ai expérimenté ce problème, et je ne m'en suis pas rendu compte tout de suite (je regarde irrégulièrement la GSC), mais je me suis retrouvé avec une centaine d'erreurs avec les images au format .webp. Je suis alors repassé au .jpg, pour les nouvelles images et plus aucun problème. Si ce n'est que je n'ai pas fini de remplacer les .webp par des .jpg, en faisant des 301, cela me fait perdre du temps...