Smashing Podcast Episode 39 avec Addy Osmani : Optimisation d'image

Cet épisode a été aimablement soutenu par nos chers amis de Storyblok qui aident les gens à offrir des expériences de contenu puissantes sur n'importe quelle plate-forme : sites Web d'entreprise, sites de commerce électronique, applications mobiles et affichages à l'écran. Merci!

Dans l'épisode d'aujourd'hui du Smashing Podcast, nous parlons d'optimisation d'image. Quelles étapes devons-nous suivre pour des images performantes en 2021 ? J'ai parlé avec l'expert Addy Osmani pour le savoir.

Afficher les remarques

• "Optimisation des images", Addy Osmani
• Addy sur Twitter
• Site personnel d'Addy

Mise à jour hebdomadaire

• Rencontrez :has, un sélecteur parent CSS natif (et plus)
  écrit par Adrien Bece
• Trois outils d'audit frontaux que j'ai découverts récemment
  écrit par Stefan Judis
• Plaques passe-partout et kits de démarrage utiles
  écrit par Cosima Mielke
• Conception Web bien faite : utiliser l'audio
  écrit par Frederick O'Brien
• Quand CSS ne suffit pas : exigences JavaScript pour les composants accessibles
  écrit par Stéphanie Eckles

Transcription

Drew McLellan : C'est un responsable technique qui travaille sur Google Chrome, où son équipe se concentre sur la vitesse, aidant à maintenir la vitesse du Web. Dévoué à la communauté open source, ses contributions passées incluent Lighthouse, Workbox, Yeoman, Critical et to do NVC. Nous savons donc qu'il sait comment optimiser les performances Web. Mais saviez-vous qu'il veut remporter l'Oscar de la meilleure actrice dans un second rôle en raison d'une erreur d'écriture ? Mes amis fracassants, veuillez accueillir Addy Osmani. Salut Addy. Comment vas-tu?

Addy Osmani : Je suis fracassant.

Drew McLellan: C'est bon à entendre. Je voulais vous parler aujourd'hui des images sur le web. C'est un domaine où il y a eu une quantité surprenante de changements et d'innovations au cours des dernières années, et vous venez d'écrire un livre très complet sur l'optimisation des images pour Smashing. Quelle était la motivation pour penser à ce moment-là, "Le moment est venu d'écrire un livre sur l'optimisation des images ?"

Addy Osmani : C'est une excellente question. Je pense que nous savons que les images sont un élément clé du Web depuis des décennies et que nos cerveaux sont capables d'interpréter les images beaucoup plus rapidement qu'ils ne le peuvent. Mais ce sujet général est celui qui continue de devenir de plus en plus intéressant et de plus en plus nuancé au fil du temps. Et je dis toujours aux gens que c'est probablement, je pense, mon troisième ou quatrième livre. Je n'ai jamais intentionnellement entrepris d'écrire un livre.

Addy Osmani : J'ai commencé ce livre en écrivant un article sur l'optimisation d'image, puis au fil du temps, j'ai découvert que j'avais accidentellement écrit un livre entier à ce sujet. Nous travaillions sur ce projet depuis environ deux ans maintenant. Et même à cette époque, l'industrie a fait évoluer les navigateurs et les outils autour des images et des formats d'image ont évolué.

Addy Osmani : Et donc j'ai écrit ce livre parce que j'avais du mal à rester au courant de tous ces changements. Et je me suis dit : « Je vais être un bon citoyen du Web et essayer de suivre tout ce que j'ai appris au même endroit pour que tout le monde puisse en profiter.

Drew McLellan : C'est l'un de ces domaines, je pense, avec beaucoup d'optimisation des performances dans le navigateur, c'est un paysage qui évolue rapidement, n'est-ce pas ? Lorsqu'une technique que vous avez apprise comme étant actuelle et comme étant la meilleure pratique, un changement de technologie se produit, puis vous découvrez qu'il s'agit en fait d'un anti-modèle et que vous ne devriez pas le faire. Et essayer de maintenir vos connaissances et de vous assurer que vous lisez les bons articles et apprenez les bonnes choses et que vous ne lisez pas quelque chose d'il y a deux ans est assez difficile.

Drew McLellan: Donc, avoir tout rassemblé dans un livre bien documenté provenant d'une source faisant autorité est vraiment formidable.

Addy Osmani : Oui. Même du point de vue d'un auteur, l'une des choses les plus intéressantes et peut-être l'une des choses les plus stressantes pour notre équipe éditoriale était que je remettais un chapitre et disais que c'était fait. Et puis deux semaines plus tard, quelque chose changeait dans un navigateur, et je me disais : « Oh, attends. Je dois faire un autre changement de dernière minute.

Addy Osmani : Mais le paysage de l'image a beaucoup évolué, même l'année dernière. Nous avons vu la prise en charge de WebP franchir enfin la ligne d'arrivée dans la plupart des navigateurs modernes. La prise en charge des images AVIF est dans Chrome, arrive sur Firefox, JPEG XL, chargement paresseux. Et dans l'ensemble, nous avons vu des améliorations dans la façon dont vous pouvez utiliser les images sur le Web assez concrètement dans les navigateurs. Mais encore une fois, beaucoup de choses pour les gens à garder au courant.

Drew McLellan : Certaines personnes pourraient considérer le sujet de l'optimisation d'image comme un sujet plutôt guindé. Nous avons tous, à un moment donné de notre carrière, appris à exporter pour le Web à partir de notre logiciel graphique. Et certains d'entre nous ont peut-être l'habitude de prendre ces images exportées et de les faire passer par quelque chose comme ImageOptim.

Drew McLellan : Donc, nous savons peut-être que nous devrions choisir un JPEG lorsqu'il s'agit d'une image photographique et un PNG lorsqu'il s'agit d'une image basée sur des graphiques et penser que « d'accord, c'est tout. Je connais l'optimisation d'image, j'ai terminé. Mais vraiment, ces choses ne sont que des enjeux de table, n'est-ce pas, à ce stade ?

Addy Osmani : Oui, ils le sont. Je pense que notre capacité à afficher des images et des images plus détaillées et plus nettes, même dans un contexte différent, selon que vous vous souciez ou non de la direction artistique, a évolué au fil du temps. Je pense que la nécessité de comprendre comment vous pouvez rendre ces images aussi belles que prévu pour vos utilisateurs finaux, en gardant à l'esprit leur environnement, leurs contraintes d'appareil, leurs contraintes de réseau est un problème difficile et quelque chose que je connais encore beaucoup de gens avoir du mal avec.

Addy Osmani : Et donc, quand il s'agit de penser aux images et d'obtenir une vision légèrement plus raffinée de cela au-delà de simplement « Hé, utilisons un JPEG » ou « Utilisons un PNG », je pense qu'il y a quelques dimensions à cela. garder en tête. Le premier est juste généralement la compression. Vous avez mentionné ImageOptim, et beaucoup d'entre nous ont l'habitude de simplement faire glisser une image dans un endroit et d'obtenir quelque chose de plus petit à l'arrière.

Addy Osmani : En ce qui concerne la compression, nous parlons généralement de différents codecs. Et les codecs sont une technologie de compression qui comporte généralement un composant encodeur pour encoder les fichiers et un composant décodeur pour les décoder et les décompresser. Et lorsque vous décidez si vous utilisez quelque chose, vous devez généralement vous demander si les photos ou les images que vous utilisez sont acceptables pour vous en utilisant une approche de compression avec perte ou une approche sans perte.

Addy Osmani : Juste au cas où les gens ne seraient pas aussi familiers avec ces concepts, une approche sans perte est celle où vous reproduisez exactement le même fichier à la toute fin lors de la décompression. Vous ne perdez donc pas grand-chose en termes de qualité. Sans perte, c'est bien plus que de passer votre image par un télécopieur. Vous obtenez un fac-similé de l'original, et ce ne sera pas le fichier original. Il pourrait y avoir différents artefacts en place là-bas. Cela pourrait sembler légèrement différent. Mais en termes généraux, plus vous compressez, plus vous perdez en qualité.

Addy Osmani : Et donc, avec tous ces codecs d'image modernes, ils essaient de voir quelle qualité vous pouvez obtenir tout en conservant une taille de fichier relativement décente, selon le cas d'utilisation.

Drew McLellan : Donc, vraiment, d'un point de vue technologique, vous avez une image source, puis vous avez le format de fichier de destination. Mais le processus de transformation de l'un en l'autre est ouvert au débat. Tant que vous avez un fichier conforme, la façon dont vous le faites dépend d'un codec qui peut avoir de nombreuses implémentations différentes, et certaines seront meilleures que d'autres.

Addy Osmani : Absolument. Absolument. Et je pense que, encore une fois, pour en revenir à l'endroit où nous avons commencé avec JPEG et PNG, les gens savent peut-être que le JPEG a été créé pour une compression avec perte de photos. Vous obtenez généralement un fichier plus petit à l'arrière de celui-ci, et il peut parfois avoir des artefacts de bandes différents. PNG a été créé à l'origine pour une compression sans perte, fonctionne plutôt bien sur les images non photographiques.

Addy Osmani : Mais depuis, les choses ont évolué. Vers 2010, nous avons commencé à prendre en charge WebP, qui était censé remplacer JPEG et PNG et les bat un peu en compression. Mais le nombre de formats d'image et d'options sur la table n'a fait que monter en flèche depuis lors. Je pense que les choses vont généralement dans la bonne direction, en particulier avec les formats modernes comme AVIF et JPEG XL. Mais il nous a fallu du temps pour arriver ici. Même obtenir la prise en charge de WebP sur tous les navigateurs a pris un certain temps.

Addy Osmani : Et je pense qu'en fin de compte, ce qui l'a influencé, c'est de s'assurer que les développeurs l'ont demandé, ils ont eu envie de pouvoir obtenir une meilleure compression de ces formats modernes, et le désir d'avoir juste une bonne compatibilité entre les navigateurs pour ces choses aussi.

Drew McLellan : Oui. WebP me semble vraiment intéressant, car en plus d'avoir une compression sans perte et avec perte disponible dans le format, nous avons évidemment une taille de fichier beaucoup plus réduite en conséquence. Et il y a un bon support de navigateur, et nous voyons l'adoption de grandes entreprises comme Google et Netflix et diverses grandes entreprises.

Drew McLellan : Mais ma perception dans l'industrie est que nous ne voyons pas le même type d'adoption au niveau local. WebP attend-il toujours son jour ?

Addy Osmani : Je pense que je dirais que WebP arrive. Beaucoup de gens attendaient que le support Safari et WebKit se matérialise, et nous l'avons enfin. Mais lorsque nous pensons à de nouveaux formats d'image, il est très important que nous comprenions ce que signifie réellement la prise en charge. Le navigateur prend en charge le décodage de ces images. Nous avons également besoin d'un très bon support d'outils pour que, que vous soyez dans un environnement de nœud, un CDN d'image, si vous êtes dans un CMS, vous ayez la possibilité d'utiliser ces formats d'image.

Addy Osmani : Je me souviens il y a de nombreuses années quand WebP est sorti pour la première fois. Les premiers utilisateurs avaient ce problème de sauvegarder votre fichier WebP sur votre bureau, puis tout à coup, "Oh, attendez. Dois-je le faire glisser dans mon navigateur pour le voir ? » ou « Si mes utilisateurs téléchargent le WebP, vont-ils rester bloqués et se demander ce qui se passe ? »

Addy Osmani : Et donc s'assurer qu'il y a un support assez holistique pour le format d'image à la fois au niveau du système d'exploitation ainsi que dans d'autres contextes est vraiment important, je pense, pour qu'un format d'image décolle. Il est également important que les personnes qui diffusent des images réfléchissent un peu à ces cas d'utilisation afin que, si j'enregistre ou télécharge un fichier, vous essayez de le mettre dans un format portable que les gens peuvent généralement partager facilement. Et je pense que c'est là que, du moins sur iOS, iOS prend en charge une randonnée et un trait d'union. Et convertir les choses en JPEG si nécessaire permet aux gens de les partager.

Addy Osmani : Il est donc important, je pense, de réfléchir à ces types de cas d'utilisation où nous pouvons nous assurer que les utilisateurs ne sont pas perdants pendant que nous leur offrons une meilleure compression.

Drew McLellan : Je gère un service de partage de diapositives qui, comme vous pouvez l'imaginer, traite des centaines de milliers d'images. Et quand je regardais WebP, et c'était probablement il y a peut-être trois ans, je cherchais principalement un moyen de réduire les coûts de bande passante CDN, car si vous servez un fichier plus petit, vous payez moins cher pour le servir. Mais alors que j'avais encore besoin d'une image de fond, d'un format d'image hérité également, mes calculs ont montré que le coût de stockage d'un tout autre ensemble d'images l'emportait sur les avantages de servir un fichier plus petit. Nous voici donc en 2021. Est-ce une décision que je devrais reconsidérer à ce stade ?

Addy Osmani : Je pense que c'est une considération très importante. Parfois, lorsque nous parlons de la façon dont vous devriez aborder votre stratégie d'image, il est très facile de donner aux gens une réponse de haut niveau : « Hé, ouais. Générez simplement cinq formats différents, et cela évoluera à l'infini. Et ce n'est pas toujours le cas.

Addy Osmani : Je pense que lorsque vous devez garder à l'esprit le stockage, essayez parfois de trouver le meilleur dénominateur commun pour servir vos utilisateurs, cela vaut la peine de garder à l'esprit. Ces jours-ci, je dirais en fait que WebP vaut la peine d'être considéré comme ce dénominateur commun. Pour les personnes qui ont l'habitude d'utiliser la balise d'image pour servir conditionnellement différents formats aux personnes, vous utiliserez généralement un JPEG comme solution de repli principale. Peut-être qu'il est acceptable de nos jours d'utiliser le WebP comme solution de repli pour la plupart des utilisateurs, à moins que vous n'ayez des gens qui utilisent des navigateurs très, très anciens. Et je pense qu'on en voit beaucoup moins de nos jours. Mais vous avez certainement une certaine flexibilité là-bas.

Addy Osmani: Maintenant, si vous essayez d'être tourné vers l'avant, je dirais de choisir un format qui, selon vous, fonctionne vraiment bien. Si vous pouvez aborder le stockage d'une manière qui s'adapte et s'adapte à vos besoins, je dirais que les gens devraient envisager JPEG XL. Techniquement, ce n'est pas encore disponible dans un navigateur. Lorsque c'est le cas, JPEG XL devrait être une très bonne option pour de nombreuses photos dans des cas d'utilisation avec ou sans perte ou pour des cas d'utilisation non photo également. Et ce sera probablement bien meilleur que WebP V1. Donc c'est un endroit.

Addy Osmani : Je pense que l'AVIF sera probablement meilleur si vous devez passer à des débits binaires vraiment bas. Peut-être que vous vous souciez beaucoup de la bande passante. Peut-être que vous vous souciez un peu moins de la fidélité de l'image. Et à ces débits binaires, je pouvais imaginer qu'il avait l'air plus net que certaines des alternatives. Et jusqu'à ce que nous ayons JPEG XL, j'essaierais de jeter un œil à vos analyses et de comprendre s'il vous est possible de servir AVIF. Sinon, je me concentrerais sur ce WebP. Si vous étiez analytique, je suppose que la plupart des gens peuvent être servis WebP et que vous vous souciez un peu moins des superpositions de large gamme ou de texte, des endroits où l'échantillonnage des chromosomes peut ne pas être parfait dans WebP. C'est certainement quelque chose qu'il vaut la peine de garder à l'esprit.

Addy Osmani : J'essaierais donc de garder à l'esprit qu'il n'y aura pas de taille unique pour tout le monde. Personnellement, ces jours-ci, je m'inquiète un peu moins des coûts de stockage, de sortie et de bande passante, simplement parce que j'utilise un CDN d'image. Et je suis heureux de dire que j'utilise personnellement Cloudinary. Nous utilisons de nombreux CDN d'images différents là où je travaille. Mais j'ai trouvé que je n'avais pas à me soucier autant des coûts de maintenance liés à la gestion des pipelines d'images, de la façon dont je vais prendre en charge comme, "Oh, hé, voici encore un autre format d'image ou de nouveaux types de replis ou de nouvelles API Web », cela a été un bel avantage d'investir dans quelque chose qui s'en occupe pour moi.

Addy Osmani : Et puis le coût global pour mes cas d'utilisation a été correct. Mais je peux tout à fait imaginer que si vous utilisez un service de diapositives à cette échelle, ce n'est peut-être pas nécessairement une option non plus.

Drew McLellan : Oui. Je veux donc revenir sur certains de ces futurs formats à venir. Mais je pense que cela vaut la peine d'être approfondi, car avec n'importe quel type d'outils de performance, Lighthouse ou WebPageTests, si l'un d'entre nous exécute nos sites, l'une des principales choses qu'il suggérera est que nous utilisons un CDN pour les images. Et c'est une chose très réaliste à faire pour les très grandes entreprises. Est-ce réaliste et à la portée des personnes qui créent des sites Web et des applications plus petits, ou est-ce aussi facile à faire qu'il y paraît ?

Addy Osmani : Je pense que la question que les gens devraient se poser est la suivante : « Pourquoi utilisez-vous les images ? » Si vous n'avez que quelques images, si vous créez un blog et que les images que vous ajoutez sont relativement simples, vous n'avez pas des centaines et des centaines ou des milliers de milliers d'images, vous pourriez vous contenter d'aborder ceci au moment de la construction, de manière très statique, où vous installez quelques packages NPM. Peut-être que vous utilisez simplement Sharp. Et cela prend soin de vous pour la plupart.

Addy Osmani : Il existe des outils qui peuvent vous aider à générer plusieurs formats. Cela augmente un peu votre temps de construction, mais cela pourrait en fait convenir à beaucoup de gens. Et puis pour les gens qui veulent pouvoir tirer parti de plusieurs

Addy Osmani : Et puis, pour les gens qui veulent pouvoir exploiter plusieurs formats, ils ne veulent pas gérer autant de minutie d'outillage et veulent pouvoir mettre en place une image ou une histoire réactive vraiment riche, je dirais d'essayer un CDN d'image. J'étais personnellement assez réticent à l'utiliser pour des projets personnels pour les problèmes de coût au départ, puis au fil du temps, en examinant ma facturation, j'ai réalisé que cela me faisait gagner du temps que j'investirais autrement pour résoudre ces problèmes moi-même. Je ne sais pas combien vous avez dû écrire des scripts personnalisés pour gérer vos images dans le passé, mais j'ai réalisé que si je pouvais m'épargner au moins quelques jours de débogage via ces différents packages npm par mois, alors les coûts sorte de prendre soin du temps que je gagne et donc ça va.

Addy Osmani : Mais cela peut être quelque chose où si vous passez à des centaines de milliers ou à des millions d'images et que ce n'est pas nécessairement couvert par vos revenus ou que vous n'êtes pas prêt à payer, vous devez y penser. stratégies alternatives. Et je pense que nous avons de la chance d'avoir suffisamment de flexibilité avec les outils dont nous disposons aujourd'hui pour pouvoir aller dans l'une ou l'autre de ces directions, où nous faisons quelque chose d'un peu plus personnalisé, nous nous y attaquons nous-mêmes ou roulons notre propre image CDN ou nous investissons dans quelque chose d'un peu plus commercial. Et nous en sommes à un point où je dirais que pour certains cas d'utilisation, oui, vous pouvez utiliser un CDN d'image et c'est abordable.

Drew McLellan : Je suppose que l'un des principes directeurs consiste toujours à être agile et à se préparer au changement. Et vous pouvez commencer à utiliser un CDN d'image pour convertir dynamiquement vos images pour vous au fur et à mesure qu'elles sont demandées, et si cela arrive à un point où ce n'est pas durable en termes de coûts, vous pouvez envisager une autre solution et avoir votre base de code dans un état où il sera facile de substituer une solution à une autre. Je pense que généralement et partout où vous comptez sur un service tiers, c'est un bon principe à avoir, n'est-ce pas ? Donc, ces formats d'image à venir, vous avez mentionné JPEG XL. Qu'est-ce que JPEGXL ? D'où vient-il ? Et qu'est-ce que ça nous fait ?

Addy Osmani : C'est une excellente question. Ainsi, JPEG XL est un format d'image de nouvelle génération, il est censé être à usage général et c'est un codec du comité JPEG. Cela a commencé avec quelques racines dans le format pic de Google, puis dans le format FUIF de Cloudinary. Il y a eu beaucoup de formats au fil des ans qui ont été en quelque sorte subsumés par cet effort, mais c'est devenu bien plus que le genre de somme de ses parties individuelles et certains des avantages de JPEG XL sont qu'il est idéal pour la haute fidélité images, vraiment bon pour sans perte, il prend en charge le décodage progressif, le transcodage JPEG sans perte, et c'est aussi une sorte d'agitation et sans redevance, ce qui est certainement un avantage. Je pense que JPEG XL pourrait potentiellement être un très bon candidat. Nous parlions plus tôt, si vous deviez en choisir un, qu'utiliseriez-vous ? Et je pense que le JPEG XL a le potentiel d'être celui-là.

Addy Osmani : Je ne veux pas non plus trop promettre, nous en sommes encore très tôt à la prise en charge des navigateurs. Et donc je pense que nous devrions vraiment attendre et voir, expérimenter et évaluer dans quelle mesure il s'aligne dans la pratique et répond aux attentes des gens, mais je vois beaucoup de potentiel avec JPEG XL pour les cas avec et sans perte. À l'heure actuelle, je pense que Chrome est probablement le plus avancé en termes de support, mais j'ai également constaté un intérêt certain du côté de Mozilla et d'autres navigateurs pour cela, donc je suis enthousiasmé par l'avenir avec JPEG XL. Et si nous devions dire, qu'est-ce qui intéresse les gens à plus court terme ? Il y a bien sûr AVIF aussi.

Drew McLellan : Parlez-nous d'AVIF, c'en est un autre que je ne connais pas.

Addy Osmani : D'accord. Nous avons donc mentionné un peu plus tôt qu'AVIF est peut-être un meilleur candidat si vous devez passer à des débits binaires faibles et que vous vous souciez plus de la bande passante que de la fidélité de l'image. En règle générale, AVIF prend vraiment la tête de la compression haute fidélité basse fidélité. Et JPEG XL, il devrait exceller en moyenne à haute fidélité, mais ce sont des formats légèrement différents à part entière. Nous sommes à un stade où AVIF bénéficie d'un support de navigateur de plus en plus bon, mais permettez-moi de prendre du recul et de parler un peu plus du format. Ainsi, AVIF lui-même est basé sur le codec vidéo AV1, qui a été normalisé par l'Alliance for Open Media, et il essaie d'obtenir des gains de compression significatifs sur JPEG, sur WebP, dont nous parlions plus tôt. Et tandis que les économies exactes que vous pouvez obtenir d'AVIF dépendront du contenu et de vos objectifs de qualité, nous avons vu de nombreux cas où il peut offrir plus de 50 % d'économies par rapport au JPEG.

Addy Osmani : Il a beaucoup de bonnes fonctionnalités, il est capable de vous donner un support de conteneur pour de nouvelles fonctionnalités comme une plage dynamique élevée et de larges gammes de couleurs, la synthèse de grain de film. Et encore une fois, comme pour parler d'être orienté vers l'avant, l'une des bonnes choses à propos de la balise d'image est que vous pouvez servir des fichiers AVIF aux utilisateurs dès maintenant et il reviendra toujours à votre WebP ou votre JPEG dans les cas où il n'est pas nécessairement pris en charge . Mais pour en revenir à votre exemple sur Photoshop Save For Web, vous pouvez prendre un JPEG d'une taille de 500 kilo-octets, essayer d'obtenir une qualité similaire à Photoshop Save For Web et avec AVIF, je dirais que vous pourrez probablement accéder à un point où cette taille de fichier est d'environ 90 kilo-octets, 100 kilo-octets, donc beaucoup d'économies sans perte de qualité perceptible.

Addy Osmani : Et l'un des avantages de cela est que vous ne verrez idéalement pas autant de perte de texture dans les images riches en détails. Donc, si vous avez des photos de forêts ou de camping ou l'un de ces types de choses, elles devraient toujours avoir l'air vraiment riches avec AVIF. Je suis donc très enthousiasmé par la direction prise par AVIF. Je pense qu'il a besoin d'un peu plus de travail en termes de support d'outillage. J'ai donc publié un tweet à ce sujet l'autre jour, nous avons un certain nombre d'options pour utiliser AVIF en ce moment, pour les images uniques, nous avons Squoosh, squoosh.app, qui est écrit par une autre équipe de Chrome, alors criez à Surma et Jake pour avoir travaillé sur Squoosh. Avif.io propose un certain nombre de bonnes options pour les personnes qui essaient d'utiliser AVIF aujourd'hui, quelle que soit la pile technologique sur laquelle elles se concentrent, Sharp prend également en charge AVIF.

Addy Osmani : Mais alors généralement, vous pensez à d'autres endroits où nous traitons des images, que ce soit dans Figma ou dans Sketch ou dans Photoshop ou dans d'autres endroits, et je dirais que nous devons encore faire un peu de travail en termes de Le support AVIF là-bas, car il doit être omniprésent pour que les développeurs et les utilisateurs aient vraiment l'impression d'avoir atterri et de rentrer à la maison. Et c'est l'un des domaines sur lesquels nous nous concentrons avec les équipes travaillant sur AVIF dans Chrome en ce moment, en essayant de nous assurer que nous pouvons obtenir des outils à un assez bon endroit.

Drew McLellan : Nous avons donc en HTML, l'élément d'image maintenant, ce qui nous donne plus de flexibilité par rapport à la balise d'image traditionnelle. Bien que la balise d'image ait également parcouru un long chemin, n'est-ce pas ? Mais nous avons vu l'image ajoutée, c'était à peu près au même moment que la balise vidéo native, je pense dans ce genre de lot original de modifications HTML5. Et cela nous donne la possibilité de spécifier plusieurs sources, n'est-ce pas ?

Addy Osmani : Oui, c'est vrai.

Drew McLellan : Ainsi, vous pouvez répertorier différents formats d'images et le navigateur choisira celui qu'il prend en charge, ce qui nous permet d'être assez expérimental tout de suite sans avoir à trop nous soucier de casser des choses pour les utilisateurs de navigateurs plus anciens.

Addy Osmani : Absolument. Je pense que c'est l'un des plus beaux avantages de l'utilisation de la balise d'image en dehors des cas d'utilisation où nous réfléchissons à notre direction, simplement être capable de servir une image aux gens et que le navigateur parcoure la liste des sources potentielles et voit, d'accord, eh bien, je vais utiliser le premier de cette liste que je comprends sinon je vais me replier, c'est une capacité vraiment puissante pour les gens. Je pense qu'en même temps, j'ai aussi entendu certaines personnes exprimer des inquiétudes ou des inquiétudes quant au fait que nous régénérons de très grosses gouttes de balisage maintenant lorsque nous essayons de prendre en charge plusieurs formats et que vous tenez compte de différentes tailles pour ces formats et du coup ça devient un peu encombrant.

Addy Osmani : Existe -t-il d'autres façons d'aborder ces problèmes ? Je ne veux pas trop vendre les gens sur les CDN d'images, je veux qu'ils soient autonomes. Mais c'est l'un de ces endroits où une idée appelée négociation de contenu peut en fait vous offrir une voie intéressante. Donc, nous avons un peu parlé de la balise d'image où vous devez générer un tas de ressources différentes et décider de l'ordre de préférence, à droite, du HTML supplémentaire. Avec la négociation de contenu, ce qu'elle dit, c'est faisons tout ce travail sur le serveur. Ainsi, les clients peuvent dire au serveur quels formats il prend en charge via la liste des types MIME via l'en-tête Accept HTTP. Ensuite, le serveur peut effectuer tout le travail lourd de génération et de gestion des ressources ultimes et décider lesquelles envoyer aux clients. Et l'une des choses puissantes ici est que si vous utilisez un CDN d'image, vous pouvez pointer vers une seule ressource.

Addy Osmani : Alors peut-être que si nous avons une image de chiot comme chiot.JPEG, nous pourrions donner aux gens une URL vers chiot.JPEG et si leur navigateur prend en charge WebP ou s'il prend en charge un AVIF, le serveur peut devenir très intelligent en servant à droite image à ces utilisateurs en fonction de ce à quoi ressemble leur support, mais sinon, revenez en arrière sans que vous ayez à faire une tonne de travail supplémentaire vous-même. Maintenant, je pense que c'est une idée puissante. Il y a beaucoup de choses que vous pouvez faire sur le serveur, nous parlons parfois du fait que tout le monde n'a pas accès à une très bonne qualité de réseau, votre type de connexion efficace peut être très différent selon l'endroit où vous vous trouvez.

Addy Osmani : Même en vivant dans la Silicon Valley, je pourrais marcher d'un café à un hôtel ou je pourrais être dans la voiture et la qualité de mon wifi ou de mon signal peut ne pas être excellente. C'est donc là que vous avez accès à d'autres API, à d'autres idées comme l'indice du client Save-Data pour pouvoir potentiellement servir des personnes avec des ressources encore plus petites, si l'utilisateur a opté pour l'économie de données. Il y a donc beaucoup de choses intéressantes que nous pourrions faire côté serveur et je pense que nous devrions continuer à pousser ces idées pour trouver un bon équilibre où les personnes qui sont à l'aise avec le chemin du marché ont toute la flexibilité pour le faire et les personnes qui veulent une solution un peu plus magique ont également quelques options.

Drew McLellan : Le concept de ce type d'approche d'économiseur de données est quelque chose que j'ai appris en premier dans votre livre. Je veux dire, allons-y un peu plus parce que c'est assez intéressant. Vous parlez donc de la capacité du navigateur à signaler une préférence pour une expérience de données réduite, car il s'agit peut-être d'une connexion mesurée ou d'une batterie faible ou quelque chose du genre.

Addy Osmani : Exactement. Exactement. J'ai voyagé en temps normal ou à l'époque où nous voyagions beaucoup plus, j'ai connu de nombreux endroits dans le monde ou des situations où la qualité de mon réseau peut être vraiment mauvaise ou vraiment inégale, et donc même l'ouverture créer une page Web peut être une expérience frustrante ou difficile. Je suis peut-être en train de chercher un menu et si je ne vois pas de photos de la belle nourriture qu'ils ont à disposition, je pourrais aller quelque part où je peux, ou je pourrais, je ne sais pas, me préparer de la nourriture à la place. Mais je pense que l'une des choses intéressantes à propos de l'économiseur de données est qu'il vous donne un lien avec les préférences de l'utilisateur. Donc si en tant qu'utilisateur, je sais que j'ai du mal avec ma connexion réseau. Je peux dire : "D'accord, eh bien, je vais activer le mode économiseur de données dans mon navigateur".

Addy Osmani : Et ensuite, vous pouvez utiliser cela en tant que développeur comme un signal pour dire : "D'accord, eh bien, l'utilisateur est un peu limité, peut-être que nous allons le surfer sur des images beaucoup plus petites ou des images de qualité bien inférieure." Mais ils peuvent toujours voir quelques images, ce qui est mieux que d'attendre très longtemps que quelque chose de beaucoup plus riche soit servi. Les autres avantages de ces types de signaux sont que vous pouvez les utiliser pour diffuser des médias de manière conditionnelle. Alors peut-être qu'il y a des cas où le texte est la chose la plus importante dans cette page, peut-être que vous pouvez désactiver ces images si vous découvrez que les utilisateurs sont dans une sorte d'environnement contraint. Je ne passerai que 30 secondes là-dessus, mais vous pouvez vraiment pousser cette idée à l'extrême. Certaines des choses intéressantes que vous pouvez faire avec Save-Data sont peut-être même la désactivation de fonctionnalités très coûteuses implémentées en JavaScript.

Addy Osmani : Si vous avez certains composants qui sont considérés comme légèrement plus facultatifs, peut-être que ceux-ci n'ont pas nécessairement besoin d'être envoyés à tous les utilisateurs s'ils ne font qu'améliorer l'expérience. Vous pouvez toujours offrir à tout le monde une expérience très centrale, petite et rapide, puis simplement la superposer avec un joli glaçage pour les personnes qui ont une connexion ou un appareil plus rapide.

Drew McLellan: Potentiellement, je suppose que cela pourrait être pris en compte dans la pagination et vous pourriez renvoyer 10 résultats sur une page plutôt que 100 et ce genre de choses également. Donc, beaucoup de capacités intéressantes et intéressantes là-bas. Je pense que nous connaissons tous le processus frustrant de préparer un nouveau site, d'optimiser toutes vos images, de le remettre au client, de lui donner un CMS pour gérer le contenu et de constater qu'il remplace tout par images mal optimisées. Je veux dire, encore une fois, un CDN d'image, je suppose, serait une solution très pratique à cela, mais y a-t-il d'autres solutions, y a-t-il des choses que le CMS pourrait faire sur le serveur pour aider à cela ou est-ce qu'un CDN d'image est probablement le marche à suivre?

Addy Osmani : Je pense que ce que nous avons découvert après probablement au moins six ou sept ans à essayer d'amener tout le monde à optimiser ses images, c'est que c'est un problème difficile où certaines personnes impliquées dans l'image peuvent être légèrement plus avisées sur le plan technique et peut-être à l'aise. mettre au point leurs propres outils ou utiliser Lighthouse ou essayer d'autres outils pour leur faire savoir s'il existe des possibilités d'amélioration. J'aimerais voir des gens utiliser systématiquement des choses comme Lighthouse pour saisir si vous avez des opportunités d'optimiser davantage ou de servir des images de la bonne taille, mais au-delà de cela, nous rencontrons parfois des cas d'utilisation où les personnes qui téléchargent des images peuvent ne pas nécessairement même comprendre le coût des ressources qu'ils téléchargent. C'est souvent quelque chose que nous rencontrons, et je m'excuse, je ne vais pas trop appeler les gens, mais c'est quelque chose que nous rencontrons même avec le blog Google.

Addy Osmani : Toutes les deux semaines sur le blog de Google, quelqu'un télécharge un très gros GIF animé de 20 ou 30 mégaoctets. Et je ne m'attends pas à ce qu'ils sachent que ce n'est pas une bonne idée, ils essaient de rendre l'article cool et très engageant et interactif, mais ces publics ne sauront pas nécessairement utiliser des outils ou utiliser ImageOptim ou utiliser l'un de ces autres outils en place et ainsi documenter pour eux, qu'ils devraient les vérifier, est certainement une option. Mais être capable d'automatiser le problème, je pense que c'est très convaincant et nous aide constamment à arriver à un endroit où nous espérons équilibrer les besoins de tous nos utilisateurs de CMS, qu'ils soient techniques ou non techniques, ainsi que les besoins de nos utilisateurs.

Addy Osmani: So I think the image CDNs can definitely play a role in helping out here. Ultimately, the thing that's important is making sure you have a solution in place between people, stakeholders who might be uploading those images, and what gets served down to users. If it's an image CDN, if it's something you've rolled yourself, if it's a built step, just needs to be something in place to make sure that you are not serving down something that's very, very large and inefficient.

Drew McLellan: Talking about animated GIFs, they're surprisingly popular. They're fun, we love them, but they're also huge. And really, it's a case where a file format that was not designed for video is being used for video. Is there a solution to that with any of these image formats? What can we do?

Addy Osmani: Oh, gosh. The history of GIFs is fascinating. We saw a lot of the formats we know and love or have been around for a while were originated in the late '80s to early '90s, and the GIF is one of those. It was created in 1987. I'm about as old as the GIF.

Addy Osmani: As you mentioned, it wasn't originally created necessarily for use case. I think it was Netscape Navigator which in mid '90s maybe added support for looping GIFs and giving us this kind of crazy fun way to do memes and the like, but GIFs have got so many weaknesses. They're kind of limited in many cases to a very finite color palette; 256 colors, in many cases. They're a bitmapped raster format with pixel value stored in image files.

Addy Osmani: They're very inefficient, for a number of reasons. And you mentioned that they're also quite large. I think that we've gotten into this place of thinking that if we want a short segment of video or animation that's going to be looping, the GIF is the thing that we have to use. And that's just not the case.

Addy Osmani: While we do see that there are modern image formats that have support for animation, I think that the most basic thing you can do these days is make sure you're serving a video down instead of a GIF. Muted auto-play videos combined with HD64, HD65, whatever video you're going to use, can be really powerful, and significantly smaller for use cases where you need to be showing a sequence of images.

Addy Osmani: There are options for this. AVIF has got image sequences in there, potentially. Other formats have explored these ideas as well. But I think that one thing you can do is, if you're using GIFs today, or you have users who are slightly less technical who are using GIFs today, try to see if you can give them tools that will allow them to export a video instead, or if your pipeline can take care of that for them, that's even better.

Addy Osmani: I have plenty of conversations with CMS providers where you do see people uploading GIFs. They don't know the difference between a video and a GIF file. But if you can just, whether it's with an image CDN or via some built process, change the file over to a more efficient format, that would be great.

Drew McLellan: We talked briefly about tools like ImageOptim that manage to strip out information from the files to give us the same quality of result with a smaller file size. I'm presuming that's because the file formats that we commonly deal with weren't optimized for delivery over the Web in the first place, so they're doing that step of removing anything that isn't useful for serving on the Web. Do these new formats take that into consideration already? Is something like ImageOptim a tool that just won't be required with these newer formats?

Addy Osmani: I'm anticipating that some of the older formats… Things that have been around for a while, take a while to phase out or to evolve into something else. And so I can see tools like ImageOptim continuing to be useful. Now, what are modern image formats doing that are much better? Well, I would say that they're taking into account quite a few things.

Addy Osmani: They're taking into account, are there aspects of the picture that the human eye can't necessarily make out a difference around? When I'm playing around with different quality settings or different codecs, I'm always looking for that point where if I take the quality down low enough, I'm going to see banding artifacts. I'm going to see lots of weird looking squares around my buildings or the details of my picture.

Addy Osmani: But once those start to disappear, I really need to start zooming in to the image and making comparisons across these different formats. And if users are unlikely to do that, then I think that there are good questions around is that point of quality good enough? I think that modern image formats are pretty good at being able to help you navigate, filtering out some of those details pretty well. Keeping in mind what are the needs of color, because obviously we've got white gamut as a thing right now as well.

Addy Osmani: Some people might be okay with an amount of changing your color palette versus not, depending on the type of images that you have available, but definitely I see modern formats trying to be resilient against things like generational loss as well. Generational loss is this idea that… We mentioned memes earlier. A common problem on the Web today is you'll find a meme, whether it's on Facebook or Instagram or Reddit or wherever else, you'll save it, and maybe you'll share it around with a friend. Maybe they'll upload it somewhere else. And you suddenly have this terrible kind of copy machine or fax effect of the quality of that image getting worse and worse and worse over time.

Addy Osmani: And so when I see something get reshared that I may have seen three months ago, now it might not be really, really bad quality. You can still make out some of the details, but image formats, being able to keep that in mind and work around those types of problems, I think are really interesting.

Addy Osmani: I know that JPEG XL was trying to keep this idea of generational loss in mind as well. So there's plenty of things that modern codecs and formats are trying to do to evolve for our needs, even if they're very meme focused.

Drew McLellan: Let's say you've inherited a project that has all sorts of images on it. What would be the best way to assess the state of that project in terms of image optimization? Are there tools or anything that would help there?

Addy Osmani: I think that it depends on how much time you've got to sink into the problem. There are very basic things people can try doing, like obviously batch converting those images over to more modern formats at the recommended default quality and do an eyeball check on how well they're doing compared to the original.

Addy Osmani: If you're able to invest a little bit more time, there are plenty of tools and techniques like DSSIM and other ways of being able to compare what the perceptual quality differences are between different types of images that have been converted. And you can use that as a kind of data-driven approach to deciding, if I'm going to batch convert all of my old images to WebP, what is the quality setting that I should be relying on? If I'm going to be doing it for AVIF or JPEG XL, what is the quality setting that I should be relying on?

Addy Osmani: I think that there's plenty of tools people have available. It really just depends on your time sink that's possible. Other things that you can do, again, going back to the image CDN aspect, if you don't have a lot of time and you're comfortable with the cost of an image CDN, you can just bulk upload all of those images. And there are CDNs that support this idea of automatic quality setting. I think in Cloudinary it's q_auto, or something like that.

Addy Osmani: But the basic idea there is they will do a scan of the image, try to get a sense of the type of content that's in there, and automatically decide on the right level of quality that you should be using for the images that are getting served down to users. And so you do have some tooling options that are available here, for sure.

Drew McLellan: I mean, you mentioned batch processing of images. Presumably you're into the area of that generational loss that you're talking about, when you do that. When you take an already compressed JPEG and then convert it to a WebP, for example, you risk some loss of quality. Is batch converting a viable strategy or does that generational loss come too much into play if you care about the pristine look of the images?

Addy Osmani: I think it depends on how much you're factoring in your levels of comfort with lossy versus lossless, and your use case. If my use case is that I've inherited a project where the project in question is all of my family's photos from the last 20 years, I may not be very comfortable with there being too much quality loss in those images, and maybe I'm okay with spending a little bit more money on storage if the quality can remain mostly the same, just using a more modern format.

Addy Osmani: If those are images for a product catalog or any commerce site, I think that you do need to keep in mind what your use case is. Are users going to require being able to see these images with a certain level of detail? And if that's the case, you need to make those trade-offs in mind when you're choosing the right format, when you're choosing the right quality.

Addy Osmani: So I think that batch is still okay. To give you a concrete idea of one way of seeing people approach this at scale, sometimes people will take a smaller sample of the images from that big collection that they've inherited, and they'll try out a more serious set of experiments with just that set. And if they're able to land on an approach that works well for the sample, they'll just apply it to the whole batch. And I've seen that work to varying degrees of success.

Drew McLellan: So optimizing file size is just sort of one point on the overall image optimization landscape. And I'd like to get on to talking about what we can do in our browsers to optimize the way the images are used, which we'll do after a quick word from this episode sponsor.

Drew McLellan: So we've optimized and compressed our large files, but now we need to think about a strategy for using those in the browser. The good old faithful image tag has gained some new powers in recent times, hasn't it?

Addy Osmani: Yeah, it has. And maybe it's useful for folks… I know that a lot of people that ask me about images these days also ask me to frame it in terms of metrics and the Core Web Vitals. Would it be useful for me to talk about what the Core Web Vitals are and maybe frame some of those ideas in those current terms?

Drew McLellan: Absolutely, because Core Web Vitals is a sort of initiative from Google, isn't it, that we've seen more recently? We're told that it factors into search ranking potentially at some level. What does Core Web Vitals actually mean for us in terms of images?

Addy Osmani: Great question. As you mentioned, Core Web Vitals is an initiative by Google, and it's all about trying to share unified guidance for quality signals. That can be pretty key to delivering a great user experience on the Web. And it is part of a set of page experience signals Google Search may be evaluating for ranking purposes, but they can impact the Core Web Vitals in a number of ways.

Addy Osmani: Now, before I talk about what those ways are, I should probably say, what are the Core Web Vitals metrics? There's currently three metrics that are in the Core Web Vitals. There's largest contentful paint, there's cumulative layout shift, and there's first input delay. Now, in a lot of modern Web experiences we find that images tend to be one of the largest visible elements on the page. We see a lot of product pages where we have a big image that's the main product item image. We see images in carousels, in stories and in banners.

Addy Osmani: Now, largest contentful paint, or LCP, is a Core Web Vitals metric that tries to measure when the largest contentful element, whether it's an image text or something else, is in a user's viewport, such that we're able to tell when that image becomes visible. And that really allows a browser to determine when the main content of the page has really finished rendering.

Addy Osmani : Donc, si j'essaie d'aller sur un site de recettes, je pourrais me soucier de l'apparence de cette recette, et nous nous soucions donc de nous assurer que cette grande image de héros de la recette est visible pour moi. Désormais, l'élément LCP peut changer dans le temps. Il est très possible qu'au début du chargement, la plus grande chose puisse être un titre, mais au fur et à mesure que la page continue de se charger, cela pourrait en fait finir par être une image beaucoup plus grande ou une affiche quelconque.

Addy Osmani : Et donc, lorsque vous essayez d'optimiser la plus grande peinture de contenu, il y a environ quatre choses que vous pouvez faire. La première chose est de vous assurer que vous demandez votre image de héros clé le plus tôt possible. Généralement, nous avons un certain nombre de choses qui sont importantes dans la page. Nous voulons nous assurer que nous pouvons rendre le contenu et la mise en page de la page principale.

Addy Osmani : Pour la mise en page, nous parlons généralement de CSS. Ainsi, vous utilisez peut-être du CSS critique, du CSS en ligne, dans vos pages, vous voulez éviter les choses qui bloquent le rendu, mais en ce qui concerne votre image, idéalement, vous devriez demander cette image tôt. Peut-être que cela implique simplement de s'assurer que le navigateur peut découvrir cette image le plus tôt possible dans la page, étant donné que beaucoup d'entre nous ces jours-ci s'appuient sur des frameworks.

Addy Osmani : Si vous n'utilisez pas forcément le SSR, rendu côté serveur, si vous attendez sur le navigateur de découvrir certains de vos bundles JavaScript, des bundles pour vos composants, que vous ayez un composant pour votre image hero ou image produit, si le navigateur doit attendre pour récupérer, analyser, exécuter, compiler et exécuter tous ces différents fichiers avant de pouvoir découvrir l'image, cela peut signifier que votre plus grande image de contenu prendra un certain temps avant de pouvoir être découverte.

Addy Osmani : Maintenant, si c'est le cas, si vous vous trouvez dans un endroit où l'image est demandée assez tard, vous pouvez profiter d'une fonctionnalité de navigateur appelée préchargement de lien pour vous assurer que le navigateur peut découvrir cette image le plus tôt possible. que possible. Maintenant, la précharge est une capacité vraiment puissante. C'est aussi celui avec lequel vous devez prendre beaucoup de soin. De nos jours, il est très facile de se rendre à un endroit où vous entendez peut-être que nous recommandons le préchargement de votre clé.

Addy Osmani : Vous entendez peut-être que nous recommandons le préchargement pour votre image de héros clé, ainsi que vos scripts clés, ainsi que vos polices clés. Et cela devient vraiment énorme, massif, en essayant de vous assurer que vous séquencez les choses dans le bon ordre. Les images LCP sont donc certainement un élément clé à garder à l'esprit pour cela.

Addy Osmani : L'autre chose, comme j'ai mentionné quatre choses, l'autre chose est de s'assurer que vous utilisez un jeu de sources et un format d'image moderne et efficace. Je pense que cet ensemble source est vraiment puissant. Je vois aussi parfois que lorsque les gens l'utilisent, ils essaient de surcompenser et envoient peut-être 10 versions différentes d'images pour chaque résolution possible. Nous avons tendance à constater, du moins dans certaines recherches, qu'au-delà de trois par images, les utilisateurs ont vraiment du mal à dire quelles sont les différences en termes de qualité d'image, de netteté et de détails. Ainsi, le plafonnement DPR, le plafonnement du ratio de pixels de l'appareil, est certainement une idée à garder à l'esprit.

Addy Osmani : Et puis pour les formats d'image modernes, nous avons parlé des formats plus tôt, mais considérez votre WebP, votre AVIF, votre JPEG XL. Évitez de gaspiller des pixels. Il est vraiment important d'avoir une bonne stratégie en place pour la qualité. Et je pense qu'il y a beaucoup de cas où même la qualité par défaut peut parfois être trop. J'expérimenterais donc en essayant de réduire votre débit binaire, de réduire vos paramètres de qualité et de voir jusqu'où vous pouvez aller pour vos utilisateurs tout en maintenant la netteté.

Addy Osmani : Et puis, lorsque nous parlons de chargement, l'une des autres choses que la balise d'image a en quelque sorte évolué pour prendre en charge au cours des deux dernières années est le chargement paresseux. Ainsi, avec chargement égal paresseux, vous n'avez plus nécessairement besoin d'utiliser une bibliothèque JavaScript pour ajouter un chargement paresseux à vos images. Vous venez de déposer cela sur votre image. Et dans les navigateurs Chrome et Firefox, vous pourrez charger ces images paresseusement sans avoir à utiliser de dépendances tierces. Et c'est plutôt sympa aussi.

Addy Osmani : Donc, nous avons mis en place le chargement paresseux. Nous avons un support pour d'autres choses comme le décodage de synchronisation, mais je vais continuer et parler très rapidement des deux autres mesures vitales de base.

Drew McLellan : Allez-y, oui.

Addy Osmani : Alors, débarrassez-vous des changements de mise en page. Personne n'aime que les choses sautent dans leurs pages. J'ai l'impression que l'une de mes plus grandes frustrations est d'ouvrir une page Web. Je passe mon doigt sur un bouton sur lequel je veux cliquer, puis tout à coup un tas de publicités ou d'images sans définition de dimension ou d'autres choses apparaît. Et cela provoque une expérience vraiment désagréable.

Addy Osmani : Le changement de mise en page cumulatif essaie donc de mesurer l'instabilité du contenu. Et la plupart du temps, les choses courantes qui poussent vos changements de mise en page sont des images ou d'autres éléments de votre page qui n'ont tout simplement pas de dimension définie. Je pense que c'est l'un de ces endroits où il est souvent simple pour les gens de définir les dimensions de l'image. Ce n'est peut-être pas quelque chose que nous avons historiquement fait autant, mais certainement quelque chose qui vaut la peine de passer votre temps. Dans des outils comme lighthouse essaiera de vous aider à collecter, comme quelle est la liste des images sur votre page qui nécessitent des dimensions ? Vous pouvez donc y aller et vous pouvez les définir.

Drew McLellan : J'allais dire que c'est un point vraiment intéressant parce que lorsque la conception Web réactive est devenue une chose, nous avons tous parcouru nos sites et supprimé les dimensions de l'image parce que les outils dont nous disposions pour faire ce travail exigeaient que nous le fassions. 't ont des attributs de hauteur et de largeur sur nos images. Mais c'est une mauvaise idée maintenant, n'est-ce pas ?

Addy Osmani : Ce qui est ancien redevient nouveau. Je dirais que cela vaut vraiment la peine de définir des dimensions sur vos images. Définissez des dimensions sur vos publicités, vos montures pour les yeux, tout ce qui est un contenu dynamique qui pourrait potentiellement changer de taille vaut la peine de définir des dimensions.

Addy Osmani : Et pour les gens qui créent une expérience vraiment amusante, il y a la mauvaise expression, des expériences de mise en page vraiment amusantes où vous devrez peut-être faire un peu plus de travail sur les cartes réactives et autres ; J'envisagerais d'utiliser des cases de rapport d'aspect ou de rapport d'aspect CSS pour réserver votre espace. Et cela peut également compléter la définition des dimensions de ces images pour vous assurer que les choses sont aussi fixes que possible lorsque vous essayez d'éviter les changements de mise en page.

Addy Osmani: Et puis, enfin, le dernier Core Web Vital est le premier délai d'entrée. C'est une chose à laquelle les gens ne pensent pas nécessairement toujours lorsqu'il s'agit d'images. Il est donc en fait possible que les images bloquent la bande passante et le processeur d'un utilisateur lors du chargement de la page. Ils peuvent entraver le chargement d'autres ressources critiques, en particulier sur des connexions très lentes ou sur des appareils mobiles bas de gamme, ce qui peut entraîner une saturation de la bande passante.

Addy Osmani : Donc, le premier délai d'entrée est une métrique Core Web Vital qui capture la première impression des utilisateurs sur l'interactivité et la réactivité d'un site. Ainsi, en réduisant l'utilisation du processeur du thread principal, votre premier délai d'entrée peut également être en quelque sorte minimisé. Donc, en général, évitez simplement les images qui pourraient provoquer des conflits de réseau. Ils ne bloquent pas le rendu. Mais ils peuvent toujours avoir un impact indirect sur vos performances de rendu.

Drew McLellan : Pouvons -nous faire quelque chose avec les images pour les empêcher de bloquer le rendu ? Pouvons-nous soulager le navigateur dans cette phase initiale d'une manière ou d'une autre pour nous permettre d'être interactifs plus rapidement ?

Addy Osmani : Je pense qu'il est de plus en plus important de nos jours d'avoir une bonne compréhension de la bonne séquence d'images optimale pour afficher quelque chose au-dessus de la ligne de flottaison. Je sais qu'au-dessus du pli est un terme surchargé, mais comme dans le premier port de vue de l'utilisateur. Très souvent, nous pouvons finir par essayer de demander une tonne de ressources, dont certaines sont des images, qui ne sont pas vraiment nécessaires pour ce que l'utilisateur va voir immédiatement. Et ceux-ci ont tendance à être d'excellents candidats pour le chargement plus tard dans le cycle de vie de la page, de bonnes choses à charger paresseux sur place. Mais si vous demandez très tôt toute une série d'images, comme toute une file d'attente, celles-ci peuvent potentiellement avoir un impact.

Drew McLellan : Oui. Donc, je veux dire, vous avez mentionné le chargement paresseux d'images que nous avons toujours exigé d'une bibliothèque JavaScript, qui a ses propres revers, je pense, en raison des méthodes historiques utilisées par les navigateurs pour optimiser le chargement des images, où il est presque impossible de les empêcher de charger des images , à moins que vous ne lui donniez pas de source. Et si vous ne lui donnez pas de source et que vous essayez ensuite de le corriger avec JavaScript, si ce JavaScript ne s'exécute pas, vous n'obtenez aucune image. Donc, le chargement paresseux, le chargement paresseux natif est une réponse à tout cela.

Addy Osmani : Oui, absolument. Et je pense que c'est un endroit où nous avons essayé d'améliorer à travers les navigateurs, l'expérience native de chargement paresseux au cours de la dernière année. Comme vous le savez, c'est l'une de ces fonctionnalités où nous avons livré quelque chose tôt et nous sommes en mesure de tirer parti des conversations avec des leaders d'opinion de l'industrie pour comprendre comme, "Oh, hé, quels sont les seuils que vous définissez manuellement si vous utilisez des tailles paresseuses ou si vous utilisez d'autres bibliothèques de chargement paresseux JavaScript ?" Et puis nous avons ajusté nos seuils pour essayer de nous rapprocher légèrement de ce à quoi vous vous attendiez.

Addy Osmani : Donc, dans de nombreux cas, vous pouvez simplement utiliser le chargement paresseux natif. Si vous avez besoin de quelque chose de beaucoup plus raffiné, si vous avez besoin de beaucoup plus de contrôle sur la possibilité de définir les seuils d'observateur d'intersection, le moment où le navigateur va demander des choses, nous suggérons généralement d'utiliser une bibliothèque dans ces cas , simplement parce que nous essayons de résoudre le cas d'utilisation à 90 %. Mais les 10% sont toujours valables. Il y a peut-être des gens qui ont encore besoin de quelque chose d'un peu plus. Et donc, pour la plupart des gens, j'espère que le chargement paresseux natif sera suffisant dans un avenir prévisible.

Drew McLellan : Surtout, c'est gratuit. Un simple attribut à ajouter, et vous obtenez toutes ces fonctionnalités gratuitement, ce qui est formidable. S'il y avait une chose que notre auditeur pourrait faire, pourrait s'en aller et faire sur son site pour améliorer l'optimisation de son image, quelle serait-elle ? Par où commencer ?

Addy Osmani : Un bon point de départ est de comprendre à quel point c'est un problème pour votre site. J'irais vérifier soit le phare, soit les informations sur la vitesse de paiement. Lancez-le sur quelques-unes de vos pages les plus populaires et voyez ce qui en ressort. S'il semble que vous n'ayez qu'une ou deux petites choses à faire, c'est fantastique. Peut-être que vous pouvez y consacrer du temps.

Addy Osmani : Si vous avez une longue liste de choses à faire, jetez peut-être un coup d'œil aux opportunités les plus élevées que vous avez là-dedans, des choses qui disent : « Oh, hé, vous pourriez gagner plusieurs secondes si vous faisiez celle-ci. chose." Et concentrez-y votre énergie pour commencer.

Addy Osmani : Comme nous en avons parlé ici, les outils pour les formats d'image modernes se sont améliorés au fil du temps. Les CDN d'images peuvent certainement valoir la peine d'être envisagés. Mais au-delà de cela, il y a beaucoup de petites étapes que vous pouvez prendre. Parfois, s'il s'agit d'un site suffisamment petit, même en ouvrant simplement Squoosh, y mettre quelques-unes de vos images peut être un excellent point de départ.

Drew McLellan : C'est un bon conseil. Maintenant, je sais que c'est une publication sensationnelle, mais je dois vraiment vous féliciter pour le livre. C'est tellement complet et vraiment facile à digérer. Je pense que c'est une lecture très précieuse.

Drew McLellan : J'ai donc tout appris sur l'optimisation des images. Qu'as-tu appris dernièrement, Addy ?

Addy Osmani : Qu'est-ce que j'ai appris dernièrement ? En fait, sur un sujet légèrement différent qui a toujours à voir avec les images, alors quand je faisais ma maîtrise à l'université, je me suis vraiment plongé dans la vision par ordinateur et j'ai essayé de comprendre, comment pouvons-nous détecter différentes parties d'une image et faire sauvage et des choses intéressantes avec eux?

Addy Osmani: Et un problème spécifique sur lequel j'ai creusé récemment est que je regardais des photos de moi quand j'étais bébé ou enfant. Et à l'époque, une grande partie de la nourriture que mes parents prenaient n'était pas nécessairement sur des appareils photo numériques. C'étaient des Polaroïds. Ce sont souvent des images à faible résolution. Et je voulais un moyen de pouvoir les étendre. Et j'ai donc recommencé à creuser ce problème récemment. Et cela m'a amené à en apprendre beaucoup plus sur ce que je peux faire dans le navigateur.

Addy Osmani : J'ai donc créé de petits outils qui vous permettent, en utilisant l'apprentissage automatique, en utilisant TensorFlow, en utilisant les technologies existantes, de prendre une image ou une illustration à résolution relativement faible, puis de les mettre à l'échelle en quelque chose de bien meilleure qualité. C'est donc mieux que de simplement étirer l'image. C'est comme remplir en fait en détail.

Addy Osmani : Et ça a été plutôt amusant. J'ai beaucoup appris sur la stabilité de l'assemblage Web à travers le navigateur, sur la façon dont vous pouvez utiliser certaines de ces idées pour les cas d'utilisation d'applications de bureau. Et ça a été vraiment amusant. J'ai donc fouillé dans beaucoup d'assemblages Web récemment. Et c'était cool.

Drew McLellan : C'est drôle, n'est-ce pas ? Quand une technologie arrive qui bouleverse tout ce que vous savez. Nous avons toujours dit que sur le Web, nous pouvions réduire la taille des images. Mais si nous n'avons qu'une petite image, nous ne pouvons pas l'agrandir. C'est juste impossible. Mais maintenant, nous avons une technologie qui, dans de nombreuses circonstances, pourrait rendre cela possible. C'est vraiment fascinant.

Drew McLellan: Si vous, cher auditeur, souhaitez en savoir plus sur Addie, vous pouvez le trouver sur Twitter où il est @AddieOsmani et trouver tous ses projets liés à AddyOsmani.com. Le livre "Image Optimization" est disponible à la fois physiquement et numériquement auprès de Smashing dès maintenant sur smashingmagazine.com. Merci de vous joindre à nous aujourd'hui, Addy. Avez-vous des mots d'adieu?

Addy Osmani : Des mots d'adieu ? J'ai une petite bizarrerie de l'histoire que je partagerai avec les gens. Tim Berners-Lee a téléchargé la toute première image sur Internet en 1992. Je ne sais pas si vous pouvez deviner ce que c'était, mais vous serez probablement surpris. Drew, as-tu des suppositions ?

Drew McLellan : Je suppose un chat.

Addy Osmani : Un chat. C'est une bonne supposition, mais non. C'était au CERN. Et l'image était en fait celle d'un groupe appelé Les Horribles Cernettes, qui était un groupe pop parodique formé par un groupe d'employés du CERN. Et la musique qu'ils faisaient était comme de la musique doo-wop. Et ils chantaient des chansons d'amour sur les collisionneurs et les bizarreries et l'azote liquide et l'anti-matière portant des tenues des années 60, ce que je trouvais tout simplement merveilleux et aléatoire.