Indipendentemente da quanto tempo stai per imparare a progettare e sviluppare per il web, l'elemento <img> richiede pochissima introduzione.
Lanciato in Netscape ("Mosaico", all'epoca) nel 1993 e aggiunto alla specifica HTML nel 1995, <img> ha svolto a lungo un ruolo semplice ma potente all'interno della piattaforma web. Lo sviluppatore aggiunge un file immagine "di origine" con l'attributo src e fornisce un'alternativa di testo con l'attributo alt nel caso in cui non sia possibile visualizzare l'immagine o che le tecnologie per la disabilità richiedano un'alternativa. Da qui, il browser ha un solo compito, ovvero ottenere i dati dell'immagine, quindi eseguirne il rendering il più rapidamente possibile.
Nella maggior parte della storia dello sviluppo web, lavorare con le immagini non è sempre stato molto più complicato. Inoltre, nonostante la complessità del web moderno, le basi del lavoro con le immagini non sono cambiate: utilizzare un formato di immagine ottimizzato per il web per garantire la compatibilità, compressione sensibile per risparmiare larghezza di banda e dimensioni adatte allo spazio che l'immagine occuparà nel layout della pagina.
L'utilizzo di layout a larghezza fissa, come abbiamo fatto quando pensavamo di avere più voce in merito all'esperienza sul web da parte degli utenti, rendeva il processo semplice. È stato particolarmente facile impostare le dimensioni dell'origine dell'immagine. Per un'immagine che occupava uno spazio di 500 pixel in larghezza e trecento pixel in altezza, si trattava di specificare un'immagine di origine con le stesse dimensioni.
Immagini in layout adattabile
Insieme al layout flessibile e all'utilizzo di query supporti CSS, "immagini e contenuti multimediali flessibili" sono uno dei tre aspetti che definiscono il sito web reattivo. Per rendere un'immagine flessibile, gli sviluppatori hanno iniziato a utilizzare CSS per impostare max-width: 100% sull'immagine (o su tutte le immagini, a livello di sito) per indicare al motore di rendering del browser in modo che un'immagine non riempia mai il container principale, scalandola verso il basso. A livello visivo, questo metodo funziona perfettamente: il ridimensionamento di un'immagine raster risulta uniforme a livello visivo. Con una o due righe di codice CSS,
un'immagine ingrandita risulterà sempre come se abbiamo specificato un'origine immagine che deve essere visualizzata con quelle dimensioni.
Quando ai motori di rendering vengono dati più dati di quelli necessari per lo spazio occupato dall'immagine in un layout, possono prendere decisioni informate su come eseguire il rendering dell'immagine ridotta, senza introdurre artefatti visivi o sfocature.
In genere, non è consigliabile ridimensionare un'immagine, ovvero eseguire il rendering di <img> a una dimensione superiore a quella intrinseca dell'immagine di origine.
L'immagine visualizzata risulterà sfocata e sgranata.
Se usi img { max-width: 100% }, le immagini verranno ridimensionate a seconda dei casi essendo un contenitore flessibile.
A differenza dell'impostazione di un width: 100% più rigido, ciò garantisce anche che l'immagine non venga ridimensionata oltre le dimensioni intrinseche.
Per molto tempo, è stato questo per le regole del lavoro con le immagini: usa un formato conosciuto dai browser, usa un livello di compressione ragionevole e non ingrandire mai le immagini.
Ma per quanto semplice ed efficace sia visivamente che questo approccio ha comportato un enorme costo in termini di rendimento. Poiché <img> supportava solo
una singola origine per i dati immagine, questo approccio ci ha richiesto di fornire un asset immagine con una dimensione intrinseca grande quanto
la dimensione più grande in cui poteva essere visualizzato. Un'immagine destinata a occupare uno spazio in un layout che poteva avere una larghezza compresa tra 300px e 2000px, a seconda delle dimensioni dell'area visibile dell'utente, richiedeva un'origine immagine con larghezza intrinseca di almeno 2000px. Per un utente che visualizza la pagina solo tramite un'area visibile di piccole dimensioni, tutto verrebbe visualizzato come previsto: l'immagine verrà ridimensionata correttamente. Nella pagina visualizzata, un'immagine sorgente di grandi dimensioni ma in scala ridotta non apparirebbe diversamente da un'immagine di dimensioni appropriate. Tuttavia, trasferiscono e renderizzano comunque un'immagine larga 2000px, utilizzando un'enorme quantità di larghezza di banda e potenza di elaborazione senza alcun vantaggio tangibile.
Le cose sono peggiorate molto con l'avvento dei primi dispositivi "Retina", poiché insieme alle dimensioni dell'area visibile la densità del display è diventata un problema. Un'origine immagine ha bisogno di una larghezza intrinseca molto più grande per garantire uno schermo ad alta densità. In parole povere, una visualizzazione con il doppio della densità richiede il doppio dei pixel immagine per visualizzare l'immagine il più possibile.
In questo caso, gli sviluppatori hanno potuto fare di nuovo affidamento sulla capacità dei motori di rendering per ridimensionare le immagini visivamente. Se al browser viene fornita un'immagine sorgente larga 800px in src e poi specifichi che deve essere visualizzata con CSS con larghezza di 400px, il risultato è un'immagine visualizzata con una densità di pixel doppia:
Un'unica immagine sorgente, tagliata per adattarsi al più ampio spazio possibile nel tuo layout e display ad alta densità, funziona visivamente per tutti gli utenti. Un'enorme origine di immagine ad alta risoluzione visualizzata su un display piccolo e a bassa densità sarà simile a qualsiasi altra immagine piccola e a bassa densità, ma risulterà molto più lenta. L'utente dovrà sostenere tutti i costi relativi al rendimento dell'enorme sorgente di immagini, a 4000 px, senza alcun vantaggio.
Per molto tempo, <img> ha fatto in gran parte una cosa: "ha ottenuto i dati delle immagini e li ha visualizzati sullo schermo". Lo ha fatto in modo ragionevole, per certo, ma <img> non è stato all'altezza dell'impegno di adattarsi ai cambiamenti radicali nel contesto di navigazione che stavamo vivendo. Sebbene il web design reattivo sia diventato una pratica di sviluppo tradizionale, i browser hanno ottimizzato le prestazioni di img per quasi vent'anni, ma per tutti gli utenti meno privilegiati, i contenuti delle immagini delle pagine erano inefficienti fin dall'inizio. Indipendentemente dalla velocità con cui il browser è riuscito a richiedere, analizzare ed eseguire il rendering di un'origine immagine, l'asset sarà probabilmente molto più grande di quanto l'utente abbia bisogno.