Gli utenti che caricano il tuo sito una seconda volta utilizzeranno la cache HTTP, quindi funziona bene.
Questo post è un complemento del video Love your cache, parte della serie Contenuti al Chrome Dev Summit 2020. Assicurati di guardare il video:
Quando gli utenti caricano il sito una seconda volta, il loro browser utilizza le risorse interne cache HTTP per velocizzare il caricamento. Ma gli standard per la memorizzazione nella cache web risalgono al 1999, sono definiti in modo abbastanza ampio, determinando se un file, come un CSS o un'immagine, possa essere recuperato nuovamente dalla rete e caricato dalla cache è un po' una scienza inesatta.
In questo post, vi parlerò di un'impostazione predefinita moderna e sensata per la memorizzazione nella cache, in realtà non viene memorizzata nella cache. Ma questa è solo l'impostazione predefinita ed più articolato rispetto alla semplice "disattivazione". Continua a leggere.
Obiettivi
Quando un sito viene caricato per la seconda volta, hai due obiettivi:
- Assicurati che gli utenti ricevano la versione più aggiornata disponibile, se hai cambiato qualcosa, le modifiche dovrebbero riflettersi rapidamente
- Esegui la procedura n. 1 mentre recuperi il meno possibile la quantità di dati dalla rete.
Nel senso più ampio, vuoi inviare ai clienti solo la modifica minima quando caricano nuovamente il sito. e strutturare il sito in modo da garantire la distribuzione efficiente di qualsiasi cambiamento è difficile (maggiori informazioni di seguito e il video).
Detto questo, esistono anche altre manopole quando si considera la memorizzazione nella cache, magari hai deciso di lasciare che la cache HTTP del browser di un utente conservasse il tuo sito per un periodo prolungato in modo che non siano necessarie richieste di rete per la sua pubblicazione. Oppure hai ha creato un service worker che distribuirà un sito interamente offline prima per controllare se sono aggiornati. Si tratta di un'opzione estrema, valida e utilizzata per molte esperienze web simili a quelle di un'app offline, ma il web non deve necessariamente solo all'estremità della cache o addirittura solo alla rete.
Sfondo
Come sviluppatori web, siamo tutti abituati all'idea di avere una "cache inattiva". Ma conosciamo istintivamente gli strumenti disponibili per risolvere questo problema: fare una aggiorna" o apri una finestra di navigazione in incognito oppure utilizza una combinazione delle strumenti per sviluppatori per cancellare i dati di un sito.
Gli utenti normali su internet non usufruiscono dello stesso lusso. Anche se hanno alcuni obiettivi fondamentali: garantire che i nostri utenti si divertano bene con il loro carico, è anche molto importante assicurarsi che non abbiano problemi o si bloccano. (Guarda il video se vuoi sentirmi parlare di come il sito web.dev/live si è quasi bloccato!)
Per un po' di contesto, un motivo molto comune di "cache inattiva" è in realtà
l'impostazione predefinita del 1999 per la memorizzazione nella cache. Si basa sull'intestazione Last-Modified:
Ogni file caricato viene conservato per un ulteriore 10% della sua durata attuale,
il tuo browser. Ad esempio, se index.html è stato creato un mese fa,
questo verrà memorizzato nella cache dal tuo browser per altri tre giorni circa.
Una volta si trattava di un'idea ben intenzionata, ma considerata la integrata dei siti web odierni, questo comportamento predefinito consente per entrare in uno stato in cui un utente ha file progettati per versioni diverse sul tuo sito web (ad es. il codice JS della versione di martedì e il codice CSS della versione ), perché i file non venivano aggiornati esattamente nello stesso momento.
Il percorso ben illuminato
Un'impostazione predefinita moderna per la memorizzazione nella cache è quella di non eseguire alcuna memorizzazione nella cache e utilizzare CDN per avvicinare i tuoi contenuti per i tuoi utenti. Ogni volta che un utente carica il tuo sito, accede alla rete per per vedere se sono aggiornati. Questa richiesta avrà una bassa latenza, come sarà fornita da una CDN geograficamente vicina a ciascun utente finale.
Puoi configurare l'host web in modo che risponda alle richieste web con questa intestazione:
Cache-Control: max-age=0,must-revalidate,public
Questo dice in pratica: il file sia valido per nessun periodo e devi convalidare prima di poterlo riutilizzare (altrimenti "suggerito").
Questo processo di convalida è relativamente economico in termini di byte trasferiti, se il file immagine di grandi dimensioni non è cambiato, il browser riceverà un piccolo 304 di risposta, ma costa la latenza perché l'utente deve comunque accedere alla rete per trovare fuori. E questo è lo svantaggio principale di questo approccio. Può funzionare molto bene per le persone con connessioni veloci nel primo mondo, e dove la rete CDN di tua scelta un'ottima copertura, ma non per quelle persone che utilizzano dispositivi mobili più lenti o l'utilizzo di un'infrastruttura di scarsa qualità.
In ogni caso, si tratta di un approccio moderno è l'impostazione predefinita sulle reti CDN più diffuse, Netlify, ma possono essere configurati su quasi tutte le reti CDN. Per Firebase Hosting, puoi includere questa intestazione nella sezione hosting del file firebase.json:
"headers": [
// Be sure to put this last, to not override other headers
{
"source": "**",
"headers": [ {
"key": "Cache-Control",
"value": "max-age=0,must-revalidate,public"
}
}
]
Quindi, anche se suggerisco comunque questa soluzione come valida predefinita, è solo quella predefinita. Continua a leggere per scoprire come eseguire l'upgrade delle impostazioni predefinite.
URL con fingerprint
Includendo un hash dei contenuti del file nel nome delle risorse, delle immagini e così via
pubblicati sul tuo sito, puoi assicurarti che questi file abbiano sempre
contenuti: questo comporterà, ad esempio, file denominati sitecode.af12de.js. Quando
se il server risponde alle richieste per questi file, puoi indicare in modo sicuro
per memorizzare nella cache i browser dell'utente finale a lungo
configurandoli con questo
intestazione:
Cache-Control: max-age=31536000,immutable
Questo valore è un anno, in secondi. E secondo le specifiche, questo è in realtà uguale a "per sempre".
Soprattutto, non generare questi hash manualmente: è un lavoro manuale eccessivo. Tu puoi utilizzare strumenti come Webpack, Rollup e così via per aiutarti. Assicurati che Per saperne di più, consulta il report sugli strumenti.
Ricorda che non è solo JavaScript a poter trarre vantaggio dagli URL con fingerprint; asset come icone, CSS e altri file di dati immutabili possono essere denominati anche in molti modi diversi. (Inoltre, guarda il video qui sopra per saperne di più sul codice la suddivisione del codice, in modo da distribuire meno codice ogni volta che il sito cambia.)
Indipendentemente da come il tuo sito si approccia alla memorizzazione nella cache, questi tipi di sono incredibilmente preziosi per qualsiasi sito tu possa creare. La maggior parte dei siti non cambiano a ogni release.
Ovviamente non possiamo rinominare le nostre pagine "facili" rivolte agli utenti nel seguente modo:
il tuo file index.html in index.abcd12.html: è impossibile, si può dire
agli utenti di accedere a un nuovo URL ogni volta che caricano il sito. Questi 'gentili' URL
non possono essere rinominate e memorizzate nella cache in questo modo, il che mi rimanda a una possibile
da terra.
La via di mezzo
Ovviamente c'è spazio per una via di mezzo quando si tratta di memorizzazione nella cache. Ho ha presentato due opzioni estreme: Memorizza nella cache mai o sempre. E ci sarà essere un numero di file che potresti voler memorizzare nella cache per un certo periodo, come "amichevole" agli URL citati sopra.
Se vuoi memorizzare nella cache questi contenuti URL e il relativo codice HTML, valutando quali dipendenze includono, come possono essere memorizzate nella cache e potrebbe causare problemi alla memorizzazione nella cache degli URL per un po' di tempo. Esaminiamo una pagina HTML che include un'immagine come questa:
<img src="/images/foo.jpeg" loading="lazy" />
Se aggiorni o modifichi il tuo sito eliminando o modificando questo caricamento lento
gli utenti che visualizzano una versione del codice HTML memorizzata nella cache potrebbero ricevere un link
immagine mancante, perché ha ancora memorizzato nella cache il file /images/foo.jpeg originale quando
visitano di nuovo il sito.
Se fai attenzione, questo potrebbe non riguardarti. Ma in linea di massima è importante ricorda che il tuo sito, memorizzato nella cache dagli utenti finali, non esiste più nei tuoi server. Potrebbe trovarsi invece in pezzi all'interno delle cache del browser.
In generale, la maggior parte delle guide sulla memorizzazione nella cache parlerà di questo tipo di di memorizzazione nella cache per un'ora, diverse ore e così via. Per impostare questa opzione tipo di cache, usa un'intestazione come questa (che memorizza nella cache per 3600 secondi o ore):
Cache-Control: max-age=3600,immutable,public
Un ultimo punto. Se crei contenuti tempestivi che in genere potrebbero essere a cui gli utenti accedono una sola volta, ad esempio articoli di notizie. La mia opinione è che questi non dovrebbero mai essere memorizzato nella cache. Utilizza l'impostazione predefinita indicata sopra. Penso che spesso sopravvalutare il valore della memorizzazione nella cache rispetto al desiderio di un utente di vedere sempre e i contenuti migliori, come un aggiornamento critico su una notizia di cronaca o .
Opzioni non HTML
Oltre all'HTML, alcune altre opzioni per i file che si trovano nella posizione di mezzo include:
In generale, cerca asset che non influiscono su altri
- Ad esempio, evita CSS, perché provoca modifiche nel modo in cui il codice HTML viene sottoposto a rendering
Immagini di grandi dimensioni utilizzate come parte di articoli aggiornati
- I tuoi utenti probabilmente non visiteranno più i tuoi articoli più volte, quindi non memorizzare nella cache foto o immagini hero per sempre stoccaggio rifiuti
Una risorsa che rappresenta un elemento a sua volta valido per tutta la durata
- I dati JSON sul meteo potrebbero essere pubblicati solo ogni ora, quindi memorizza nella cache il risultato precedente per un'ora, non cambierà nella finestra
- Le build di un progetto open source potrebbero avere limitazioni di frequenza, quindi memorizza nella cache build dell'immagine di stato finché è possibile che lo stato cambi
Riepilogo
Quando gli utenti caricano il tuo sito una seconda volta, hai già ricevuto un voto di in tutta sicurezza, vogliono tornare e usufruire di ciò che offrono. In questo momento punto, non si tratta sempre solo di ridurre il tempo di caricamento, una serie di opzioni a tua disposizione per assicurarti che il browser funzioni solo ma deve garantire un'esperienza rapida e aggiornata.
La memorizzazione nella cache non è un concetto nuovo sul Web, ma forse necessita di un quadro impostazione predefinita: valuta la possibilità di utilizzarne una e di attivare fortemente strategie di memorizzazione nella cache quando ne hai bisogno. Grazie per l'attenzione.
Vedi anche
Per una guida generale sulla cache HTTP, consulta Previeni richieste di rete non necessarie con la cache HTTP.