Mappa la policy alla risorsa, non al server
Fai l'inventario di URL rappresentativi prima di modificare gli header: una home page, una pagina di contenuto, la shell dell'applicazione, CSS, JavaScript, immagini, font, API, login, account, checkout e download. Per ciascuno, registra se la risposta è pubblica o personalizzata, se il suo URL cambia quando cambiano i byte e quanto rapidamente una correzione deve raggiungere i visitatori.
Costruisci una matrice di policy da quell'inventario. Un asset pubblico indirizzato dal contenuto necessita di una regola diversa dall'HTML a un indirizzo stabile. Risposte senza Cache-Control possono comunque essere memorizzate in modo euristico, quindi regole esplicite sono più facili da testare.
Il periodo durante il quale una risposta memorizzata può essere riutilizzata; max-age lo dà in secondi.
Usa i termini di Cache-Control con precisione
Cache-Control indica a browser e cache condivise come memorizzare e riutilizzare una risposta. max-age=N permette il riuso mentre la risposta è fresca. s-maxage=N imposta la freschezza per le cache condivise e sovrascrive max-age lì, ma i browser ignorano s-maxage. public permette a qualsiasi cache di memorizzare; private permette la memorizzazione nel browser ma impedisce l'archiviazione nelle cache condivise.
no-cache permette la memorizzazione ma richiede la validazione all'origin prima del riuso. no-store significa che le cache non devono memorizzare la risposta, ma non è un controllo privacy completo. Usa must-revalidate quando servire contenuti scaduti dopo l'expiry è inaccettabile; un origin non disponibile potrà così restituire un 504 piuttosto che un fallback scaduto.
Rimuove l'archiviazione anziché richiedere solo un controllo; riservalo alle risposte che davvero non devono essere memorizzate.
Versiona gli asset immutabili prima di assegnare una lunga durata
Un URL di asset versionato include una fingerprint di contenuto o una versione di rilascio, ad esempio app.4f2c.js. Quando i byte dell'asset cambiano, pubblica un URL diverso e aggiorna il riferimento nell'HTML. La cache vedrà una nuova risorsa, quindi i visitatori scaricheranno il nuovo asset senza che una invalidazione debba raggiungere ogni browser.
Per una rappresentazione che non cambierà durante la sua finestra di freschezza, Cache-Control: max-age=31536000, immutable è uno schema pratico. immutable indica ai client che lo supportano di non rivedere condizionalmente mentre la risorsa è fresca. Non applicarlo né un max-age di un anno a un file mutabile con lo stesso URL. Mantieni disponibili le vecchie versioni fingerprinted finché l'HTML memorizzato nella cache potrebbe ancora farvi riferimento.
L'HTML sceglie gli URL degli asset, quindi la sequenza di rilascio deve preservare la generazione referenziata.
Rendi l'HTML aggiornato tramite validazione, non tramite caching prolungato
L'HTML di solito ha un URL stabile e rivolto all'utente e cambia con il contenuto, i riferimenti agli asset, i feature flag o gli avvisi di sicurezza. Un pattern conservativo per l'HTML pubblico è Cache-Control: no-cache con ETag e Last-Modified quando la tua piattaforma può produrli correttamente. Il browser memorizza il corpo ma usa una richiesta condizionale prima del riuso; una risposta immutata può restituire 304 Not Modified senza corpo.
ETag identifica una versione della risorsa. Su una risposta scaduta, il browser può inviarlo in If-None-Match; se corrisponde, il server risponde 304, altrimenti invia la nuova rappresentazione. Le linee guida RFC preferiscono, quando possibile, sia ETag sia Last-Modified su una risposta 200. no-cache non garantisce la validazione su navigazioni Back o Forward perché un browser può ripristinare uno snapshot della cronologia della sessione.
Un ETag deve cambiare quando la rappresentazione cambia; testalo attraverso origini e deployment.
Separa la delivery pubblica dalle risposte personalizzate e sensibili
Una cache condivisa, come un CDN, può riutilizzare una risposta per più utenti. Non permettere che riutilizzi HTML o dati API specifici dell'account tra utenti diversi. Per contenuti personalizzati che possono vivere nel browser, private, no-cache è un punto di partenza sensato: impedisce l'archiviazione condivisa e richiede la validazione. Un header Set-Cookie da solo non blocca la cache.
Per risposte che non devono essere memorizzate, usa no-store e rivedi il codice applicativo, le regole CDN, i service worker, gli archivi del browser, i log e le pagine di errore. Gli header da soli non costituiscono un programma di privacy, compliance o sicurezza dei pagamenti. Fai valutare i flussi sensibili da revisori qualificati in security, privacy e pagamenti per i requisiti applicabili.
Testa sign-in, sign-out, cambio account e cambi di permessi con cache browser e CDN già calde.
Distribuisci le modifiche alla cache come un rilascio reversibile
Cattura gli header di base e il comportamento del corpo per richieste uncached e ripetute. In staging, distribuisci prima gli asset versionati, poi l'HTML che li referenzia, e testa l'HTML memorizzato più vecchio contro il nuovo origin. Controlla i percorsi direct-origin e CDN se entrambi esistono. Gli header nella scheda Network di DevTools devono mostrare la policy prevista e il comportamento sui richiami.
Conserva un manifesto di rilascio degli URL degli asset, delle regole header e della versione di configurazione. Se un rilascio combina file client incompatibili, ripristina l'HTML compatibile e il comportamento applicativo, ma non sovrascrivere un file fingerprinted già pubblicato. Ricollega l'HTML alla generazione nota come buona e mantieni entrambe le generazioni finché l'HTML memorizzato nella cache potrebbe richiederle. Una purge sulla cache condivisa non può obbligare i browser a scartare una risposta ancora fresca.
Trasforma i fallimenti dei test degli header, i 404 degli asset e le discrepanze di versione in cambi da includere nella checklist del rilascio successivo.