I pro e i contro dell'utilizzo di una logica di scadenza coerente o diversa tra i livelli della cache del service worker e della cache HTTP.
Sebbene i service worker e le PWA stiano diventando standard delle moderne applicazioni web, la memorizzazione nella cache delle risorse è diventata più complessa che mai. Questo articolo illustra il quadro generale della memorizzazione nella cache del browser, tra cui:
- I casi d'uso e le differenze tra la memorizzazione nella cache del service worker e la memorizzazione nella cache HTTP.
- I pro e i contro delle diverse strategie di scadenza della memorizzazione nella cache del service worker rispetto alle normali strategie di memorizzazione nella cache HTTP.
Panoramica del flusso di memorizzazione nella cache
A livello generale, un browser segue l'ordine di memorizzazione nella cache riportato di seguito quando richiede una risorsa:
- Cache del service worker: il service worker controlla se la risorsa è presente nella cache e decide se restituire la risorsa stessa in base alle strategie di memorizzazione nella cache programmate. Tieni presente che questa operazione non avviene automaticamente. Devi creare un gestore di eventi fetch nel service worker e intercettare le richieste di rete in modo che le richieste vengano pubblicate dalla cache del service worker anziché dalla rete.
- Cache HTTP (nota anche come cache del browser): se la risorsa viene trovata nella cache HTTP e non è ancora scaduta, il browser utilizza automaticamente la risorsa dalla cache HTTP.
- Lato server: se non viene trovato nulla nella cache del service worker o nella cache HTTP, il browser si connette alla rete per richiedere la risorsa. Se la risorsa non è memorizzata nella cache di una CDN, la richiesta deve tornare al server di origine.
Livelli di memorizzazione nella cache
Memorizzazione nella cache del service worker
Un service worker intercetta le richieste HTTP di tipo rete e utilizza una strategia di memorizzazione nella cache per determinare quali risorse devono essere restituite al browser. La cache del service worker e la cache HTTP hanno lo stesso scopo generale, ma la cache del service worker offre più funzionalità di memorizzazione nella cache, come il controllo granulare di ciò che viene memorizzato nella cache e di come viene eseguita la memorizzazione nella cache.
Controllo della cache del service worker
Un service worker intercetta le richieste HTTP con i listener
di eventi (in genere l'evento fetch). Questo
snippet di codice mostra la logica di una
strategia di memorizzazione nella cache Cache-First.
Ti consigliamo vivamente di utilizzare Workbox per evitare di reinventare la ruota. Ad esempio, puoi registrare i percorsi degli URL delle risorse con una sola riga di codice di espressione regolare.
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
Strategie e casi d'uso per la memorizzazione nella cache del service worker
La tabella seguente descrive le strategie comuni di memorizzazione nella cache del service worker e quando ogni strategia è utile.
| Strategie | Motivazione dell'aggiornamento | Casi d'uso |
|---|---|---|
| Solo rete | I contenuti devono essere aggiornati in ogni momento. |
|
| Rete con fallback alla cache | È preferibile pubblicare i contenuti aggiornati. Tuttavia, se la rete non funziona o è instabile, è accettabile pubblicare contenuti leggermente obsoleti. |
|
| Stale-while-revalidate | È possibile pubblicare subito i contenuti memorizzati nella cache, ma in futuro devono essere utilizzati i contenuti memorizzati nella cache aggiornati. |
|
| Cache first, fall back to network | I contenuti non sono critici e possono essere pubblicati dalla cache per migliorare il rendimento, ma il service worker deve controllare occasionalmente gli aggiornamenti. |
|
| Solo cache | I contenuti cambiano raramente. |
|
Vantaggi aggiuntivi della memorizzazione nella cache del service worker
Oltre al controllo granulare della logica di memorizzazione nella cache, la memorizzazione nella cache del service worker fornisce anche:
- Più memoria e spazio di archiviazione per l'origine: il browser alloca le risorse della cache HTTP in base all'origine. In altre parole, se hai più sottodomini, tutti condividono la stessa cache HTTP. Non è garantito che i contenuti dell'origine/del dominio rimangano nella cache HTTP per un lungo periodo di tempo. Ad esempio, un utente può svuotare la cache eseguendo una pulizia manuale dall'interfaccia utente delle impostazioni di un browser o attivando un ricaricamento forzato di una pagina. Con una cache del service worker è molto più probabile che i contenuti memorizzati nella cache rimangano memorizzati nella cache. Per saperne di più, consulta Archiviazione permanente.
- Maggiore flessibilità con reti instabili o esperienze offline: con la cache HTTP hai solo una scelta binaria: la risorsa è memorizzata nella cache o meno. Con la memorizzazione nella cache del service worker puoi mitigare più facilmente i piccoli "problemi" (con la strategia "stale-while-revalidate"), offrire un'esperienza offline completa (con la strategia "Solo cache") o anche qualcosa di intermedio, come UI personalizzate con parti della pagina provenienti dalla cache del service worker e alcune parti escluse (con la strategia "Imposta gestore di intercettazione") a seconda dei casi.
Memorizzazione nella cache HTTP
La prima volta che un browser carica una pagina web e le risorse correlate, le memorizza nella cache HTTP. La cache HTTP è in genere attivata automaticamente dai browser, a meno che non sia stata disattivata esplicitamente dall'utente finale.
L'utilizzo della memorizzazione nella cache HTTP significa affidarsi al server per determinare quando memorizzare una risorsa nella cache e per quanto tempo.
Controllare la scadenza della cache HTTP con le intestazioni delle risposte HTTP
Quando un server risponde a una richiesta di una risorsa da parte di un browser, utilizza le intestazioni delle risposte HTTP per indicare a un browser per quanto tempo deve memorizzare la risorsa nella cache. Per saperne di più, consulta Intestazioni delle risposte: configurare il server web.
Strategie e casi d'uso per la memorizzazione nella cache HTTP
La memorizzazione nella cache HTTP è molto più semplice della memorizzazione nella cache del service worker, perché la memorizzazione nella cache HTTP gestisce solo la logica di scadenza delle risorse basata sul tempo (TTL). Per saperne di più sulle strategie di memorizzazione nella cache HTTP, consulta Quali valori delle intestazioni delle risposte devi utilizzare? e Impedire richieste di rete non necessarie con la cache HTTP (riepilogo).
Progettare la logica di scadenza della cache
Questa sezione illustra i pro e i contro dell'utilizzo di una logica di scadenza coerente tra i livelli della cache del service worker e della cache HTTP, nonché i pro e i contro di una logica di scadenza separata tra questi livelli.
Logica di scadenza coerente per tutti i livelli della cache
Per illustrare i pro e i contro, esamineremo tre scenari: a lungo termine, a medio termine e a breve termine.
| Scenarios | Memorizzazione nella cache a lungo termine | Memorizzazione nella cache a medio termine | Memorizzazione nella cache a breve termine |
|---|---|---|---|
| Strategia di memorizzazione nella cache del service worker | Cache, con fallback alla rete | Stale-while-revalidate | Rete con fallback alla cache |
| TTL della cache del service worker | 30 giorni | 1 giorno | 10 minuti |
| max-age della cache HTTP | 30 giorni | 1 giorno | 10 minuti |
Scenario: memorizzazione nella cache a lungo termine (cache, con fallback alla rete)
- Quando una risorsa memorizzata nella cache è valida (<= 30 giorni): il service worker restituisce immediatamente la risorsa memorizzata nella cache senza connettersi alla rete.
- Quando una risorsa memorizzata nella cache è scaduta (> 30 giorni): il service worker si connette alla rete per recuperare la risorsa. Il browser non ha una copia della risorsa nella cache HTTP, quindi si connette al server per recuperarla.
Contro: in questo scenario, la memorizzazione nella cache HTTP fornisce meno valore perché il browser passerà sempre la richiesta al server quando la cache scade nel service worker.
Scenario: memorizzazione nella cache a medio termine (stale-while-revalidate)
- Quando una risorsa memorizzata nella cache è valida (<= 1 giorno): il service worker restituisce immediatamente la risorsa memorizzata nella cache e si connette alla rete per recuperarla. Il browser ha una copia della risorsa nella cache HTTP, quindi la restituisce al service worker.
- Quando una risorsa memorizzata nella cache è scaduta (> 1 giorno): il service worker restituisce immediatamente la risorsa memorizzata nella cache e si connette alla rete per recuperarla. Il browser non ha una copia della risorsa nella cache HTTP, quindi si connette lato server per recuperarla.
Contro: il service worker richiede un'ulteriore eliminazione della cache per sostituire la cache HTTP al fine di sfruttare al meglio il passaggio "revalidate".
Scenario: memorizzazione nella cache a breve termine (rete con fallback alla cache)
- Quando una risorsa memorizzata nella cache è valida (<= 10 minuti): il service worker si connette alla rete per recuperare la risorsa. Il browser ha una copia della risorsa nella cache HTTP, quindi la restituisce al service worker senza connettersi al server.
- Quando una risorsa memorizzata nella cache è scaduta (> 10 minuti): il service worker restituisce immediatamente la risorsa memorizzata nella cache e si connette alla rete per recuperarla. Il browser non ha una copia della risorsa nella cache HTTP, quindi si connette lato server per recuperarla.
Contro: analogamente allo scenario di memorizzazione nella cache a medio termine, il service worker richiede un'ulteriore logica di eliminazione della cache per sostituire la cache HTTP al fine di recuperare la risorsa più recente dal server.
Service worker in tutti gli scenari
In tutti gli scenari, la cache del service worker può comunque restituire le risorse memorizzate nella cache quando la rete è instabile. D'altra parte, la cache HTTP non è affidabile quando la rete è instabile o non funziona.
Logica di scadenza della cache diversa nei livelli della cache del service worker e della cache HTTP
Per illustrare i pro e i contro, esamineremo di nuovo gli scenari a lungo termine, a medio termine e a breve termine.
| Scenarios | Memorizzazione nella cache a lungo termine | Memorizzazione nella cache a medio termine | Memorizzazione nella cache a breve termine |
|---|---|---|---|
| Strategia di memorizzazione nella cache del service worker | Cache, con fallback alla rete | Stale-while-revalidate | Rete con fallback alla cache |
| TTL della cache del service worker | 90 giorni | 30 giorni | 1 giorno |
| max-age della cache HTTP | 30 giorni | 1 giorno | 10 minuti |
Scenario: memorizzazione nella cache a lungo termine (cache, con fallback alla rete)
- Quando una risorsa memorizzata nella cache è valida nella cache del service worker (<= 90 giorni): il service worker restituisce immediatamente la risorsa memorizzata nella cache.
- Quando una risorsa memorizzata nella cache è scaduta nella cache del service worker (> 90 giorni): il service worker si connette alla rete per recuperare la risorsa. Il browser non ha una copia della risorsa nella cache HTTP, quindi si connette lato server.
Pro e contro:
- Pro: gli utenti sperimentano una risposta immediata perché il service worker restituisce immediatamente le risorse memorizzate nella cache.
- Pro: il service worker ha un controllo più granulare su quando utilizzare la cache e quando richiedere nuove versioni delle risorse.
- Contro: è necessaria una strategia di memorizzazione nella cache del service worker ben definita.
Scenario: memorizzazione nella cache a medio termine (stale-while-revalidate)
- Quando una risorsa memorizzata nella cache è valida nella cache del service worker (<= 30 giorni): il service worker restituisce immediatamente la risorsa memorizzata nella cache.
- Quando una risorsa memorizzata nella cache è scaduta nella cache del service worker (> 30 giorni): il service worker si connette alla rete per recuperare la risorsa. Il browser non ha una copia della risorsa nella cache HTTP, quindi si connette al server.
Pro e contro:
- Pro: gli utenti sperimentano una risposta immediata perché il service worker restituisce immediatamente le risorse memorizzate nella cache.
- Pro: grazie alla convalida che avviene "in background", il service worker può garantire che la prossima richiesta di un determinato URL utilizzi una risposta aggiornata dalla rete.
- Contro: è necessaria una strategia di memorizzazione nella cache del service worker ben definita.
Scenario: memorizzazione nella cache a breve termine (rete con fallback alla cache)
- Quando una risorsa memorizzata nella cache è valida nella cache del service worker (<= 1 giorno): il service worker si connette alla rete per recuperare la risorsa. Il browser restituisce la risorsa dalla cache HTTP, se presente. Se la rete non funziona, il service worker restituisce la risorsa dalla cache del service worker.
- Quando una risorsa memorizzata nella cache è scaduta nella cache del service worker (> 1 giorno): il service worker si connette alla rete per recuperare la risorsa. Il browser recupera le risorse dalla rete perché la versione memorizzata nella cache nella cache HTTP è scaduta.
Pro e contro:
- Pro: quando la rete è instabile o non funziona, il service worker restituisce immediatamente le risorse memorizzate nella cache.
- Contro: il service worker richiede un'ulteriore eliminazione della cache per sostituire la cache HTTP ed effettuare richieste "Network first".
Conclusione
Data la complessità della combinazione di scenari di memorizzazione nella cache, non è possibile progettare una regola che copra tutti i casi. Tuttavia, in base ai risultati delle sezioni precedenti, ecco alcuni suggerimenti da tenere in considerazione quando progetti le tue strategie di memorizzazione nella cache:
- La logica di memorizzazione nella cache del service worker non deve essere coerente con la logica di scadenza della memorizzazione nella cache HTTP. Se possibile, utilizza una logica di scadenza più lunga nel service worker per concedere al service worker un maggiore controllo.
- La memorizzazione nella cache HTTP svolge ancora un ruolo importante, ma non è affidabile quando la rete è instabile o non funziona.
- Rivedi le strategie di memorizzazione nella cache per ogni risorsa per assicurarti che la strategia di memorizzazione nella cache del service worker fornisca il suo valore, senza entrare in conflitto con la cache HTTP.