Vai al contenuto 
Condizionale HTTP Le richieste riducono i costi di trasmissione assicurando che il client carichi completamente una risorsa solo se questa è stata effettivamente modificata dall'ultima richiesta. Mostrerò come Convalida della cache con ETag, Last-Modified, If-None-Match, If-Modified-Since e 304 Not Modified funziona in modo affidabile e i tempi di caricamento sono notevolmente ridotti.
Punti centrali
- Convalida invece del download completo: 304 consente di risparmiare larghezza di banda e tempo.
- ETag e Last-Modified lavorano insieme per un controllo pulito.
- Controllo della cache definisce la freschezza, scade solo l'integrazione.
- Condizioni preliminari come i processi di scrittura sicuri If-Match.
- Sicurezza richiede la memorizzazione privata/no-store per i contenuti sensibili.
Cosa fanno le richieste condizionali nella vita quotidiana
Ho impostato Condizionale per porre al server una domanda chiara: Ho davvero bisogno di trasferire nuovi dati o la mia cache è sufficiente? Il browser o un proxy invia le condizioni, il server controlla se un file è cambiato e risponde con 304 Not Modified senza corpo. Questo schema mantiene aggiornati HTML, CSS, JavaScript, immagini e risposte API, riducendo in modo significativo il carico sull'infrastruttura. Per le risorse valide più lunghe, utilizzo valori di età massima lunghi e mi assicuro che siano aggiornati attraverso la convalida. Se si dispone del giusto Strategie di controllo della cache ottiene il massimo dalle cache senza rischiare di avere contenuti obsoleti.
Intestazioni che consentono la validazione della cache
Per un'affidabile Cache-Il cliente ha bisogno di segnali chiari dalla risposta per prendere decisioni. Uso Cache-Control per la freschezza e le regole, Expires occasionalmente come supplemento, e Last-Modified e ETag per la validazione vera e propria. Last-Modified fornisce un tempo di modifica che può essere controllato rapidamente, mentre ETag fornisce un identificatore di versione che viene utilizzato anche per i contenuti dinamici. Importante: no-cache significa convalidare prima dell'uso, non eliminare. Se si applica correttamente questa semantica, si otterrà una notevole riduzione del traffico di dati, mantenendo il contenuto aggiornato. Contenuti.
Sequenza di una richiesta condizionale senza deviazioni
Alla prima chiamata, il client salva il file e i valori di convalida, come ad esempio ETag o Last-Modified nella cache. Successivamente, la risorsa scade o richiede un nuovo controllo prima dell'uso e il client invia If-None-Match o If-Modified-Since. Il server confronta le informazioni con lo stato attuale e restituisce 200 OK con un nuovo corpo o 304 Not Modified senza payload. Il client continua quindi a utilizzare la copia esistente, risparmiando la trasmissione, il carico di lavoro TLS e il tempo. Questo ping-pong sembra poco appariscente, ma la Effetto sulla sensazione di carico e sul carico del server è chiaro.
ETag vs. Last-Modified a confronto diretto
Uso Ultima modifica Mi piace usare i timestamp come riferimento rapido e semplice, ma uso ETag per un controllo a grana fine. I timestamp possono raggiungere i loro limiti con intervalli di modifica molto brevi o falsificare i risultati dinamici. Creo gli ETag dagli hash dei file, dalle versioni dei database o dalle varianti di rendering, in modo che ogni modifica del contenuto generi un nuovo identificatore. Entrambi i meccanismi possono essere combinati: Il client può inviare If-None-Match e If-Modified-Since in parallelo e il server seleziona il controllo appropriato. Questo è il modo in cui garantisco un'affidabile Convalida, che si applica ugualmente alle risorse statiche e dinamiche.
| Criterio | Ultima modifica | ETag |
|---|---|---|
| Precisione | Seconda risoluzione, adatta ai file | Identificatore di versione per ogni modifica del contenuto |
| Dinamica | Debole per modifiche frequenti non basate su file | Forte per le API e i contenuti renderizzati |
| Spese | Basso, disponibile dal file system | Da basso a moderato, generazione in app/proxy |
| Conflitti | Possibili deviazioni dell'orologio | Possibilità di configurare in modo errato i tag weak/strong |
Impostazioni corrette per la cache del browser e le API
Per le risorse statiche, uso il lungo età massima e salvare tramite ETag o hash del nome del file, in modo che gli aggiornamenti vengano riconosciuti immediatamente. Spesso contrassegno le risposte HTML e API con no-cache, in modo che il client le convalidi prima dell'uso senza dover ricaricare tutto ogni volta. Contrassegno le pagine personalizzate con private, in modo che le cache condivise non mostrino nulla che sia stato conservato ad altri. Gli errori sono spesso causati da direttive contraddittorie o da intestazioni di convalida mancanti, che evito con regole chiare. Se si conoscono gli ostacoli tipici, è possibile evitarli facilmente; buoni esempi di ciò si trovano nell'articolo su Trappole di intestazione nella cache, su cui mi piace orientarmi.
Utilizzare efficacemente i codici di stato e le condizioni
Organizzo Codici di stato Chiaramente: 200 OK fornisce il contenuto, 304 Not Modified conferma l'uso della cache e 412 Precondition Failed annulla se una condizione non è soddisfatta. Per le operazioni di scrittura sicure, uso If-Match, in modo che gli aggiornamenti abbiano effetto solo se l'ETag corrisponde alla versione prevista. La lettura con If-None-Match o If-Modified-Since evita payload superflui e mantiene i client sincronizzati. È importante un comportamento coerente: Lo stesso endpoint deve rispondere in modo identico per condizioni preliminari identiche. Per la SEO e i bot, faccio attenzione a come cache e crawler interpretano i messaggi di stato; una buona panoramica di Codici di stato HTTP e crawling aiuta a prendere decisioni pulite.
Sicurezza e protezione dei dati per la cache
Tratto i contenuti sensibili con no-store e quindi non hanno alcuna possibilità di finire nella cache del browser o del proxy. Contrassegno le pagine personalizzate con Cache-Control: private e controllo che nessun dato personale compaia negli URL memorizzati nella cache a lungo termine. Progetto ETag in modo neutrale, senza permettere di trarre conclusioni su account utente o ID interni. Disattivo costantemente la cache per le visualizzazioni di login e i flussi bancari. Se si combinano minimizzazione dei dati, direttive adeguate e intestazioni pulite, si riduce il rischio e si proteggono i dati. Riservatezza.
Implementazione: Passi per il server e l'applicazione
All'inizio separo statico delle risorse dinamiche e decido dove le scadenze lunghe hanno senso e dove la convalida ha la priorità. In Nginx, Apache o in un server app, configuro il controllo della cache e attivo l'ultima modifica e gli ETag, inserendo la generazione degli ETag nell'applicazione per gli endpoint dinamici. Quando elaboro le richieste in entrata, valuto If-None-Match e If-Modified-Since e rispondo con 304 se la condizione corrisponde. Per le operazioni di scrittura, uso If-Match e restituisco 412 in caso di deviazioni per evitare la sovrascrittura. In questo modo si crea un comportamento coerente che utilizza le cache in modo efficiente e allo stesso tempo Correttezza assicura.
Utilizzate metriche, test e monitoraggio in modo sensato
Controllo il Rete-di DevTools per verificare se le risorse provengono dalla cache, sono in fase di convalida o sono appena caricate. Monitoro lo stato, i valori di età, gli ETag e la dimensione della risposta trasferita. Sotto carico, misuro la latenza, il volume di trasferimento e la CPU del server per vedere l'effetto effettivo delle 304 risposte. I log del reverse proxy mostrano se le cache condivise stanno facendo il loro lavoro e quante convalide hanno successo. Utilizzo questi dati per regolare l'età massima, le direttive di controllo della cache e le strategie di ETag fino a quando i tempi di risposta e le Tasso di successo voto.
Prestazioni dell'hosting: perché le richieste condizionali fanno risparmiare denaro
Qualsiasi 304-La risposta della cache condivisa risparmia larghezza di banda, riduce l'overhead TLS e accorcia il tempo di risposta, il che è particolarmente importante per molte richieste simili. Nelle configurazioni di hosting con reverse proxy, bilanciatori di carico e CDN, ottengo il massimo effetto quando permetto chiaramente o escludo specificamente le cache condivise. Meno trasferimenti spesso significano anche minori costi di traffico in euro e maggiori riserve per i picchi di carico reali. Anche l'esperienza dell'utente è migliorata, perché le visualizzazioni ripetute delle pagine e i sondaggi API rispondono più rapidamente. In questo modo, realizzo un potenziale di prestazioni che i soli aggiornamenti hardware non sono in grado di fornire e utilizzo le risorse esistenti. Infrastrutture meglio.
Errori comuni e soluzioni pragmatiche
Contraddittorio Intestazione come no-cache abbinato a scadenze lontane nel tempo confondono le cache; stabilisco regole chiare senza duplicazioni. Gli ETag mancanti per gli endpoint dinamici portano a inutili download completi; aggiungo un identificatore affidabile e valuto se non c'è corrispondenza. Valori di età massima troppo brevi sprecano potenziale con file modificati raramente; allungo le scadenze e le proteggo comunque con la convalida. Una cache aggressiva dell'HTML ritarda le modifiche visibili; combino no-cache con ETag e mantengo i contenuti aggiornati. Con decisioni chiare sulla freschezza, la convalida e la validità, risolvo questi ostacoli e rafforzo il sistema. Pianificabilità.
Utilizzare Vary in modo pulito e controllare le rappresentazioni
Per garantire che le richieste condizionali funzionino in modo sicuro nelle cache condivise, mi assicuro di usare la corretta opzione Variare. L'intestazione definisce quali intestazioni della richiesta influenzano la rappresentazione. Esempi tipici sono Accetta codifica (gzip, br), Lingua accettata e Accettare. Se fornisco contenuti per lingua, imposto Vary: Accept-Language in modo che un proxy non condivida la versione tedesca in risposta a una richiesta francese. Per i contenuti personalizzati, faccio deliberatamente a meno di Vary: Cookie e uso invece Controllo della cache: privato, per evitare un'esplosione incontrollabile di chiavi di cache. Per le risorse che vengono consegnate solo con un'autorizzazione valida, utilizzo private o garantisco una chiara separazione con Vary: Authorisation o Vary sulle intestazioni pertinenti. La coerenza è importante: l'insieme selezionato di dimensioni Vary deve rimanere stabile, altrimenti il tasso di accesso alla cache e i vantaggi della validazione crolleranno a causa della creazione costante di nuove varianti.
ETag forti e deboli, compressione e uguaglianza dei byte
ETag forti caratterizzano le rappresentazioni identiche byte per byte e consentono una validazione precisa, anche in combinazione con le richieste di intervallo. ETag deboli (W/...) segnalano solo l'uguaglianza dei contenuti, non necessariamente byte identici. In pratica, uso ETag forti se posso generare un identificatore unico per ogni rappresentazione (compresa la compressione). Non appena un reverse proxy utilizza gzip o brotli al volo, adatto la generazione di ETag o passo a ETag deboli, in modo che il server e il client non riconoscano erroneamente byte diversi come identici. Una variante robusta è quella di creare l'ETag dai byte finali della risposta consegnata e allo stesso tempo di usare Vary: Accept-Encoding da impostare. Questo assicura che „gzip“ e „br“ ricevano ciascuno il proprio ETag valido. Nei casi in cui non posso garantire l'uguaglianza dei byte (ad esempio, timestamp diversi nell'HTML), scelgo ETag deboli che consentono comunque risposte 304 affidabili, purché il significato della pagina non sia cambiato.
Controllo della cache nella regolazione fine: s-maxage, must-revalidate, stale-while-revalidate
Inoltre età massima In particolare, uso direttive più fini. s-maxage si rivolge esclusivamente Cache condivise (CDN, proxy) e mi permette di effettuare la cache in modo più aggressivo rispetto al browser. deve essere convalidato nuovamente obbliga i clienti a non utilizzare i contenuti scaduti in modo euristico, ma a convalidarli sempre - utile per i dati critici. proxy-revalidate affronta questo obbligo in modo specifico per le cache condivise. Con stale-while-revalidate Permetto di consegnare temporaneamente una copia leggermente obsoleta mentre la convalida è in corso in background; gli utenti vedono subito qualcosa e la richiesta successiva beneficia di metadati freschi. stale-if-error come rete di sicurezza: Se l'origine fallisce o restituisce errori, la cache può consegnare l'ultima copia conosciuta per un periodo di tempo definito. Per le risorse con build-hashed, combino un lungo max-age con immutabile, poiché il nome del file cambia con il contenuto e le convalide intermedie non sono necessarie. Per l'HTML e le API, no-cache più validatore rimane il gold standard per garantire l'aggiornamento e risparmiare larghezza di banda.
Ulteriori condizioni e metodi: TESTA, gamma e conflitti di scrittura
Le richieste condizionali non sono limitate a GET. A HEAD-request fornisce solo le intestazioni ed è ideale per le convalide veloci senza corpo. Per i file di grandi dimensioni uso Gamma-richieste; con Se-Range Mi assicuro che le aree parziali siano inviate solo se la risorsa corrisponde ancora alla versione prevista, altrimenti rispondo con 200 e un corpo completo. Per le operazioni di scrittura, assicuro la coerenza con Se-Corrispondenza ab: PUT, PATCH o DELETE funzionano solo se l'ETag del client corrisponde alla versione corrente; altrimenti rispondo con 412 Precondition Failed. Quando voglio far rispettare le precondizioni, per esempio con risorse a rischio di conflitto, uso 428 Precondition Required per far sì che i client usino If-Match. Scelgo deliberatamente tra 409 Conflict e 412: 412 segnala le precondizioni violate, 409 enfatizza i conflitti di contenuto (ad esempio, le regole di business logic). Questa chiarezza facilita le implementazioni dei client ed evita le sovrascritture cieche.
Personalizzazione, cookie e protezione dei dati nella pratica
Per le pagine personalizzate, contrassegno le risposte con privato oppure no-store. Evito di codificare gli stati dell'utente in e-tag perché questi e-tag „per utente“ possono involontariamente diventare marcatori di tracciamento. Invece, faccio una distinzione rigorosa tra rappresentazioni pubbliche e private. Imposto i cookie nella chiave della cache (Vary: Cookie) solo se assolutamente necessario, perché aumentano il numero di varianti e riducono drasticamente il tasso di risposta. Per le risposte API autorizzate mi attengo a Controllo della cache: privato e, se necessario, a Variare il formato dell'intestazione Autorizzazione. In questo modo mi assicuro che le cache condivise non condividano inavvertitamente risposte riservate. Nelle applicazioni con contenuti misti (struttura di base pubblica, sottoaree personalizzate), mi affido alla cache frammentata o all'edge ESI/SSI, mentre le parti critiche rimangono private. Il risultato è una protezione dei dati senza un calo delle prestazioni.
Operazione: CDN, surrogati e invalidazioni
Nelle configurazioni CDN combino s-maxage con validatori chiari e, se disponibili, utilizzare direttive specifiche per i surrogati per controllare le cache dei bordi separatamente dal browser. La riconvalida riduce il carico su Origin, ma di tanto in tanto è necessaria un'invalidazione dura (per esempio, una correzione di sicurezza). Ho quindi previsto due modi: Sfruttamento della cache tramite hash dei nomi dei file per le risorse statiche e Epurazione/Invalidazione per HTML e API. In questo modo si evitano le „tempeste di spurgo“ e si mantiene comunque un breve tempo di aggiornamento. È anche importante avere una chiave di cache coerente nella CDN (compresi host, percorso, parametri di query e intestazioni Vary pertinenti). Per quanto riguarda i parametri di query, distinguo consapevolmente tra parametri semantici (ad esempio, ?lang=) e parametri puramente legati al tracciamento; ignoro questi ultimi nella chiave della cache per evitare la frammentazione. In questo modo la catena di cache del browser, proxy intermedio e CDN rimane trasparente e prevedibile.
304 in dettaglio: Aggiornare correttamente intestazione e metadati
Anche un 304-La risposta contiene metadati importanti. Riporto Data, Cache-Control, ETag/Last-Modified e, se rilevanti, Expires e Vary, in modo che il client possa aggiornare le sue voci nella cache. Content-Type e Content-Encoding non devono necessariamente essere ripetuti, ma possono contribuire alla chiarezza. È importante che il 304 non contenga un payload del corpo e che invii validatori coerenti: Cambiare l'ETag nel 304 senza cambiare la rappresentazione porta a confusione. Se le linee guida vengono modificate (ad esempio, un'età massima più lunga), il client può adottare i metadati senza dover ricaricare il corpo: una piccola leva con un grande impatto sulle prestazioni percepite.
Strategie di test e debug per una validazione pulita
In DevTools controllo in particolare i seguenti punti: dalla cache del disco vs. dalla memoria cache vs. riconvalidato; Stato 200/304; intestazione Age nelle risposte delle cache condivise; coerenza ETag/Last-Modified ed effetto di Vary. Per test riproducibili, disattivo temporaneamente la cache del browser o utilizzo una modalità privata. Sul lato server, valuto i log sul rapporto 200/304, la dimensione media delle risposte e l'utilizzo della CPU. I segnali di allarme sono, ad esempio, molte risposte 200 a risorse con intervalli di modifica brevi (validatori mancanti), cicli di riconvalida (tempi diversi/deriva dell'orologio) o un numero insolitamente elevato di varianti per URL (Vary eccessivo). Uso i test di carico per verificare il comportamento di s-maxage, stale-while-revalidate e if-none-match sotto pressione e regolo le direttive finché throughput e latenza non corrispondono.
Casi limite e default robusti
Non tutte le risorse hanno regole di modifica chiare. Ho impostato dei valori predefiniti prudenti per le sitemap, i feed o i dashboard generati: no-cache più ETag/Last-Modified. In presenza di orologi instabili tra i sistemi upstream, evito confronti rigidi tra i secondi e preferisco ETag indipendenti dai timestamp. Se la compressione è variabile (diversi livelli di gzip), includo il risultato della compressione nella generazione di ETag o passo a ETag deboli. E se i clienti richiedono senza validatori, invio segnali chiari: o freschezza chiara (max-age/immutabile) o validazione chiara (no-cache + ETag). Questi predefiniti robusti garantire che anche i client incompleti o difettosi non provochino picchi di carico indesiderati.
Breve sintesi
Collegare le richieste condizionali Velocità e tempestività, facendo in modo che i client recuperino risorse complete solo quando il contenuto è cambiato. Uso il controllo della cache per la freschezza, combino l'ultimo modificato e l'ETag per controlli affidabili e rispondo coerentemente con 304 se le condizioni sono soddisfatte. Isolo i contenuti personalizzati e riservati con private o no-store, in modo che nessun dato finisca nelle cache condivise. Le misurazioni in DevTools, i registri e le metriche mi mostrano dove posso allungare le scadenze o rafforzare la logica di convalida. Se pensate a questi elementi costruttivi insieme, otterrete pagine più veloci, un carico del server ridotto e una maggiore efficienza. rotondo Esperienza utente senza spreco di dati.
