{"id":315,"date":"2012-10-16T10:37:12","date_gmt":"2012-10-16T08:37:12","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/piu-pixel-piu-problemi\/"},"modified":"2012-10-16T10:37:12","modified_gmt":"2012-10-16T08:37:12","slug":"piu-pixel-piu-problemi","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/piu-pixel-piu-problemi\/","title":{"rendered":"Pi\u00f9 pixel pi\u00f9 problemi"},"content":{"rendered":"

I dispositivi mobile hanno un PPI<\/a> sempre pi\u00f9 alto, ma anche i computer desktop e portatili stanno seguendo questo trend. Non lo si pu\u00f2 pi\u00f9 evitare: i display ad alta densit\u00e0 di pixel o “Retina” si stanno ampiamente diffondendo<\/a> e, c’era da aspettarselo, i siti web cominciano ad apparire leggermente sfuocati su questi monitor meravigliosi. Ma, prima di agire di impulso e ingrandire tutti i nostri siti, dobbiamo identificare i problemi che si presentano volendo adeguare i siti a queste risoluzioni e trovare il modo pi\u00f9 responsabile per procedere, tenendo bene a mente i nostri utenti.<\/p>\n

\n

Il grande problema: immagini enormi<\/h2>\n

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<\/code>“, sperando segretamente che “@3x<\/code>” non venga mai realizzato. Si potrebbe essere indotti a credere che un’immagine @2x<\/code> abbia il doppio dei kilobyte, mentre in realt\u00e0 \u00e8 circa tre o quattro volte pi\u00f9 grande. Come potete vedere nella mia dimostrazione di @1x<\/code> rispetto a @2x<\/code><\/a>, il risultato finale \u00e8 che le foto o le composizioni maggiormente dettagliate arrivano in fretta ai megabyte.<\/p>\n

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

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

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<\/a> o collegati tramite un hotspot 3G in un aeroporto. Dobbiamo essere cauti nelle ipotesi che facciamo sui pixel e sulla banda.<\/p>\n<\/div>\n

\n

Percorsi sbagliati: JavaScript<\/h2>\n
\n

User\u00f2 JavaScript.<\/p>\n

\u2014 Tutti, sempre<\/cite><\/p>\n<\/blockquote>\n

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

Mat Marquis l’ha spiegato bene<\/a>, ma vale la pena ripeterlo: nella loro ricerca della velocit\u00e0 e per rendere il web pi\u00f9 veloce<\/a>, 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.<\/p>\n

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

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\u00f9 alta per il web developer medio: il punto di maggior sofferenza \u00e8 che introducono delle dipendenze server\/cookie, che storicamente hanno sempre presentato dei problemi.<\/p>\n

Abbiamo bisogno di una soluzione puramente front-end per le immagini ad alta risoluzione.<\/p>\n

Vi suona familiare? \u00c8 perch\u00e9 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<\/code>?<\/p>\n<\/div>\n

\n

La soluzione: il caro vecchio progressive enhancement<\/h2>\n

Quelli tra noi che sono coinvolti nei CSS e negli standard web conoscono bene il concetto di progressive enhancement. \u00c8 importante che facciamo fronte comune su questo punto: i pixel, sia in termini di spazio sul device sia in termini di densit\u00e0 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<\/a> se necessario. In effetti, imparare a costruire in maniera appropriata e migliorare progressivamente un sito web pu\u00f2 far risparmiare molto tempo a voi e al vostro cliente.<\/p>\n

Ecco le “regole della strada” che abbiamo seguito io e i miei colleghi di Paravel navigando in questo groviglio di immagini ad alta densit\u00e0:<\/p>\n