No. 207

Tutti noi vogliamo che i nostri siti siano veloci. Ottimizziamo le immagini, creiamo le sprite CSS, usiamo i CDN, facciamo caching aggressivo, usiamo gzip e minimizziamo il contenuto statico. Usiamo tutti i trucchi da manuale.

Ma possiamo fare ancora di più. Se vogliamo dei risultati più rapidi, dobbiamo pensare in maniera diversa. E se, invece di lasciare i nostri utenti a fissare una spinning wheel aspettando che venga consegnato il contenuto, potessimo predire dove vorrebbero andare dopo? E se potessimo avere quel contenuto pronto per loro ancora prima che lo chiedano?

Tendiamo a vedere il web come un modello reattivo, in cui ogni azione causa una reazione. Gli utenti cliccano e poi noi li portiamo a una nuova pagina. Cliccano di nuovo e noi apriamo un'altra pagina. Ma possiamo fare di meglio. Possiamo essere proattivi con il prebrowsing.

Le tre grandi tecniche

Steve Souders ha coniato il termine prebrowsing (da predictive browsing) in uno dei suoi articoli alla fine dello scorso anno. Il prebrowsing consiste nell'anticipare dove gli utenti vogliono andare e nel preparare quel contenuto in anticipo. È un grande passo verso un internet più veloce e meno visibile.

I browser possono analizzare i pattern per prevedere dove gli utenti andranno successivamente e dare inizio alla risoluzione del DNS e ai TCP handshakes non appena gli utenti passano sopra ai link. Ma per ottenere il massimo da questi miglioramenti, possiamo abilitare il prebrowsing sulle nostre pagine web con tre tecniche a nostra disposizione:

  • DNS prefetching
  • Resource prefetching
  • Prerendering

Esaminiamo ciascuna di queste separatamente.

DNS prefetching

Ogni volta che sappiamo che i nostri utenti probabilmente richiederanno una risorsa da un dominio diverso da quello del nostro sito, possiamo usare il DNS prefetching per riscaldare i motori delle macchine che apriranno il nuovo URL. Il browser può pre-risolvere in anticipo il DNS per il nuovo dominio, facendo risparmiare diversi millisecondi quando l'utente effettivamente lo richiederà. Stiamo giocando d'anticipo e preparandoci per un'azione.

I browser moderni sono molto bravi nel fare il parsing delle pagine, guardando avanti per pre-risolvere tutti i domini necessari in anticipo. Chrome si spinge così in là da tenere un elenco con tutti i domini collegati ogni volta che un utente visita un sito, li pre-risolve quando l'utente ritorna (potete vedere questo elenco navigando su chrome://dns/ nel vostro browser Chrome). Tuttavia, a volte l'accesso ai nuovi URL può essere nascosto dietro ai redirect o incorporato in JavaScript e qui sta la nostra opportunità per aiutare il browser.

Diciamo che stiamo scaricando un insieme di risorse dal dominio cdn.example.com usando una chiamata JavaScript dopo che un utente ha cliccato un pulsante. Normalmente, il browser dovrebbe risolvere il DNS nel momento del click, ma noi possiamo accelerare il processo includendo una direttiva dns-prefetch nella sezione head della nostra pagina:

<link rel="dns-prefetch" href="http://cdn.example.com">

Facendo così si informa il browser dell'esistenza del nuovo dominio ed esso combinerà questo suggerimento con il suo algoritmo di pre-risoluzione per dare inizio alla risoluzione del DNS il prima possibile. L'intero processo sarà più veloce per l'utente dal momento che stiamo eliminando dall'operazione il tempo necessario per la risoluzione del DNS. (Si noti che i browser non garantiscono che la risoluzione del DNS avvenga in anticipo: usano semplicemente il nostro suggerimento come un segnale per il proprio algoritmo interno di pre-risoluzione.)

Ma esattamente, quanto rende più rapide le cose la pre-risoluzione del DNS? Nel vostro browser Chrome, aprite chrome://histograms/DNS e cercate DNS.PrefetchResolution. Vedrete una tabella come questa:

Istogramma per DNS.PrefetchResolution

Questo istogramma mostra la mia personale distribuzione di latenze per le richieste di DNS prefetch. Sul mio computer, per 335 campioni, il tempo medio è 88 millisecondi, con una media di circa 60 millisecondi. Eliminare 88 millisecondi da tutte le richieste che il nostro sito fa verso un dominio esterno? È qualcosa da celebrare!

Ma cosa succede se l'utente non clicca mai sul pulsante per accedere al dominio cdn.example.com? Non stiamo pre-risolvendo inutilmente un dominio? Lo stiamo facendo, ma fortunatamente per noi, il DNS prefetching è un'operazione davvero a basso costo: il browser dovrà mandare solo poche centinaia di byte sulla rete, quindi il rischio che ci assumiamo facendo una ricerca DNS preventiva è molto basso. Detto ciò, non eccedete nell'uso di questa feature: fate il prefetch solo dei domini di cui siete piuttosto sicuri che l'utente vorrà accedervi e lasciate che il browser gestisca il resto.

Cercate situazioni che possano essere ottime candidate per l'introduzione del DNS prefetching sul vostro sito:

  • Risorse su domini diversi nascosti dietro a dei redirect 301
  • Risorse a cui si accede mediante codice JavaScript
  • Risorse per statistiche e social sharing (che solitamente provengono da domini diversi)

Il DNS prefetching è attualmente supportato su IE11, Chrome, Chrome Mobile, Safari, Firefox e Firefox Mobile, il che rende molto diffusa questa feature tra i browser attuali. I browser che attualmente non supportano il DNS prefetching ignoreranno semplicemente il suggerimento e la risoluzione del DNS avverà in maniera regolare.

Resource prefetching

Possiamo spingerci un po' più in là e prevedere che i nostri utenti apriranno una pagina specifica del nostro sito. Se conosciamo alcune delle risorse critiche utilizzate da questa pagina, possiamo istruire il browser a fare il prefetch di queste in anticipo:

        <link rel="prefetch" href="http://cdn.example.com/library.js">
    

Il browser userà questa istruzione per fare il prefetch delle risorse indicate e le memorizzerà nella cache locale. In questo modo, non appena le risorse saranno in effetti necessarie, il browser le avrà lì pronte da mandare.

A differenza del DNS prefetching, il resource prefetching è un'operazione più costosa: state attenti a come e dove la utilizzate. Il prefetch delle risorse può accelerare i nostri siti in modi che non otteremo mai semplicemente facendo il prefetch dei nuovi domini, ma se ne abusiamo, i nostri utenti pagheranno un overhead per qualcosa che non useranno.

Diamo un'occhiata alla dimensione della risposta media di alcune tra le più popolari risorse su una pagina web, cortesemente offerte da HTTP Archive:

Grafico della dimensione di risposta media delle risorse di una pagina web

In media, fare il prefetch di un file di script (come facciamo nell'esempio di cui sopra) causerà la trasmissione di 16kB sulla rete (senza includere la dimensione della richiesta stessa). Questo significa che risparmieremo dal processo 18kB dal tempo di download, più il tempo di risposta del serve, che è stupefacente, sempre che l'utente vi acceda poi dopo. Se l'utente non accede mai al file, potremmo in effetti rendere l'intero workflow più lento introducendo un delay non necessario.

Se decidete di usare questa tecnica, fate il prefetch solo delle risorse più importanti e assicuratevi che il browser le possa mettere in cache. Di solito, le immagini, i CSS, i JavaScript e i files dei font sono buoni candidati per il prefetching, ma le HTML response non lo sono dal momento che non le si può mettere in cache.

Ecco alcune situazioni in cui, data la probabilità che l'utente visiti una pagina specifica, potete fare in anticipo il prefetch delle risorse:

  • Su una pagina di login, dal momento che gli utenti vengono solitamente rediretti a una pagina di benvenuto o a una dashboard dopo aver fatto il login.
  • In ogni pagina di un questionario lineare o di un workflow di un sondaggio, in cui gli utenti visitano pagine in sequenza con un ordine preciso.
  • Su un'animazione multi-step, dato che sapete in anticipo quali sono le immagini necessarie nelle scene successive.

Il resource prefetching attualmente è supportato in IE11, Chrome, Chrome Mobile, Firefox e Firefox Mobile. (Per determinare la compatibilità del browser potete fare un testare velocemente il browser su prebrowsing.com.)

Prerendering

Perché non ci spingiamo oltre e chiediamo un'intera pagina? Supponiamo di essere totalmente sicuri che i nostri utenti visiteranno la pagina about.html del nostro sito. Possiamo dare questo suggerimento al browser:

        <link rel="prerender" href="http://example.com/about.html">
    

Questa volta il browser scaricherà in anticipo e visualizzerà la pagina in background, così da averla pronta per l'utente non appena la chiederà. La transizione dalla pagina corrente a quella pre-visualizzata sarebbe istantanea.

Non è necessario dire che il prerendering è la tecnica più rischiosa e costosa delle tre. Farne cattivo uso può causare grossi sprechi di banda specialmente dannosi per gli utenti sui dispositivi mobile. Per illustrare ciò, diamo un'occhiata a questo grafico, ancora per gentile concessione di HTTP Archive:

Grafico della dimensione di trasferimento totale e delle richieste totali per visualizzare una pagina web

Nel giugno di quest'anno, il numero medio di richieste per rendere una pagina web era 96, con una dimensione totale di 1.808kB. Quindi, se il vostro utente alla fine accede alla pagina pre-visualizzata, allora avrete fatto jackpot: risparmierete il tempo di download di quasi 2.000kB, più il tempo di risposta del server. Ma se vi sbagliate e il vostro utente non accede mai alla pagina pre-visualizzata, gli farete pagare un prezzo molto alto.

Quando dovete decidere se fare in anticipo il prerendering di intere pagine, considerate che Google fa il prerendering dei primi risultati delle sue pagine di ricerca e che Chrome fa la pre-visualizzazione delle pagine basandosi sui pattern della cronologia di navigazione degli utenti. Usando lo stesso principio, potete determinare i pattern di uso comuni e di conseguenza fare il prerender di alcune pagine selezionate. Potete anche usarlo, proprio come il resource prefetching, nei questionari e nei sondaggi in cui sapete che gli utenti completeranno il workflow seguendo un ordine particolare.

Al momento, il prerendering è supportato solo in IE11, Chrome e Chrome Mobile. Né Firefox né Safari hanno ancora aggiunto il supporto per questa tecnica (e, come per il resource prefetching, potete controllare prebrowsing.com per verificare se questa tecnica sia supportata nel vostro browser).

Conclusioni

Siti come Google e Bing utilizzano ampiamente queste tecniche per rendere istantanee le ricerche per i propri utenti. Adesso è ora che torniamo sui nostri siti e li esaminiamo di nuovo. Possiamo rendere migliori e più rapide le nostre esperienze con il prefetching e il prerendering?

I browser stanno già lavorando dietro le quinte per rendere la navigazione quanto più veloce possibile, cercando dei pattern nei nostri siti. Il prebrowsing poggia su queste fondamenta: possiamo combinare i dati che abbiamo derivanti dalle nostre pagine con ulteriori analisi dei pattern degli utenti. Aiutando i browser a fare un lavoro migliore, acceleriamo e miglioriamo l'esperienza dei nostri utenti.

Illustrazioni: Carlo Brigatti

Share/Save/Bookmark
 

Discutiamone

Ti sembra interessante? Scrivi tu il primo commento


Cenni sull'autore

Santiago Valdarrama

Santiago Valdarrama è un software developer che lavora come engineer manager in Levatas. Scrive di tecnologia e software development sul suo blog e twitta cose a caso alle persone che non gli piacciono. Al momento, passa la gran parte del suo tempo lavorando ad applicazioni scalabili e tormentandosi con la performance web.

Questo sito per poter funzionare utilizza i cookie. Per saperne di più visita la pagina relativa all' INFORMATIVA