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.
Mentre i service worker e le PWA stanno diventando gli 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 dei service worker e la memorizzazione nella cache HTTP.
- I pro e i contro di diverse strategie di scadenza della memorizzazione nella cache dei 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 si trova nella sua cache e decide se restituirla in base alle sue strategie di memorizzazione nella cache programmate. Tieni presente che questo 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 fornite dalla cache del worker di servizio anziché dalla rete.
- Cache HTTP (nota anche come cache del browser): se la risorsa si trova nella cache HTTP e non è ancora scaduta, il browser la utilizza automaticamente.
- Lato server: se non viene trovato nulla nella cache del service worker o nella cache HTTP, il browser accede alla rete per richiedere la risorsa. Se la risorsa non viene memorizzata nella cache in una rete CDN, la richiesta deve tornare al server di origine.
Memorizzazione nella cache dei livelli
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 restituire al browser. La cache del service worker e quella HTTP hanno lo stesso scopo generico, ma offre maggiori funzionalità di memorizzazione nella cache, come un controllo granulare su ciò che viene memorizzato nella cache e sulle relative modalità di memorizzazione.
Controllo della cache dei service worker
Un service worker intercetta le richieste HTTP con gli ascoltatori di eventi (di solito l'evento fetch). Questo snippet di codice dimostra 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 singola riga di codice regex.
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
Strategie di memorizzazione nella cache e casi d'uso dei service worker
La tabella successiva descrive le strategie comuni di memorizzazione nella cache dei service worker e quando ciascuna strategia è utile.
| Strategie | Motivazione per l'aggiornamento | Casi d'uso |
|---|---|---|
| Solo rete | I contenuti devono essere sempre aggiornati. |
|
| Networking di riserva nella cache | È preferibile pubblicare contenuti aggiornati. Tuttavia, se la rete presenta problemi o è instabile, è accettabile pubblicare contenuti leggermente vecchi. |
|
| Riconvalida in caso di inattività | È consentito pubblicare subito i contenuti memorizzati nella cache, ma in futuro dovrebbero essere utilizzati i contenuti memorizzati nella cache aggiornati. |
|
| Prima la cache, poi la rete di riserva | I contenuti non sono critici e possono essere forniti dalla cache per migliorare le prestazioni, ma il service worker di tanto in tanto dovrebbe controllare la disponibilità di aggiornamenti. |
|
| Solo cache | I contenuti cambiano raramente. |
|
Ulteriori vantaggi della memorizzazione nella cache dei service worker
Oltre a un controllo granulare della logica di memorizzazione nella cache, la memorizzazione nella cache dei service worker offre anche:
- Più memoria e spazio di archiviazione per l'origine: il browser alloca le risorse della cache HTTP in base alla 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ò eliminare definitivamente la cache eliminando manualmente l'interfaccia utente delle impostazioni del browser o attivando un riavvio forzato di una pagina. La cache di un service worker ha una probabilità molto maggiore che i contenuti memorizzati nella cache rimangano memorizzati nella cache. Per ulteriori informazioni, consulta Archiviazione permanente.
- Maggiore flessibilità in caso di reti instabili o esperienze offline: con la cache HTTP puoi scegliere solo se la risorsa deve essere memorizzata nella cache o meno. Con la memorizzazione nella cache dei service worker puoi ridurre molto più facilmente i piccoli "singhiozzi" (con la strategia "stale-while-revalidate"), offrire un'esperienza offline completa (con la strategia "Solo cache") o anche qualcosa di intermedio, ad esempio UI personalizzate con parti della pagina provenienti dalla cache del service worker e alcune parti escluse (con la strategia "Imposta gestore di rilevamento"), ove opportuno.
Memorizzazione nella cache HTTP
La prima volta che un browser carica una pagina web e le risorse correlate, le archivia nella cache HTTP. La cache HTTP viene generalmente attivata automaticamente dai browser, a meno che non sia stata disattivata esplicitamente dall'utente finale.
Utilizzare la memorizzazione nella cache HTTP significa affidarsi al server per determinare quando memorizzare una risorsa nella cache e per quanto tempo.
Controlla la scadenza della cache HTTP con le intestazioni delle risposte HTTP
Quando un server risponde a una richiesta del browser relativa a una risorsa, il server utilizza le intestazioni della risposta HTTP per indicare al browser per quanto tempo deve memorizzare la risorsa nella cache. Per saperne di più, consulta Intestazioni di risposta: configurare il server web.
Strategie di memorizzazione nella cache HTTP e casi d'uso
La memorizzazione nella cache HTTP è molto più semplice rispetto a quella dei service worker, poiché la memorizzazione nella cache HTTP gestisce solo la logica di scadenza delle risorse basata sul tempo (TTL). Consulta Quali valori dell'intestazione della risposta devi utilizzare? e Riepilogo per scoprire di più sulle strategie di memorizzazione nella cache HTTP.
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 in questi livelli.
Il glitch riportato di seguito mostra come funzionano la memorizzazione nella cache HTTP e la memorizzazione nella cache dei service worker in azione in scenari diversi:
Logica di scadenza coerente per tutti i livelli di cache
Per illustrarne i pro e i contro, esamineremo tre scenari: a lungo termine, a medio termine e a breve termine.
| Scenari | 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, passaggio alla rete | Riconvalida in caso di inattività | Errore di rete nella cache |
| TTL cache del service worker | 30 giorni | 1 giorno | 10 min |
| Durata massima della cache HTTP | 30 giorni | 1 giorno | 10 min |
Scenario: memorizzazione nella cache a lungo termine (cache, passaggio alla rete)
- Quando una risorsa memorizzata nella cache è valida (<= 30 giorni): il service worker restituisce la risorsa memorizzata nella cache immediatamente senza accedere alla rete.
- Quando una risorsa memorizzata nella cache è scaduta (più di 30 giorni): il service worker accede alla rete per recuperarla. Il browser non dispone di una copia della risorsa nella cache HTTP, pertanto la risorsa va lato server.
Svantaggio: in questo scenario, la memorizzazione nella cache HTTP offre meno valore perché il browser passerà sempre la richiesta al lato server quando la cache scade nel service worker.
Scenario: memorizzazione nella cache a medio termine (Inattivo, riconvalidare)
- Quando una risorsa memorizzata nella cache è valida (<= 1 giorno): il service worker restituisce immediatamente la risorsa memorizzata nella cache e accede alla rete per recuperarla. Il browser ha una copia della risorsa nella sua cache HTTP, quindi restituisce la copia al service worker.
- Quando una risorsa memorizzata nella cache è scaduta (più di un giorno), il service worker restituisce immediatamente la risorsa memorizzata nella cache e accede alla rete per recuperarla. Il browser non dispone di una copia della risorsa nella cache HTTP, quindi recupera la risorsa dal lato server.
Contro: il service worker richiede un busting della cache aggiuntivo per sostituire la cache HTTP al fine di utilizzare al meglio il passaggio di "riconvalida".
Scenario: memorizzazione nella cache a breve termine (fallback di rete nella cache)
- Quando una risorsa memorizzata nella cache è valida (<= 10 minuti): il service worker accede alla rete per recuperare la risorsa. Il browser include una copia della risorsa nella cache HTTP, in modo che venga restituita al service worker senza passare dal lato server.
- Quando una risorsa memorizzata nella cache è scaduta (> 10 minuti), il service worker restituisce immediatamente la risorsa memorizzata nella cache e accede alla rete per recuperarla. Il browser non dispone di una copia della risorsa nella cache HTTP, quindi recupera la risorsa dal lato server.
Svantaggio: simile allo scenario di memorizzazione nella cache a medio termine, il service worker richiede una logica di busting della cache aggiuntiva per eseguire l'override della cache HTTP per recuperare la risorsa più recente dal lato server.
Service worker in tutti gli scenari
In tutti gli scenari, la cache dei service worker può comunque restituire le risorse memorizzate nella cache quando la rete è instabile. La cache HTTP, invece, non è affidabile quando la rete è instabile o non disponibile.
Logica di scadenza della cache diversa a livello di cache del service worker e di livello HTTP
Per illustrarne i pro e i contro, esamineremo nuovamente gli scenari a lungo termine, a medio termine e a breve termine.
| Scenari | 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, passaggio alla rete | Riconvalida in caso di inattività | Errore di rete nella cache |
| TTL cache del service worker | 90 giorni | 30 giorni | 1 giorno |
| Durata massima della cache HTTP | 30 giorni | 1 giorno | 10 min |
Scenario: memorizzazione nella cache a lungo termine (cache, passaggio alla rete)
- Quando una risorsa memorizzata nella cache è valida nella cache del service worker (<= 90 giorni): il worker di servizio restituisce immediatamente la risorsa memorizzata nella cache.
- Quando una risorsa memorizzata nella cache è scaduta nella cache del service worker (> 90 giorni), il worker del servizio accede alla rete per recuperare la risorsa. Il browser non dispone di una copia della risorsa nella cache HTTP, quindi passa al lato server.
Pro e contro:
- Pro: gli utenti riscontrano una risposta immediata poiché 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.
- Svantaggio: è necessaria una strategia di memorizzazione nella cache del service worker ben definita.
Scenario: memorizzazione nella cache a medio termine (instabile durante la riconvalida)
- Quando una risorsa memorizzata nella cache è valida nella cache del service worker (<= 30 giorni): il worker di servizio restituisce immediatamente la risorsa memorizzata nella cache.
- Quando una risorsa memorizzata nella cache è scaduta nella cache del service worker (più di 30 giorni), il worker del servizio accede alla rete per la risorsa. Il browser non dispone di una copia della risorsa nella cache HTTP, quindi va lato server.
Pro e contro:
- Pro: gli utenti riscontrano una risposta immediata poiché il service worker restituisce immediatamente le risorse memorizzate nella cache.
- Pro: il service worker può garantire che la richiesta next per un determinato URL utilizzi una risposta aggiornata dalla rete, grazie alla riconvalida che avviene "in background".
- Svantaggio: è necessaria una strategia di memorizzazione nella cache del service worker ben definita.
Scenario: memorizzazione nella cache a breve termine (fallback di rete nella cache)
- Quando una risorsa memorizzata nella cache è valida nella cache del service worker (<= 1 giorno): il worker di servizio accede alla rete per reperire la risorsa. Il browser restituisce la risorsa dalla cache HTTP, se presente. Se la rete non è attiva, 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 worker del servizio accede alla rete per recuperare la risorsa. Il browser recupera le risorse sulla rete poiché la versione memorizzata nella cache HTTP è scaduta.
Pro e contro:
- Pro: quando la rete è instabile o non disponibile, il service worker restituisce immediatamente le risorse memorizzate nella cache.
- Svantaggio: il service worker richiede un busting della cache aggiuntivo per eseguire l'override della cache HTTP ed effettuare richieste "Network first".
Conclusione
Data la complessità della combinazione di scenari di memorizzazione nella cache, non è possibile progettare un'unica regola che copra tutti i casi. Tuttavia, in base ai risultati delle sezioni precedenti, ci sono alcuni suggerimenti da prendere in considerazione quando si progettano le strategie di 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 concedergli un maggiore controllo.
- La memorizzazione nella cache HTTP continua a svolgere un ruolo importante, ma non è affidabile quando la rete è instabile o non disponibile.
- Rivedi le strategie di memorizzazione nella cache per ogni risorsa per assicurarti che la strategia di memorizzazione nella cache del service worker fornisca il proprio valore senza entrare in conflitto con la cache HTTP.