Smashing Podcast Episodio 39 con Addy Osmani: ottimizzazione dell'immagine
Pubblicato: 2022-03-10Questo episodio è stato gentilmente supportato dai nostri cari amici di Storyblok che aiutano le persone a fornire potenti esperienze di contenuti su qualsiasi piattaforma: siti Web aziendali, siti di e-commerce, app mobili e display. Grazie!
Nella puntata di oggi dello Smashing Podcast, si parla di ottimizzazione delle immagini. Quali passaggi dovremmo seguire per immagini performanti nel 2021? Ho parlato con l'esperto Addy Osmani per scoprirlo.
Mostra note
- "Ottimizzazione dell'immagine", Addy Osmani
- Addi su Twitter
- Sito personale di Addy
Aggiornamento settimanale
- Meet :has, un selettore genitore CSS nativo (e altro)
scritto da Adrian Bece - Tre strumenti di auditing front-end che ho scoperto di recente
scritto da Stefan Judis - Utili piastre caldaia e kit di avviamento
scritto da Cosima Mielke - Web Design fatto bene: utilizzare l'audio
scritto da Frederick O'Brien - Quando i CSS non bastano: requisiti JavaScript per componenti accessibili
scritto da Stephanie Eckles
Trascrizione
Drew McLellan: È un responsabile tecnico che lavora su Google Chrome, dove il suo team si concentra sulla velocità, contribuendo a mantenere il Web veloce. Dedicato alla comunità open source, i suoi contributi passati includono Lighthouse, Workbox, Yeoman, Critical e to do NVC. Quindi sappiamo che sa come ottimizzare le prestazioni web. Ma lo sapevate che vuole vincere l'Oscar come migliore attrice non protagonista a causa di un errore materiale? Miei formidabili amici, vi prego di dare il benvenuto ad Addy Osmani. Ciao, Addy. Come stai?
Addy Osmani: Sto distruggendo.
Drew McLellan: È bello sentirlo. Volevo parlarvi oggi delle immagini sul web. È un'area in cui c'è stata una quantità sorprendente di cambiamenti e innovazioni negli ultimi anni, e hai appena scritto un libro molto completo sull'ottimizzazione delle immagini per Smashing. Qual è stata la motivazione a pensare in questo momento: "Ora è il momento per un libro sull'ottimizzazione delle immagini?"
Addy Osmani: Questa è un'ottima domanda. Penso che sappiamo che le immagini sono state una parte fondamentale del web per decenni e che i nostri cervelli sono in grado di interpretare le immagini molto più velocemente del testo. Ma questo argomento generale è quello che continua a diventare sempre più interessante e più sfumato nel tempo. E dico sempre alla gente che questo è probabilmente, credo, il mio terzo o quarto libro. Non ho mai deciso intenzionalmente di scrivere un libro.
Addy Osmani: Ho iniziato questo libro scrivendo un articolo sull'ottimizzazione delle immagini, e poi col tempo ho scoperto di aver scritto per sbaglio un intero libro al riguardo. Abbiamo lavorato a questo progetto per circa due anni. E anche in quel periodo, l'industria ha fatto evolvere i browser e gli strumenti relativi alle immagini e ai formati di immagine si sono evoluti.
Addy Osmani: E così ho scritto questo libro perché ho trovato difficile rimanere al passo con tutti questi cambiamenti. E ho pensato: "Sarò un buon cittadino del web e cercherò di tenere traccia di tutto ciò che ho imparato in un unico posto in modo che tutti gli altri possano trarne vantaggio".
Drew McLellan: Penso che sia una di quelle aree, con molta ottimizzazione delle prestazioni nel browser, è un panorama in rapido cambiamento, vero? Laddove una tecnica che hai appreso è attuale e rappresenta la migliore pratica, si verifica un cambiamento tecnologico e poi scopri che in realtà è un anti-modello e non dovresti farlo. E cercare di mantenere elevate le tue conoscenze e assicurarti di leggere gli articoli giusti e di imparare le cose giuste e di non leggere qualcosa di due anni fa è piuttosto difficile.
Drew McLellan: Quindi avere tutto raccolto in un libro ben studiato da una fonte autorevole è davvero straordinario.
Addy Osmani: Sì. Anche dal punto di vista di un autore, una delle cose più interessanti e forse una delle più stressanti per la nostra redazione era che consegnavo un capitolo e dicevo che era fatto. E poi due settimane dopo, qualcosa sarebbe cambiato in un browser e io avrei detto: "Oh, aspetta. Devo fare un altro cambiamento dell'ultimo minuto".
Addy Osmani: Ma il panorama dell'immagine si è evoluto parecchio, anche nell'ultimo anno. Abbiamo visto che il supporto WebP ha finalmente raggiunto il traguardo nella maggior parte dei browser moderni. Il supporto delle immagini AVIF è in Chrome, in arrivo su Firefox, JPEG XL, caricamento lento. E su tutta la linea, abbiamo visto miglioramenti nel modo in cui puoi utilizzare le immagini sul Web in modo abbastanza concreto nei browser. Ma ancora una volta, c'è molto da tenere sotto controllo per la gente.
Drew McLellan: Alcune persone potrebbero considerare l'argomento dell'ottimizzazione delle immagini come un argomento piuttosto serio. Tutti, a un certo punto della nostra carriera, abbiamo imparato a esportare per il web dal nostro software di grafica. E alcuni di noi potrebbero avere l'abitudine di prendere quelle immagini esportate ed eseguirle attraverso qualcosa come ImageOptim.
Drew McLellan: Quindi potremmo sapere che dovremmo scegliere un JPEG quando è un'immagine fotografica e un PNG quando è un'immagine basata su grafica e pensare che: "Okay, è tutto. Conosco l'ottimizzazione delle immagini, ho finito." Ma in realtà, quelle cose sono solo puntate da tavolo, non è vero, a questo punto?
Addy Osmani: Sì, lo sono. Penso che la nostra capacità di mostrare immagini e immagini più dettagliate e nitide anche in un contesto diverso, a seconda che ti interessi o meno alla direzione artistica, si sia evoluta nel tempo. Penso che la necessità di capire come ottenere quelle immagini belle come destinate ai tuoi utenti finali, tenendo presente il loro ambiente, i loro vincoli sui dispositivi, i loro vincoli di rete sia un problema difficile e qualcosa che conosco ancora molte persone lottare con.
Addy Osmani: E quindi quando si tratta di pensare alle immagini e ottenere una versione leggermente più raffinata di questo oltre a "Ehi, usiamo un JPEG" o "Usiamo un PNG", penso che ci siano alcune dimensioni in questo valore tenere a mente. Il primo è solo generalmente la compressione. Hai menzionato ImageOptim e molti di noi sono abituati a trascinare semplicemente un'immagine in un punto e ottenere qualcosa di più piccolo dal retro.
Addy Osmani: Ora, quando si tratta di compressione, di solito si parla di codec diversi. E i codec sono una tecnologia di compressione che di solito ha un componente codificatore per codificare i file e un componente decodificatore per decodificarli e decomprimerli. E quando arrivi a decidere se stai usando qualcosa, in genere devi pensare se le foto o le immagini che stai usando vanno bene per avvicinarti usando un approccio di compressione con perdita o un approccio con perdita di meno.
Addy Osmani: Nel caso in cui le persone non abbiano la stessa familiarità con questi concetti, un approccio senza perdita di dati è quello in cui riproduci lo stesso identico file alla fine della decompressione. Quindi non stai davvero perdendo molto in termini di qualità. Lossless è molto di più mettere la tua immagine attraverso un fax. Ottieni un facsimile dell'originale e non sarà il file originale. Potrebbero esserci degli artefatti diversi lì. Potrebbe sembrare leggermente diverso. Ma in termini generali, più comprimi, maggiore è la qualità che in genere perdi.
Addy Osmani: E così, con tutti questi moderni codec di immagine, stanno cercando di vedere quanta qualità puoi spremere pur mantenendo una dimensione del file relativamente decente, a seconda del caso d'uso.
Drew McLellan: Quindi, dal punto di vista tecnologico, hai un'immagine sorgente e poi hai il formato del file di destinazione. Ma il processo di trasformazione dell'uno nell'altro è aperto al dibattito. Finché hai un file conforme, il modo in cui lo fai dipende da un codec che può avere molte implementazioni diverse e alcune saranno migliori di altre.
Addy Osmani: Assolutamente. Assolutamente. E penso che, ancora una volta, tornando da dove abbiamo iniziato con JPEG e PNG, la gente potrebbe sapere che il JPEG è stato creato per una compressione con perdita di foto. In genere si ottiene un file più piccolo sul retro e a volte può avere diversi artefatti di banding. PNG è stato originariamente creato per una compressione senza perdita di dati, funziona abbastanza bene su immagini non fotografiche.
Addy Osmani: Ma da allora le cose si sono evolute. Intorno al 2010, abbiamo iniziato a ottenere il supporto per WebP, che avrebbe dovuto sostituire JPEG e PNG e li batte un po' in compressione. Ma il numero di formati di immagine e opzioni sul tavolo è appena salito alle stelle da allora. Penso che le cose stiano andando generalmente in una buona direzione, specialmente con i formati moderni come AVIF e JPEG XL. Ma ci è voluto un po' per arrivare qui. Anche ottenere il supporto WebP su tutti i browser ha richiesto un po' di tempo.
Addy Osmani: E penso che alla fine ciò che ha influenzato è stato assicurarsi che gli sviluppatori lo chiedessero, avessero l'appetito per essere in grado di ottenere una migliore compressione da questi formati moderni e il desiderio di avere una buona compatibilità tra i browser anche per queste cose.
Drew McLellan: Sì. WebP mi sembra davvero interessante, perché oltre ad avere una compressione lossless e lossy disponibile all'interno del formato, ovviamente abbiamo una dimensione del file molto ridotta di conseguenza. E c'è un buon supporto per i browser e vediamo l'adozione da parte di grandi aziende come Google e Netflix e varie grandi aziende.
Drew McLellan: Ma la mia percezione nel settore è che non vediamo lo stesso tipo di adozione a livello di base. WebP sta ancora aspettando che arrivi il suo giorno?
Addy Osmani: Penso che direi che WebP sta arrivando. Molte persone hanno aspettato che il supporto di Safari e WebKit si materializzasse e finalmente l'abbiamo. Ma quando pensiamo a nuovi formati di immagine, è molto importante capire cosa significa effettivamente supporto. C'è il supporto del browser per la decodifica di quelle immagini. Abbiamo anche bisogno di un ottimo supporto per gli strumenti in modo che, sia che ti trovi in un ambiente di nodi, CDN di immagini, se ti trovi in un CMS, tu abbia la possibilità di utilizzare quei formati di immagine.
Addy Osmani: Ricordo molti anni fa quando WebP uscì per la prima volta. I primi utenti avevano il problema di salvare il file WebP sul desktop e poi improvvisamente: "Oh, aspetta. Devo trascinarlo nel mio browser per visualizzarlo?" oppure "Se i miei utenti stanno scaricando WebP, si bloccheranno e si chiederanno cosa sta succedendo?"
Addy Osmani: E quindi assicurarsi che ci sia un supporto abbastanza olistico per il formato dell'immagine sia a livello di sistema operativo che in altri contesti è davvero importante, penso, per far decollare un formato immagine. È anche importante che le persone che forniscono immagini riflettano un po' su questi casi d'uso in modo che, se sto salvando o scaricando un file, stai cercando di metterlo in un formato portatile che le persone possono generalmente condividere facilmente. E penso che sia qui che, almeno su iOS, iOS ha il supporto per un'escursione e un trattino. E convertire le cose in JPEG quando necessario consente alle persone di condividerle.
Addy Osmani: Penso che sia importante pensare a quei tipi di casi d'uso in cui possiamo assicurarci che gli utenti non perdano risultati mentre forniamo loro una migliore compressione.
Drew McLellan: Ho un servizio di condivisione diapositive che gestisco che, come puoi immaginare, gestisce centinaia di migliaia di immagini. E quando stavo guardando WebP, e probabilmente tre anni fa, stavo principalmente cercando un modo per ridurre i costi della larghezza di banda CDN, perché se stai servendo un file più piccolo, ti viene addebitato meno per servirlo. Ma mentre avevo ancora bisogno di un'immagine di terzino, anche di un formato immagine legacy, i miei calcoli hanno mostrato che il costo di archiviazione di un intero altro set di immagini superava i vantaggi di servire un file più piccolo. Quindi eccoci nel 2021. È una decisione che dovrei riconsiderare a questo punto?
Addy Osmani: Penso che sia una considerazione davvero importante. A volte, quando parliamo di come dovresti affrontare la tua strategia di immagine, è molto facile dare alle persone una risposta di alto livello: "Ehi, sì. Basta generare cinque formati diversi e questo si ridimensionerà all'infinito". E non è sempre così.
Addy Osmani: Penso che quando devi tenere a mente lo spazio di archiviazione, a volte vale la pena tenere a mente cercare di trovare il denominatore migliore e più comune per servire i tuoi utenti. In questi giorni, direi che vale la pena considerare WebP come quel denominatore comune. Per le persone che sono state abituate a utilizzare il tag immagine per servire in modo condizionale formati diversi fino alle persone, in genere utilizzeresti un JPEG come riserva principale. Forse va bene in questi giorni utilizzare effettivamente WebP come riserva per la maggior parte degli utenti, a meno che tu non abbia persone che utilizzano browser molto, molto vecchi. E penso che ne stiamo vedendo molto meno in questi giorni. Ma hai sicuramente una certa flessibilità lì.
Addy Osmani: Ora, se stai cercando di essere rivolto in avanti, direi di scegliere un formato che ritieni funzioni davvero bene. Se puoi avvicinarti allo storage in un modo che sia scalabile e flessibile alle tue esigenze, quello che direi che le persone dovrebbero fare è considerare JPEG XL. Tecnicamente non viene ancora spedito in un browser. Quando lo fa, JPEG XL dovrebbe essere un'ottima opzione per molte foto in casi d'uso con o senza perdita di dati o anche per casi d'uso non fotografici. E probabilmente sarà molto meglio di WebP V1. Quindi questo è un posto.
Addy Osmani: Penso che AVIF sarà probabilmente migliore se hai bisogno di andare a bit rate davvero bassi. Forse ti interessa molto la larghezza di banda. Forse ti interessa un po' meno la fedeltà dell'immagine. E a quei bit rate, potrei immaginarlo più nitido di alcune delle alternative. E finché non avremo JPEG XL, proverei a dare un'occhiata alle tue analisi e capire se è possibile per te servire l'AVIF. Altrimenti, mi concentrerei su quel WebP. Se fossi analitica, immagino che la maggior parte delle persone possa essere servita da WebP e che ti preoccupi un po' meno di wide-gamut o overlay di testo, luoghi in cui il campionamento cromosomico potrebbe non essere perfetto in WebP. È sicuramente qualcosa che vale la pena tenere a mente.
Addy Osmani: Quindi cercherei di tenere a mente che non ci sarà una taglia unica per tutti. Personalmente, in questi giorni, mi preoccupo un po' meno dei costi di archiviazione, uscita e larghezza di banda, solo perché utilizzo una CDN di immagini. E sono felice di dire che uso personalmente Cloudinary. Utilizziamo molte CDN di immagini diverse nel luogo in cui lavoro. Ma ho scoperto che non dovevo preoccuparmi tanto dei costi di manutenzione per gestire le pipeline di immagini, occupandomi di come supporterò come "Oh, ehi, ecco ancora un altro formato di immagine o nuovi tipi di fallback o nuove API Web ”, è stato un bel vantaggio investire in qualcosa che se ne prende cura per me.
Addy Osmani: E poi il costo complessivo per i miei casi d'uso è andato bene. Ma posso assolutamente immaginare che se stai eseguendo un servizio di diapositive su quella scala, anche questa potrebbe non essere necessariamente un'opzione.
Drew McLellan: Sì. Quindi voglio tornare su alcuni di questi imminenti formati futuri. Ma penso che valga la pena approfondire, perché con qualsiasi tipo di strumento per le prestazioni, Lighthouse o WebPageTests, se qualcuno di noi esegue i nostri siti attraverso di esso, una delle cose chiave che suggerirà è che usiamo una CDN per le immagini. E questa è una cosa molto realistica da fare per le aziende molto grandi. È realistico e alla portata delle persone che creano siti Web e app più piccoli, o in realtà è così facile da fare come sembra?
Addy Osmani: Penso che la domanda che le persone dovrebbero porre sia: "Per cosa stai usando le immagini?" Se hai solo poche immagini, se stai costruendo un blog e le immagini che stai aggiungendo sono relativamente semplici, non hai centinaia e centinaia o migliaia di migliaia di immagini, potresti essere d'accordo semplicemente avvicinandoti a questo in fase di compilazione, in modo molto statico, in cui installi un paio di pacchetti NPM. Forse stai solo usando Sharp. E questo si prende cura di te per la maggior parte.
Addy Osmani: Ci sono strumenti che possono aiutarti a generare più formati. Aumenta un po' il tempo di costruzione, ma in realtà potrebbe andare bene per molte persone. E poi per le persone che vogliono essere in grado di sfruttare molteplici-
Addy Osmani: E poi per le persone che vogliono essere in grado di sfruttare più formati, non vogliono occuparsi della minuzia degli strumenti e vogliono essere in grado di ottenere un'immagine o una storia reattiva davvero ricca, io direi di provare un CDN di immagini. Personalmente ero piuttosto reticente nell'usarlo per progetti personali per problemi di costi inizialmente, e poi nel tempo, quando ho dato un'occhiata alla mia fatturazione, mi sono reso conto che mi sta facendo risparmiare tempo che altrimenti avrei investito nell'affrontare questi problemi da solo. Non so quanto hai dovuto scrivere script personalizzati per gestire le tue immagini in passato, ma mi sono reso conto che se posso risparmiare almeno un paio di giorni di debug con questi diversi pacchetti npm al mese, allora i costi prenditi cura del tempo che sto risparmiando e quindi va bene.
Addy Osmani: Ma può essere qualcosa per cui se stai ridimensionando a 100 di 1000 o milioni di immagini e non è qualcosa che è necessariamente coperto dalle tue entrate o non è qualcosa per cui sei disposto a pagare, devi pensare a strategie alternative. E penso che siamo fortunati ad avere abbastanza flessibilità con gli strumenti a nostra disposizione oggi per poter andare in una di queste direzioni, dove facciamo qualcosa di un po' più personalizzato, lo affrontiamo da soli o rotoliamo la nostra immagine CDN o investiamo in qualcosa di leggermente più commerciale. E siamo a un punto in cui direi che per alcuni casi d'uso, sì, puoi usare un CDN di immagini ed è conveniente.
Drew McLellan: Immagino che uno dei principi guida sia sempre quello di essere agili ed essere preparati al cambiamento. E potresti iniziare a utilizzare un CDN di immagini per convertire dinamicamente le tue immagini per te come richiesto, e se ciò arriva a un punto in cui non è sostenibile dal punto di vista dei costi, puoi guardare un'altra soluzione e avere la tua base di codice in uno stato dove sarà facile sostituire una soluzione con un'altra. Penso che in generale e ovunque ti affidi a un servizio di terze parti, è un buon principio da avere, vero? Quindi, questi imminenti formati di immagine, hai menzionato JPEG XL. Cos'è JPEG XL? Da dove viene? E cosa fa per noi?
Addy Osmani: Questa è un'ottima domanda. Quindi JPEG XL è un formato immagine di nuova generazione, dovrebbe essere generico ed è un codec del comitato JPEG. È iniziato con alcune radici nel formato immagine di Google e poi nel formato FUIF di Cloudinary. Ci sono stati molti formati nel corso degli anni che sono stati in qualche modo inclusi in questo sforzo, ma è diventato molto più della semplice somma delle sue singole parti e alcuni dei vantaggi di JPEG XL sono che è ottimo per l'alta fedeltà immagini, davvero buono per senza perdita di dati, ha il supporto per la decodifica progressiva, la transcodifica JPEG senza perdita di dati ed è anche un po 'senza complicazioni e royalty, il che è sicuramente un vantaggio. Penso che JPEG XL potrebbe potenzialmente essere un candidato davvero forte. Stavamo parlando prima, se dovessi sceglierne solo uno, cosa useresti? E penso che il JPEG XL abbia il potenziale per essere quello.
Addy Osmani: Inoltre, non voglio esagerare, siamo ancora molto presto con il supporto del browser. E quindi penso che dovremmo davvero aspettare e vedere, sperimentare e valutare quanto bene si allinea nella pratica e soddisfa le aspettative delle persone, ma vedo molto potenziale con JPEG XL sia per quei casi con perdita che per quelli senza perdita. In questo momento, credo che Chrome sia probabilmente il più avanti in termini di supporto, ma ho anche visto sicuramente l'interesse da parte di Mozilla e di altri browser in questo, quindi sono entusiasta del futuro con JPEG XL. E se dovessimo dire, qual è il termine ancora più breve di interesse per la gente? Ovviamente c'è anche l'AVIF.
Drew McLellan: Parlaci di AVIF, questo è un altro che non conosco.
Addy Osmani: Va bene. Quindi abbiamo menzionato un po 'prima che AVIF potrebbe essere un candidato migliore se devi andare a velocità in bit basse e ti preoccupi della larghezza di banda più della fedeltà dell'immagine, come principio generale, AVIF è davvero all'avanguardia nella compressione ad alto appeal a bassa fedeltà. E JPEG XL, dovrebbe eccellere nella fedeltà medio-alta, ma sono formati leggermente diversi a pieno titolo. Siamo a un punto in cui AVIF ha un supporto per i browser sempre più buono, ma permettetemi di fare un passo indietro e parlare un po' di più del formato. Quindi lo stesso AVIF si basa sul codec video AV1, che è stato standardizzato dall'Alliance for Open Media, e cerca di ottenere significativi guadagni di compressione rispetto a JPEG, su WebP, di cui stavamo parlando prima. E mentre l'esatto risparmio che puoi ottenere da AVIF dipenderà dal contenuto e dai tuoi obiettivi di qualità, abbiamo visto molti casi in cui può offrire risparmi di oltre il 50% rispetto a JPEG.
Addy Osmani: Ha molte buone funzionalità, è in grado di darti supporto contenitore per nuove funzionalità come gamma dinamica elevata e ampie gamme di colori, sintesi della grana della pellicola. E ancora, in modo simile al parlare di essere rivolti in avanti, una delle cose belle del tag immagine è che potresti offrire agli utenti file AVIF in questo momento e tornerà comunque al tuo WebP o al tuo JPEG nei casi in cui non è necessariamente supportato . Ma tornando al tuo esempio su Photoshop Save For Web, potresti prendere un JPEG di 500 kilobyte, provare a scattare con una qualità simile a Photoshop Save For Web e con AVIF direi che probabilmente sarai in grado di ottenere un punto in cui la dimensione del file è di circa 90 kilobyte, 100 kilobyte, quindi un bel po' di risparmi senza una reale perdita di qualità distinguibile.
Addy Osmani: E una delle cose belle di questo è che idealmente non vedrai così tanta perdita di texture in nessuna immagine che ha dettagli ricchi. Quindi, se hai foto di foreste o campeggi o uno di questi tipi di cose, dovrebbero comunque sembrare davvero ricche con AVIF. Quindi sono piuttosto entusiasta della direzione che ha l'AVIF. Penso che abbia bisogno di un po' più di lavoro in termini di supporto per gli strumenti. Quindi ho pubblicato un tweet su questo l'altro giorno, abbiamo una serie di opzioni per utilizzare AVIF in questo momento, per le singole immagini abbiamo Squoosh, squoosh.app, che è scritto da un altro team in Chrome, quindi grida a Surma e Jake per aver lavorato su Squoosh. Avif.io ha una serie di buone opzioni per le persone che stanno cercando di utilizzare AVIF oggi, indipendentemente dallo stack tecnologico su cui si concentrano, Sharp supporta anche AVIF.
Addy Osmani: Ma poi generalmente pensi ad altri luoghi in cui trattiamo le immagini, che siano in Figma o in Sketch o in Photoshop o in altri posti, e direi che dobbiamo ancora lavorare un po' in termini di L'AVIF supporta lì, perché deve essere onnipresente affinché sviluppatori e utenti si sentano davvero come se fosse atterrato e torni a casa. E questa è una delle aree di interesse per noi con i team che lavorano su AVIF in Chrome al momento, cercando di assicurarci di poter portare gli strumenti a un posto abbastanza buono.
Drew McLellan: Quindi ora abbiamo in HTML, l'elemento immagine, che ci dà maggiore flessibilità rispetto al tradizionale tag immagine. Anche se anche il tag dell'immagine ha fatto molta strada, non è vero? Ma abbiamo visto l'aggiunta di un'immagine, era più o meno nello stesso periodo del tag video nativo, penso in quella sorta di batch originale di modifiche HTML5. E questo ci dà la possibilità di specificare più fonti, giusto?
Addy Osmani: Sì, è vero.
Drew McLellan: Quindi puoi elencare diversi formati di immagini e il browser sceglierà quello che supporta, e questo ci consente di essere subito abbastanza sperimentali senza doverci preoccupare troppo di rompere le cose per le persone con browser meno recenti.
Addy Osmani: Assolutamente. Penso che sia uno dei più bei vantaggi dell'uso del tag immagine al di fuori dei casi d'uso in cui stiamo pensando alla nostra direzione, essere semplicemente in grado di offrire alle persone un'immagine e fare in modo che il browser esamini l'elenco delle potenziali fonti e veda, ok, bene, userò il primo in quell'elenco che capisco, altrimenti tornerò indietro, questa è una capacità davvero potente per la gente. Penso che allo stesso tempo, ho anche sentito alcune persone esprimere qualche preoccupazione o qualche preoccupazione sul fatto che stiamo rigenerando enormi blocchi di markup ora quando stiamo cercando di supportare più formati e si tiene conto di dimensioni diverse per quei formati e improvvisamente diventa un po' ingombrante.
Addy Osmani: Quindi ci sono altri modi in cui potremmo affrontare questi problemi? Non voglio vendere troppo alle persone con CDN di immagini, voglio che stiano in piedi da sole. Ma questo è uno di quei luoghi in cui un'idea chiamata negoziazione dei contenuti può effettivamente offrirti un percorso interessante. Quindi, abbiamo parlato un po' del tag immagine in cui devi generare un sacco di risorse diverse e decidere l'ordine di preferenza, giusto, HTML extra. Con la negoziazione dei contenuti, quello che dice è facciamo tutto questo lavoro sul server. Quindi i client possono dire al server quali formati supporta in anticipo tramite l'elenco dei tipi MIME tramite l'intestazione HTTP Accept. Quindi il server può fare tutto il lavoro pesante di generazione e gestione delle risorse finali e decidere quali inviare ai clienti. E una delle cose potenti qui è che se stai usando una CDN di immagini, puoi puntare a una singola risorsa.
Addy Osmani: Quindi forse se abbiamo un'immagine cucciolo come cucciolo.JPEG, potremmo fornire alle persone un URL per cucciolo.JPEG e se il loro browser supporta WebP o supporta un AVIF, il server può diventare davvero intelligente nel servire a destra immagine a quegli utenti a seconda dell'aspetto del loro supporto, ma per il resto ripiegano senza che tu debba fare un sacco di lavoro extra da solo. Ora, penso che sia un'idea potente. C'è molto che puoi fare sul server, a volte parliamo di come non tutti abbiano accesso a una qualità di rete davvero forte, il tuo tipo di connessione efficace può essere molto diverso a seconda di dove ti trovi.
Addy Osmani: Anche vivendo nella Silicon Valley, potrei camminare da un bar a un hotel o potrei essere in macchina e la qualità del mio wifi o del mio segnale potrebbe non essere eccezionale. Quindi è qui che hai accesso ad altre API, altre idee come il suggerimento del client Save-Data per essere potenzialmente in grado di servire le persone con risorse di dimensioni ancora più ridotte, se l'utente ha optato per il risparmio di dati. Quindi ci sono molte cose interessanti che potremmo fare sul lato server e penso che dovremmo continuare a spingere su queste idee per trovare un buon equilibrio in cui le persone che si sentono a proprio agio con il percorso di mercato hanno tutta la flessibilità per farlo e le persone che desiderano una soluzione leggermente più magica hanno anche alcune opzioni.
Drew McLellan: Il concetto di questo tipo di approccio al risparmio di dati è stato qualcosa che ho appreso per la prima volta dal tuo libro. Voglio dire, approfondiamolo un po' di più perché è piuttosto interessante. Quindi stai parlando del browser in grado di segnalare una preferenza per il ripristino di un'esperienza di dati ridotta perché forse è su una connessione a consumo o ha la batteria scarica o qualcosa del genere.
Addy Osmani: Esattamente. Esattamente. Ho viaggiato in tempi normali o prima, quando avremmo viaggiato molto di più, ho sperimentato molti posti nel mondo o situazioni in cui la qualità della mia rete potrebbe essere davvero scarsa o davvero imprevedibile, e quindi anche l'apertura su una pagina web potrebbe essere un'esperienza frustrante o difficile. Potrei cercare un menu e se non riesco a vedere le foto del bel cibo che hanno a disposizione potrei andare da qualche parte dove posso, o potrei, non so, prepararmi del cibo invece. Ma penso che una delle cose interessanti del risparmio di dati sia che ti restituisce una connessione a quali sono le preferenze dell'utente. Quindi, se come utente, so che sto attraversando un periodo difficile con la mia connessione di rete. Posso dire: "Ok, bene, ho intenzione di attivare la modalità di risparmio dati nel mio browser".
Addy Osmani: E poi puoi usarlo come sviluppatore come segnale per dire: "Okay, beh, l'utente è un po' vincolato, forse gli faremo scorrere immagini molto più piccole o immagini di qualità molto inferiore". Ma riescono comunque a vedere alcune immagini, il che è meglio che aspettare molto tempo prima che qualcosa di molto più ricco venga servito. Altri vantaggi di questi tipi di segnali sono che puoi usarli per servire i media in modo condizionale. Quindi forse ci sono casi in cui il testo è la cosa più importante in quella pagina, forse puoi disattivare quelle immagini se scopri che gli utenti si trovano in una specie di ambiente limitato. Ci dedicherò solo 30 secondi, ma puoi davvero spingere questa idea agli estremi. Alcune delle cose interessanti che puoi fare con Save-Data sono forse anche la disattivazione di funzionalità molto costose implementate in JavaScript.
Addy Osmani: Se hai alcuni componenti considerati leggermente più opzionali, forse non è necessario inviarli a tutti gli utenti se solo migliorano l'esperienza. Puoi comunque offrire a tutti un'esperienza molto semplice, piccola e rapida, e poi semplicemente sovrapporla con una bella glassa per le persone che hanno una connessione o un dispositivo più veloce.
Drew McLellan: Potenzialmente, immagino che potrebbe influire sull'impaginazione e potresti restituire 10 risultati su una pagina anziché 100 e anche questo genere di cose. Ci sono così tante capacità interessanti e interessanti lì. Penso che abbiamo tutti una certa familiarità con il processo frustrante di preparare un nuovo sito, ottimizzare tutte le tue immagini, consegnarlo al cliente, fornire loro un CMS per gestire il contenuto e scoprire che stanno semplicemente sostituendo tutto con immagini poco ottimizzate. Voglio dire, ancora una volta, un CDN di immagini, immagino, sarebbe una soluzione davvero conveniente a questo, ma ci sono altre soluzioni, ci sono cose che il CMS potrebbe fare sul server per aiutarlo o è un CDN di immagini probabilmente il ben fatto?
Addy Osmani: Penso che quello che abbiamo scoperto dopo probabilmente almeno sei o sette anni di tentativi per far sì che tutti ottimizzino le proprie immagini sia che è un problema difficile in cui alcune persone coinvolte nell'immagine potrebbero essere leggermente più esperte dal punto di vista tecnico e forse a proprio agio nell'impostazione potenziare i propri strumenti o avviare Lighthouse o provare altri strumenti per far loro sapere se ci sono opportunità per migliorare. Mi piacerebbe vedere le persone che usano costantemente cose come Lighthouse per catturare se hai l'opportunità di ottimizzare ulteriormente o ridurre le immagini della giusta dimensione, ma oltre a ciò, a volte ci imbattiamo in casi d'uso in cui le persone che stanno caricando le immagini potrebbero non necessariamente anche comprendere il costo delle risorse che stanno caricando. Questo è spesso qualcosa in cui ci imbattiamo e mi scuso, non chiamerò troppo le persone, ma questo è qualcosa in cui ci imbattiamo anche con il blog di Google.
Addy Osmani: Ogni due settimane sul blog di Google, avremo qualcuno che caricherà una GIF animata molto grande da 20 o 30 megabyte. E non mi aspetto che sappiano che non è una buona idea, stanno cercando di rendere l'articolo interessante, molto coinvolgente e interattivo, ma quel pubblico non necessariamente saprà utilizzare gli strumenti o utilizzare ImageOptim o utilizzare uno qualsiasi di questi altri strumenti in atto e quindi documentare per loro, che dovrebbero controllarli, è sicuramente un'opzione. Ma essere in grado di automatizzare il problema, penso sia molto avvincente e ci aiuti a raggiungere costantemente un punto in cui si spera di bilanciare le esigenze di tutti i nostri utenti di CMS, siano essi tecnici o non, anche come le esigenze dei nostri utenti.
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: Quindi, se sto cercando di andare su un sito di ricette, potrebbe interessarmi di come appare quella ricetta, quindi ci preoccupiamo di assicurarci che quell'immagine da grande eroe della ricetta sia visibile a me. Ora, l'elemento LCP può cambiare nel tempo. È molto probabile che all'inizio del caricamento, la cosa più grande possa essere un'intestazione, ma mentre la pagina continua a caricarsi, potrebbe effettivamente finire per essere un'immagine molto più grande o un poster di qualche tipo.
Addy Osmani: E quindi, quando stai cercando di ottimizzare la pittura più ricca di contenuti, ci sono circa quattro cose che puoi fare. La prima cosa è assicurarti di richiedere la tua immagine di eroe chiave il prima possibile. In generale, abbiamo una serie di cose importanti nella pagina. Vogliamo assicurarci di poter eseguire il rendering del contenuto e del layout della pagina principale.
Addy Osmani: Per il layout, in genere si parla di CSS. Quindi potresti utilizzare CSS critici, CSS in linea, nelle tue pagine, vuoi evitare cose che bloccano il rendering, ma quando si tratta della tua immagine, idealmente dovresti richiedere quell'immagine in anticipo. Forse ciò implica semplicemente assicurarsi che il browser possa scoprire quell'immagine il più presto possibile nella pagina, dato che molti di noi in questi giorni fanno affidamento sui framework.
Addy Osmani: se non stai necessariamente utilizzando SSR, rendering lato server, se stai aspettando che il browser scopra alcuni dei tuoi bundle JavaScript, bundle per i tuoi componenti, indipendentemente dal fatto che tu abbia un componente per l'immagine del tuo eroe o per l'immagine del prodotto, se il browser deve attendere per recuperare, analizzare, eseguire, compilare ed eseguire tutti questi diversi file prima di poter scoprire l'immagine, ciò potrebbe significare che la tua immagine di contenuto più grande impiegherà del tempo prima che possa essere scoperta.
Addy Osmani: Ora, se è il caso, se ti trovi in un luogo in cui l'immagine viene richiesta abbastanza tardi, puoi sfruttare una funzione del browser chiamata link rel preload per assicurarti che il browser possa scoprire quell'immagine il prima possibile il più possibile. Ora, il precarico è una capacità davvero potente. È anche uno con cui devi prenderti molta cura. Al giorno d'oggi, è molto facile arrivare in un posto in cui forse senti che ti stiamo consigliando il precaricamento per la tua chiave-
Addy Osmani: Forse hai sentito che stiamo consigliando il precaricamento per l'immagine del tuo eroe chiave, così come per i tuoi script chiave e per i tuoi caratteri chiave. E diventa proprio questo davvero grande, enorme tentativo di assicurarti di mettere in sequenza le cose nell'ordine giusto. Quindi le immagini LCP sono sicuramente un posto chiave da tenere a mente per questo.
Addy Osmani: L'altra cosa, come ho menzionato quattro cose, l'altra cosa è assicurarsi di utilizzare il set di sorgenti e un formato immagine moderno ed efficiente. Penso che il set di sorgenti sia davvero potente. Vedo anche che a volte quando le persone lo usano, cercheranno di compensare eccessivamente e forse spediranno 10 diverse versioni di immagini lì per ogni possibile risoluzione. Tendiamo a scoprire, almeno in alcune ricerche, che oltre tre per immagini, gli utenti hanno davvero difficoltà a capire quali sono le differenze per qualità dell'immagine, nitidezza e dettaglio. Quindi il limite DPR, il limite del rapporto pixel del dispositivo, è sicuramente un'idea che vale la pena tenere a mente.
Addy Osmani: E poi per i formati immagine moderni, abbiamo parlato di formati in precedenza, ma considera il tuo WebP, il tuo AVIF, il tuo JPEG XL. Evita di sprecare pixel. È davvero importante avere una buona strategia in atto per la qualità. E penso che ci siano molti casi in cui anche la qualità predefinita a volte può essere eccessiva. Quindi sperimenterei il tentativo di abbassare il bit rate, abbassare le impostazioni di qualità e vedere fino a che punto puoi portare le cose per i tuoi utenti mantenendo la nitidezza.
Addy Osmani: E poi, quando parliamo di caricamento, una delle altre cose che il tag immagine si è evoluto per supportare negli ultimi due anni è il caricamento lento. Quindi, con il caricamento uguale a lazy, non è più necessario utilizzare necessariamente una libreria JavaScript per aggiungere il caricamento lazy alle tue immagini. Lascialo cadere sulla tua immagine. E nei browser chromium e Firefox, sarai in grado di caricare in modo pigro quelle immagini senza dover utilizzare dipendenze di terze parti. Ed è anche abbastanza carino.
Addy Osmani: Quindi, abbiamo il caricamento lento in atto. Abbiamo il supporto per altre cose come la decodifica della sincronizzazione, ma ho intenzione di continuare le cose e parlerò molto rapidamente delle altre due metriche vitali fondamentali.
Drew McLellan: Provaci, sì.
Addy Osmani: Quindi, sbarazzati dei cambiamenti di layout. A nessuno piacciono le cose che saltano sulle loro pagine. Sento che una delle mie più grandi frustrazioni è aprire una pagina web. Passo il dito su un pulsante su cui voglio fare clic, e all'improvviso vengono visualizzati un mucchio di annunci o immagini senza set di dimensioni o altre cose. E questo provoca un'esperienza davvero spiacevole.
Addy Osmani: Quindi lo spostamento cumulativo del layout cerca di misurare l'instabilità del contenuto. E la maggior parte delle volte, le cose comuni che spingono i tuoi cambiamenti di layout sono immagini o altri elementi sulla tua pagina che semplicemente non hanno le dimensioni impostate. Penso che sia uno di quei posti in cui è spesso semplice per le persone impostare le dimensioni dell'immagine. Forse non è qualcosa di cui storicamente abbiamo fatto così tanto, ma sicuramente qualcosa su cui vale la pena dedicare il tuo tempo. In strumenti come il faro cercherà di aiutarti a raccogliere, come qual è l'elenco delle immagini sulla tua pagina che richiedono dimensioni? Quindi puoi andare e puoi impostarli.
Drew McLellan: Stavo per dire, questo è un punto davvero interessante perché quando il web design reattivo è diventato una cosa, abbiamo tutti esplorato i nostri siti e eliminato le dimensioni dell'immagine perché gli strumenti che avevamo a nostra disposizione per farlo funzionare richiedevano che lo facessimo non hanno attributi di altezza e larghezza sulle nostre immagini. Ma questa è una cattiva idea ora, vero?
Addy Osmani: Ciò che è vecchio è di nuovo nuovo. Direi che vale sicuramente la pena impostare le dimensioni sulle tue immagini. Impostare le dimensioni sui tuoi annunci, sulla cornice degli occhi, su qualsiasi contenuto dinamico che potrebbe potenzialmente cambiare di dimensione vale la pena impostare le dimensioni.
Addy Osmani: E per le persone che stanno costruendo un'esperienza davvero divertente, là fuori c'è la frase sbagliata, esperienze di layout davvero divertenti in cui forse è necessario lavorare di più su schede reattive e simili; Prenderei in considerazione l'utilizzo delle proporzioni CSS o delle caselle delle proporzioni per prenotare il tuo spazio. E questo può anche completare l'impostazione delle dimensioni su quelle immagini per assicurarti che le cose siano il più corrette possibile quando stai cercando di evitare i cambiamenti di layout.
Addy Osmani: E infine, l'ultimo Core Web Vital è il primo ritardo di input. Questo è qualcosa a cui le persone non sempre pensano quando si tratta di immagini. Quindi è in effetti possibile che le immagini blocchino la larghezza di banda e la CPU di un utente al caricamento della pagina. Possono interferire con il modo in cui vengono caricate altre risorse critiche, in particolare su connessioni molto lente o su dispositivi mobili di fascia bassa che possono portare alla saturazione della larghezza di banda.
Addy Osmani: Quindi il ritardo del primo input è una metrica di Core Web Vital che cattura la prima impressione degli utenti sull'interattività e la reattività di un sito. Quindi, riducendo l'utilizzo della CPU del thread principale, anche il tuo primo ritardo di input può essere ridotto al minimo. Quindi, in generale, evita semplicemente le immagini che potrebbero causare contese di rete. Non stanno bloccando il rendering. Ma possono comunque influenzare indirettamente le prestazioni di rendering.
Drew McLellan: C'è qualcosa che possiamo fare con le immagini per impedire che blocchino il rendering? Possiamo in qualche modo scaricare il browser in quella fase iniziale per consentirci di essere interattivi più velocemente?
Addy Osmani: Penso che in questi giorni sia sempre più importante avere una buona comprensione della giusta sequenza di immagini ottimale per visualizzare qualcosa above the fold. So che above the fold è un termine sovraccarico, ma come nella prima porta di visualizzazione dell'utente. Molto spesso possiamo finire per cercare di richiedere un'intera tonnellata di risorse, alcune delle quali sono immagini, che non sono realmente necessarie per ciò che l'utente vedrà immediatamente. E quelli tendono ad essere ottimi candidati per il caricamento più avanti nel ciclo di vita della pagina, ottime cose per il caricamento lento in atto. Ma se stai richiedendo un'intera serie di immagini, come un'intera coda di cose molto presto, queste possono potenzialmente avere un impatto.
Drew McLellan: Sì. Quindi, voglio dire, hai menzionato il caricamento lento delle immagini che storicamente abbiamo richiesto a una libreria JavaScript, che ha le sue battute d'arresto, penso, a causa dei modi storici in cui i browser ottimizzano il caricamento delle immagini, dove è quasi impossibile impedire loro di caricare le immagini , a meno che tu non gli fornisca una fonte. E se non gli dai una fonte e poi provi a correggerlo con JavaScript in seguito, se quel JavaScript non viene eseguito, non ottieni immagini. Quindi il caricamento lento, il caricamento lento nativo è una risposta a tutto ciò.
Addy Osmani: Sì, assolutamente. E penso che questo sia un luogo in cui abbiamo cercato di migliorare attraverso i browser, l'esperienza di caricamento lento nativa nell'ultimo anno. Come sai, questa è una di quelle funzionalità in cui abbiamo spedito qualcosa in anticipo e siamo in grado di sfruttare le conversazioni con i leader di pensiero del settore per capire come "Oh, ehi, quali sono le soglie che stai effettivamente impostando manualmente se stai utilizzando dimensioni pigre o stai utilizzando altre librerie di caricamento lento di JavaScript?" E poi abbiamo regolato le nostre soglie per cercare di arrivare a un punto leggermente più vicino a quello che ti aspetteresti che fossero.
Addy Osmani: Quindi, in molti casi, puoi semplicemente usare il caricamento lento nativo. Se hai bisogno di qualcosa di molto più raffinato, se hai bisogno di molto più controllo sulla possibilità di impostare le soglie dell'osservatore dell'intersezione, il punto in cui il browser richiederà le cose, generalmente suggeriamo di utilizzare una libreria in quei casi , solo perché stiamo cercando di risolvere il caso d'uso del 90%. Ma il 10% è ancora valido. Potrebbero esserci persone che hanno ancora bisogno di qualcosa in più. E quindi, per la maggior parte delle persone, spero che il caricamento lento nativo sarà abbastanza buono per il prossimo futuro.
Drew McLellan: Soprattutto, è gratuito. Un semplice attributo da aggiungere e ottieni tutte queste funzionalità gratuitamente, il che è fantastico. Se ci fosse una cosa che il nostro ascoltatore potrebbe fare, andare via e fare sul proprio sito per migliorare l'ottimizzazione delle immagini, quale sarebbe? Da dove dovrebbero iniziare?
Addy Osmani: Un buon punto di partenza è capire quanto sia un problema per il tuo sito. Andrei a controllare il faro o pagare le informazioni sulla velocità. Vai ed eseguilo su alcune delle tue pagine più popolari e guarda cosa viene fuori. Se sembra che tu abbia solo una o due piccole cose da fare, è fantastico. Forse puoi dedicarci un po' di tempo.
Addy Osmani: Se c'è una lunga lista di cose da fare, forse dai un'occhiata alle maggiori opportunità che hai lì dentro, cose che dicono: "Oh, ehi, potresti risparmiare più secondi se dovessi fare questo cosa." E concentra la tua energia lì per cominciare.
Addy Osmani: Come abbiamo detto qui, gli strumenti per i moderni formati di immagine sono migliorati nel tempo. Le CDN di immagini possono sicuramente valere la pena di prendere in considerazione. Ma oltre a questo, ci sono molti piccoli passi che puoi fare. A volte, se è un sito abbastanza piccolo, anche solo aprire Squoosh, inserire alcune delle tue immagini può essere un ottimo punto di partenza.
Drew McLellan: Questo è un consiglio valido. Ora so che è una pubblicazione formidabile, ma devo davvero congratularmi con te per il libro. È così completo e davvero facile da digerire. Penso che sia una lettura davvero preziosa.
Drew McLellan: Quindi ho imparato tutto sull'ottimizzazione delle immagini. Cosa stai imparando ultimamente, Addy?
Addy Osmani: Cosa sto imparando ultimamente? In realtà, su un argomento leggermente diverso che ha ancora a che fare con le immagini, quindi quando stavo facendo i miei master al college, sono andato davvero a fondo nella visione artificiale e ho cercato di capire, come possiamo rilevare parti diverse di un'immagine e fare cose selvagge e cose interessanti con loro?
Addy Osmani: E un problema specifico che ho approfondito di recente è che ho guardato le foto di me stesso quando ero un bambino o un bambino. E a quei tempi, gran parte del cibo che i miei genitori avrebbero preso non erano necessariamente su fotocamere digitali. Erano Polaroid. Sono spesso immagini a bassa risoluzione. E volevo un modo per poterli aumentare. E così ho iniziato a scavare di nuovo in questo problema di recente. E mi ha portato a imparare molto di più su cosa posso fare nel browser.
Addy Osmani: Quindi ho creato alcuni piccoli strumenti che ti consentono, utilizzando l'apprendimento automatico, utilizzando TensorFlow, utilizzando le tecnologie esistenti, di acquisire un'immagine o un'illustrazione a risoluzione relativamente bassa e quindi ridimensionarle a qualcosa di qualità molto più elevata. In modo che sia meglio che semplicemente allungare l'immagine. È come riempire i dettagli.
Addy Osmani: Ed è stato divertente. Ho imparato molto su quanto sia stabile l'assembly Web nel browser, su come puoi utilizzare alcune di queste idee per casi d'uso di applicazioni desktop. Ed è stato davvero divertente. Quindi ho scavato in un sacco di assemblaggi web di recente. Ed è stato bello.
Drew McLellan: È divertente, vero? Quando arriva una tecnologia che capovolge tutto ciò che conosci. Abbiamo sempre detto che sul web possiamo rimpicciolire le immagini. Ma se abbiamo solo una piccola immagine, non possiamo ingrandirla. È semplicemente impossibile. Ma ora abbiamo una tecnologia che, in molte circostanze, potrebbe renderlo possibile. È davvero affascinante.
Drew McLellan: Se tu, caro ascoltatore, vorresti sentire di più da Addie, puoi trovarlo su Twitter dove è @AddieOsmani e trovare tutti i suoi progetti collegati da AddyOsmani.com. Il libro "Ottimizzazione dell'immagine" è disponibile sia fisicamente che digitalmente da Smashing in questo momento su smashingmagazine.com. Grazie per esserti unito a noi oggi, Addy. Hai qualche parola d'addio?
Addy Osmani: Qualche parola d'addio? Ho una piccola stranezza della storia che condividerò con le persone. Tim Berners-Lee ha caricato la prima immagine su Internet nel 1992. Non sono sicuro che tu possa indovinare cosa fosse, ma probabilmente rimarrai sorpreso. Drew, hai qualche ipotesi?
Drew McLellan: Immagino un gatto.
Addy Osmani: Un gatto. È una buona ipotesi, ma no. Questo era al CERN. E l'immagine era in realtà di una band chiamata Les Horribles Cernettes, che era una band pop parodia formata da un gruppo di dipendenti del CERN. E la musica che farebbero è come la musica doo-wop. E cantavano canzoni d'amore su collider e stranezze, azoto liquido e antimateria indossando abiti anni Sessanta, che ho trovato semplicemente meravigliosi e casuali.