Rendere performanti i siti web responsive

C’è stato un tempo in cui potevi distinguere con sicurezza tra una pagina web desktop e una pagina web mobile. Tanto è vero, infatti, che un intero settore è cresciuto attorno al riutilizzo di siti desktop per dispositivi mobili.

Per un po’ non eri nessuno se non avevi un sito mobile separato su un dominio separato. Poi le cose iniziarono a cambiare.

I display mobili sono migliorati oltre ogni riconoscimento. Così hanno fatto i browser mobili. I tablet hanno gettato un altro elemento nell’equazione. È arrivato il 4G. I display Retina offrivano nuovi livelli di chiarezza per gli utenti finali.

Improvvisamente, il confine tra desktop e mobile sembrava sfocato.

Allo stesso tempo, c’era una crescente diversità nelle dimensioni e nella risoluzione dei display desktop.

E un mal di testa crescente per i web designer.

Sono finiti i giorni in cui dovevi soddisfare solo una manciata di dimensioni di viewport. Le cose si stavano complicando.

Fortunatamente, l’aiuto era a portata di mano sotto forma di query sui media e il concetto di responsive design.

Grazie alle media query, è diventato possibile variare gli stili e il layout, persino il contenuto, a seconda della larghezza del viewport dell’utente e della risoluzione dello schermo. Naturalmente, le media query non sono affatto l’unico strumento nella borsa dei trucchi del responsive designer, ma è giusto dire che costituiscono la base della tecnica.

Questa è stata un’ottima notizia per i dispositivi mobili. Il design reattivo significava che potevi fornire in modo efficace diverse versioni dello stesso sito a dispositivi diversi. Il tutto senza sviluppare un sito mobile separato su un dominio diverso.

E le prestazioni?

I proprietari dei siti stanno iniziando a rendersi conto che gli utenti finali si preoccupano delle prestazioni. I rivenditori, in particolare, stanno iniziando ad apprezzare il fatto che ridurre i millisecondi del tempo di caricamento può tradursi in milioni in bilancio.

Fortunatamente, i siti reattivi offrono un chiaro vantaggio in termini di prestazioni rispetto ai loro cugini mobili dedicati: il reindirizzamento a un dominio mobile viene eliminato.

Tuttavia, nonostante ciò, il responsive design è riuscito ad acquisire una certa reputazione per le scarse prestazioni.

Per certi versi, questo è piuttosto ingiusto, ma vale la pena considerare le sfide prestazionali extra che il design reattivo pone agli incauti…

immagini

I file immagine sono grandi. E poiché sono grandi, sono spesso responsabili dei tempi di caricamento lenti. Sono quindi un buon punto di partenza per chiunque cerchi di ottimizzare le prestazioni di un sito.

Sfortunatamente, una delle prime soluzioni per fornire immagini in modo reattivo non era eccezionale per le prestazioni.

La tecnica è meravigliosamente semplice. Basta usare max-width: 100% per assicurarsi che le immagini si ridimensionino in base alla larghezza dell’elemento contenitore:

img
{
max-width: 100%;
}

Man mano che il contenitore si restringe per adattarsi a finestre più piccole, tutte le immagini all’interno si ridurranno con esso. Facile!

Ma c’è un problema. La dimensione dell’immagine potrebbe ridursi sullo schermo, ma la dimensione del file rimane la stessa. Questo è tutt’altro che ideale dal punto di vista delle prestazioni. Potresti inviare un’immagine di 800 x 800 pixel lungo il filo, solo per essere visualizzata a 80 x 80 pixel: in altre parole, potresti trasmettere centinaia (o migliaia) di byte non necessari. Non solo il caricamento dell’immagine richiederà molto tempo, ma tutti quei byte ridondanti potrebbero esaurire la preziosa quantità di dati dell’utente finale.

Tuttavia, questo non è l’unico, e nemmeno il migliore, modo per fornire immagini reattive. Per prima cosa, un’immagine che funziona a 800 pixel di larghezza non funzionerà necessariamente altrettanto bene a varie frazioni di quella dimensione.

Per risolvere questo problema, puoi utilizzare una media query per visualizzare diverse versioni dell’immagine a seconda delle dimensioni del viewport utilizzando una media query e display: nessuna.

CSS:

@media (min-width: 601px) {
#croppedImage
{
display:none;
}
}
@media (max-width: 600px) {
#largeImage
{
display:none;
}
}

codice HTML:

<img id="largeImage" width="400" height="400" alt="" src="images/largeImage.webp">
<img id="croppedImage" width="200" height="200" alt="" src="images/croppedImage.webp">

Ciò consente di visualizzare diverse versioni di un’immagine, anziché solo la stessa immagine in dimensioni diverse. Tuttavia, non riduce il numero di byte. In effetti, la dimensione complessiva della pagina sarà maggiore, poiché verranno caricate tutte le immagini, indipendentemente dal fatto che siano visualizzate o meno.

Un’alternativa migliore, se pratica, è usare immagini di sfondo al <divs>posto degli <img>elementi. Questo è preferibile perché le immagini a cui si fa riferimento in CSS vengono caricate solo se vengono utilizzate (purché non siano URI di dati):

@media (min-width: 601px) {
#largeImage
{
width:400px;
height:400px;
background-image:url(/images/largeImage.webp);
}
#croppedImage
{
display:none;
}
}
 
@media (max-width: 600px) {
#croppedImage
{
width:200px;
height:200px;
background-image:url(/images/croppedImage.webp);
}
#largeImage
{
display:none;
}
}

Funziona bene: i visitatori scaricano solo le immagini di cui hanno bisogno, come e quando ne hanno bisogno. Il problema è che è disordinato, trattando efficacemente il contenuto come stile. In quanto tale, crea potenzialmente un problema di manutenibilità e potrebbe anche far sì che immagini importanti vengano ignorate dai motori di ricerca.

Invece, perché non utilizzare SVG (scalable vector graphics): un formato immagine che scala per sua stessa natura? Le immagini SVG hanno anche il vantaggio di essere facilmente stilizzate con i CSS (guarda questo fantastico tutorial su come rendere gli SVG reattivi con i CSS). Questo è perfetto per icone e loghi, ma sfortunatamente non sarai in grado di utilizzare SVG per le foto: per questi dovrai ricorrere a formati raster, come JPEG.

Un’altra opzione è utilizzare una delle numerose soluzioni JavaScript per fornire immagini reattive. Questo è un modo popolare per farlo, ma aggiunge un altro livello di complessità. Inoltre, poiché JavaScript blocca la costruzione del DOM, qualsiasi soluzione che coinvolga JavaScript ha il potenziale per ostacolare il rendering. Quindi, mentre ci sono alcuni plugin molto intelligenti là fuori, semplicemente introducendo JavaScript nell’equazione, in una certa misura ti stai rassegnando al minore dei due mali.

Fino a poco tempo fa, queste erano le uniche opzioni.

Ora, tuttavia, gli elementi <picture>e <source>e gli attributi srcset e size stanno finalmente portando sul web immagini veramente reattive. La nuova specifica sta inoltre iniziando a ottenere il supporto del browser, con il pieno supporto in Chrome e Opera e il supporto per il cambio di risoluzione in Safari. Fino a quando gli altri browser non si mettono al passo, c’è un eccellente polyfill JavaScript .

In questo nuovo mondo coraggioso, puoi utilizzare srcset per impostare un elenco di immagini candidate tra cui il browser può scegliere. È quindi possibile utilizzare una media query nell’attributo sizes per dettare la dimensione a cui verrà visualizzata l’immagine. Utilizzando l’ <picture>elemento insieme alle media query all’interno di uno o più elementi, puoi specificare un diverso intervallo di immagini per condizioni diverse (ad es. per finestre fino a una certa larghezza, usa l’immagine a, b o c, e per finestre più grandi usa l’immagine x, y o z). Ciò è utile se devi fornire una versione ritagliata di un’immagine per gli utenti con schermi piccoli.

I dettagli precisi su come utilizzare la nuova sintassi esulano dallo scopo di questo articolo, ma puoi trovare un eccellente tutorial su alistapart.

Forse l’unico svantaggio di questa nuova specifica è che è piuttosto prolisso, il che potrebbe significare HTML gonfio su pagine con molte immagini. Tuttavia, i vantaggi superano di gran lunga gli svantaggi.

Caricamento di CSS di cui non hai (necessariamente) bisogno

Sebbene le media query ti permettano di applicare diverse regole CSS a seconda dei criteri che hai impostato, non c’è scampo dal fatto che gli utenti finali dovranno scaricare tutto il CSS che potrebbe essere applicato. Questo è vero anche se inserisci il tuo CSS in file separati e inserisci la tua media query nell’elemento <link>.

Ad esempio, verranno caricati entrambi i seguenti fogli di stile, indipendentemente dalla larghezza del viewport:

<link rel="stylesheet" media="(max-width: 600px)" href="css/style1.css">
<link rel="stylesheet" media="(min-width: 601px)" href="css/style2.css">

Questo non è un bug del browser. I criteri utilizzati nelle query multimediali spesso si riferiscono a cose che cambiano durante una visita a una pagina. Ad esempio, un visitatore può decidere di ridimensionare la finestra del browser o ruotare il proprio tablet/dispositivo mobile. La modifica risultante nella visualizzazione dovrebbe essere perfetta e l’invio di una richiesta per un altro file CSS sarebbe tutt’altro che ideale. Ciò è particolarmente vero per i dispositivi mobili, che cercano di chiudere i collegamenti radio il prima possibile per preservare la carica della batteria. Potenzialmente dover ristabilire quel collegamento quando le dimensioni del viewport cambiano potrebbe essere una cattiva notizia per la durata della batteria.

Tuttavia, Chrome si sforza di gestire questi diversi file in modo intelligente. Mentre tutti i file verranno scaricati, solo quello con la media query attualmente corrispondente bloccherà il rendering. Tutti gli altri verranno caricati con priorità inferiore.

Sfortunatamente, altri browser non sono altrettanto premurosi. In Firefox, ad esempio, i file CSS inutilizzati non solo bloccano il rendering, ma bloccano anche il caricamento di altri oggetti sulla pagina.

Il grafico a cascata qui sotto illustra il punto. Le immagini in questa pagina non iniziano a caricarsi fino a quando il file CSS inutilizzato non è stato scaricato completamente:

Puoi aggirare questo problema utilizzando JavaScript per caricare i CSS in modo condizionale ma, come abbiamo già visto, JavaScript ha i suoi costi in termini di prestazioni.

Che cosa significa tutto questo per le prestazioni di un sito reattivo rispetto a un sito mobile?

Bene, gli utenti mobili e gli utenti desktop su un sito reattivo dovranno scaricare lo stesso CSS.

E ce ne sarà di più di quanto ce ne sarebbe su un sito progettato solo per desktop o dispositivi mobili.

Inoltre, è più probabile che un sito mobile dedicato utilizzi una versione più leggera e ridotta del CSS desktop (anche se questo è forse meno vero ora, poiché gli utenti crescono e si aspettano un’esperienza più ricca su display mobili sempre più sofisticati).

Quindi, a parità di altre condizioni, sembra che ci sia qualcosa nell’argomentazione secondo cui è probabile che un sito reattivo sia più lento di un sito mobile a causa del CSS aggiuntivo richiesto. Tuttavia, fintanto che i progettisti sono consapevoli delle potenziali insidie, dovrebbero essere in grado di creare fogli di stile a caricamento rapido per un sito reattivo. In particolare è bene:

• evitare di utilizzare URI di dati per le immagini: le immagini di sfondo binarie verranno (normalmente) caricate solo se/quando sono necessarie, ma tutti gli URI di dati verranno caricati a prescindere.
• mantienilo leggero: poiché tutti i CSS devono essere scaricati, è importante essere efficienti. Ciò significa evitare duplicazioni e assicurarsi che le regole globali siano impostate al di fuori del CSS basato su media query.

RESS (Responsive Web Design + Componenti lato server)

RESS è un ibrido tra design reattivo e adattivo, che prevede lo sniffing dell’agente utente sul server per esaminare le caratteristiche del dispositivo client e fornire contenuti appropriati ad esso.

Se una delle obiezioni al design reattivo è che implica la distribuzione di tutti i contenuti su tutti i dispositivi, perché non mitigare questo problema eliminando parte di quei contenuti dove è possibile?

Questo può avere molto senso. Se c’è un’immagine che sai che non vorresti mai visualizzare su dispositivi il cui schermo è al di sotto di una certa dimensione, potresti anche non inviarla a quei dispositivi, risparmiando larghezza di banda e riducendo i tempi di caricamento.

Inoltre, se stai utilizzando query multimediali che sai non potrebbero essere soddisfatte su determinati dispositivi, c’è almeno un argomento per separare il tuo CSS in file diversi e caricarli in modo condizionale.

Vale la pena ricordare che l’intero processo non è "gratuito" in termini di prestazioni. Ovviamente è necessario eseguire del lavoro sul server, il che richiede tempo, probabilmente non abbastanza per superare i vantaggi, ma è qualcosa di cui essere consapevoli.

Il verdetto

I siti responsive sono lenti?

Dipende cosa intendi per lento.

È probabile che il sito reattivo più veloce che potresti realizzare sia più lento del sito mobile dedicato più veloce che potresti realizzare?

Probabilmente.

Abbiamo anche visto che ci sono alcune insidie. Se non stai attento, è facile finire per costringere gli utenti a scaricare molte immagini e CSS ridondanti, rendendo il tuo sito reattivo molto più lento di quanto dovrebbe essere.

Tuttavia, non deve essere così. È perfettamente possibile creare un sito reattivo che sia altrettanto veloce quanto deve essere e offra un’esperienza utente eccellente. E poiché sia ​​gli standard che i browser iniziano a mettersi al passo con ciò che gli sviluppatori vogliono offrire, dovrebbe iniziare a diventare più facile.