L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
Optimisation d'image —
Dans cet épisode du Smashing Podcast, nous parlons d'optimisation d'image. Quelles étapes devons-nous suivre pour des images performantes en 2021 ? Nous discutons avec l'expert Addy Osmani pour le savoir.
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 notes
Mise à jour hebdomadaire
Transcription
Drew McLellan : C'est un responsable technique travaillant sur Google Chrome, où son équipe se concentre sur la vitesse, aidant à garder le Web rapide. Consacré à la communauté open source, ses contributions passées incluent Lighthouse, Workbox, Yeoman, Critical et pour faire 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 formidables amis, veuillez accueillir Addy Osmani. Salut, Addy. Comment vas-tu ?
Addy Osmani : Je défonce.
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 d'image pour Smashing. Quelle était la motivation pour penser à ce moment-là : « Le moment est venu d'écrire un livre sur l'optimisation d'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 notre cerveau est capable d'interpréter les images beaucoup plus rapidement qu'il ne peut le texte. Mais ce sujet global en est un qui continue à devenir de plus en plus intéressant et 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 décidé d'écrire un livre.
Addy Osmani : J'ai commencé ce livre en écrivant un article sur l'optimisation des images, 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 : J'ai donc écrit ce livre parce que j'avais du mal à rester au top de tous ces changements. Et j'ai pensé : « Je vais être un bon citoyen du Web et essayer de suivre tout ce que j'ai appris au même endroit afin que tout le monde puisse en profiter. »
Drew McLellan : C'est un de ces domaines, je pense, avec beaucoup d'optimisation des performances dans le navigateur, c'est un paysage en évolution rapide, n'est-ce pas ? Lorsqu'une technique que vous avez apprise comme étant à jour et comme étant la meilleure pratique, un changement technologique se produit, puis vous découvrez que c'est en fait 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 que vous 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 cela rassemblé dans un livre bien documenté d'une source faisant autorité est vraiment formidable.
Addy Osmani : Ouais. 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, attendez. Je dois faire un autre changement de dernière minute. »
Addy Osmani : Mais le paysage de l'image a beaucoup évolué, même au cours de la dernière année. Nous avons vu le support WebP franchir enfin la ligne d'arrivée dans la plupart des navigateurs modernes. La prise en charge des images AVIF est dans Chrome, à venir 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, il y a beaucoup à faire pour les gens.
Drew McLellan : Certaines personnes pourraient considérer le sujet de l'optimisation d'image comme un sujet assez guindé. À un moment de notre carrière, nous avons tous 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 : Nous savons donc peut-être que nous devrions choisir un JPEG lorsqu'il s'agit d'une image photographique et d'un PNG lorsqu'il s'agit d'une image graphique et pensez 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 le besoin 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 de périphérique, leurs contraintes de réseau est un problème difficile et quelque chose que je connais encore beaucoup de gens lutter 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 à garder à l'esprit. Le premier est juste généralement la compression. Vous avez mentionné ImageOptim, et beaucoup d'entre nous sont habitués à simplement faire glisser une image vers un endroit et à en retirer quelque chose de plus petit.
Addy Osmani : Maintenant, en ce qui concerne la compression, nous sommes parle généralement de différents codecs. Et les codecs sont une technologie de compression qui a généralement un composant encodeur pour coder 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 peuvent être abordées 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 une approche où vous reproduisez exactement le même fichier à la toute fin lors de la décompression. Donc, vous ne perdez pas vraiment beaucoup en termes de qualité. Sans perte, c'est beaucoup plus mettre votre image dans un télécopieur. Vous obtenez un fac-similé de l'original, et ce ne sera pas le fichier original. Il pourrait y avoir des artefacts différents en place là-bas. Cela peut sembler subtilement différent. Mais en termes généraux, plus vous compressez, plus vous perdez généralement en qualité.
Addy Osmani : Et donc avec tous ces codecs d'image modernes, ils essaient de voir à quel point vous pouvez obtenir la qualité extraire 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 dans 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, en revenant à l'endroit où nous avons commencé avec JPEG et PNG, les gens savent peut-être que le JPEG a été créé pour une compression de photos avec perte. Vous obtenez généralement un fichier plus petit au dos, et il peut parfois avoir différents artefacts de bandes. PNG a été créé à l'origine pour une compression sans perte, fonctionne assez bien sur les images non photographiques.
Addy Osmani: Mais depuis lors, 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'images et d'options sur la table vient de monter en flèche depuis lors. Je pense que les choses vont généralement dans la bonne direction, surtout avec les formats modernes comme AVIF et JPEG XL. Mais il nous a fallu du temps pour en arriver là. Même obtenir la prise en charge de WebP sur tous les navigateurs a pris un certain temps. 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: Ouais. 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. Et il y a une bonne prise en charge des navigateurs, 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 à le niveau de la base. 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 aux 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'outillage 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 peux rappelez-vous il y a de nombreuses années lorsque WebP est sorti pour la première fois. Les premiers utilisateurs ont eu ce problème : vous enregistriez votre fichier WebP sur votre bureau, puis soudain, « 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 existe une prise en charge assez globale du format d'image à la fois au niveau du système d'exploitation et 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 que je 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à, au moins sur iOS, qu'iOS prend en charge une randonnée et un trait d'union. Et convertir les choses au format JPEG lorsque cela est nécessaire permet aux gens de les partager.
Addy Osmani : Donc, en pensant à ces types de cas d'utilisation où nous pouvons nous assurer que les utilisateurs ne sont pas perdants pendant que nous les livrons mieux la compression est importante, je pense.
Drew McLellan: J'ai un service de partage de diapositives que je gère 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 êtes facturé moins cher pour le servir. Mais alors que j'avais encore besoin d'une image arrière, d'un format d'image hérité, mes calculs ont montré que le coût du 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 vraiment 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, essayer parfois de trouver le meilleur dénominateur commun pour servir vos utilisateurs vaut la peine d'être gardé à l'esprit. . De nos jours, je dirais en fait que WebP mérite d'être considéré comme ce dénominateur commun. Pour les personnes qui ont l'habitude d'utiliser la balise d'image pour servir sous condition différents formats aux personnes, vous utiliserez généralement un JPEG comme solution de secours principale. Peut-être qu'il est acceptable de nos jours d'utiliser le WebP comme solution de secours pour la plupart des utilisateurs, à moins que vous n'ayez des gens qui utilisent de très, très vieux navigateurs. Et je pense que nous en voyons beaucoup moins ces jours-ci. Mais vous avez certainement une certaine flexibilité là-bas.
Addy Osmani: Maintenant, si vous essayez d'être orienté vers l'avant, je dirais de choisir un format qui, selon vous, fonctionne très bien. Si vous pouvez aborder le stockage d'une manière qui s'adapte à vos besoins et s'adapte à vos besoins, ce que je dirais, c'est que les gens devraient considérer JPEG XL. Techniquement, il 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 sans photo. Et ce sera probablement bien mieux que WebP V1. C'est donc un endroit.
Addy Osmani : Je pense qu'AVIF sera probablement meilleur si vous devez utiliser des débits binaires très 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 pourrais imaginer qu'il semble 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 chromosomique peut ne pas être parfait dans WebP. C'est certainement quelque chose qui mérite d'être gardé à 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 Cloudinary personnellement. Nous utilisons de nombreux CDN d'images différents là où je travaille. Mais j'ai trouvé que ne pas avoir à me soucier autant des coûts de maintenance liés au traitement 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 solutions de secours ou de nouvelles API Web ”, cela a été un bon avantage à investir dans quelque chose qui s'en occupe pour moi.
Addy Osmani : Et puis le coût global de mes cas d'utilisation a été correct. Mais je peux tout à fait imaginer que si vous exécutez un service de diapositives à cette échelle, ce n'est peut-être pas nécessairement une option non plus.
Drew McLellan : Ouais. Je veux donc revenir sur certains de ces futurs formats à venir. Mais je pense que cela vaut la peine de creuser, car avec n'importe quel type d'outils de performance, Lighthouse ou WebPageTests, si l'un d'entre nous y fait passer nos sites, l'une des choses clés qu'il suggérera est que nous utilisions 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 en fait aussi facile à faire qu'il y paraît ?
Addy Osmani : Je pense que la question que les gens devraient se poser est : « Qu'utilisez-vous ? images pour ? 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 être d'accord avec cette approche. 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 en grande partie.
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 formats, ils ne veulent pas faire face à autant de minutie de l'outillage et que vous voulez pouvoir mettre en place une image ou une histoire réactive vraiment riche, je dirais d'essayer un CDN d'image. Personnellement, j'étais assez réticent à l'utiliser pour des projets personnels au départ pour des raisons de coût, 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 traiter vos images dans le passé, mais j'ai réalisé que si je pouvais m'économiser au moins quelques jours de débogage via ces différents packages npm par mois, alors les coûts en quelque sorte 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 ce n'est pas nécessairement quelque chose qui est couvert par vos revenus ou pas quelque chose que vous êtes prêt à payer, vous devez penser à des 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 sommes à un endroit 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 types de principes directeurs est toujours juste pour être agile et être prêt pour le changement. Et vous pouvez commencer à utiliser un CDN d'image pour convertir dynamiquement vos images pour vous comme elles sont demandées, et si cela arrive à un point où ce n'est pas durable du point de vue des 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 JPEG XL ? D'où vient-il ? Et qu'est-ce que cela fait pour nous ?
Addy Osmani : C'est une excellente question. JPEG XL est donc un format d'image de nouvelle génération, il est censé être général et c'est un codec du comité JPEG. Cela a commencé avec quelques racines dans le format pic de Google, puis le format FUIF de Cloudinary. Il y a eu beaucoup de formats au fil des ans qui ont été en quelque sorte englobés par cet effort, mais c'est devenu bien plus qu'une simple 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 bien pour sans perte, il prend en charge le décodage progressif, le transcodage JPEG sans perte, et c'est aussi un peu sans tracas 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 pour être celui-là.
Addy Osmani : Je ne veux pas non plus trop promettre, nous sommes encore très tôt avec 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 de la part 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 qu'un terme d'intérêt encore plus court pour les gens ? Il y a bien sûr AVIF aussi.
Drew McLellan : Parlez-nous d'AVIF, c'est un autre que je ne connais pas.
Addy Osmani : D'accord. Nous avons donc mentionné un peu plus tôt qu'AVIF était peut-être un meilleur candidat si vous devez utiliser des débits binaires faibles et que vous vous souciez davantage 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 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 en sommes à un stade où AVIF bénéficie d'une prise en charge de navigateur de plus en plus bonne, mais permettez-moi de prendre du recul et de parler un peu plus du format. Donc AVIF lui-même est basé sur le codec vidéo AV1, qui a été standardisé par l'Alliance for Open Media, et il essaie d'obtenir des gains de compression significatifs par rapport à JPEG, par rapport à WebP, dont nous parlions plus tôt. Et bien que les économies exactes que vous pouvez obtenir d'AVIF dépendent 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 à JPEG.
Addy Osmani : de nombreuses bonnes fonctionnalités, il est capable de vous offrir une prise en charge des conteneurs pour de nouvelles fonctionnalités telles que la plage dynamique élevée et les larges gammes de couleurs, la synthèse du grain du film. Et encore une fois, comme si vous parliez d'être orienté vers l'avant, l'un des avantages de la balise d'image est que vous pouvez servir les fichiers AVIF des utilisateurs dès maintenant et qu'elle reviendra toujours à votre WebP ou à votre JPEG dans les cas où elle n'est pas nécessairement prise en charge . Mais pour revenir à votre exemple sur Photoshop Save For Web, vous pouvez prendre un JPEG de 500 kilo-octets, essayer de tirer pour une qualité similaire à Photoshop Save For Web et avec AVIF, je dirais que vous pourrez probablement obtenir un point où cette taille de fichier est d'environ 90 kilo-octets, 100 kilo-octets, donc beaucoup d'économies sans réelle perte de qualité perceptible. voir autant de perte de texture dans toutes les images riches en détails. Donc, si vous avez des photos de forêts ou de camping ou de 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 individuelles, nous avons Squoosh, squoosh.app, qui est écrit par une autre équipe dans Chrome, alors criez à Surma et Jake pour avoir travaillé sur Squoosh. Avif.io a un certain nombre de bonnes options pour les personnes qui essaient d'utiliser AVIF aujourd'hui, quelle que soit la pile technologique sur laquelle ils se concentrent, Sharp prend également en charge AVIF.
Addy Osmani : Mais alors généralement, vous pensez sur 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 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 actuellement avec les équipes travaillant sur AVIF dans Chrome, en essayant de nous assurer que nous pouvons mettre l'outillage à un assez bon endroit.
Drew McLellan : Nous avons donc obtenu en HTML, l'élément image maintenant, ce qui nous donne plus de flexibilité par rapport à la balise image traditionnelle. Bien que la balise d'image ait également parcouru un long chemin, n'est-ce pas ? Mais nous avons vu une 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 : Vous pouvez donc lister différents formats d'images et le navigateur choisissez celui qu'il prend en charge, et cela nous permet d'être assez expérimental tout de suite sans avoir à trop nous soucier de casser des choses pour les personnes avec des 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 orientation, simplement pouvoir servir une image aux gens et laisser le navigateur parcourir la liste des sources potentielles et voir, d'accord, eh bien, j'utiliserai le premier de cette liste que je comprends, sinon je reviendrai, c'est une capacité vraiment puissante pour les gens. Je pense qu'en même temps, j'ai également entendu certaines personnes exprimer leur inquiétude ou leur inquiétude quant au fait que nous régénérons d'énormes taches 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 tout à coup, cela devient un peu volumineux.
Addy Osmani : Alors, y a-t-il d'autres façons d'aborder ces problèmes ? Je ne veux pas trop vendre aux gens sur les CDN d'images, je veux qu'ils se débrouillent seuls. Mais c'est l'un de ces endroits où une idée appelée négociation de contenu peut réellement vous offrir une voie intéressante. Donc, nous avons parlé un peu 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'il dit, c'est de faire tout ce travail sur le serveur. Ainsi, les clients peuvent indiquer au serveur les formats qu'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 de génération et de gestion des ressources ultimes et de décider lesquelles envoyer aux clients. Et l'une des choses les plus 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 pourrait donner aux gens une URL vers puppy.JPEG et si leur navigateur prend en charge WebP ou s'il prend en charge un AVIF, le serveur peut devenir très intelligent pour fournir la bonne image à ces utilisateurs en fonction de l'apparence de leur support, mais sinon se replier sans que vous ayez besoin faire vous-même une tonne de travail supplémentaire. 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 qualité de réseau vraiment solide, 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 si bonne. C'est donc là que vous avez accès à d'autres API, à d'autres idées comme l'astuce 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 de trouver un bon équilibre où les gens 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 du navigateur capable de signaler une préférence pour le retour d'une expérience de données réduite, car il s'agit peut-être d'une connexion limitée ou d'une batterie faible ou quelque chose du genre.
Addy Osmani : Exactement. Exactement. J'ai voyagé à l'époque normale 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 médiocre ou vraiment inégale, et donc même d'ouvrir 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 à manger à la place. Mais je pense que l'une des choses intéressantes à propos de l'économiseur de données est qu'il vous permet de revenir sur 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 opter pour le mode d'économiseur de données dans mon navigateur. »
Addy Osmani : Et puis vous pouvez utiliser cela en tant que développeur comme signal pour dire : « D'accord , eh bien, l'utilisateur est un peu limité, peut-être que nous allons surfer sur des images beaucoup plus petites ou des images de qualité beaucoup plus faible. Mais ils peuvent quand même voir des images, ce qui est mieux qu'eux d'attendre très longtemps pour que quelque chose de beaucoup plus riche soit servi. D'autres avantages de ces types de signaux sont que vous pouvez les utiliser pour servir 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 dans JavaScript.
Addy Osmani : Si certains composants sont considérés comme légèrement plus facultatifs, peut-être que ceux-ci ne le font pas. doivent nécessairement ê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 basique, petite et rapide, puis la superposer avec un bon glaçage pour les personnes qui ont une connexion ou un appareil plus rapide.
Drew McLellan : Potentiellement, je suppose que cela pourrait prendre en compte dans la pagination et vous pourriez renvoyer 10 résultats sur une page plutôt que 100 et ce genre de choses aussi. Donc, beaucoup de capacités intéressantes et intéressantes là-bas. Je pense que nous connaissons tous en quelque sorte le processus frustrant consistant à préparer un nouveau site, à optimiser toutes vos images, à le remettre au client, à lui donner un CMS pour gérer le contenu et découvrir qu'il ne fait que tout remplacer par images mal optimisées. Je veux dire, encore une fois, un CDN d'image, je suppose, serait une solution vraiment pratique à cela, mais existe-t-il d'autres solutions, y a-t-il des choses que le CMS pourrait faire sur le serveur pour aider avec cela ou est-ce qu'un CDN d'image est probablement le chemin à parcourir ?
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 leurs images, c'est que c'est un problème difficile où certaines personnes impliquées dans l'image might be slightly more technically savvy and maybe comfortable setting up their own tooling or going and running Lighthouse or trying out other tools to let them know whether there are opportunities to improve. I’d love to see people consistently using things like Lighthouse to catch if you’ve got opportunities to optimize further or serve down images of the right size but beyond that, sometimes we run into use cases where the people who are uploading images may not necessarily even understand the cost of the resources that they’re uploading. This is commonly something we run into, and I’ll apologize, I’m not going to call people out too much, but this is something we run into even with the Google blog.
Addy Osmani: Every couple of weeks on the Google blog, we’ll have somebody upload a very large 20 or 30 megabyte animated GIF. And I don’t expect them to know that that’s not a good idea, they’re trying to make the article look cool and very engaging and interactive, but those audiences are not necessarily going to know to go and run tools or to use ImageOptim or to use any of these other tools in place and so documenting for them, that they should check them out, is certainly one option. But being able to automate away the problem, I think is very compelling and helps us consistently get to a place where we’re hopefully balancing the needs of all of our users of CMSs, whether they’re technical or non-technical, as well as the needs of our users.
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: So if I’m trying to go to a recipe site, I might care about how that recipe looks, and so we care about making sure that that big hero image of the recipe is visible to me. Now, the LCP element can change over time. It’s very possible that early on in load, the largest thing may be a heading, but as the page continues to load, it might actually end up being a much larger image or a poster of some sort.
Addy Osmani: And so when you’re trying to optimize largest contentful paint, there’s about four things that you can do. The first thing is making sure that you’re requesting your key hero image as early on as possible. Generally, we have a number of things that are important in the page. We want to make sure that we can render the main page’s content and layout.
Addy Osmani: For layout, typically we’re talking about CSS. So you may be using critical CSS, inline CSS, in your pages, want to avoid things that are render blocking, but then when it comes to your image, ideally you should be requesting that image early. Maybe that involves just making sure that the browser can discover that image as early on in the page as possible, given that a lot of us these days are relying on frameworks.
Addy Osmani: If you’re not necessarily using SSR, server-side rendering, if you are waiting on the browser to discover some of your JavaScript bundles, bundles for your components, whether you have a component for your hero image or product image, if the browser has to wait to fetch, parse, execute, compile and execute all of these different files before it can discover the image, that might mean that your largest contentful image is going to take some time before it can be discovered.
Addy Osmani: Now, if that’s the case, if you find yourself in a place where the image is being requested pretty late, you can take advantage of a browser feature called link rel preload to make sure that the browser can discover that image as early as possible. Now, preload is a really powerful capability. It’s also one that you need to take a lot of care with. These days, it’s very easy to get to a place where maybe you hear that we’re recommending preload for your key-
Addy Osmani: Maybe you hear that we’re recommending preload for your key hero image, as well as your key scripts, as well as your key fonts. And it becomes just this really big, massive trying to make sure that you’re sequencing things in the right order. So the LCP images is definitely one key place worth keeping in mind for this.
Addy Osmani: The other thing, as I mentioned four things, the other thing is make sure you’re using source set and an efficient modern image format. I think that source set is really powerful. I also see sometimes when people are using it, they’ll try to overcompensate and will maybe ship 10 different versions of images in there for each possible resolution. We tend to find, at least in some research, that beyond three by images, users have a really hard time being able to tell what the differences are for image quality and sharpness and detail. So DPR capping, device pixel ratio capping, is certainly an idea worth keeping in mind.
Addy Osmani: And then for modern image formats, we talked about formats earlier, but consider your WebP, your AVIF, your JPEG XL. Avoid wasting pixels. It’s really important to have a good strategy in place for quality. And I think that there are a lot of cases where even the default quality can sometimes be too much. So I would experiment with trying to lower your bit rate, lower your quality settings, and see just how far you can take things for your users while maintaining sharpness.
Addy Osmani: And then when we’re talking about loading, one of the other things that the image tag has kind of evolved to support over the last couple of years is the lazy loading. So with loading equals lazy, you no longer need to necessarily use a JavaScript library to add lazy loading to your images. You just drop that onto your image. And in chromium browsers and Firefox, you’ll be able to lazy load those images without needing to use any third-party dependencies. And that’s quite nice too.
Addy Osmani: So, we’ve got lazy loading in place. We’ve got support for other things like sync decoding, but I’m going to keep things going and talk very quickly about the other two core vitals metrics.
Drew McLellan: Go for it, yep.
Addy Osmani: So, get rid of layout shifts. Nobody likes things jumping around their pages. I feel like, one of my biggest frustrations is I open up a web page. I hover my finger over a button I want to click, and then suddenly a bunch of either ads or images without dimension set or other things pop in. And it causes a really unpleasant experience.
Addy Osmani: So cumulative layout shift tries to measure the instability of content. And a lot of the time, the common things that are pushing your layout shifts are images or other elements on your page that just don’t have dimension set. I think that that’s one of those places where it’s often straightforward for people to set image dimensions. Maybe it’s not something we’ve historically done quite as much of, but certainly something worth spending your time on. In tools like lighthouse will try to help you collect, like what is the list of images on your page that require dimensions? So you can go and you can set them.
Drew McLellan: I was going to say, that’s a really interesting point because when responsive web design became a thing, we all went through our sites and stripped out image dimensions because the tools we had at our disposal to make that work required that we didn’t have height and width attributes on our images. But that’s a bad idea now, is it?
Addy Osmani: What’s old is new again. I would say that it’s definitely worth setting dimensions on your images. Set dimensions on your ads, your eye frames, anything that is dynamic content that could potentially change in size is worth setting dimensions on.
Addy Osmani: And for folks who are building really fun out there experience, out there is the wrong phrase, really fun layout experiences where maybe you need to do kind of more work on responsive cards and the like; I would consider using CSS aspect ratio or aspect ratio boxes to reserve your space. And that can compliment setting dimensions on those images as well for making sure that things are as fixed as possible when you’re trying to avoid your layout shifts.
Addy Osmani: And then, finally last Core Web Vital is first input delay. This is something people don’t necessarily always think about when it comes to images. So it is in fact possible for images to block a user’s bandwidth and CPU on page load. They can get in the way of how other critical resources are loaded in, in particular on really slow connections or on lower end mobile devices that can lead to bandwidth saturation.
Addy Osmani: So first input delay is a Core Web Vital metric that captures, it users first impression of a site’s interactivity and responsiveness. And so by reducing main thread CPU usage, your first input delay can also be kind of minimized. So in general there, just avoid images that might cause network contention. They’re not render blocking. But they can still indirectly impact your rendering performance.
Drew McLellan: Is there anything we can do with images to stop them render blocking? Can we take load off the browser in that initial phase somehow to enable us to be interactive quicker?
Addy Osmani: I think it’s really important increasingly these days to have a good understanding of the right optimal image sequence for displaying something above the fold. I know that above the fold is an overloaded term, but like in the user’s first view port. Very often we can end up trying to request a whole ton of resources, some of them being images, that are not really necessary for what the user is immediately going to see. And those tends to be great candidates for loading later on in the page’s lifecycle, great things to lazy load in place. But if you’re requesting a whole slew of images, like a whole queue of things very early on, those can potentially have an impact.
Drew McLellan: Yeah. So, I mean, you mentioned lazy loading images that we’ve historically required a JavaScript library to do, which has its own setbacks, I think, because of historic ways that browsers optimize loading images, where it’s almost impossible to stop them loading images, unless you just don’t give it a source. And if you don’t give it a source and then try and correct it with JavaScript afterwards, if that JavaScript doesn’t run, you get no images. So lazy loading, native lazy loading is an answer to all that.
Addy Osmani: Yeah, absolutely. And I think that this is a place where we have tried to improve across browsers, the native lazy loading experience over the last year. As you know, this is one of those features where we shipped something early and we’re able to take advantage of conversations with thought leaders in the industry to understand like, “Oh, hey, what are the thresholds you’re actually manually setting if you’re using lazy sizes or you’re using other JavaScript’s lazy loading libraries?” And then we tuned our thresholds to try getting to a slightly closer place to what you’d expect them to be.
Addy Osmani: So in a lot of cases, you can just use native lazy loading. If you need something a lot more refined, if you need a lot more control over being able to set the intersection observer thresholds, the point of when the browser is going to request things, we generally suggest, go and use a library in those cases, just because we’re trying to solve for the 90% use case. But the 10% is still valid. There might be people who still need something a little bit more. And so, for most people, I’m hopeful that native lazy loading will be good enough for the foreseeable future.
Drew McLellan: Most of all, it’s free. A simple attribute to add, and you get all this functionality for free, which is great. If there was one thing that our listener could do, could go away and do to their site to improve their image optimization, what would it be? Where should they start?
Addy Osmani: A good place to start is understand how much of a problem this is for your site. I’d go and check out either lighthouse or pay speed insights. Go and run it on a few of your most popular pages and just see what comes out. If it looks like you’ve only got one or two small things to do, that’s fantastic. Maybe you can put some time in there.
Addy Osmani: If there’s a long list of things for you to do, maybe take a look at the highest opportunities that you have in there, things that say, “Oh, hey, you could save multiple seconds if you were to do this one thing.” And focus your energy there to begin with.
Addy Osmani: As we’ve talked about here, tooling for modern image formats has gotten better over time. Image CDNs can definitely be worth considering. But beyond that, there’s a lot of small steps you can take. Sometimes if it’s a small enough site, even just going and opening up Squoosh, putting a few of your images through there can be a great starting point.
Drew McLellan: That’s solid advice. Now I know it’s a smashing publication, but I really must congratulate you on the book. It’s just so comprehensive and really easy to digest. I think it’s a really valuable read.
Drew McLellan: So I’ve been learning all about image optimization. What have you been learning about lately, Addy?
Addy Osmani: What have I been learning about lately? Actually, on a slightly different topic that still has to do with images, so when I was doing my masters at college, I got really deep into computer vision and trying to understand, how can we detect different parts of an image and do wild and interesting things with them?
Addy Osmani: And a specific problem I’ve been digging into recently is I’ve been looking at pictures of myself when I was a baby or a kid. And back then, a lot of the food is my parents would take were not necessarily on digital cameras. They were Polaroids. They’re often somewhat low resolution images. And I wanted a way to be able to scale those up. And so I started digging into this problem again recently. And it led me to learn a lot more about what I can do in the browser.
Addy Osmani: So I’ve been building out some small tools that let you, using machine learning, using TensorFlow, using existing technologies, take a relatively low resolution image or illustration, and then upscale them to something that is much higher quality. So that it’s better than simply just like stretching the image out. It’s like actually filling in detail.
Addy Osmani: And that’s been kind of fun. I’ve been learning a lot about how stable web assembly is now across browser, how well you can use some of these ideas for desktop application use cases. And that’s been really fun. So I’ve been digging into a lot of web assembly recently. And that’s been cool.
Drew McLellan: It’s funny, isn’t it? When a technology comes along that turns everything you know on its head. We’ve always said that on the web, we can make images smaller. But if we’ve only got a small image, we can’t make it bigger. It’s just impossible. But now we have technology that, under a lot of circumstances, might make that possible. It’s really fascinating.
Drew McLellan: If you, dear listener, would like to hear more from Addie, you can find him on Twitter where he’s @AddieOsmani and find all his projects linked from AddyOsmani.com. The book “Image Optimization” is available both physically and digitally from Smashing right now at smashingmagazine.com. Thanks for joining us today, Addy. Do you have any parting words?
Addy Osmani: Any parting words? I have a little quirk from history that I will share with people. Tim Berners-Lee uploaded the very first image to the internet in 1992. I’m not sure if you can guess what it was, but you’ll probably be surprised. Drew, do you have any guesses?
Drew McLellan: I’m guessing a cat.
Addy Osmani: A cat. It’s a good guess, but no. This was at CERN. And the image was actually of a band called Les Horribles Cernettes, which was a parody pop band formed by a bunch of CERN employees. And the music they would do is like doo-wop music. And they would sing love songs about colliders and quirks and liquid nitrogen and anti-matter wearing sixties outfits, which I found just wonderful and random.
(il)Source link