I pro e i contro dell'utilizzo di una logica di scadenza coerente o diversa nei livelli della cache del Service worker e nei livelli della cache HTTP.
Sebbene i service worker e le PWA stanno diventando degli standard delle moderne applicazioni web, la memorizzazione nella cache delle risorse è diventata più complessa che mai. Questo articolo tratta 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 quella HTTP.
- Vantaggi e svantaggi delle 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 è nella cache e decide se restituire la risorsa stessa in base alle strategie di memorizzazione nella cache programmate. Nota che ciò non avvenga automaticamente. Devi creare un gestore di eventi di recupero nel il service worker e intercettare le richieste di rete in modo che vengano fornite dal servizio alla cache del worker anziché alla rete.
- Cache HTTP (nota anche come cache del browser): se la risorsa si trova nella sezione HTTP Cache e non è ancora scaduta, il browser utilizza automaticamente la classe dalla cache HTTP.
- Lato server: se non trova nulla nella cache del service worker o nella cache HTTP, un browser va alla rete per richiedere la risorsa. Se la risorsa non è memorizzata nella cache in una CDN, deve risalire al server di origine.
Memorizzazione nella cache dei livelli
Memorizzazione nella cache dei service worker
Un service worker intercetta le richieste HTTP di tipo di rete e utilizza una strategia di memorizzazione nella cache per determinare quali risorse devono essere restituite al browser. La cache del service worker e il protocollo La cache del servizio ha lo stesso scopo generico, ma offre maggiori funzionalità di memorizzazione nella cache. ad esempio un controllo granulare su ciò che viene memorizzato nella cache e sulle modalità di esecuzione della memorizzazione nella cache.
Controllo della cache del service worker
Un service worker intercetta le richieste HTTP con event
listener (di solito l'evento fetch). Questo
Lo snippet di codice dimostra la logica di uno
Prima cache
di memorizzazione nella cache.
Ti consigliamo vivamente di utilizzare Workbox per evitare reinventando 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 e casi d'uso per la memorizzazione nella cache dei service worker
La tabella successiva illustra le strategie di memorizzazione nella cache dei service worker e quando ciascuna strategia è utile.
| Strategie | Motivazione per l'aggiornamento | Casi d'uso |
|---|---|---|
| Rete | I contenuti devono essere sempre aggiornati. |
|
| Rete utilizzando la cache | È preferibile pubblicare contenuti aggiornati. Tuttavia, se la rete si arresta o è instabile, accettabile per la pubblicazione di contenuti leggermente obsoleti. |
|
| Inattivo-durante-riconvalida | I contenuti memorizzati nella cache possono essere pubblicati immediatamente, ma è consigliabile utilizzare i contenuti memorizzati nella cache aggiornati per il futuro. |
|
| Prima cache, poi fallback alla rete | I contenuti non sono critici e possono essere pubblicati dalla cache per migliorare le prestazioni, ma il Service worker dovrebbe di tanto in tanto controllare se ci sono aggiornamenti disponibili. |
|
| Solo cache | Raramente cambiano i contenuti. |
|
Ulteriori vantaggi della memorizzazione nella cache dei service worker
Oltre al 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 una cache HTTP delle risorse in base all'origine. In altre Se hai più sottodomini, avranno tutti la stessa cache HTTP. Non sono presenti garantire che i contenuti dell'origine/del dominio rimangano nella cache HTTP per molto tempo. Per Ad esempio, un utente può svuotare la cache manualmente eliminando l'interfaccia utente delle impostazioni del browser che attiva il ricaricamento forzato di una pagina. Con una cache di Service worker hai a disposizione probabilità che i contenuti restino memorizzati nella cache. Vedi Persistente spazio di archiviazione per saperne di più.
- Maggiore flessibilità con reti instabili o esperienze offline: con la cache HTTP hanno solo una scelta binaria: se la risorsa è memorizzata o meno nella cache. Con memorizzazione nella cache dei service worker puoi mitigare i piccoli "singhiozzi" molto più semplice (con la strategia offrire un'esperienza offline completa (con la strategia "Solo cache") o persino qualcosa in come UI personalizzate con parti della pagina provenienti dalla cache del service worker e escluse alcune parti (con la strategia "Imposta gestore di recupero") laddove opportuno.
Memorizzazione nella cache HTTP
La prima volta che un browser carica una pagina web e le risorse correlate, le memorizza nel suo Cache HTTP. La cache HTTP viene solitamente attivata automaticamente dai browser, a meno che non sia stata esplicitamente disattivato dall'utente finale.
Utilizzare la memorizzazione nella cache HTTP significa fare affidamento sul server per determinare quando memorizzare una risorsa nella cache e come lunga.
Controlla la scadenza della cache HTTP con le intestazioni delle risposte HTTP
Quando un server risponde a una richiesta del browser per una risorsa, utilizza le intestazioni delle risposte HTTP per indicare a un browser per quanto tempo deve memorizzare la risorsa nella cache. Consulta la sezione Intestazioni delle risposte: server web per saperne di più.
Strategie di memorizzazione nella cache HTTP e casi d'uso
La memorizzazione nella cache HTTP è molto più semplice rispetto alla memorizzazione nella cache dei service worker, in quanto la memorizzazione nella cache HTTP riguarda solo la logica di scadenza delle risorse basata sul tempo (TTL). Consulta Quali valori di intestazione della risposta dovresti usare? e Riepilogo per saperne di più sulle strategie di memorizzazione nella cache HTTP.
Progettazione della logica di scadenza della cache
Questa sezione illustra i pro e i contro dell'utilizzo di una logica di scadenza coerente nel Service worker e HTTP Cache, oltre ai pro e ai contro di una logica di scadenza separata diversi strati.
Il Glitch riportato di seguito mostra come la memorizzazione nella cache dei service worker e della memorizzazione nella cache HTTP funzionano in azione scenari diversi:
Logica di scadenza coerente per tutti i livelli della cache
Per dimostrare i pro e i contro, osserveremo 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 dei service worker | Cache, fallback alla rete | Inattivo-durante-riconvalida | Rete di riserva nella cache |
| TTL cache del service worker | 30 giorni | 1 giorno | 10 min |
| Durata massima cache HTTP | 30 giorni | 1 giorno | 10 min |
Scenario: memorizzazione nella cache a lungo termine (cache, fallback alla rete)
- Quando una risorsa memorizzata nella cache è valida (<= 30 giorni): il service worker restituisce la risorsa memorizzata nella cache senza accedere alla rete.
- Quando una risorsa memorizzata nella cache è scaduta (> 30 giorni): il service worker va alla rete per per recuperare la risorsa. Il browser non ha una copia della risorsa nella cache HTTP, quindi va sul lato server per la risorsa.
Contro: in questo scenario, la memorizzazione nella cache HTTP fornisce meno valore perché il browser passare la richiesta al lato 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 la risorsa memorizzata nella cache e va alla rete per recuperarla. Il browser ha una copia la risorsa nella sua cache HTTP, quindi restituisce quella copia al service worker.
- Quando una risorsa memorizzata nella cache è scaduta (più di 1 giorno): il service worker restituisce la risorsa memorizzata nella cache e va alla rete per recuperarla. Il browser non dispone di della risorsa nella cache HTTP, quindi passa dal lato server per recuperarla.
Svantaggio: il service worker richiede un busting della cache aggiuntivo per eseguire l'override della cache HTTP per sfruttare al meglio la funzione passaggio.
Scenario: memorizzazione nella cache a breve termine (fallimento della rete nella cache)
- Quando una risorsa memorizzata nella cache è valida (<= 10 minuti): il service worker va alla rete per recuperare la risorsa. Il browser ha una copia della risorsa nella cache HTTP, quindi restituisce al service worker senza passare dal lato server.
- Quando una risorsa memorizzata nella cache è scaduta (> 10 minuti): il service worker restituisce la risorsa memorizzata nella cache e va alla rete per recuperarla. Il browser non dispone di della risorsa nella cache HTTP, quindi passa dal lato server per recuperarla.
Contro: in modo simile allo scenario di memorizzazione nella cache a medio termine, il service worker richiede della logica di busting della cache per eseguire l'override della cache HTTP al fine di recuperare la risorsa più recente dal lato server.
Service worker in tutti gli scenari
In tutti gli scenari, la cache del service worker può comunque restituire risorse memorizzate nella cache quando la rete instabile. D'altra parte, la cache HTTP non è affidabile quando la rete è instabile o non disponibile.
Logica di scadenza della cache diversa a livello di cache e livelli HTTP del service worker
Per dimostrare i pro e i contro, esamineremo nuovamente le metriche a lungo termine, a medio e a breve termine diversi scenari.
| Scenari | Memorizzazione nella cache a lungo termine | Memorizzazione nella cache a medio termine | Memorizzazione nella cache a breve termine |
|---|---|---|---|
| Strategia di memorizzazione nella cache dei service worker | Cache, fallback alla rete | Inattivo-durante-riconvalida | Rete di riserva nella cache |
| TTL cache del service worker | 90 giorni | 30 giorni | 1 giorno |
| Durata massima cache HTTP | 30 giorni | 1 giorno | 10 min |
Scenario: memorizzazione nella cache a lungo termine (cache, fallback alla rete)
- Quando una risorsa memorizzata nella cache è valida nella cache del Service worker (<= 90 giorni): il servizio il worker restituisce immediatamente la risorsa memorizzata nella cache.
- Quando una risorsa memorizzata nella cache è scaduta nella cache del service worker (> 90 giorni): il servizio il worker va alla rete per recuperare la risorsa. Il browser non dispone di una copia del nella cache HTTP, quindi va sul lato server.
Pro e contro:
- Pro: gli utenti ricevono una risposta immediata quando il service worker restituisce le risorse memorizzate nella cache. immediatamente.
- Pro: il service worker ha un controllo più granulare su quando usare la cache e quando per richiedere nuove versioni delle risorse.
- Contro: è necessaria una strategia di memorizzazione nella cache dei service worker ben definita.
Scenario: memorizzazione nella cache a medio termine (Stale-until-revalidate)
- Quando una risorsa memorizzata nella cache è valida nella cache del Service worker (<= 30 giorni): il servizio il worker restituisce immediatamente la risorsa memorizzata nella cache.
- Quando una risorsa memorizzata nella cache è scaduta nella cache del service worker (più di 30 giorni): il servizio il worker va alla rete per cercare la risorsa. Il browser non ha una copia della risorsa in dalla cache HTTP, quindi va dal lato server.
Pro e contro:
- Pro: gli utenti ricevono una risposta immediata quando il service worker restituisce le risorse memorizzate nella cache. immediatamente.
- Pro: il service worker può garantire che la richiesta next per un determinato URL utilizzi un nuova risposta dalla rete, grazie alla riconvalida che avviene "in background".
- Contro: è necessaria una strategia di memorizzazione nella cache dei service worker ben definita.
Scenario: memorizzazione nella cache a breve termine (fallimento della rete nella cache)
- Quando una risorsa memorizzata nella cache è valida nella cache del Service worker (<= 1 giorno): il servizio il worker va alla rete per cercare la risorsa. Il browser restituisce la risorsa dall'HTTP , se presente. Se la rete non è attiva, il service worker restituisce la risorsa dal cache del service worker
- Quando una risorsa memorizzata nella cache è scaduta nella cache del service worker (più di 1 giorno): il servizio il worker va alla rete per recuperare la risorsa. Il browser recupera le risorse tramite perché la versione memorizzata nella cache HTTP è scaduta.
Pro e contro:
- Pro: quando la rete è instabile o non disponibile, il service worker restituisce una copia cache risorse immediatamente.
- Svantaggio: il service worker richiede un ulteriore busting della cache per eseguire l'override della cache HTTP e imposta "Prima la rete" richieste.
Conclusione
Data la complessità della combinazione di scenari di memorizzazione nella cache, non è possibile progettare un'unica regola che copre tutti i casi. Tuttavia, sulla base dei risultati nelle sezioni precedenti, ci sono alcune suggerimenti da considerare durante la progettazione delle strategie di cache:
- La logica di memorizzazione nella cache dei service worker non deve essere coerente con la scadenza della memorizzazione nella cache HTTP logica. Se possibile, utilizza una logica di scadenza più lunga nel service worker per concederlo un maggiore controllo.
- La memorizzazione nella cache HTTP continua ad avere un ruolo importante, ma non è affidabile quando la rete instabile o non stabile.
- Riesamina le tue strategie di memorizzazione nella cache per ogni risorsa per assicurarti che la memorizzazione nella cache del Service worker che fornisce il proprio valore, senza essere in conflitto con la cache HTTP.