Memorizzazione nella cache del service worker e memorizzazione nella cache HTTP

I pro e i contro dell'utilizzo di una logica di scadenza coerente o diversa nei livelli della cache del servizio worker e della cache HTTP.

Jonathan Chen

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 illustra la panoramica 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:

1. Cache del servizio worker: il servizio worker controlla se la risorsa è nella sua cache e decide se restituire la risorsa stessa in base alle strategie di memorizzazione nella cache programmate. Tieni conto che questo non avviene automaticamente. Devi creare un gestore eventi di recupero nel servizio worker e intercettare le richieste di rete in modo che vengano pubblicate dalla cache del servizio worker anziché dalla rete.
2. Cache HTTP (nota anche come cache del browser): se la risorsa viene trovata nella cache HTTP e non è ancora scaduta, il browser la utilizza automaticamente dalla cache HTTP.
3. 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, la richiesta deve tornare 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 servizio worker e la cache HTTP hanno lo stesso scopo generale, ma la cache del servizio worker offre più funzionalità di memorizzazione nella cache, come il controllo granulare su cosa viene memorizzato nella cache e su come viene eseguita la memorizzazione nella cache.

Controllo della cache del servizio worker

Un worker di servizio intercetta le richieste HTTP con ascoltatori di eventi (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 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 e casi d'uso della memorizzazione nella cache dei worker di servizio

La tabella successiva illustra le strategie di memorizzazione nella cache dei service worker e quando ciascuna strategia è utile.

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 le risorse della cache HTTP in base all'origine. In altre parole, se hai più sottodomini, questi condividono tutti la stessa cache HTTP. Non sono presenti garantire che i contenuti dell'origine/del dominio rimangano nella cache HTTP per molto tempo. Ad esempio, un utente può svuotare la cache rimuovendo manualmente i dati dall'interfaccia utente delle impostazioni di un browser o attivando un ricaricamento forzato di una pagina. Con una cache di Service worker hai a disposizione probabilità che i contenuti restino memorizzati nella cache. Per scoprire di più, consulta Spazio di 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 dei worker di servizio, puoi attenuare i piccoli "intoppi" molto più facilmente (con la strategia "stale-while-revalidate"), offrire un'esperienza offline completa (con la strategia "Cache only") o anche qualcosa di intermedia, come UI personalizzate con parti della pagina provenienti dalla cache del worker di servizio e alcune parti escluse (con la strategia "Set catch handler") ove opportuno.

Memorizzazione nella cache HTTP

La prima volta che un browser carica una pagina web e le risorse correlate, le memorizza nella cache HTTP. In genere, la cache HTTP viene attivata automaticamente dai browser, a meno che non sia stata disattivata esplicitamente dall'utente finale.

L'utilizzo della memorizzazione nella cache HTTP significa fare affidamento sul server per determinare quando memorizzare nella cache una risorsa e per quanto tempo.

Controlla la scadenza della cache HTTP con le intestazioni delle risposte HTTP

Quando un server risponde alla richiesta di una risorsa da parte di un browser, utilizza le intestazioni di risposta HTTP per indicare al browser per quanto tempo deve memorizzare nella cache la risorsa. Per saperne di più, consulta Intestazioni di risposta: configura il tuo server web.

Strategie e casi d'uso della memorizzazione nella cache HTTP

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.

Progettare la logica di scadenza della cache

Questa sezione illustra i pro e i contro dell'utilizzo di una logica di scadenza coerente nei livelli della cache del servizio 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 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, esamineremo tre scenari: a lungo termine, a medio termine e a breve termine.

Scenario: memorizzazione nella cache a lungo termine (cache, ripristino della rete)

• Quando una risorsa memorizzata nella cache è valida (<= 30 giorni): il service worker restituisce immediatamente 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 la recupera lato server.

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 (non valido durante la convalida)

• 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 (> 1 giorno): il service worker restituisce immediatamente la risorsa memorizzata nella cache e accede 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'ulteriore eliminazione della cache per eseguire l'override della cache HTTP al fine di sfruttare al meglio il passaggio "Convalida di nuovo".

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 la restituisce al service worker senza passare al 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 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 nei livelli HTTP e della cache 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.

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-while-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 nella sua cache HTTP, quindi la richiesta viene eseguita lato server.

Pro e contro:

• Vantaggio: gli utenti ricevono una risposta immediata perché il service worker restituisce immediatamente le risorse memorizzate nella cache.
• Vantaggio: il service worker può assicurarsi che la prossima richiesta per un determinato URL utilizzi una risposta aggiornata della rete, grazie alla convalida che avviene "in background".
• Svantaggio: è necessaria una strategia di memorizzazione nella cache del servizio 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 servizio worker (<= 1 giorno): il servizio worker accede alla rete per recuperare la risorsa. Il browser restituisce la risorsa dall'interfaccia HTTP , se presente. Se la rete non è disponibile, il service worker restituisce la risorsa dalla 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:

• Vantaggio: quando la rete è instabile o non è disponibile, il worker del servizio restituisce immediatamente le risorse memorizzate nella cache.
• Svantaggio: il worker del servizio richiede un'ulteriore eliminazione della cache per eseguire l'override della cache HTTP e effettuare richieste "Priorità alla rete".

Conclusione

Data la complessità della combinazione di scenari di memorizzazione nella cache, non è possibile progettare una sola regola che copra tutti i casi. Tuttavia, in base ai risultati delle sezioni precedenti, ecco alcuni suggerimenti da considerare quando progetti le tue 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 svolge ancora 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 tuo worker di servizio fornisca il suo valore, senza entrare in conflitto con la cache HTTP.

Scopri di più

• Affidabilità della rete
• Impedire le richieste di rete non necessarie con la cache HTTP
• Codelab sulla cache HTTP
• Misurare l'impatto reale delle prestazioni dei lavoratori dei servizi
• Cache-Control e Expires
• Decodifica della cache: ispeziona, svuota e disattiva le cache