Vai al contenuto 
La cache HTTP consente di risparmiare tempo e dati, poiché ricarica le risorse solo quando sono state effettivamente modificate. Tramite ETag e Ultima modifica Verifico tramite una richiesta condizionale se il server risponde con un codice 304 Not Modified, riducendo così notevolmente il traffico e il carico sul server.
Punti centrali
I seguenti punti chiave illustrano gli aspetti su cui mi concentro quando si tratta di conditional caching con ETag e Ultima modifica attenzione.
- Meno traffico: I file invariati restituiscono un codice 304, anziché l'intero corpo della risposta, riducendo notevolmente il volume di dati e la latenza.
- Migliori prestazioni: Tempi di attesa più brevi migliorano l'esperienza utente (UX) e i Core Web Vitals, il che SEO aiuta.
- Due meccanismi: Last-Modified/If-Modified-Since ed ETag/If-None-Match garantiscono una validazione sicura della cache.
- Controllo della cache: Le direttive controllano l'aggiornamento, la rivalidazione e il comportamento nelle cache intermedie.
- Combinazione: Questi due metodi, utilizzati insieme, garantiscono un'elevata precisione e soluzioni alternative semplici.
Per prima cosa verifico quali risorse cambiano davvero spesso e quali raramente. Per i file che vengono modificati raramente, imposto un Ultima modifica- e aggiungo un ETag. Per le risposte dinamiche preferisco utilizzare il ETag, poiché ogni modifica ai contenuti risulta immediatamente evidente. In questo modo alleggerisco il carico sui server, riduco le latenze e garantisco ai visitatori abituali una visualizzazione molto rapida delle pagine. Questa strategia rafforza la Vitali Web principali e quindi, indirettamente, la visibilità.
Caching condizionale HTTP: come verificare la validità
Quando effettua una nuova richiesta, il client invia, oltre al metodo GET, ulteriori intestazioni che io analizzo sul lato server. Se la risorsa ha lo stesso ETag Se il contenuto corrisponde a quello in cache (If-None-Match), restituisco un 304 Not Modified senza corpo. Se il timestamp non è cambiato (If-Modified-Since), il server risponde ugualmente con 304. Se il giorno o la data non corrispondono più, invio un 200 OK con nuovo contenuto e Ultima modifica e ETag. In questo modo risparmio larghezza di banda, mantengo aggiornata la cache e garantisco tempi di caricamento notevolmente più rapidi.
Last-Modified e If-Modified-Since nell'uso quotidiano
L'intestazione Ultima modifica Mi baso sulla data effettiva di modifica del file, ricavata ad esempio dal file system. Se in seguito arriva una richiesta con l’intestazione «If-Modified-Since» e la risorsa non è cambiata da allora, rispondo con un codice 304. Questo metodo è semplice, facilmente comprensibile e ideale per risorse statiche come CSS, JS o immagini. I limiti sono rappresentati dalla griglia di secondi dei timestamp HTTP e dalle situazioni in cui i contenuti cambiano logicamente senza che esista un'ora di modifica del file ben definita. Laddove Last-Modified raggiunge i propri limiti, un ETag il controllo.
ETag e If-None-Match nei sistemi dinamici
A ETag Lo genero come hash, ID di versione o da una colonna del database che indica i cambiamenti di stato. Al successivo accesso, il browser invia If-None-Match, io confronto il tag con il mio valore attuale e rispondo di conseguenza con 304 o 200. Questo confronto rileva ogni modifica significativa del contenuto, senza fare affidamento sui timestamp dei file. Soprattutto con le API, le pagine composte o i frammenti personalizzati, questo fornisce risultati molto precisi. È importante mantenere gli ETag coerenti negli ambienti cluster, in modo che nessun server ne generi casualmente uno diverso Giorno prodotto.
Come combinare correttamente le impostazioni Cache-Control
Con Controllo della cache In questo modo definisco per quanto tempo i contenuti vengono considerati aggiornati senza necessità di una nuova richiesta e quando il browser deve effettuare una nuova convalida. Impostiamo valori max-age adeguati in base alla frequenza delle modifiche e utilizziamo must-revalidate quando i dati obsoleti potrebbero comportare problemi critici. Per i file con versione è indicata una validità lunga, mentre le risposte che cambiano spesso hanno una durata più breve e possono quindi essere verificate in modo accurato tramite ETag o data. In questo modo combino tempi di risposta brevi con una corretta attualità. Chi desidera approfondire l'argomento troverà molti esempi su Strategie di Cache-Control, che utilizzo nella pratica.
Procedura passo dopo passo di una richiesta GET condizionale
Al primo accesso, il server invia un codice di stato 200 OK con l'intestazione Cache-Control, Ultima modifica e l'ETag, il browser salva tutto. Alla visita successiva, è l'età nella cache a determinare se è necessaria una rivalidazione. Se è necessaria, il browser invia una richiesta con If-None-Match e/o If-Modified-Since. Se i valori corrispondono allo stato attuale, invio un 304 Not Modified e il client continua a utilizzare la propria cache. Se non corrispondono più, segue un 200 OK con un nuovo body e i dati aggiornati Dati di convalida.
Confronto: ETag vs. Last-Modified
Entrambi i metodi mi garantiscono il controllo, ma differiscono in termini di impegno richiesto, precisione e idoneità. Ultima modifica Si distingue per la semplicità di implementazione e la semantica chiara, purché si disponga di timestamp precisi. L'ETag riflette i contenuti in modo molto accurato, ma richiede un po' di logica per la sua generazione. In molte configurazioni combino entrambi, beneficiando così della semplicità e del riconoscimento preciso. La tabella seguente riassume le caratteristiche tipiche e aiuta nella scelta.
| Aspetto | Ultima modifica | ETag | Suggerimento |
|---|---|---|---|
| Identità | Data e ora dell'ultima modifica | Hash del contenuto o ID della versione | Tempo rispetto all'identificativo basato sul contenuto |
| Rilevamento delle modifiche | Risoluzione al secondo, indiretta | Orientato direttamente al contenuto | ETag rileva anche le più piccole Differenze |
| implementazione | Molto leggero, il file system è sufficiente | Richiede generazione e coerenza | I cluster hanno bisogno di ETags |
| Utilizzo | Risorse statiche | Risposte dinamiche | Questa combinazione copre molti Casi da |
| Risposte | 304 con timestamp invariato | 304 con tag identico | 200 in caso di modifiche con un nuovo Valore |
Esempio pratico: distribuzione efficiente delle risorse statiche
I file statici come CSS, JS e immagini cambiano raramente e sono adatti per periodi di tempo prolungati età massima-Tempi. Per i file con versione, imposto valori elevati fino a un anno e li contrassegno come immutabili, in modo che il browser li carichi senza richiedere conferme. Per le risorse non versionate scelgo scadenze più brevi e mi affido alla rivalidazione tramite ETag e Last-Modified. In questo modo evito contenuti obsoleti e mantengo basso il traffico. Se faccio attenzione a non Sabotare l'intestazione della cache In questo modo ottengo un'elevata percentuale di risultati nella cache.
Esempio pratico: API e pagine dinamiche
Quando si tratta di API, di solito mi affido a ETags, che ricavo dal risultato serializzato o da una colonna della versione. Se il record cambia, genero un nuovo tag e i client lo riconoscono immediatamente. Per i contenuti con timestamp inaffidabili, spesso rinuncio a Last-Modified, in modo da non dare un'impressione errata di freschezza. Inoltre, controllo la durata tramite Cache-Control e, una volta scaduta, impongo la rivalidazione. In questo modo mantengo i dati affidabili e aggiornati, senza rendere le risposte inutilmente grandi.
Test e monitoraggio del tasso di successo della cache
Controllo le intestazioni come ETag, Last-Modified, If-None-Match e If-Modified-Since negli Strumenti per sviluppatori. In questo contesto, prendo nota dei codici di risposta, in particolare 304 rispetto a 200, per verificare l'efficacia della mia rivalidazione. Se il 304 si verifica raramente, regolo Cache-Control, i periodi di validità e la generazione dell'ETag. I log e le metriche mi mostrano quali percorsi generano risposte inutilmente grandi. Per miglioramenti raggruppati, mi piace utilizzare un Pacchetto Conditional-Requests, che integra configurazione e test.
Architettura di hosting e trappole ETag
Nelle configurazioni multi-server è necessario un ETag deve essere indipendente dall'istanza, altrimenti il riconoscimento non funziona. Mi assicuro che tutti i nodi utilizzino la stessa logica e la stessa chiave per la generazione. I proxy inversi o i CDN non devono modificare gli ETag e dovrebbero inoltrare correttamente gli header di condizione. Nelle implementazioni con impronte digitali delle risorse, evito il ricalcolo dell'ETag lato server se il file ha già un URL con versione. Regole uniformi impediscono risposte incoerenti e mantengono alto il tasso di hit della cache.
Freschezza vs. convalida: utilizzare le direttive con precisione
Faccio una chiara distinzione tra Freschezza (per quanto tempo una cache può utilizzare una copia senza richiedere una nuova consultazione?) e Convalida (come faccio a verificare se è ancora valida?). Tramite Controllo della cache regolo entrambi con estrema precisione: età massima definisce la durata sul client, s-maxage per cache condivise come i proxy. pubblico consente la memorizzazione temporanea in cache condivise, privato lo limita al browser finale. deve essere convalidato nuovamente richiede una conferma alla scadenza, mentre immutabile evita inutili rivalidazioni in caso di risorse soggette a controllo delle versioni. no-cache non vieta la memorizzazione nella cache, ma richiede sempre una nuova convalida; no-store vieta invece completamente la memorizzazione. I modelli più vecchi Scadenza-Utilizzo l'intestazione solo come soluzione di ripiego, mentre sposto sistematicamente la logica su Cache-Control. E se voglio attenuare gli effetti di eventuali interruzioni, mi aiutano stale-while-revalidate e stale-if-error, per condividere contenuti scaduti da poco, mentre in background eseguo gli aggiornamenti o risolvo eventuali errori.
ETag forti e deboli, compressione e varianti
Distinguo consapevolmente tra validatori forti e deboli. ETag forti identificano la stessa rappresentazione al byte – l'ideale se anch'io Richieste di gamma desidera gestire in modo efficiente. ETag deboli (Prefisso W/) sono sufficienti quando basta l'equivalenza semantica, ad esempio in caso di piccole modifiche di formato irrilevanti. È importante il modo in cui si gestisce Compressione: Se fornisco contenuti codificati sia con gzip che con Brotli, un unico ETag non può valere per tutte le varianti. Devo generare l'ETag sulla versione non compressa e impostare inoltre un Vary: Accept-Encoding, oppure genero ETag coerenti ma diversi per ogni variante. In questo modo evito i risultati errati e le risposte 200 che in realtà dovrebbero essere 304. In caso di Se-Range Combino le richieste di copertura con un validatore: se l'ETag o la data corrispondono, rispondo con un codice di stato 206 (Partial Content); altrimenti invio un 200 con il corpo completo, in modo che il client disponga di una base coerente.
Padroneggiare alla perfezione l'intestazione Vary e la negoziazione dei contenuti
Ogni volta che il server fornisce diverse rappresentazioni a seconda delle esigenze, io impiego Variare corretti. Esempi tipici sono Accetta codifica (compressione), Lingua accettata (localizzazione) o flag di funzionalità specifici. Evito di fare riferimento a header volatili come Agente utente o addirittura Biscotto variare, perché ciò compromette gravemente il tasso di successo della cache. Laddove è necessaria la personalizzazione, contrassegno le risposte come privato oppure no-store e le distinguo chiaramente dalle risorse memorizzabili nella cache pubblica. Importante: le varianti riguardano anche gli ETag – ogni variante deve avere un proprio validatore coerente. In questo modo mi assicuro che browser, proxy e CDN applichino la stessa logica e che nessuna variante venga accidentalmente confusa con un'altra.
Richieste condizionali oltre GET
Le richieste condizionali non funzionano solo durante la lettura. Per i metodi di scrittura utilizzo Se-Corrispondenza oppure If-Unmodified-Sinceal fine di aggiornamenti mancanti per evitare che ciò accada. Se, in caso di PUT o DELETE, il client fornisce l'ETag visualizzato per ultimo tramite Se-Corrispondenza se lo stato del server è ancora lo stesso, eseguo la modifica; altrimenti rispondo con 412 Condizione preliminare non soddisfatta. Per garantire il rispetto delle regole da parte dei client, il server può inoltre 428 Precondizione richiesta stabilire. Per verifiche rapide senza body utilizzo HEAD, che mi restituisce le stesse intestazioni di una richiesta GET; l'ideale se voglio testare i metadati. E in caso di 304-Nelle risposte includo nuovamente tutti gli header rilevanti per la cache (Cache-Control, ETag, Expires, Last-Modified), in modo che il client aggiorni i propri metadati senza trasmettere il corpo del messaggio.
Sicurezza, protezione dei dati e conformità
Non salvo dati personali o contenuti sensibili nella cache pubblica. In questo caso utilizzo Controllo della cache: privato oppure no-store, in modo che né il browser né alcuna altra istanza memorizzi i contenuti. Attenzione agli account utente e alle dashboard: le risposte con Impostare il cookie oppure Autorizzazione non devono essere accidentalmente memorizzabili nella cache pubblica. Gli ETag stessi possono essere utilizzati impropriamente come vettori di tracciamento se rimangono stabili per un lungo periodo. Per ovviare a questo problema, utilizzo i validatori solo dove la memorizzazione nella cache è effettivamente desiderata, disattivandoli per i percorsi specifici degli utenti o limitandone la durata. In questo modo concilio le prestazioni con i requisiti di protezione dei dati.
Dettagli di implementazione e impatto sulle prestazioni
La creazione di un ETag non deve comportare costi superiori ai benefici. Per i file di grandi dimensioni o i rendering complessi, salvo il tag insieme ai metadati (checksum del file, hash della build, database-versione della riga) e non lo ricompilo ad ogni richiesta. Nel caso di pagine composte, è utile un Strategia di composizione delle versioni: Creo l'ETag a partire da ETag parziali stabili (ad es. modello, frammento di dati, configurazione), in modo che piccole modifiche producano un nuovo valore mirato ma riproducibile. Nei cluster sincronizzo la logica di generazione in una libreria comune e la verifico in CI, in modo che nessuna istanza si discosti. Per i blob estremamente grandi, utilizzo checksum veloci (CRC64) o memorizzo gli hash di build, invece di eseguire l'hash del corpo al volo. Laddove non è necessaria l'assoluta uguaglianza dei byte, è sufficiente ETag deboli come compromesso pragmatico.
Errori comuni e come evitarli
- ETag casuali: Se i tag vengono rigenerati ad ogni richiesta, ogni nuova convalida è inutile. Mi assicuro che i valori siano deterministici e cambino solo in caso di modifiche effettive.
- Combinazione errata delle direttive: no-store L'uso dell'ETag non serve a nulla: il browser non lo memorizza comunque. Scelgo combinazioni coerenti per ottenere il comportamento desiderato.
- Vary eccessivo: Le variazioni relative ai cookie o all'User-Agent compromettono la cache. Limito l'uso di Vary ai soli cambiamenti effettivi nella rappresentazione.
- Trappole da compressione: Un ETag comune per gzip e br causa errori di identificazione. Associo correttamente gli ETag alla variante specifica e imposto correttamente il campo Vary.
- Sfasamento dell'ora: Gli orologi dei server imprecisi alterano il valore "Last-Modified". Mantengo sincronizzate le fonti di tempo affinché l'intestazione "If-Modified-Since" funzioni correttamente.
- Errore di no-cache: Molti leggono „non memorizzare nella cache“. Ciò che si intende è „riconvalidare sempre“. Per un vero e proprio divieto utilizzo no-store.
Risoluzione dei problemi, metriche e flussi di lavoro
Per la ricerca degli errori, inizio dalla scheda Rete: è corretto Controllo della cache? Si verifica durante la riabilitazione 304 invece di 200? Va bene ETag e Ultima modifica Tra la richiesta e la risposta? Sto verificando Variare, per verificare se le varianti vengono riconosciute correttamente. Nei log visualizzo Centro/Mancato- Visualizzare i tassi di 304 e le dimensioni medie delle risposte per ogni percorso. Se il tasso di 304 aumenta, il volume dei dati e il TTFB tendono a diminuire in modo evidente. Nei test di carico simulo chiamate ripetute per misurare i costi di rivalidazione anziché quelli di trasferimento. In caso di anomalie, elimino gradualmente i fattori di disturbo: Set-Cookie, regole Vary troppo rigide, header contraddittori come Pragma. In questo modo individuo rapidamente il collo di bottiglia che riduce l'hitrate.
I Service Worker come livello di cache supplementare
Quando utilizzo un Service Worker, lo impiego come livello aggiuntivo, non come livello in contrasto. Gli affido gli stessi Controllo della cache-Rispetta i segnali e combina strategie come stale-while-revalidate utilizza in modo consapevole la convalida HTTP tramite ETag e Last-Modified. Nei casi in cui l'utente è offline, il worker può fornire risorse temporaneamente obsolete e riconvalutarle in background. Resta importante che trasmetta correttamente gli header di condizione, altrimenti perdo i vantaggi del 304 sulla tratta di rete. In questo modo anche gli scenari PWA traggono vantaggio da un caching HTTP pulito, invece di aggirarne i meccanismi.
Effetto SEO e Core Web Vitals
Migliorare la rapidità delle risposte UX e i segnali degli utenti, il che favorisce il posizionamento nei motori di ricerca. Ne traggono vantaggio soprattutto i visitatori abituali, poiché il loro browser recupera molti file direttamente dalla cache o tramite un codice di stato 304. Questa minore latenza ha un effetto positivo su FCP, LCP e TTFB, che riesco a ridurre grazie a una rivalidazione mirata. Inoltre, il server risparmia tempo di elaborazione, che posso utilizzare per i picchi di carico o per richieste complesse. In questo modo mantengo le prestazioni, mentre i contenuti arrivano correttamente e tempestivamente.
Sintesi: Il mio piano d'azione
Mi affido a una chiara Combinazione da Cache-Control, Last-Modified ed ETag. Per le risorse statiche scelgo durate di validità lunghe e mi assicuro di effettuare una rivalidazione quando i file non sono versionati. Per le risposte dinamiche, genero ETag affidabili e mantengo la coerenza dei cluster. Successivamente, verifico con strumenti, metriche e log se i 304 si verificano con sufficiente frequenza e adeguo le impostazioni. In questo modo garantisco una distribuzione veloce, un carico ridotto e una migliore esperienza utente attraverso un'efficace Caching HTTP.
