Quando parliamo di prestazioni front-end, pensiamo a cose come concatenazione, minificazione, memorizzazione nella cache o risorse gzipping sul server in modo che la pagina si carichi più rapidamente e gli utenti possano completare i loro obiettivi il più rapidamente possibile.
Il prefetching delle risorse è un’altra tecnica di miglioramento delle prestazioni. Possiamo usarlo per dire al browser quali risorse l’utente potrebbe aver bisogno in futuro, prima ancora che ne abbiano bisogno.
Pre-fetching è un modo per suggerire al browser le risorse che verranno utilizzate o che potrebbero essere utilizzate in futuro, alcuni suggerimenti si applicano alla pagina corrente, altri a possibili pagine future.
Come sviluppatori, conosciamo le nostre applicazioni meglio del browser. Possiamo utilizzare queste informazioni per informare il browser sulle risorse principali.
Questa pratica di indovinare ciò di cui gli utenti hanno bisogno prima che ne abbiano bisogno è stata chiamata prebrowsing . Non è solo una singola tecnica, però, si rompe in un certo numero di tecniche diverse: dns-prefetch, subresourceprefetch, preconnecte prerender.
Prefetching DNS
Questo notifica al cliente che ci sono risorse che ci serviranno in seguito da un URL specifico in modo che il browser possa risolvere il DNS il più rapidamente possibile. Diciamo che abbiamo bisogno di una risorsa, come un’immagine o un file audio, dall’URL example.com. Nel <head>del documento scriveremmo:
<link rel="dns-prefetch" href="//mandaz.com">Quindi, quando richiediamo un file da esso, non dovremo più attendere la ricerca DNS. Ciò è particolarmente utile se utilizziamo codice di terze parti o risorse dai social network in cui potremmo caricare un widget da un <script>.
Nel suo epico post di performance front-end , Harry Roberts suggerisce di utilizzare questa tecnica:
Questa semplice linea dirà ai browser di supporto di iniziare a prefetch il DNS per quel dominio una frazione prima che sia effettivamente necessario. Ciò significa che il processo di ricerca DNS sarà già in corso dal momento in cui il browser raggiunge l’elemento di script che richiede effettivamente il widget. Dà solo un piccolo vantaggio al browser.
Questo potrebbe sembrare un miglioramento delle prestazioni così piccolo da non importa molto, ma questo non è necessariamente il caso – Chrome fa qualcosa di simile tutto il tempo . Preassegnerà automaticamente il DNS (ea volte anche il prerender della pagina) se si digita solo una piccola parte del dominio nella barra degli URL, eliminando così i millisecondi cruciali da ogni richiesta.
Preconnect
Proprio come il metodo di prefetch DNS, preconnect risolverà il DNS ma renderà anche l’handshake TCP e la negoziazione TLS opzionale. Può essere usato in questo modo:
<link rel="preconnect" href="http://mandaz.com">Per maggiori informazioni, Ilya Grigorik ha scritto un ottimo post su questo utile suggerimento sulle risorse:
I browser moderni fanno del loro meglio per anticipare le connessioni necessarie per il sito prima che venga effettuata la richiesta effettiva. Avviando i “preconnessioni” iniziali, il browser può impostare in anticipo i socket necessari ed eliminare i costosi roundtrip DNS, TCP e TLS dal percorso critico della richiesta effettiva. Detto questo, per quanto intelligenti siano i browser moderni, non possono prevedere in modo affidabile tutti gli obiettivi di precablazione per ogni sito Web.
La buona notizia è che possiamo – finalmente – aiutare il browser; possiamo dire al browser quali socket avremo bisogno prima di avviare le richieste effettive tramite il nuovo hint preconnect shipping in Firefox 39 e Chrome 46!
Prefetching
Se siamo certi che in futuro sarà richiesta una risorsa specifica, allora possiamo chiedere al browser di richiedere quell’elemento e memorizzarlo nella cache per un riferimento successivo. Ad esempio un’immagine o uno script, o davvero qualcosa che può essere memorizzato nella cache dal browser:
<link rel="prefetch" href="image.png">A differenza del prefetching di DNS, in realtà richiediamo e scarichiamo quella risorsa e la archiviamo nella cache. Tuttavia, questo dipende da una serie di condizioni, poiché il prefetching può essere ignorato dal browser. Ad esempio, un client potrebbe abbandonare la richiesta di un file di font di grandi dimensioni su una rete lenta. Firefox preleverà le risorse solo quando “il browser è inattivo” .
Come spiega Bram Stein nel suo post sull’argomento, questo potrebbe avere enormi benefici in termini di prestazioni per i webfonts. Al momento, i file di font devono aspettare che il DOM e il CSSOM vengano costruiti prima ancora di essere scaricati. Ma, se li prefetch, allora quel collo di bottiglia può essere circumnavigato con facilità.
Nota: sebbene il prefetching delle risorse sia un po ‘difficile da testare, Chrome e Firefox mostreranno le risorse prefetched nel pannello Network. Inoltre, è utile ricordare che non esiste una restrizione di origine identica per il prefetching dei collegamenti.
Risorse secondarie (vedi nota)
Un’altra tecnica di prefetching aiuta a identificare le risorse che hanno la massima priorità e deve essere richiesta prima degli elementi prefissati. Ad esempio, in Chrome e Opera potremmo aggiungere quanto segue al headnostro documento:
<link rel="subresource" href="styles.css">Secondo i documenti di Chromium , funziona in questo modo:
“Link rel = subresource” fornisce un nuovo tipo di relazione di collegamento con semantica diversa da LINK rel = prefetch. Mentre rel = prefetch fornisce un download di risorse a bassa priorità da utilizzare nelle pagine successive, rel = subresource consente il caricamento anticipato delle risorse all’interno della pagina corrente.
Quindi: se la risorsa è richiesta per la pagina corrente, o se è necessaria il prima possibile, allora probabilmente è meglio usarla subresource, altrimenti attenersi a prefetch.
Prerendering pages
Questa è l’opzione nucleare, poiché prerenderci dà la possibilità di caricare preventivamente tutte le risorse di un determinato documento, in questo modo:
<link rel="prerender" href="http://mandaz.com">Steve Souders ha scritto una grande spiegazione su questa tecnica :
È come aprire l’URL in una scheda nascosta: tutte le risorse vengono scaricate, il DOM viene creato, la pagina è strutturata, il CSS è applicato, il JavaScript è eseguito, ecc. Se l’utente naviga verso il specificato
href, allora il la pagina nascosta viene sostituita in vista e sembra caricata istantaneamente. Ricerca Google ha avuto questa funzione per anni sotto il nome di Pagine istantanee. Microsoft ha recentemente annunciato che useranno il prerender in Bing su IE11.
Ma attenzione! Probabilmente dovresti essere certo che l’utente farà clic su quel link, altrimenti il client scaricherà tutte le risorse necessarie a rendere la pagina senza alcun motivo.
Souders continua:
Come con qualsiasi di questo lavoro di previsione, c’è il rischio che la previsione sia sbagliata. Se il lavoro di previsione è costoso (ad esempio, ruba la CPU da altri processi, consuma batteria, o spreca la larghezza di banda), allora la cautela è garantita. Sembrerebbe difficile anticipare a quale pagina andranno gli utenti successivi, ma esistono scenari altamente attendibili:
- Se l’utente ha effettuato una ricerca con un risultato ovvio, è probabile che la pagina dei risultati venga caricata successivamente.
- Se l’utente naviga verso una pagina di accesso, probabilmente la prossima pagina verrà visualizzata.
- Se l’utente sta leggendo un articolo di più pagine o una serie di risultati impaginati, è probabile che la pagina successiva alla pagina corrente sia successiva.
Infine, l’ API di visibilità della pagina può essere utilizzata per proteggersi dagli script che vengono attivati prima che vengano renderizzati sullo schermo dell’utente.
OK, quindi con queste considerazioni di progettazione fuori mano, possiamo parlare di aggiunte future alle specifiche che potrebbero essere di interesse.
Opzione futura: precaricamento
Una nuova specifica chiamata precarico suggerisce che a volte è meglio scaricare sempre una risorsa, indipendentemente dal fatto che il browser pensi che sia una buona idea o meno. A differenza del prefetching delle risorse, che può essere ignorato, le risorse di precaricamento devonoessere richieste dal browser.
<link rel="preload" href="image.png">Quindi, anche se al momento il precaricamento non è supportato da nessun browser , l’idea alla base è sicuramente interessante.
Conclusione
Predire ciò che i nostri utenti faranno dopo è difficile, e certamente richiede un sacco di pianificazione e test. Ma i benefici in termini di prestazioni meritano sicuramente la caccia. Se siamo disposti a sperimentare con queste tecniche di prefetching, siamo sicuri di migliorare l’esperienza dell’utente in modo evidente.