Più pixel più problemi

Il grande problema: immagini enormi#section1

Nel tentativo di tenere i propri siti aggiornati con le ultime tecnologie, molti di noi hanno intrapreso il processo della realizzazione dei design di questi a “@2x“, sperando segretamente che “@3x” non venga mai realizzato. Si potrebbe essere indotti a credere che un’immagine @2x abbia il doppio dei kilobyte, mentre in realtà è circa tre o quattro volte più grande. Come potete vedere nella mia dimostrazione di @1x rispetto a @2x, il risultato finale è che le foto o le composizioni maggiormente dettagliate arrivano in fretta ai megabyte.

Vi starete chiedendo: “Perché questo dovrebbe essere un problema? Il web non dovrebbe essere bello?”. Certo! Il motivo per cui abbiamo intrapreso la nostra carriera è quasi sicuramente per rendere il web un posto migliore. Il problema sta nelle assunzioni che facciamo sull’ampiezza di banda.

Nelle parti più ricche del mondo, trattiamo l’accesso alla banda larga come un diritto civile, ma per molte persone sul nostro pianeta la realtà è che devono pagare la banda al gigabyte o non hanno accesso a connessioni ad alta velocità. “Perché è bello” non è un motivo sufficiente per mandare un’immagine da 1MB sulla rete 3G, o, ancora peggio, su qualcosa come la rete EDGE.

Anche nei nostri paradisi a banda larga, non occorre cercare molto per trovare esempi di banda limitata. Un visitatore del vostro sito potrebbe usare un tablet o un telefono con un alto PPI dal suo comodo divano oppure nel bel mezzo del deserto dell’Arizona. In maniera analoga, i nuovi Retina Macbook Pro potrebbero essere connessi a internet tramite Google Fiber o collegati tramite un hotspot 3G in un aeroporto. Dobbiamo essere cauti nelle ipotesi che facciamo sui pixel e sulla banda.

Percorsi sbagliati: JavaScript#section2

Userò JavaScript.

— Tutti, sempre

JavaScript ha risolto molti dei nostri problemi in passato, perciò è normale che si faccia ricorso ad esso per salvarci un’altra volta. Tuttavia, la maggior parte delle soluzioni non è all’altezza e finisce con il penalizzare gli utenti con quello che viene comunemente chiamato il “download doppio”.

Mat Marquis l’ha spiegato bene, ma vale la pena ripeterlo: nella loro ricerca della velocità e per rendere il web più veloce, i browsers hanno cominciato a fare “prefetching” di tutte le immagini presenti in un documento prima che JavaScript vi abbia accesso e possa fare una qualunque modifica.

Per questo le soluzioni in cui vengono rilevate le capacità di alta risoluzione e in cui viene immessa una nuova sorgente per l’immagine causano in realtà il caricamento di due immagini, obbligando gli utenti con strumenti ad alta risoluzione ad aspettare che entrambe gli insiemi di immagini vengano scaricati. Questo download doppio non sembra eccessivamente penalizzante per una singola immagine, ma provate a pensare a cosa può accadere con una photogallery con 100 immagini per pagina… Ahia!

Ci sono altri tentativi, come la “bandwith detection”, l’impostazione di cookie, la “server-side detection” o un mix di queste tre. Per quanto mi piacerebbe che i robot risolvessero i miei problemi, queste soluzioni hanno una barriera in ingresso più alta per il web developer medio: il punto di maggior sofferenza è che introducono delle dipendenze server/cookie, che storicamente hanno sempre presentato dei problemi.

Abbiamo bisogno di una soluzione puramente front-end per le immagini ad alta risoluzione.

Vi suona familiare? È perché le immagini ad alta risoluzione e le immagini responsive fanno entrambe riferimento allo stesso problema: come mandare diverse immagini a diversi device e contesti usando lo stesso tag HTML?

La soluzione: il caro vecchio progressive enhancement#section3

Quelli tra noi che sono coinvolti nei CSS e negli standard web conoscono bene il concetto di progressive enhancement. È importante che facciamo fronte comune su questo punto: i pixel, sia in termini di spazio sul device sia in termini di densità del device, dovrebbero essere trattati come un miglioramento o come una feature che alcuni browser hanno e altri no. Create una baseline solida di supporto, poi ottimizzate se necessario. In effetti, imparare a costruire in maniera appropriata e migliorare progressivamente un sito web può far risparmiare molto tempo a voi e al vostro cliente.

Ecco le “regole della strada” che abbiamo seguito io e i miei colleghi di Paravel navigando in questo groviglio di immagini ad alta densità:

• usate i CSS e i web type ovunque sia possibile,
• ogni volta che potete farlo, usate SVG e le icone realizzate mediante font,
• usate Picturefill per la grafica raster.

Vediamoli uno per uno.

CSS e web font#section4

CSS3 ci permette di replicare nel browser degli effetti visivi più particolareggiati con pochissimo sforzo e il numero sempre crescente di web font di alta qualità ci permette di creare siti su una base tipograficamente ricca invece di creare dei collage di immagini. Con le capacità attuali di CSS, stanno diminuendo sempre di più i buoni motivi per fare affidamento su grafiche raster giganti per l’impatto visivo.

Quindi, rimane valida la vecchia regola: se potete ottenere il vostro design con HTML/CSS, fatelo. Se non potete farlo con CSS, allora forse la prima domanda che dovreste farvi è: perché no? Dopo tutto, se ci consideriamo come parte del business del web design, allora è imperativo che i nostri design, innanzitutto, funzionino sul web e nella maniera più efficiente possibile.

Fate un passo indietro e adottate i materiali grezzi del web: HTML e CSS.

SVG e le icone realizzate mediante font#section5

Le immagini SVG sono dei path vettoriali basati su XML progettati in origine come competitor di Flash. È come se fossero dei file di Illustrator nel browser: non solo sono indipendenti dalla risoluzione, ma tendono anche a creare dei file estremamente leggeri (pressapoco determinati dal numero di punti nel vettore).

Le icone realizzate mediante font (come ad esempio Pictos o SymbolSet) sono sostanzialmente degli insiemi di grafica vettoriale riuniti in un font dingbat custom, accessibile attraverso i caratteri Unicode in un font inserito mediante @font-face. Un piccolo aneddoto: in Paravel abbiamo notato che le piccole grafiche raster, come i bottoni e le icone, tendono a mostrare le loro stranezze soprattutto sugli schermi con risoluzioni maggiori. Le icone realizzate con i font sono un’ottima alternativa alla frustrazione derivante dagli “sprite sheet” e abbiamo già cominciato ad usare le icone realizzate mediante font come sostituti ovunque sia possibile.

Il supporto per @font-face è grandioso e il supporto per l’embed di SVG di base sfiora l’ubiquità, eccezion fatta per i soliti vecchi colpevoli: le versioni più vecchie di IE e Android. Nonostante ciò, possiamo cominciare facilmente ad usare SVG già oggi e, se necessario, faremo delle concessioni ai vecchi browser usando la feature detection per dare un polyfill o un fallback, o magari usando nuovi progetti che automatizzano gli sprite sheet SVG/PNG.

Ci sono dei casi in cui i formati non sono all’altezza. Le icone realizzate con i font, ad esempio, possono avere un solo colore. Le immagini SVG si possono ridimensionare all’infinito, ma ingrandire non significa ottenere più dettagli o maggiore fedeltà. Questo è il punto su cui occorre ingegnarsi di più.

Usare Picturefill con grafica raster#section6

Non estraneo a questa pubblicazione, l’elemento <picture>, proposto dal W3C Responsive Images Community Group, è una soluzione elegante per caricare una grafica raster molto grande. Con <picture> potete specificare progressivamente quale sorgente di immagine volete che il browser usi all’aumentare dei pixel a disposizione.

L’elemento <picture> non è esente da drammi e ha anche un concorrente valoroso. L’attributo di image @srcset, portato avanti soprattutto da Apple, si basa sulla proprietà proposta di CSS image-set(), pensata per mandare risorse ad alta risoluzione come immagini di background. Ecco un esempio della sintassi proposta (con i miei personalissimi commenti):

<img alt="Cat Dancing" src="small-1.jpg"
srcset="small-2.jpg 2x,  // this is pretty cool
large-2.jpg 100w,       // meh
large-2.jpg 100w 2x     // meh@2x
">

@srcset, come soluzione per le immagini completamente responsive, ha una fastidiosa “microsintassi” e non è “feature-complete” (ovvero, ha delle unità misteriose h e w basate sul pixel e non supporta le unità em). Ma ha delle qualità per cui farsi redimere: in teoria, l’attributo @srcset potrebbe mettere la determinazione della banda tra le mani del browser, il quale, attraverso le impostazioni dell’utente e/o aggregando dati sulla velocità di tutte le richieste, potrebbe poi prendere delle decisioni meglio informate su quale risoluzione richiedere.

Tuttavia, per come è scritta la specifica, @srcset è semplicemente un insieme di suggerimenti per il browser, tra cui deve scegliere oppure ignorarli completamente a sua discrezione. Lasciare il controllo totale al browser mi fa un po’ rabbrividire e immagino che molti di voi si sentano come me.

Non sarebbe bello se ci fosse una via di mezzo?

Notando i punti di forza dell’attributo @srcset, il Responsive Images Community Group ha presentato una proposta chiamata il Compromesso di Florian, che fonde i poteri sia di @srcset sia dell’elemento <picture>.

 
<picture alt="Cat Dancing">
<source media="(min-width: 45em)" srcset="large-1.jpg 1x, large-2.jpg 2x">
<source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
<source srcset="small-1.jpg 1x, small-2.jpg 2x">
<img src="small-1.jpg">
</picture>

Senza dubbio la sintassi di <picture> è più verbosa ma è estremamente leggibile e non usa la sintassi abbreviata “100w” che crea confusione. Aspettiamoci che le cose cambino con l’andare del tempo, ma nel frattempo noi stiamo attualmente usando la soluzione Picturefill basata sui div di Filament Group, che troviamo semplice da usare e che non richiede alcuna architettura server né alcun file .htaccess. Semplicemente, usa un polyfill sull’elemento <picture>, come se esistesse già oggi.

Vediamo cosa succede: la nostra dimostrazione precedente usava due istanze dell’originale Picturefill per scambiare le sorgenti al ridimensionamento del browser. Ho fatto delle rapide modifiche a questa demo, combinando ora sia la sorgente @1x sia quella @2x in una demo Picturefill con una sintassi più nuova.

Tecnica sperimentale l’hack 1.5x#section7

Un’altra cosa che facciamo in Paravel è giocare con le medie. La situazione nel vostro caso potrebbe essere diversa, ma ho notato che gli schermi ad alta risoluzione fanno generalmente un ottimo lavoro cercando di ottenere il meglio dai pixel a loro disposizione, come potete vedere nella versione @1.5x dell’esperimento della nostra demo.

Se non avete uno schermo ad alta risoluzione, potete aumentare lo zoom del vostro browser al 200% per simulare come apparirebbero gli artefatti di compressione su uno schermo ad alta risoluzione. L’immagine @1x chiaramente ha la peggior fedeltà sui monitor ad alta risoluzione e l’immagine @2x ha la più alta fedeltà. La versione @1.5x, tuttavia, va abbastanza bene, quasi quanto la versione @2x e ha un risparmo di carico di circa il 20%. Quale notereste di più voi come utenti: la differenza in fedeltà o la differenza in caricamento della pagina?

In definitiva, l’utilità della tecnica @1.5x dipende dalla situazione. Più di tutto, penalizza l’utente @1x, ma forse potrebbe fare al caso vostro una via di mezzo con @1.2x o @1.3x. Attualmente, vediamo dei metodi “solo un po’ più grande” come soluzione fattibile per ottenere un po’ di più da immagini di media importanza senza aggiungere un altro grado di complessità per i nostri clienti. Se vi trovate in una situazione in cui non potete fare dei cambiamenti drastici, questo potrebbe essere un buon modo per guadagnare un po’ di fedeltà senza (relativamente) aumenti a dismisura.

Ma soprattutto, usate il cervello#section8

Recentemente, facendo il redesign del sito Paravel, abbiamo imparato a sfidare le nostre stesse regole. Dal momento che abbiamo il talentuoso illustratore Reagan Ray nel nostro team, il nostro nuovo sito fa largo uso di SVG. Ma quando abbiamo esportato la nostra amata grafica dei “Three Amigos”, abbiamo fatto una rapida indagine e abbiamo notato che la versione SVG era di 140kb. Ci sembrava pesante, così l’abbiamo esportata in una versione PNG 2000×691 piuttosto grande. Pesava solo 84kb. Non siamo scienziati dell’UX, ma assumeremo che i nostri visitatori preferiscano immagini che si scaricano cinque volte più rapidamente, abbiamo deciso per PNG.

Basta usare la testa. Non sono sicuro che il nostro settore lo dica a sufficienza: siete intelligenti, siete voi a creare internet e a prendete delle buone decisioni. Fate attenzione a quello che producete, soppesate i pro e i contro e controllate le vostre assunzioni man mano che procedete.

Siate anche flessibili. Nel nostro settore non ci sono proiettili d’argento: il posizionamento assoluto, i metodi e i flussi di lavoro tendono ad essere datati da una settimana con l’altra. Come abbiamo scoperto con il nostro sito, attenersi strettamente alle nostre regole non è sempre meglio per i nostri utenti.

Fare bene per gli utenti è il fulcro del front-end development e, in realtà, anche di tutto il resto sul web. La densità di pixel potrebbe cambiare ma, come si dice, quel che va bene per l’utente va sempre bene per il nostro business.

Illustrazioni: {carlok}