Taglia unica: una guida alle soluzioni di immagini di web design reattive

Man mano che i dispositivi mobili e tablet si avvicinano al raggiungimento del dominio finale del mondo, il web design e la tecnologia sono in corsa per adattarsi al numero sempre crescente di dimensioni dello schermo. Tuttavia, l'ideazione di strumenti per affrontare le sfide di questo fenomeno comporta una serie completamente nuova di problemi, con una delle ultime parole d'ordine che è emersa è "web reattivo". Questa è la sfida di far funzionare il Web sulla maggior parte, se non su tutti, i dispositivi senza degradare l'esperienza dell'utente. Invece di progettare contenuti per adattarsi a desktop o laptop, le informazioni devono essere disponibili per telefoni cellulari, tablet o qualsiasi superficie connessa al Web. Tuttavia, questa evoluzione del responsive web design si è rivelata difficile e talvolta dolorosa.

Sebbene possa essere quasi banale ospitare informazioni testuali, la parte difficile arriva quando prendiamo in considerazione contenuti come immagini reattive, infografiche, video e così via, che una volta erano progettati pensando solo ai desktop. Questo non solo solleva la questione della corretta visualizzazione del contenuto, ma anche di come il contenuto stesso viene consumato utilizzando dispositivi diversi. Gli utenti sugli smartphone sono diversi dagli utenti sui desktop. Devono essere considerati anche aspetti come i piani dati e la velocità di elaborazione. Google ha iniziato a mettere in evidenza i siti ottimizzati per i dispositivi mobili nei suoi risultati di ricerca, con alcuni che ipotizzano che porterà a un sostanziale aumento del pagerank di tali siti. Le soluzioni precedenti risolvevano questo problema distribuendo sottodomini (e reindirizzamenti) solo per dispositivi mobili, ma questa aumentava la complessità ed è rapidamente passata di moda. (Non tutti i siti hanno la possibilità di permettersi questo percorso.)

Alla ricerca di immagini Web reattive

A questo punto, sviluppatori e designer devono assicurarsi che il caricamento del loro sito Web sia ottimizzato per soddisfare gli utenti che si trovano su siti mobili. Oltre il 20% del traffico web è ora costituito da utenti mobili e il numero è ancora in aumento. Con le immagini che prendono tra le maggiori condivisioni di dati sui contenuti della pagina, diventa una priorità ridurre questo carico. Sono stati fatti diversi tentativi per semplificare il ridimensionamento dell'immagine del design reattivo, incluse soluzioni lato server e front-end. Per discutere di queste soluzioni di immagini reattive, dobbiamo prima comprendere le attuali carenze di collegamento delle immagini.

Il tag <img> ha solo l'attributo sorgente che collega direttamente all'immagine stessa. Non ha modo di determinare il tipo corretto di immagine necessaria senza alcun componente aggiuntivo.

Non possiamo semplicemente avere tutte le dimensioni dell'immagine incluse nell'HTML e utilizzare le regole CSS per display:none for all ma l'immagine corretta? Questa è la soluzione più logica in un mondo logico perfetto. In questo modo il browser può ignorare tutte le immagini non visualizzate e, in teoria, non scaricarle. Tuttavia, i browser sono ottimizzati oltre la logica comune. Per rendere la pagina abbastanza veloce, il browser precarica il contenuto collegato prima che anche i fogli di stile e i file JavaScript necessari siano completamente caricati. Invece di ignorare le immagini di grandi dimensioni destinate ai desktop, finiamo per aver scaricato tutte le immagini e ottenere un caricamento della pagina ancora più grande. La tecnica solo CSS funziona solo per le immagini intese come immagini di sfondo perché queste possono essere impostate all'interno del foglio di stile (usando le media query).

Allora, cosa deve fare un sito web?

Soluzioni di ridimensionamento delle immagini reattive back-end

Escludendo i siti/sottodomini solo per dispositivi mobili, ci resta lo sniffing user-agent (UA) e il suo utilizzo per restituire all'utente le immagini di dimensioni corrette. Tuttavia, qualsiasi sviluppatore può attestare quanto possa essere inaffidabile questa soluzione. Nuove stringhe UA continuano a spuntare continuamente, rendendo faticoso mantenere e aggiornare un elenco completo. E, naturalmente, questo non tiene nemmeno conto dell'inaffidabilità delle stringhe UA facilmente falsificabili in primo luogo.

Immagini adattive

Tuttavia, alcune soluzioni lato server meritano di essere prese in considerazione. Adaptive Images è un'ottima soluzione per coloro che preferiscono una correzione dell'immagine reattiva di back-end. Non richiede alcun markup speciale ma utilizza invece un piccolo file JavaScript e fa la maggior parte del lavoro pesante nel suo file di back-end. Utilizza un server configurato PHP e nginx. Inoltre, non si basa su alcuno sniffing UA ma controlla invece la larghezza dello schermo. Adaptive Images funziona alla grande per ridimensionare le immagini, ma è utile anche quando le immagini di grandi dimensioni necessitano di una direzione artistica, ad esempio la riduzione dell'immagine mediante tecniche come il ritaglio e la rotazione, non semplicemente il ridimensionamento.

Sencha Touch

Sencha Touch è un'altra soluzione di immagine di design reattivo di back-end, anche se è meglio riferirsi ad essa come una soluzione di terze parti. Sencha Touch ridimensionerà l'immagine di conseguenza annusando l'UA. Di seguito è riportato un esempio di base di come funziona il servizio:

 <img src="http://src.sencha.io/http://example.com/images/kitty_cat.jpg" alt="My Kitty Cat">

C'è anche un'opzione per specificare le dimensioni dell'immagine, nel caso in cui non desideriamo che Sencha ridimensioni l'immagine automaticamente.

Alla fine della giornata, le soluzioni lato server (e di terze parti) richiedono risorse per elaborare la richiesta prima di inviare l'immagine corretta. Ciò richiede tempo prezioso e, a sua volta, rallenta il viaggio richiesta-risposta. Una soluzione migliore potrebbe essere se il dispositivo stesso determinasse quali risorse richiedere direttamente e il server rispondesse di conseguenza.

Soluzioni front-end

Negli ultimi tempi, ci sono stati grandi miglioramenti sul lato browser per indirizzare le immagini reattive.

L'elemento <picture> è stato introdotto e approvato nella specifica HTML5 dal W3C. Attualmente non è ampiamente disponibile su tutti i browser ma non passerà molto tempo prima che sia disponibile in modo nativo. Fino ad allora, ci affidiamo ai polyfill JavaScript per l'elemento. I Polyfill sono anche un'ottima soluzione per i browser legacy privi dell'elemento.

C'è anche il caso dell'attributo srcset che è disponibile per diversi browser basati su webKit per l'elemento <img> . Questo può essere utilizzato senza JavaScript ed è un'ottima soluzione se i browser non webKit devono essere ignorati. È un utile tampone per il caso strano in cui altre soluzioni non sono sufficienti, ma non dovrebbe essere considerata una soluzione completa.

Picturefill

Picturefill è una libreria polyfill per l'elemento <picture> . È una delle librerie più popolari tra le soluzioni front-end per i problemi di ridimensionamento e ridimensionamento delle immagini. Ci sono due versioni; Picturefill v1 imita l'elemento <picture> utilizzando span mentre Picturefill v2 utilizza l'elemento <picture> tra i browser che già lo offrono e fornisce un polyfill per quelli legacy (ad esempio, per IE >= IE9). Ha alcune limitazioni e soluzioni alternative, in particolare per Android 2.3, che per inciso è un esempio di dove l'attributo img srcset viene in soccorso. Di seguito è riportato un esempio di markup per l'utilizzo di Picturefill v2:

 <picture> <source media="(min-width: 768px)"> <source media="(max-width: 767px)"> <img alt="My Kitty Cat"> </picture>

Per migliorare le prestazioni degli utenti con piani dati limitati, Picturefill può essere combinato con il caricamento lento. Tuttavia, la libreria potrebbe offrire un più ampio supporto del browser e affrontare i casi strani piuttosto che fare affidamento sulle patch.

Imager.js

Imager.js è una libreria creata dal team di BBC News per realizzare immagini reattive con un approccio diverso da quello utilizzato da Picturefill. Mentre Picturefill tenta di portare l'elemento <picture> su browser non supportati, Imager.js si concentra sul download solo delle immagini appropriate, tenendo d'occhio anche le velocità della rete. Incorpora anche il caricamento lento senza fare affidamento su librerie di terze parti. Funziona utilizzando elementi segnaposto e sostituendoli con elementi <img> . Il codice di esempio riportato di seguito mostra questo comportamento:

 <div> <div class="image-load" data-src="http://example.com/images/kitty_{width}.jpg" data-alt="My Kitty Cat"></div> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

L'HTML visualizzato sarà simile a questo:

 <div> <img src="http://example.com/images/kitty_480.jpg" data-src="http://example.com/images/kitty_{width}.jpg" alt="My Kitty Cat" class="image-replace"> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>

Il supporto del browser è molto migliore di quello di Picturefill a scapito di essere una soluzione più pragmatica di una lungimirante.

Mischiare la fonte

Source Shuffling affronta il problema dell'immagine reattiva da un'angolazione leggermente diversa rispetto al resto delle librerie front-end. Assomiglia a qualcosa uscito dalla scuola di pensiero "mobile first", per cui offre la risoluzione più piccola possibile per impostazione predefinita. Dopo aver rilevato che un dispositivo ha uno schermo più grande, scambia la sorgente dell'immagine con un'immagine più grande. Sembra più un hack e meno una libreria a tutti gli effetti. Questa è un'ottima soluzione per i siti principalmente mobili, ma significa che il doppio download di risorse per desktop e/o tablet è inevitabile.

Alcune altre librerie JavaScript degne di nota sono:

• HiSRC - Un plug-in jQuery per immagini reattive. La dipendenza da jQuery potrebbe essere un problema.
• Mobify.js - Una libreria più generale per contenuti reattivi, incluse immagini, fogli di stile e persino JavaScript. "Cattura" il DOM prima del caricamento delle risorse. Mobify è una potente libreria completa, ma potrebbe essere eccessiva se l'obiettivo sono solo immagini reattive.

Sommario

Alla fine della giornata, spetta allo sviluppatore decidere quale approccio all'immagine di web design reattivo si adatta alla base di utenti. Ciò significa che la raccolta e il test dei dati daranno un'idea migliore dell'approccio da adottare.

Per concludere, l'elenco di domande di seguito può essere utile da considerare prima di decidere la soluzione di immagine reattiva appropriata.

• I browser legacy sono un problema? In caso contrario, considera l'utilizzo di un approccio più moderno (ad es. Picturefill, attributo srcset )
• Il tempo di risposta è critico? In caso contrario, scegli una soluzione di terze parti o di back-end.
• Le soluzioni dovrebbero essere interne? Le soluzioni di terze parti saranno ovviamente escluse.
• Ci sono già molte immagini su un sito che sta tentando di passare a immagini reattive? Ci sono preoccupazioni sulla convalida o sui tag semantici (o piuttosto sui tag non semantici)? Ciò richiederà una soluzione back-end per instradare le richieste di immagini a qualcosa come le immagini adattive.
• La direzione artistica è un problema (in particolare per immagini di grandi dimensioni con molte informazioni)? Una libreria come Picturefill sarà una soluzione migliore per uno scenario del genere. Inoltre, funzionerà anche qualsiasi soluzione di back-end.
• C'è una preoccupazione per la mancanza di JavaScript? Qualsiasi soluzione front-end sarà fuori questione, il che lascia le opzioni back-end o di terze parti che si basano sullo sniffing UA.
• C'è una priorità per i tempi di risposta mobile rispetto ai tempi di risposta desktop? Una libreria come Source Shuffling potrebbe essere più appropriata.
• È necessario fornire un comportamento reattivo a ogni aspetto del sito, non solo alle immagini? Mobify.js potrebbe funzionare meglio.
• Il mondo perfetto è stato raggiunto? Usa solo CSS display:none approccio!