Smashing Podcast Episodul 39 Cu Addy Osmani: Optimizarea imaginii

Publicat: 2022-03-10
Rezumat rapid ↬ În acest episod al Smashing Podcast, vorbim despre optimizarea imaginii. Ce pași ar trebui să urmăm pentru imagini performante în 2021? Vorbim cu expertul Addy Osmani pentru a afla.

În episodul de astăzi al Smashing Podcast, vorbim despre optimizarea imaginii. Ce pași ar trebui să urmăm pentru imagini performante în 2021? Am vorbit cu expertul Addy Osmani pentru a afla.

Afișați note

  • „Optimizarea imaginii”, Addy Osmani
  • Addy pe Twitter
  • Site-ul personal al lui Addy

Actualizare săptămânală

  • Faceți cunoștință cu :has, un selector de părinți CSS nativ (și mai mult)
    scris de Adrian Bece
  • Trei instrumente de audit front-end pe care le-am descoperit recent
    scris de Stefan Judis
  • Placi frontale utile și kituri de pornire
    scris de Cosima Mielke
  • Web Design bine făcut: Folosind audio
    scris de Frederick O'Brien
  • Când CSS nu este suficient: cerințe JavaScript pentru componentele accesibile
    scris de Stephanie Eckles

Transcriere

Fotografie cu Addy Osmani Drew McLellan: Este un manager de inginerie care lucrează pe Google Chrome, unde echipa sa se concentrează pe viteză, ajutând la menținerea rapidă a internetului. Devotat comunității open source, contribuțiile sale anterioare includ Lighthouse, Workbox, Yeoman, Critical și to do NVC. Așa că știm că se pricepe la optimizarea pentru performanța web. Dar știai că vrea să câștige Oscarul pentru cea mai bună actriță într-un rol secundar din cauza unei erori de scris? Prietenii mei zdrobitori, vă rog bun venit lui Addy Osmani. Bună, Addy. Ce mai faci?

Addy Osmani: Sunt zdrobitoare.

Drew McLellan: E bine de auzit. Am vrut să vă vorbesc astăzi despre imaginile de pe web. Este un domeniu în care au existat o cantitate surprinzătoare de schimbări și inovații în ultimii ani și tocmai ați scris o carte foarte cuprinzătoare despre optimizarea imaginii pentru Smashing. Care a fost motivația de a gândi în acest moment: „Acum este momentul pentru o carte despre optimizarea imaginii?”

Addy Osmani: Aceasta este o întrebare grozavă. Cred că știm că imaginile au fost o parte cheie a web-ului timp de decenii și că creierul nostru este capabil să interpreteze imaginile mult mai repede decât poate textul. Dar acest subiect de ansamblu este unul care continuă să devină din ce în ce mai interesant și mai nuanțat în timp. Și le spun mereu oamenilor că aceasta este probabil, cred, a treia sau a patra carte a mea. Nu mi-am propus niciodată să scriu o carte.

Addy Osmani: Am început această carte scriind un articol despre optimizarea imaginii și apoi, de-a lungul timpului, am descoperit că am scris din greșeală o carte întreagă despre asta. Lucrăm la acest proiect de aproximativ doi ani. Și chiar și în acel timp, industria a evoluat browserele și instrumentele din jurul imaginilor și formatelor de imagine au evoluat.

Addy Osmani: Și așa am scris această carte pentru că mi-a fost greu să rămân la curent cu toate aceste schimbări. Și m-am gândit: „Voi fi un bun cetățean al internetului și voi încerca să urmăresc tot ce am învățat într-un singur loc, astfel încât toți ceilalți să poată profita de asta.”

Drew McLellan: Este una dintre acele domenii, cred că, cu multă optimizare a performanței în browser, este un peisaj care se schimbă rapid, nu-i așa? Acolo unde o tehnică pe care ați învățat-o ca fiind actuală și cea mai bună practică, are loc o schimbare tehnologică și apoi descoperiți că este de fapt un anti-model și nu ar trebui să o faceți. Și să încerci să-ți păstrezi cunoștințele și să te asiguri că citești articolele potrivite și că înveți lucrurile potrivite și că nu citești ceva de acum doi ani este destul de dificil.

Drew McLellan: Așadar, să ai totul colectat într-o singură carte bine cercetată dintr-o sursă autorizată este cu adevărat extraordinar.

Addy Osmani: Da. Chiar și din perspectiva unui autor, unul dintre cele mai interesante lucruri și poate unul dintre cele mai stresante pentru echipa noastră editorială a fost să predau un capitol și să spun că s-a făcut. Și apoi două săptămâni mai târziu, ceva s-a schimbat într-un browser și aș fi de genul: „Oh, stai. Trebuie să fac o altă schimbare de ultimă oră.”

Addy Osmani: Dar peisajul imaginii a evoluat destul de mult, chiar și în ultimul an. Am văzut că suportul WebP a depășit în sfârșit linia de sosire în majoritatea browserelor moderne. Suportul pentru imagini AVIF este în Chrome, vine în Firefox, JPEG XL, încărcare leneră. Și în general, am văzut îmbunătățiri în modul în care puteți utiliza imaginile de pe web destul de concret în browsere. Dar din nou, o mulțime de oameni pe care să le țină la curent.

Drew McLellan: Unii oameni ar putea vedea subiectul optimizării imaginii ca pe un subiect destul de sigur. Cu toții, la un moment dat în cariera noastră, am învățat cum să exportăm pentru web din software-ul nostru de grafică. Și unii dintre noi ar putea avea obiceiul de a lua acele imagini exportate și de a le rula prin ceva de genul ImageOptim.

Drew McLellan: Așa că s-ar putea să știm că ar trebui să alegem un JPEG când este o imagine fotografică și un PNG când este o imagine bazată pe grafic și să ne gândim că, „Bine, asta este. Știu optimizarea imaginii, am terminat.” Dar într-adevăr, acele lucruri sunt doar mize de masă, nu-i așa, în acest moment?

Addy Osmani: Da, sunt. Cred că, pe măsură ce capacitatea noastră de a afișa imagini și imagini mai detaliate și mai clare chiar și într-un context diferit, în funcție de faptul că îți pasă de direcția artistică sau nu, a evoluat de-a lungul timpului. Cred că nevoia de a-ți da seama cum poți obține acele imagini să arate la fel de frumos așa cum s-a dorit pentru utilizatorii tăi finali, ținând cont de mediul lor, de constrângerile dispozitivului lor, de constrângerile de rețea, este o problemă dificilă și ceva despre care știu încă mulți oameni. a se lupta cu.

Addy Osmani: Și atunci când vine vorba de a ne gândi la imagini și de a obține o interpretare puțin mai rafinată a acestui lucru, dincolo de „Hei, haideți să folosim un JPEG” sau „Hai să folosim un PNG”, cred că există câteva dimensiuni pentru această valoare. tine minte. Prima este doar compresia în general. Ați menționat ImageOptim și mulți dintre noi sunt obișnuiți să trageți o imagine într-un loc și să scoatem ceva mai mic de pe spatele acesteia.

Addy Osmani: Acum, când vine vorba de compresie, de obicei vorbim despre diferite codecuri. Și codecurile sunt o tehnologie de compresie care au de obicei o componentă de codificare pentru codificarea fișierelor și o componentă de decodare pentru decodarea și decomprimarea lor. Și când ajungeți să decideți dacă utilizați ceva, în general trebuie să vă gândiți dacă fotografiile sau imaginile pe care le utilizați sunt în regulă pentru a le aborda folosind o abordare cu compresie cu pierderi sau o abordare cu pierderi mai mici.

Addy Osmani: În cazul în care oamenii nu sunt într-adevăr la fel de familiarizați cu aceste concepte, o abordare fără pierderi este aceea în care reproduc exact același fișier la sfârșitul decompresiei. Deci nu pierzi prea mult în ceea ce privește calitatea. Lossless înseamnă mult mai mult să vă puneți imaginea printr-un fax. Primești un facsimil al originalului și nu va fi fișierul original. S-ar putea să fie niște artefacte diferite acolo. S-ar putea să arate subtil diferit. Dar, în termeni generali, cu cât comprimați mai mult, cu atât mai multă calitate pierdeți de obicei.

Addy Osmani: Și astfel, cu toate aceste codecuri de imagine moderne, ei încearcă să vadă cât de multă calitate puteți scoate, menținând totuși o dimensiune relativ decentă a fișierului, în funcție de cazul de utilizare.

Drew McLellan: Deci, într-adevăr, din punct de vedere al tehnologiei, aveți o imagine sursă și apoi aveți formatul fișierului destinație. Dar procesul de transformare a unuia în celălalt este deschis pentru dezbatere. Atâta timp cât aveți un fișier conform, modul în care o faceți se datorează unui codec care poate avea o mulțime de implementări diferite, iar unele vor fi mai bune decât altele.

Addy Osmani: Absolut. Absolut. Și cred că, din nou, revenind la locul unde am început cu JPEG și PNG, oamenii ar putea ști că JPEG a fost creat pentru o compresie cu pierderi a fotografiilor. În general, obțineți un fișier mai mic de pe spatele acestuia și, uneori, poate avea diferite artefacte de bandă. PNG a fost creat inițial pentru o compresie fără pierderi, se descurcă destul de bine pe imaginile non-fotografice.

Addy Osmani: Dar de atunci lucrurile au evoluat. În jurul anului 2010, am început să obținem suport pentru WebP, care trebuia să înlocuiască JPEG și PNG și le bate puțin în compresie. Dar numărul de formate și opțiuni de imagine de pe masă tocmai a crescut vertiginos de atunci. Cred că lucrurile se îndreaptă în general într-o direcție bună, mai ales cu formatele moderne precum AVIF și JPEG XL. Dar ne-a luat ceva timp să ajungem aici. Chiar și obținerea suportului WebP în toate browserele a durat destul de mult.

Addy Osmani: Și cred că, în cele din urmă, ceea ce a influențat a fost să se asigure că dezvoltatorii au cerut acest lucru, au avut apetitul pentru a putea obține o compresie mai bună din aceste formate moderne și dorința de a avea doar o compatibilitate bună între browsere. și pentru aceste lucruri.

Drew McLellan: Da. WebP mi se pare foarte interesant, pentru că, pe lângă faptul că avem o compresie fără pierderi și cu pierderi disponibilă în format, avem, evident, o dimensiune a fișierului mult redusă ca rezultat. Și există un suport bun pentru browser și vedem adoptarea de la companii mari precum Google și Netflix și diverse companii mari.

Drew McLellan: Dar percepția mea în industrie este că nu vedem același tip de acceptare la nivel de bază. Mai așteaptă WebP să-și vină ziua?

Addy Osmani: Cred că aș spune că sosește WebP. Mulți oameni au așteptat ca suportul Safari și WebKit să se materializeze și, în sfârșit, avem asta. Dar când ne gândim la noile formate de imagine, este foarte important să înțelegem ce înseamnă de fapt suportul. Există suport pentru browser pentru decodarea acestor imagini. Avem nevoie, de asemenea, de un suport foarte bun pentru instrumente, astfel încât, indiferent dacă vă aflați într-un mediu nod, CDN de imagine, dacă vă aflați într-un CMS, aveți posibilitatea de a utiliza acele formate de imagine.

Addy Osmani: Îmi amintesc acum mulți ani când a apărut pentru prima dată WebP. Primii adoptatori au avut această problemă: ai salva fișierul WebP pe desktop și apoi brusc, „Oh, stai. Trebuie să trageți acest lucru în browserul meu pentru a-l vedea?,” sau, „Dacă utilizatorii mei descarcă WebP, vor rămâne blocați și se vor întreba ce se întâmplă?”

Addy Osmani: Așadar, să vă asigurați că există un suport destul de holistic pentru formatul de imagine, atât la nivel de sistem de operare, cât și în alt context, este foarte important, cred, pentru ca un format de imagine să descopere. De asemenea, este important ca persoanele care difuzează imagini să se gândească puțin la aceste cazuri de utilizare, astfel încât, dacă salvez sau descarc un fișier, să încercați să îl puneți într-un format portabil pe care oamenii îl pot partaja cu ușurință. Și cred că aici, cel puțin pe iOS, iOS are suport pentru o excursie și o cratimă. Și convertirea lucrurilor în format JPEG, atunci când este necesar, permite oamenilor să le partajeze.

Addy Osmani: Așadar, cred că este important să ne gândim la acele tipuri de cazuri de utilizare în care ne putem asigura că utilizatorii nu pierd în timp ce le oferim o compresie mai bună.

Drew McLellan: Am un serviciu de partajare de diapozitive pe care îl conduc și care, după cum vă puteți imagina, se ocupă cu sute de mii de imagini. Și când mă uitam la WebP, și asta probabil a fost acum trei ani, mă uitam în primul rând la o modalitate de a reduce costurile cu lățimea de bandă CDN, pentru că dacă serviți un fișier mai mic, vi se taxează mai puțin pentru a-l servi. Dar, deși încă aveam nevoie de o imagine cu spate, și de un format de imagine moștenit, calculele mele au arătat că costul stocării unui întreg alt set de imagini depășește beneficiile servirii unui fișier mai mic. Deci iată-ne în 2021. Este aceasta o decizie pe care ar trebui să o reconsider în acest moment?

Addy Osmani: Cred că este un aspect foarte important. Uneori, când vorbim despre modul în care ar trebui să abordezi strategia ta de imagine, este foarte ușor să le dai oamenilor un răspuns la nivel înalt: „Hei, da. Doar generați cinci formate diferite, iar acestea se vor scala la infinit.” Și nu este întotdeauna cazul.

Addy Osmani: Cred că atunci când trebuie să țineți cont de spațiul de stocare, uneori să încercați să găsiți care este cel mai bun numitor comun pentru a vă servi utilizatorii, merită să aveți în vedere. În zilele noastre, aș spune de fapt că WebP merită luat în considerare ca numitor comun. Pentru persoanele care au fost obișnuite să folosească eticheta de imagine pentru a difuza în mod condiționat diferite formate până la oameni, de obicei ați folosi un JPEG ca alternativă principală. Poate că în zilele noastre este în regulă să folosești WebP ca rezervă pentru majoritatea utilizatorilor, cu excepția cazului în care ai oameni care folosesc browsere foarte, foarte vechi. Și cred că vedem mult mai puțin din asta zilele astea. Dar cu siguranță aveți o oarecare flexibilitate acolo.

Addy Osmani: Acum, dacă încerci să fii orientat spre înainte, aș spune că alege un format care crezi că funcționează foarte bine. Dacă puteți aborda stocarea într-un mod care să se adapteze și să fie flexibil la nevoile dvs., ceea ce aș spune că oamenii ar trebui să facă este să ia în considerare JPEG XL. Din punct de vedere tehnic, încă nu se livrează într-un browser. Când o face, JPEG XL ar trebui să fie o opțiune destul de grozavă pentru o mulțime de fotografii în cazuri de utilizare cu pierderi sau fără pierderi sau, de asemenea, pentru cazuri de utilizare fără fotografii. Și probabil va fi mult mai bun decât WebP V1. Deci ăsta e un singur loc.

Addy Osmani: Cred că AVIF va fi probabil mai bun dacă trebuie să mergeți la rate de biți foarte mici. Poate îți pasă mult de lățimea de bandă. Poate vă pasă puțin de fidelitatea imaginii. Și la acele rate de biți, mi-aș putea imagina că arată mai clar decât unele dintre alternative. Și până când vom avea JPEG XL, aș încerca să arunc o privire asupra analizelor dvs. și să înțeleg dacă este posibil să furnizați AVIF. Altfel, m-aș concentra pe acel WebP. Dacă ați fi analytics, cred că majoritatea oamenilor pot primi servicii WebP și vă pasă puțin de suprapunerile cu gamă largă sau de text, locuri în care eșantionarea cromozomilor poate să nu fie perfectă în WebP. Acesta este cu siguranță ceva demn de reținut.

Addy Osmani: Așa că aș încerca să țin cont de faptul că nu va exista o dimensiune unică pentru toată lumea. Eu personal, în aceste zile, îmi fac puțin mai puține griji cu privire la costurile de stocare și de ieșire și de lățime de bandă, doar pentru că folosesc un CDN de imagine. Și mă bucur să spun că folosesc Cloudinary personal. Folosim o mulțime de CDN-uri diferite de imagini acolo unde lucrez. Dar am constatat că nu trebuie să-mi fac griji atât de mult cu privire la costurile de întreținere ale gestionării conductelor de imagine, ocupându-mă de modul în care voi suporta, cum ar fi „Oh, hei, iată încă un alt format de imagine sau noi tipuri de alternative sau noi API-uri web. ”, care a fost un beneficiu frumos pentru a investi în ceva care are grijă doar de asta pentru mine.

Addy Osmani: Și apoi costul total pentru cazurile mele de utilizare a fost ok. Dar îmi pot imagina pe deplin că, dacă rulați un serviciu de diapozitive la acea scară, s-ar putea să nu fie neapărat o opțiune.

Drew McLellan: Da. Așa că vreau să revin la unele dintre aceste formate viitoare viitoare. Dar cred că merită să cercetăm, deoarece cu orice fel de instrumente de performanță, Lighthouse sau WebPageTests, dacă vreunul dintre noi își rulează site-urile prin ele, unul dintre lucrurile cheie pe care le va sugera este că folosim un CDN pentru imagini. Și acesta este un lucru foarte realist de făcut pentru companii foarte mari. Este realist și la îndemâna oamenilor care construiesc site-uri web și aplicații mai mici sau este de fapt la fel de ușor de făcut pe cât pare?

Addy Osmani: Cred că întrebarea pe care ar trebui să o pună oamenii este: „Pentru ce folosești imaginile?” Dacă ai doar câteva imagini, dacă construiești un blog și imaginile pe care le adaugi sunt relativ simple, nu ai sute și sute sau mii de mii de imagini, s-ar putea să fii de acord să abordezi asta în timpul construirii, într-un mod foarte static, unde instalați câteva pachete NPM. Poate doar folosești Sharp. Și asta are grijă de tine în cea mai mare parte.

Addy Osmani: Există instrumente care vă pot ajuta să generați mai multe formate. Îți crește puțin timpul de construire, dar asta ar putea fi de fapt bine pentru mulți oameni. Și apoi pentru cei care doresc să poată folosi mai multe

Addy Osmani: Și apoi, pentru cei care doresc să poată folosi mai multe formate, nu vor să se ocupe de atât de multe detalii despre instrumente și vor să poată obține o imagine sau o poveste foarte bogată, receptivă, eu ar spune că încercați un CDN de imagine. Inițial, am fost destul de reticent în privința utilizării lui pentru proiecte personale pentru problemele legate de costuri, iar apoi, în timp, când m-am uitat la facturarea mea, mi-am dat seama că îmi economisește timp pe care altfel aș fi investit în rezolvarea acestor probleme. Nu știu cât de mult ați trebuit să scrieți scripturi personalizate pentru a vă ocupa de imaginile dvs. în trecut, dar mi-am dat seama dacă mă pot economisi cel puțin câteva zile de depanare prin aceste pachete npm diferite pe lună, atunci costurile. am grijă de timpul pe care îl economisesc și deci e în regulă.

Addy Osmani: Dar poate fi ceva în care dacă scalați la 100 de 1000 sau milioane de imagini și nu este ceva care este neapărat acoperit de veniturile dvs. sau nu este ceva pentru care sunteți pregătit să plătiți, trebuie să vă gândiți la strategii alternative. Și cred că suntem norocoși că avem suficientă flexibilitate cu instrumentele care ne sunt la dispoziție astăzi pentru a putea merge în oricare dintre aceste direcții, în care facem ceva un pic mai personalizat, o abordăm singuri sau rulăm. propria noastră imagine CDN sau investim în ceva ceva mai comercial. Și suntem într-un loc în care aș spune că, pentru unele cazuri de utilizare, da puteți folosi un CDN de imagine și este accesibil.

Drew McLellan: Cred că unul dintre principiile directoare este întotdeauna să fii agil și să fii pregătit pentru schimbare. Și ați putea începe să utilizați un CDN de imagine pentru a vă converti în mod dinamic imaginile pentru dvs., așa cum sunt solicitate, iar dacă acest lucru ajunge într-un punct în care nu este sustenabil din punct de vedere al costurilor, puteți căuta o altă soluție și puteți avea baza de cod într-o stare. unde va fi ușor să înlocuiți o soluție cu alta. Cred că, în general și oriunde te bazezi pe un serviciu terță parte, acesta este un principiu bun, nu-i așa? Deci, aceste formate de imagine viitoare, ați menționat JPEG XL. Ce este JPEG XL? De unde vine? Și ce face pentru noi?

Addy Osmani: Aceasta este o întrebare excelentă. Deci JPEG XL este un format de imagine de generație următoare, ar trebui să fie de uz general și este un codec de la comitetul JPEG. A început cu niște rădăcini în formatul pic al Google și apoi în formatul FUIF al lui Cloudinary. Au existat o mulțime de formate de-a lungul anilor care au fost într-un fel subsumate de acest efort, dar a devenit mult mai mult decât un fel de sumă a părților sale individuale, iar unele dintre beneficiile JPEG XL sunt că este grozav pentru înaltă fidelitate. imagini, foarte bune pentru fără pierderi, are suport pentru decodare progresivă, transcodare JPEG fără pierderi și, de asemenea, este un fel de tam-tam și fără drepturi de autor, ceea ce este cu siguranță un beneficiu. Cred că JPEG XL ar putea fi un candidat foarte puternic. Vorbeam mai devreme despre, dacă ar fi să alegi doar unul, ce ai folosi? Și cred că JPEG XL are potențialul de a fi acesta.

Addy Osmani: De asemenea, nu vreau să promit prea mult, suntem încă foarte devreme cu suportul pentru browser. Și deci cred că ar trebui să așteptăm și să vedem, să experimentăm și să evaluăm cât de bine se aliniază în practică și îndeplinește așteptările oamenilor, dar văd mult potențial cu JPEG XL atât pentru acele cazuri cu pierderi, cât și pentru acele cazuri fără pierderi. În acest moment, cred că Chrome este probabil cel mai avansat în ceea ce privește suportul, dar am văzut, de asemenea, un interes cu siguranță din partea Mozilla și a altor browsere în acest sens, așa că sunt încântat de viitorul cu JPEG XL. Și dacă ar fi să spunem, care este un termen și mai scurt de interes pentru oameni? Bineînțeles că există și AVIF.

Drew McLellan: Spune-ne despre AVIF, acesta este altul cu care nu sunt familiarizat.

Addy Osmani: Bine. Așa că am menționat puțin mai devreme despre AVIF că poate fi un candidat mai bun dacă trebuie să mergeți la rate de biți scăzute și vă pasă de lățimea de bandă mai mult decât de fidelitatea imaginii, ca principiu general, AVIF este într-adevăr lider în compresia cu atractivitate ridicată de joasă fidelitate. Și JPEG XL, ar trebui să exceleze la fidelitate medie spre înaltă, dar sunt formate ușor diferite în drepturi proprii. Ne aflăm într-un loc în care AVIF are un suport din ce în ce mai bun pentru browser, dar permiteți-mi să fac un pas înapoi și să vorbesc puțin mai mult despre format. Deci AVIF în sine se bazează pe codecul video AV1, care a fost standardizat de Alianța pentru Media Deschise și încearcă să obțină oamenilor câștiguri semnificative de compresie față de JPEG, față de WebP, despre care vorbeam mai devreme. Și deși economiile exacte pe care le puteți obține de la AVIF vor depinde de conținut și de obiectivele dvs. de calitate, am văzut o mulțime de cazuri în care poate oferi economii de peste 50% în comparație cu JPEG.

Addy Osmani: Are o mulțime de caracteristici bune, este capabil să vă ofere suport container pentru noi funcții, cum ar fi o gamă dinamică ridicată și o gamă largă de culori, sinteza granulelor de film. Și din nou, asemănător cu vorbirea despre a fi orientat spre înainte, unul dintre lucrurile frumoase despre eticheta de imagine este că ați putea servi utilizatorilor fișiere AVIF chiar acum și va reveni în continuare la WebP sau JPEG în cazurile în care nu este neapărat acceptat. . Dar revenind la exemplul dvs. despre Photoshop Save For Web, ați putea să luați un JPEG cu o dimensiune de 500 de kiloocteți, să încercați să fotografiați pentru o calitate similară cu Photoshop Save For Web și cu AVIF aș spune că probabil puteți ajunge la un punctul în care dimensiunea fișierului este de aproximativ 90 de kiloocteți, 100 de kiloocteți, deci o mulțime de economii fără pierderi reale de calitate.

Addy Osmani: Și unul dintre lucrurile frumoase despre asta este că, în mod ideal, nu vei vedea atâta pierdere a texturii în imaginile care au detalii bogate. Deci, dacă aveți fotografii cu păduri sau camping sau oricare dintre aceste tipuri de lucruri, ar trebui să arate în continuare foarte bogate cu AVIF. Așa că sunt destul de încântat de direcția pe care o are AVIF. Cred că are nevoie de ceva mai multă muncă în ceea ce privește suportul pentru scule. Așa că am renunțat la un tweet despre asta zilele trecute, avem o serie de opțiuni pentru utilizarea AVIF chiar acum, pentru imagini individuale avem Squoosh, squoosh.app, care este scris de o altă echipă în Chrome, așa că strigă lui Surma și Jake pentru că au lucrat la Squoosh. Avif.io are o serie de opțiuni bune pentru cei care încearcă să folosească AVIF astăzi, indiferent de stiva tehnologică pe care se concentrează, Sharp acceptă și AVIF.

Addy Osmani: Dar, în general, te gândești la alte locuri în care ne ocupăm de imagini, fie că este în Figma sau în Sketch sau în Photoshop sau în alte locuri, și aș spune că mai trebuie să lucrăm puțin în ceea ce privește Suport AVIF acolo, pentru că trebuie să fie omniprezent pentru dezvoltatori și utilizatori pentru a simți cu adevărat că a aterizat și vin acasă. Și acesta este unul dintre domeniile de atenție pentru noi, echipele care lucrează la AVIF în Chrome în acest moment, încercând să ne asigurăm că putem aduce instrumente într-un loc destul de bun.

Drew McLellan: Deci avem HTML, elementul imagine acum, care ne oferă mai multă flexibilitate față de eticheta tradițională de imagine. Deși eticheta de imagine a parcurs un drum lung, nu-i așa? Dar am văzut că se adaugă o imagine, era cam în același timp cu eticheta video nativă, cred că în acel tip de lot original de modificări HTML5. Și asta ne oferă posibilitatea de a specifica mai multe surse, nu-i așa?

Addy Osmani: Da, așa este.

Drew McLellan: Așa că puteți enumera diferite formate de imagini, iar browserul îl va alege pe cel pe care îl acceptă, ceea ce ne permite să fim destul de experimentali imediat, fără a fi nevoie să ne facem prea multe griji cu privire la distrugerea lucrurilor pentru persoanele cu browsere mai vechi.

Addy Osmani: Absolut. Cred că acesta este unul dintre cele mai frumoase beneficii ale utilizării etichetei imagine în afara cazurilor de utilizare în care ne gândim la direcția noastră, doar să putem oferi oamenilor o imagine și ca browserul să parcurgă lista de surse potențiale și să vedem, bine, Ei bine, îl voi folosi pe primul din acea listă pe care îl înțeleg, altfel mă voi întoarce, asta este o capacitate foarte puternică pentru oameni. Cred că, în același timp, i-am auzit și pe unii oameni care își exprimă îngrijorarea sau îngrijorarea că regenerăm cantități uriașe de markup acum, când încercăm să acceptăm mai multe formate și luați în considerare dimensiuni diferite pentru aceste formate și brusc devine un pic voluminos.

Addy Osmani: Există, deci, alte moduri prin care am putea aborda aceste probleme? Nu vreau să vând oamenii prea mult pe CDN-uri de imagine, vreau ca ei să stea pe cont propriu. Dar acesta este unul dintre acele locuri în care o idee numită negociere de conținut vă poate oferi de fapt o cale interesantă. Deci, am vorbit puțin despre eticheta de imagine în care trebuie să generați o grămadă de resurse diferite și să decideți asupra ordinii preferințelor, corect, HTML suplimentar. Cu negocierea conținutului, ceea ce spune este să facem toată munca pe server. Așadar, clienții pot spune serverului ce formate acceptă, prin intermediul listei de tipuri MIME prin antetul Accept HTTP. Apoi serverul poate face toată munca grea de a genera și gestiona resursele finale și de a decide pe care să le trimită clienților. Și unul dintre lucrurile puternice aici este că dacă utilizați un CDN de imagine, puteți indica o singură resursă.

Addy Osmani: Poate că dacă avem o imagine de cățeluș precum puppy.JPEG, le-am putea oferi oamenilor o adresă URL către puppy.JPEG și dacă browserul lor acceptă WebP sau acceptă un AVIF, serverul poate deveni foarte inteligent în ceea ce privește difuzarea corectă. imaginea acelor utilizatori, în funcție de cum arată suportul lor, dar, în caz contrar, retrageți fără să fiți nevoit să faceți o mulțime de muncă suplimentară. Acum, cred că este o idee puternică. Există multe lucruri pe care le puteți face pe server, uneori vorbim despre cum nu toată lumea are acces la o calitate foarte bună a rețelei, tipul de conexiune eficientă poate fi foarte diferit în funcție de locul în care vă aflați.

Addy Osmani: Chiar și locuind în Silicon Valley, aș putea merge de la o cafenea la un hotel sau aș putea fi în mașină, iar calitatea wifi-ului meu sau a semnalului meu ar putea să nu fie atât de grozav. Deci, aici aveți acces la alte API-uri, alte idei, cum ar fi indicația clientului Save-Data, pentru a putea servi oamenii cu resurse de dimensiuni și mai mici, dacă utilizatorul a optat pentru economisirea datelor. Deci, există o mulțime de lucruri interesante pe care le-am putea face pe partea de server și cred că ar trebui să continuăm să promovăm aceste idei de a găsi un echilibru frumos în care oamenii care se simt confortabil să urmeze calea pieței să aibă toată flexibilitatea necesară pentru a face acest lucru. iar oamenii care doresc o soluție ceva mai magică au, de asemenea, câteva opțiuni.

Drew McLellan: Conceptul acestui tip de abordare a economisirii datelor a fost ceva despre care am aflat mai întâi din cartea dumneavoastră. Adică, hai să intrăm puțin în asta pentru că este destul de interesant. Deci, vorbiți despre browser-ul care poate semnala o preferință pentru a dori o experiență de date redusă înapoi, deoarece poate este pe o conexiune contorizată sau are bateria scăzută sau ceva de genul.

Addy Osmani: Exact. Exact. Am călătorit în vremuri obișnuite sau în vremuri de dinainte, când am călători mult mai mult, am experimentat o mulțime de locuri din lume sau situații în care calitatea rețelei mele ar putea fi cu adevărat slabă sau foarte neregulată și, prin urmare, chiar și deschiderea o pagină web ar putea fi o experiență frustrantă sau dificilă. S-ar putea să caut un meniu și dacă nu pot vedea imagini cu mâncarea frumoasă pe care o au disponibilă, aș putea să merg undeva unde pot sau, nu știu, aș putea să-mi fac și eu niște mâncare. Dar cred că unul dintre lucrurile interesante despre economizorul de date este că vă oferă o conexiune înapoi la preferințele utilizatorului. Deci, dacă în calitate de utilizator, știu că îmi este greu cu conexiunea la rețea. Pot spune: „Bine, bine, voi opta pentru modul de economisire a datelor în browserul meu”.

Addy Osmani: Și apoi poți folosi asta ca dezvoltator ca un semnal pentru a spune: „Bine, ei bine, utilizatorul este puțin constrâns, poate le vom naviga pe imagini mult mai mici sau imagini de o calitate mult mai scăzută.” Dar ei încă ajung să vadă niște imagini, ceea ce este mai bine decât ei să aștepte mult timp să fie servit ceva mult mai bogat. Alte avantaje ale acestor tipuri de semnale sunt că le puteți utiliza pentru difuzarea condiționată a media. Deci, poate că există cazuri în care textul este cel mai important lucru din pagina respectivă, poate că puteți dezactiva acele imagini dacă descoperiți că utilizatorii se află într-un mediu restrâns. Voi petrece doar 30 de secunde pentru asta, dar poți să împingi această idee la extrem. Unele dintre lucrurile interesante pe care le puteți face cu Save-Data sunt poate chiar să dezactivați funcțiile foarte costisitoare implementate în JavaScript.

Addy Osmani: Dacă aveți anumite componente care sunt considerate puțin mai opționale, poate că acestea nu trebuie neapărat trimise tuturor utilizatorilor dacă doar îmbunătățesc experiența. Poți în continuare să ofere tuturor o experiență de bază, mică și rapidă, și apoi doar să o îmbraci cu niște glazură plăcută pentru persoanele care au o conexiune sau un dispozitiv mai rapid.

Drew McLellan: Potențial, cred că ar putea lua în considerare paginarea și ați putea returna 10 rezultate pe o pagină mai degrabă decât 100 și asemenea lucruri. Deci o mulțime de capabilități interesante, interesante acolo. Cred că suntem cu toții familiarizați cu procesul frustrant de a pregăti un nou site, de a vă optimiza toate imaginile, de a le preda clientului, de a le oferi un CMS pentru a gestiona conținutul și de a descoperi că doar înlocuiesc totul cu imagini slab optimizate. Adică, din nou, un CDN de imagine, cred, ar fi o soluție cu adevărat convenabilă pentru asta, dar există alte soluții, există lucruri pe care CMS-ul ar putea să le facă pe server pentru a ajuta la asta sau este probabil un CDN de imagine drum de urmat?

Addy Osmani: Cred că ceea ce am descoperit după cel puțin șase sau șapte ani în care am încercat să-i convingem pe toată lumea să-și optimizeze imaginile este că este o problemă grea în care unii oameni implicați în imagine ar putea fi puțin mai pricepuți din punct de vedere tehnic și poate fi confortabil. își construiesc propriile instrumente sau funcționează Lighthouse sau încercând alte instrumente pentru a le informa dacă există oportunități de îmbunătățire. Mi-ar plăcea să văd oameni folosind în mod constant lucruri precum Lighthouse pentru a prinde dacă aveți oportunități de a optimiza în continuare sau de a difuza imagini de dimensiunea potrivită, dar dincolo de aceasta, uneori întâlnim cazuri de utilizare în care oamenii care încarcă imagini s-ar putea să nu neapărat chiar să înțeleagă costul resurselor pe care le încarcă. De obicei, ne întâlnim cu asta și îmi voi cere scuze, nu voi chema oamenii prea mult, dar acesta este ceva cu care ne confruntăm chiar și cu blogul Google.

Addy Osmani: La fiecare două săptămâni pe blogul Google, vom avea pe cineva să încarce un GIF animat foarte mare de 20 sau 30 de megaocteți. Și nu mă aștept ca ei să știe că nu este o idee bună, ei încearcă să facă articolul să arate cool, foarte captivant și interactiv, dar publicul respectiv nu va ști neapărat să folosească instrumente sau să folosească ImageOptim. sau să folosești oricare dintre aceste alte instrumente și să documentezi astfel încât să le verifice, este cu siguranță o opțiune. Dar posibilitatea de a automatiza problema, cred că este foarte convingătoare și ne ajută să ajungem în mod constant într-un loc în care sperăm să echilibrăm nevoile tuturor utilizatorilor noștri de CMS, fie că sunt tehnici sau non-tehnic, de asemenea. ca nevoile utilizatorilor noștri.

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: Deci, dacă încerc să merg la un site de rețete, s-ar putea să-mi pese de modul în care arată rețeta și, așadar, ne pasă să ne asigurăm că imaginea de mare erou a rețetei este vizibilă pentru mine. Acum, elementul LCP se poate schimba în timp. Este foarte posibil ca la începutul încărcării, cel mai mare lucru să fie un titlu, dar pe măsură ce pagina continuă să se încarce, ar putea ajunge să fie o imagine mult mai mare sau un afiș.

Addy Osmani: Și atunci când încerci să optimizezi cea mai mare vopsea plină de conținut, există aproximativ patru lucruri pe care le poți face. Primul lucru este să vă asigurați că vă solicitați imaginea eroului cheie cât mai devreme posibil. În general, avem o serie de lucruri care sunt importante în pagină. Vrem să ne asigurăm că putem reda conținutul și aspectul paginii principale.

Addy Osmani: Pentru aspect, de obicei vorbim despre CSS. Deci, este posibil să utilizați CSS critic, CSS inline, în paginile dvs., doriți să evitați lucrurile care blochează randarea, dar atunci când vine vorba de imaginea dvs., în mod ideal ar trebui să solicitați acea imagine mai devreme. Poate că asta implică doar să ne asigurăm că browserul poate descoperi acea imagine cât mai devreme posibil în pagină, având în vedere că mulți dintre noi în prezent ne bazăm pe cadre.

Addy Osmani: Dacă nu utilizați neapărat SSR, randare pe server, dacă așteptați în browser să descoperiți unele dintre pachetele dvs. JavaScript, pachete pentru componente, indiferent dacă aveți o componentă pentru imaginea eroului sau imaginea produsului, dacă browserul trebuie să aștepte să preia, să analizeze, să execute, să compileze și să execute toate aceste fișiere diferite înainte de a putea descoperi imaginea, asta ar putea însemna că cea mai mare imagine cu conținut va dura ceva timp înainte de a putea fi descoperită.

Addy Osmani: Acum, dacă acesta este cazul, dacă vă aflați într-un loc în care imaginea este solicitată destul de târziu, puteți profita de o funcție de browser numită link rel preload pentru a vă asigura că browserul poate descoperi acea imagine cât mai devreme pe cat posibil. Acum, preîncărcarea este o capacitate cu adevărat puternică. De asemenea, este unul căruia trebuie să ai multă grijă. În zilele noastre, este foarte ușor să ajungeți într-un loc unde poate auziți că vă recomandăm preîncărcare pentru cheia dvs. -

Addy Osmani: Poate ați auzit că vă recomandăm preîncărcarea pentru imaginea eroului dvs. cheie, precum și scripturile cheie, precum și fonturile cheie. Și devine atât de mare și masiv să încerci să te asiguri că ordonezi lucrurile în ordinea corectă. Deci, imaginile LCP sunt cu siguranță un loc cheie demn de reținut pentru acest lucru.

Addy Osmani: Celălalt lucru, așa cum am menționat patru lucruri, celălalt lucru este să vă asigurați că utilizați setul sursă și un format de imagine modern eficient. Cred că acel set de surse este foarte puternic. De asemenea, văd, uneori, când oamenii îl folosesc, vor încerca să compenseze în exces și, poate, vor livra acolo 10 versiuni diferite de imagini pentru fiecare rezoluție posibilă. Tindem să descoperim, cel puțin în unele cercetări, că dincolo de trei după imagini, utilizatorilor le este foarte greu să spună care sunt diferențele pentru calitatea imaginii, claritate și detalii. Deci limitarea DPR, limitarea raportului de pixeli a dispozitivului, este cu siguranță o idee demnă de reținut.

Addy Osmani: Și apoi, pentru formatele moderne de imagine, am vorbit despre formate mai devreme, dar luați în considerare WebP-ul dvs., AVIF-ul dvs., JPEG XL. Evitați irosirea pixelilor. Este foarte important să existe o strategie bună pentru calitate. Și cred că există o mulțime de cazuri în care chiar și calitatea implicită poate fi uneori prea mare. Așa că aș experimenta cu încercarea de a reduce rata de biți, de a reduce setările de calitate și de a vedea cât de departe puteți duce lucrurile pentru utilizatorii dvs., menținând în același timp claritatea.

Addy Osmani: Și atunci când vorbim despre încărcare, unul dintre celelalte lucruri pe care eticheta de imagine a evoluat pentru a le suporta în ultimii doi ani este încărcarea leneșă. Deci, cu încărcarea echivalează cu leneș, nu mai trebuie să utilizați neapărat o bibliotecă JavaScript pentru a adăuga încărcare leneșă imaginilor dvs. Aruncă asta pe imaginea ta. Și în browserele Chrome și Firefox, veți putea încărca leneș acele imagini fără a fi nevoie să utilizați dependențe de la terți. Și asta e destul de frumos.

Addy Osmani: Deci, avem încărcare leneșă. Avem suport pentru alte lucruri precum decodarea sincronizată, dar voi continua lucrurile și voi vorbi foarte repede despre celelalte două valori vitale de bază.

Drew McLellan: Da, da.

Addy Osmani: Deci, scăpați de schimbările de aspect. Nimănui nu-i plac lucrurile să-i sar pe paginile lor. Simt că una dintre cele mai mari frustrări ale mele este că deschid o pagină web. Trec cu degetul peste un buton pe care vreau să dau clic și apoi deodată apar o grămadă de anunțuri sau imagini fără setare de dimensiuni sau alte lucruri. Și provoacă o experiență cu adevărat neplăcută.

Addy Osmani: Deci, schimbarea cumulată a aspectului încearcă să măsoare instabilitatea conținutului. Și de cele mai multe ori, lucrurile obișnuite care împing schimbările de aspect sunt imaginile sau alte elemente de pe pagina dvs. care pur și simplu nu au dimensiuni setate. Cred că acesta este unul dintre acele locuri în care este adesea simplu pentru oameni să stabilească dimensiunile imaginii. Poate că nu este ceva pentru care am făcut la fel de mult în istorie, dar cu siguranță ceva pentru care merită să-ți petreci timpul. În instrumente precum farul va încerca să vă ajute să colectați, cum ar fi care este lista de imagini de pe pagina dvs. care necesită dimensiuni? Deci poți merge și le poți seta.

Drew McLellan: Aveam să spun, acesta este un punct cu adevărat interesant, deoarece atunci când designul web responsive a devenit un lucru, cu toții ne-am uitat prin site-urile noastre și am eliminat dimensiunile imaginii, deoarece instrumentele pe care le aveam la dispoziție pentru a face această funcționare ne-au impus să nu facem. Nu au atribute de înălțime și lățime pe imaginile noastre. Dar asta e o idee proastă acum, nu-i așa?

Addy Osmani: Ceea ce este vechi este din nou nou. Aș spune că cu siguranță merită să setați dimensiuni pe imaginile dvs. Setați dimensiuni pentru anunțurile dvs., ramele pentru ochi, orice conținut dinamic care s-ar putea modifica în dimensiune merită să setați dimensiuni.

Addy Osmani: Și pentru cei care construiesc o experiență cu adevărat distractivă, există o expresie greșită, experiențe de aspect cu adevărat distractive în care poate trebuie să lucrați mai mult pe carduri responsive și altele asemenea; Aș lua în considerare utilizarea raportului de aspect CSS sau a casetelor de raport de aspect pentru a vă rezerva spațiul. Și asta poate completa setarea dimensiunilor pentru acele imagini, de asemenea, pentru a vă asigura că lucrurile sunt cât mai fixe posibil atunci când încercați să evitați schimbările de aspect.

Addy Osmani: Și apoi, în sfârșit, ultimul Core Web Vital este prima întârziere de intrare. Acesta este ceva la care oamenii nu se gândesc neapărat întotdeauna când vine vorba de imagini. Deci, este posibil ca imaginile să blocheze lățimea de bandă și CPU-ul unui utilizator la încărcarea paginii. Ele pot împiedica modul în care sunt încărcate alte resurse critice, în special pe conexiunile foarte lente sau pe dispozitivele mobile de gamă inferioară care pot duce la saturarea lățimii de bandă.

Addy Osmani: Așadar, prima întârziere de introducere este o valoare Core Web Vital care captează prima impresie a utilizatorilor despre interactivitatea și capacitatea de răspuns a unui site. Și astfel, prin reducerea utilizării procesorului de fir principal, prima întârziere de intrare poate fi, de asemenea, redusă la minimum. Deci, în general, evitați doar imaginile care ar putea provoca conflicte în rețea. Nu blochează randarea. Dar ele încă pot afecta indirect performanța dvs. de redare.

Drew McLellan: Putem face ceva cu imaginile pentru a le opri blocarea randării? Putem dezactiva cumva browserul în acea fază inițială pentru a ne permite să fim interactivi mai rapid?

Addy Osmani: Cred că este din ce în ce mai important în aceste zile să înțelegem bine secvența optimă de imagini pentru afișarea a ceva deasupra pliului. Știu că deasupra pliului este un termen supraîncărcat, dar ca în primul port de vizualizare al utilizatorului. De foarte multe ori putem ajunge să încercăm să solicităm o tonă întreagă de resurse, unele dintre ele fiind imagini, care nu sunt cu adevărat necesare pentru ceea ce utilizatorul va vedea imediat. Și aceștia tind să fie candidați grozavi pentru încărcare mai târziu în ciclul de viață al paginii, lucruri grozave pentru încărcare leneșă. Dar dacă solicitați o mulțime de imagini, cum ar fi o coadă întreagă de lucruri foarte devreme, acestea pot avea un impact potențial.

Drew McLellan: Da. Deci, vreau să spun, ați menționat încărcarea leneșă a imaginilor pe care istoricul le-a cerut o bibliotecă JavaScript, care are propriile ei dezavantaje, cred, din cauza modalităților istorice prin care browserele optimizează încărcarea imaginilor, unde este aproape imposibil să le opriți încărcarea imaginilor. , cu excepția cazului în care pur și simplu nu îi dai o sursă. Și dacă nu îi dați o sursă și apoi încercați să o corectați cu JavaScript după aceea, dacă acel JavaScript nu rulează, nu veți primi imagini. Deci, încărcarea leneșă, încărcarea leneșă nativă este un răspuns la toate acestea.

Addy Osmani: Da, absolut. Și cred că acesta este un loc în care am încercat să îmbunătățim în toate browserele, experiența nativă de încărcare leneșă în ultimul an. După cum știți, aceasta este una dintre acele caracteristici în care am livrat ceva devreme și putem profita de conversațiile cu lideri de gândire din industrie pentru a înțelege cum ar fi „Oh, hei, care sunt pragurile pe care le setați de fapt manual dacă utilizați dimensiuni leneșe sau dacă utilizați alte biblioteci de încărcare leneșă ale JavaScript?" Și apoi ne-am reglat pragurile pentru a încerca să ajungem într-un loc puțin mai aproape de ceea ce vă așteptați să fie.

Addy Osmani: Deci, în multe cazuri, puteți utiliza doar încărcarea leneșă nativă. Dacă aveți nevoie de ceva mult mai rafinat, dacă aveți nevoie de mult mai mult control asupra posibilității de a seta pragurile observatorului de intersecție, momentul în care browserul va solicita lucruri, vă sugerăm, în general, să mergeți și să folosiți o bibliotecă în acele cazuri. , doar pentru că încercăm să rezolvăm cazul de utilizare de 90%. Dar cei 10% sunt încă valabili. S-ar putea să fie oameni care au nevoie de ceva mai mult. Și astfel, pentru majoritatea oamenilor, sper că încărcarea nativă leneșă va fi suficient de bună pentru viitorul previzibil.

Drew McLellan: Cel mai mult, este gratuit. Un atribut simplu de adăugat și obțineți toată această funcționalitate gratuit, ceea ce este grozav. Dacă ar fi un lucru pe care ascultătorul nostru ar putea să-l facă, să plece și să-l facă pe site-ul său pentru a-și îmbunătăți optimizarea imaginii, care ar fi acesta? De unde ar trebui să înceapă?

Addy Osmani: Un loc bun pentru a începe este să înțelegeți cât de mare este această problemă pentru site-ul dvs. M-aș duce să verific fie farul, fie statisticile privind viteza plății. Du-te și rulează-l pe câteva dintre cele mai populare pagini ale tale și vezi doar ce iese. Dacă se pare că ai doar unul sau două lucruri mici de făcut, este fantastic. Poate ai putea pune ceva timp acolo.

Addy Osmani: Dacă există o listă lungă de lucruri de făcut, poate aruncați o privire la cele mai mari oportunități pe care le aveți acolo, lucruri care spun: „Oh, hei, ai putea economisi mai multe secunde dacă ai face asta. lucru." Și concentrează-ți energia acolo pentru început.

Addy Osmani: După cum am vorbit aici, instrumentele pentru formatele moderne de imagine s-au îmbunătățit în timp. CDN-urile de imagine pot fi cu siguranță demne de luat în considerare. Dar dincolo de asta, există o mulțime de pași mici pe care îi poți face. Uneori, dacă este un site suficient de mic, chiar dacă mergi și deschizi Squoosh, introducerea câteva dintre imaginile tale poate fi un punct de plecare excelent.

Drew McLellan: Acesta este un sfat solid. Acum știu că este o publicație uluitoare, dar chiar trebuie să te felicit pentru carte. Este atât de cuprinzător și foarte ușor de digerat. Cred că este o lectură cu adevărat valoroasă.

Drew McLellan: Așa că am învățat totul despre optimizarea imaginii. Despre ce ai învățat în ultima vreme, Addy?

Addy Osmani: Despre ce am învățat în ultima vreme? De fapt, pe un subiect puțin diferit, care are încă de-a face cu imaginile, așa că, atunci când îmi făceam masterul la facultate, m-am adâncit în viziunea computerizată și am încercat să înțeleg cum putem detecta diferite părți ale unei imagini și să facem sălbăticie și lucruri interesante cu ei?

Addy Osmani: Și o problemă specifică în care am săpat recent este că m-am uitat la poze cu mine când eram copil sau copil. Și pe atunci, o mare parte din mâncarea pe care o luau părinții mei nu era neapărat pe camere digitale. Erau Polaroid. Sunt adesea imagini cu rezoluție oarecum scăzută. Și mi-am dorit o modalitate de a le putea extinde. Și așa am început să sapă din nou în această problemă recent. Și m-a determinat să învăț mult mai multe despre ce pot face în browser.

Addy Osmani: Așa că am dezvoltat câteva instrumente mici care vă permit, folosind învățarea automată, folosind TensorFlow, folosind tehnologiile existente, să faceți o imagine sau o ilustrație cu rezoluție relativ scăzută și apoi să le măriți la ceva de o calitate mult mai bună. Așa că este mai bine decât pur și simplu ca întinderea imaginii. Este ca și cum ai completa cu detalii.

Addy Osmani: Și asta a fost cam distractiv. Am învățat multe despre cât de stabil este acum asamblarea web în browser, cât de bine puteți folosi unele dintre aceste idei pentru cazurile de utilizare a aplicațiilor desktop. Și asta a fost foarte distractiv. Așa că am săpat în multe asamblare web recent. Și asta a fost cool.

Drew McLellan: E amuzant, nu-i așa? Când apare o tehnologie care dă peste cap tot ce știi. Întotdeauna am spus că pe web putem face imagini mai mici. Dar dacă avem doar o imagine mică, nu o putem mări. Este doar imposibil. Dar acum avem tehnologie care, în multe circumstanțe, ar putea face acest lucru posibil. Este cu adevărat fascinant.

Drew McLellan: Dacă, dragă ascultător, ați dori să aflați mai multe de la Addie, îl puteți găsi pe Twitter unde este @AddieOsmani și găsiți toate proiectele sale legate de AddyOsmani.com. Cartea „Image Optimization” este disponibilă atât fizic, cât și digital de la Smashing chiar acum la smashingmagazine.com. Îți mulțumim că ești alături de noi astăzi, Addy. Ai cuvinte de despărțire?

Addy Osmani: Vreo cuvinte de despărțire? Am o mică ciudatenie din istorie pe care o voi împărtăși oamenilor. Tim Berners-Lee a încărcat prima imagine pe internet în 1992. Nu sunt sigur dacă poți ghici ce a fost, dar probabil vei fi surprins. Drew, ai vreo ghicire?

Drew McLellan: Bănuiesc că o pisică.

Addy Osmani: O pisică. Este o presupunere bună, dar nu. Asta a fost la CERN. Iar imaginea era de fapt a unei trupe numită Les Horribles Cernettes, care era o trupă pop parodie formată dintr-o grămadă de angajați ai CERN. Iar muzica pe care ar face-o este ca muzica doo-wop. Și cântau cântece de dragoste despre ciocnitori și ciudatenii și azot lichid și antimaterie purtând ținute din anii șaizeci, pe care le-am găsit doar minunate și întâmplătoare.