Precaricamento, prerendering e precarico dei service worker

Negli ultimi due moduli hai scoperto concetti come il rinvio del caricamento di JavaScript e il caricamento lento delle immagini e degli elementi <iframe>. Il differimento del caricamento delle risorse riduce l'utilizzo della rete e della CPU durante il caricamento iniziale della pagina scaricando le risorse nel momento in cui sono necessarie, invece di caricarle preventivamente, dove potrebbero potenzialmente rimanere inutilizzate. Questo può migliorare i tempi di caricamento iniziali della pagina, ma le interazioni successive potrebbero comportare un ritardo se le risorse necessarie per alimentarle non sono già caricate al momento in cui si verificano.

Ad esempio, se una pagina contiene un selettore di date personalizzato, puoi rimandare le risorse del selettore della data fino a quando l'utente non interagisce con l'elemento. Tuttavia, il caricamento on demand delle risorse del selettore della data può causare un ritardo, forse leggero, ma forse no, a seconda della connessione di rete, delle funzionalità del dispositivo o di entrambe, fino al download, all'analisi e alla disponibilità delle risorse per l'esecuzione.

È un equilibrio un po' complicato: non vuoi sprecare larghezza di banda caricando risorse che potrebbero rimanere inutilizzate, ma anche ritardare le interazioni e i successivi caricamenti di pagina potrebbero non essere l'ideale. Fortunatamente, esistono diversi strumenti che puoi utilizzare per trovare un migliore equilibrio tra questi due estremi. In questo modulo vengono illustrate alcune tecniche per raggiungere questi obiettivi, come il precaricamento delle risorse, il prerendering di intere pagine e il precaricamento delle risorse nella cache mediante un service worker.

Precarica le risorse necessarie nel prossimo futuro a bassa priorità

È possibile recuperare preventivamente le risorse, inclusi immagini, fogli di stile o risorse JavaScript, utilizzando il suggerimento sulle risorse <link rel="prefetch">. Il suggerimento prefetch indica al browser che probabilmente sarà necessaria una risorsa nel prossimo futuro.

Quando viene specificato un suggerimento prefetch, il browser potrebbe quindi avviare una richiesta per la risorsa con la priorità più bassa per evitare di concorrere con le risorse richieste per la pagina corrente.

Il precaricamento delle risorse può migliorare l'esperienza utente, poiché l'utente non è tenuto ad attendere il download delle risorse necessarie nel prossimo futuro, poiché possono essere recuperate immediatamente dalla cache del disco quando ne hanno bisogno.

<head>
  <!-- ... -->
  <link rel="prefetch" as="script" href="/date-picker.js">
  <link rel="prefetch" as="style" href="/date-picker.css">
  <!-- ... -->
</head>

Lo snippet HTML precedente informa il browser che può precaricare date-picker.js e date-picker.css quando è inattivo. È possibile anche precaricare le risorse in modo dinamico mentre l'utente interagisce con la pagina in JavaScript.

prefetch è supportato in tutti i browser moderni, ad eccezione di Safari, dove è disponibile dietro un flag. Se hai la necessità di caricare preventivamente le risorse del tuo sito web in un modo che funzioni in tutti i browser (e utilizzi un service worker), leggi la sezione più avanti di questo modulo sulla pre-memorizzazione delle risorse nella cache mediante un service worker.

Precarica le pagine per velocizzare le navigazioni future

È anche possibile precaricare una pagina e tutte le relative risorse secondarie specificando l'attributo as="document" quando punta a un documento HTML:

<link rel="prefetch" href="/page" as="document">

Quando il browser è inattivo, potrebbe avviare una richiesta a bassa priorità per /page.

Nei browser basati su Chromium, puoi precaricare i documenti utilizzando l'API Speculation Rules. Le regole di speculazione sono definite come oggetti JSON inclusi nel codice HTML della pagina o aggiunti dinamicamente tramite JavaScript:

<script type="speculationrules">
{
  "prefetch": [{
    "source": "list",
    "urls": ["/page-a", "/page-b"]
  }]
}
</script>

L'oggetto JSON descrive una o più azioni, che attualmente supportano solo prefetch e prerender, e un elenco di URL associati a questa azione. Nello snippet HTML precedente, il browser riceve le istruzioni per precaricare /page-a e /page-b. Analogamente a <link rel="prefetch">, le regole di speculazione sono un suggerimento che il browser potrebbe ignorare in determinate circostanze.

Librerie come Link rapido migliorano la navigazione nelle pagine mediante il precaricamento o il prerendering dinamico dei link alle pagine quando sono visibili all'interno dell'area visibile dell'utente. In questo modo è più probabile che l'utente acceda a quella pagina, rispetto a tutti i link che contiene.

Eseguire il prerendering delle pagine

Oltre a precaricare le risorse, è anche possibile suggerire al browser di eseguire il prerendering di una pagina prima che l'utente la visiti. In questo modo, le pagine vengono caricate quasi immediatamente, poiché la pagina e le relative risorse vengono recuperate ed elaborate in background. Quando l'utente accede alla pagina, questa viene posizionata in primo piano.

Il prerendering è supportato tramite l'API Speculation Rules:

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/page-a", "page-b"]
    }
  ]
}
</script>

Demo di precaricamento e prerendering

Pre-memorizzazione nella cache del service worker

È anche possibile precaricare in modo speculativo le risorse utilizzando un service worker. La pre-memorizzazione nella cache del service worker può recuperare e salvare le risorse utilizzando l'API Cache, consentendo al browser di gestire la richiesta utilizzando l'API Cache senza accedere alla rete. La pre-memorizzazione nella cache del service worker utilizza una strategia di memorizzazione nella cache del service worker molto efficace, nota come strategia solo cache. Questo pattern è molto efficace perché, una volta che le risorse vengono inserite nella cache del service worker, vengono recuperate quasi istantaneamente su richiesta.

Mostra il flusso di memorizzazione nella cache del service worker dalla pagina, al service worker, alla cache.
La strategia solo cache recupera sempre e sempre le risorse idonee dalla rete durante l'installazione del service worker. Una volta installate, le risorse memorizzate nella cache vengono recuperate solo dalla cache del service worker.

Per pre-memorizzare nella cache le risorse utilizzando un service worker, puoi utilizzare Workbox. Tuttavia, se preferisci, puoi scrivere codice personalizzato per memorizzare nella cache un insieme predeterminato di file. In ogni caso decidi di utilizzare un service worker per pre-memorizzare nella cache le risorse, è importante sapere che la pre-memorizzazione nella cache avviene al momento dell'installazione del service worker. Dopo l'installazione, le risorse pre-memorizzate nella cache sono disponibili per il recupero in qualsiasi pagina controllata dal service worker sul tuo sito web.

Workbox utilizza un manifest di pre-memorizzazione nella cache per determinare quali risorse devono essere pre-memorizzate nella cache. Un manifest di pre-cache è un elenco di file e informazioni sul controllo delle versioni che funge da "fonte di riferimento" per le risorse da pre-memorizzare nella cache.

[{  
    url: 'script.ffaa4455.js',
    revision: null
}, {
    url: '/index.html',
    revision: '518747aa'
}]

Il codice precedente è un file manifest di esempio che include due file: script.ffaa4455.js e /index.html. Se una risorsa contiene informazioni sulla versione nel file stesso (nota come hash del file), puoi lasciare la proprietà revision come null, in quanto il file è già sottoposto al controllo delle versioni (ad esempio, ffaa4455 per la risorsa script.ffaa4455.js nel codice precedente). Per le risorse senza versione, è possibile generare una revisione al momento della creazione.

Una volta configurato, un service worker può essere utilizzato per pre-memorizzare nella cache le pagine statiche o le relative risorse secondarie per velocizzare le successive navigazioni tra le pagine.

workbox.precaching.precacheAndRoute([
  '/styles/product-page.ac29.css',
  '/styles/product-page.39a1.js',
]);

Ad esempio, in una pagina della scheda di prodotto di e-commerce è possibile utilizzare un service worker per pre-memorizzare nella cache il CSS e JavaScript necessari per il rendering della pagina dei dettagli del prodotto, rendendo molto più veloce la navigazione alla pagina dei dettagli del prodotto. Nell'esempio precedente, product-page.ac29.css e product-page.39a1.js sono pre-memorizzati nella cache. Il metodo precacheAndRoute disponibile in workbox-precaching registra automaticamente i gestori necessari per garantire che le risorse pre-memorizzate nella cache vengano recuperate dall'API Service worker, se necessario.

Poiché i service worker sono ampiamente supportati, puoi utilizzare la pre-memorizzazione dei service worker su qualsiasi browser moderno in cui la situazione lo richieda.

verifica le tue conoscenze

Con quale priorità si verifica un suggerimento prefetch?

Alto.
Riprova.
Medio.
Riprova.
Bassa.
risposta esatta.

Qual è la differenza tra il prerecupero e il previsualizzazione di una pagina?

Mentre sia un precaricamento che un prerendering di una pagina ricevono una pagina e tutte le relative risorse secondarie, un precaricamento recupera solo la pagina e tutte le relative risorse, mentre un prerendering va oltre, visualizzando l'intera pagina come sfondo finché l'utente non vi accede.
risposta esatta.
Sono sostanzialmente gli stessi: solo un prerendering riceve tutte le sottorisorse di una pagina, contrariamente a un precaricamento.
Riprova.

La cache del service worker e la cache HTTP coincidono.

Vero
Riprova.
falso
risposta esatta.

A seguire: panoramica dei web worker

Ora che sai quanto possano essere utili il precaricamento, il prerendering e la pre-memorizzazione nella cache dei service worker per velocizzare la navigazione verso pagine future, sei in grado di prendere decisioni informate sui vantaggi che possono essere utili per il tuo sito web e i suoi utenti.

A seguire, viene fornita una panoramica dei web worker, spiegando come possono eliminare il lavoro costoso dal thread principale e dare al thread principale più spazio per le interazioni degli utenti. Se ti sei mai chiesto cosa potresti fare per dare più respiro al thread principale, allora i prossimi due moduli ti valgono la pena.