Vai al contenuto 
Utilizzo l'hosting di controllo della cache per controllare in modo specifico il modo in cui i browser, i proxy e i CDN memorizzano i contenuti nella cache, in modo che le pagine vengano caricate più velocemente e rimangano sempre aggiornate. A tal fine, utilizzo un sistema di controllo della cache mirato direttive come max-age, no-cache o no-store e quindi bilanciare prestazioni, freschezza e carico del server per HTML, risorse e API.
Punti centrali
La panoramica che segue mostra le leve più importanti per Ottimizzazione del web con controllo della cache.
- Progettazione TTLLunga età massima per gli asset, tempi brevi o riconvalida per l'HTML.
- ConvalidaETag e Last-Modified riducono il traffico di dati con risposte 304.
- Controlli sul bordos-maxage, stale-while-revalidate e stale-if-error per i CDN.
- VersioneI nomi dei file con hash/versione consentono cache aggressive.
- MonitoraggioControllare costantemente le percentuali di hit della cache, le quote 304 e il TTFB.
Cosa rende il controllo della cache così efficace nell'hosting?
Sposto il lavoro dal server Origin al server Cache, ridurre la latenza e risparmiare larghezza di banda. Un'intestazione di controllo della cache correttamente impostata controlla per quanto tempo i file rimangono validi e quando il client li richiede al server. Sono previsti lunghi periodi di validità per risorse come immagini, CSS e JS, mentre l'HTML rimane valido per poco tempo o viene sempre convalidato. Questo significa che gli utenti incontrano più frequentemente le risposte in cache e ricevono comunque attuale Contenuto. Evito i tipici ostacoli come intestazioni contraddittorie o versioni mancanti fin dall'inizio, per esempio con questo Guida alla correzione della cache.
Nozioni di base: combinare correttamente le direttive
Con età massima Impongo la durata in secondi, ad esempio 31536000 per un anno per le risorse statiche. no-cache obbliga il client a convalidare prima dell'uso, ma non proibisce la memorizzazione. no-store esclude qualsiasi memorizzazione e protegge le risposte sensibili, come i dati di pagamento. public permette la memorizzazione nella cache condivisa, come le CDN, private è limitata alla cache del browser. immutable segnala che il file rimane invariato, che può essere modificato con Versione (ad esempio app.v1.2.js) sono un'ottima aggiunta.
Definire chiaramente le intestazioni Vary e le chiavi della cache
Mi assicuro che gli oggetti in cache corrispondano al tipo di richiesta. Il Variare-L'intestazione è quindi presente in ogni strategia di cache seria. Influenza la chiave della cache e impedisce un riutilizzo errato:
- Accetta codificaObbligatorio per gzip/br, in modo che le varianti compresse e non compresse siano memorizzate nella cache separatamente.
- Lingua accettataUtilizzabile solo se si tratta di fornire contenuti che dipendono dalla lingua, altrimenti si rischia la frammentazione.
- Biscotto: evito un'operazione globale Variabile: Cookie, perché distrugge le percentuali di accesso alla cache. Invece, segmento in modo specifico in base ai cookie rilevanti (ad esempio, variante A/B) o rimuovo i cookie irrilevanti ai margini.
- AutorizzazioneI contenuti che dipendono dalle intestazioni di autenticazione non vengono memorizzati nelle cache condivise, oppure vengono deliberatamente bloccati se il fornitore di CDN lo supporta.
# Apache: intestazioni significative Vary per HTML e risorse
Intestazione Vary "Accept-Encoding"
Intestazione merge Vary "Accept-Encoding"
Definisco anche regole chiare per la chiave di cache sulle CDN: Non includo nella chiave i parametri di query utilizzati solo per il tracciamento (ad esempio utm_*). In questo modo si evita l'esplosione delle chiavi senza compromettere la freschezza.
Pratica: configurazione su Apache e Nginx
Su Apache ho impostato le regole nella cartella .htaccess o nel VirtualHost. Separo l'HTML dalle risorse, do ai file statici una lunga durata e proteggo l'HTML con la riconvalida. Evito i conflitti con le intestazioni Expires, i browser moderni rispettano principalmente il controllo della cache. Su Nginx, impongo la corretta posizione di add_header e mi assicuro che nessuna istruzione a valle li sovrascriva. Questo è il modo in cui controllo Caching del browser coerente in tutto lo stack.
.
Set di intestazioni Cache-Control "public, max-age=31536000, immutable".
Set di intestazioni Cache-Control "no-cache, must-revalidate".
location ~* \.(css|js|png|jpg|svg|woff2)$ {
add_header Cache-Control "public, max-age=31536000, immutable";
}
location ~* \.(html)$ {
add_header Cache-Control "no-cache, must-revalidate";
}
Caching solo CDN per l'HTML
Se il browser deve sempre controllare, ma Edge è autorizzato a memorizzare nella cache, imposto tempi di vita diversi per il client e il CDN:
# Apache: Browser riconvalidato, Edge in cache da 5 minuti
Set di intestazioni Cache-Control "public, max-age=0, s-maxage=300, must-revalidate, stale-while-revalidate=30, stale-if-error=86400".
Intestazione merge Vary "Accept-Encoding"
# Nginx
posizione ~* \.(html)$ {
add_header Cache-Control "public, max-age=0, s-maxage=300, must-revalidate, stale-while-revalidate=30, stale-if-error=86400";
add_header Vary "Accept-Encoding";
}
Convalida: utilizzo effettivo di ETag e Last-Modified
Combino Controllo della cache con ETag e Last-Modified per riconvalidare in modo controllato. Dopo la scadenza, il browser invia If-None-Match o If-Modified-Since; il server risponde con 304 se la risorsa è invariata. In questo modo si risparmiano byte e si riduce significativamente il tempo della CPU di Origin. Importante: gli ETag devono essere coerenti, altrimenti si verificheranno miss inutili nonostante il contenuto invariato. Sui cluster, disattivo gli ETag deboli o creo degli hash forti, in modo che il rivalidazione rimane affidabile.
Coerenza in ambienti multi-server
Mi assicuro che gli ETag non si basino su caratteristiche basate su inode che differiscono tra i nodi. Fornisco un hash stabile (artefatto di compilazione) o mi affido all'ultima modifica quando i deploy sono atomici. Per le risposte dinamiche, utilizzo ETag applicativi che corrispondono esattamente all'hash del payload. Se la riconvalida è più costosa di un nuovo rendering, rispondo deliberatamente con 200 e un TTL breve: è la misura a decidere.
Strategie per tipo di risorsa
Distinguo in base al tipo di contenuto, perché HTML, risorse, API e risposte sensibili hanno caratteristiche diverse. Requisiti. I TTL lunghi per i file in versione forniscono i valori migliori, mentre l'HTML deve essere gestito in modo rigoroso. Pianifico tempi di vita brevi per le API e prevedo una tolleranza ai guasti. Impedisco la memorizzazione di risposte personali o riservate. Coloro che approfondiscono le interfacce traggono vantaggio dai modelli compatti per Caching API nell'hosting, che adatto alle caratteristiche della risposta.
| Tipo di risorsa | Direttiva raccomandata | Motivo |
|---|---|---|
| Risorse statiche (immagini, CSS, JS) | pubblico, max-age=31536000, immutabile | Memorizzazione prolungata; impossibilità di eseguire le versioni Stale-Contenuto |
| Pagine HTML | no-cache, must-revalidate | Contenuti freschi attraverso rivalidazione |
| API | pubblico, max-age=300, stale-if-error=86400 | Scadenza breve, utilizzabile per Errori |
| Dati sensibili | no-store | Nessuna memorizzazione da Protezione dei dati-Motivi |
Codici di stato, reindirizzamenti e pagine di errore
- 301 può e deve essere memorizzato nella cache (TTL lungo) perché è permanente. Versione URL di destinazione per facilitare le modifiche successive.
- 302/307 sono temporanei - TTL breve o riconvalida, altrimenti c'è il rischio di percorsi errati nella cache.
- 404 La cache è di breve durata (ad es. 60-300 secondi), in modo che gli hotlink difettosi non gravino su Origin senza bloccare le ricreazioni reali.
- 500+ Non eseguo la cache, ma lascio l'Edge stale-if-error per fornire agli utenti le informazioni più recenti.
Direttive estese per CDN e Edge
Con s-maxage Separo la durata nella cache dell'edge da quella nel browser. stale-while-revalidate continua a fornire contenuti scaduti mentre l'edge si aggiorna in background. stale-if-error mantiene le pagine accessibili durante le interruzioni del backend e aumenta la conversione e la fiducia. must-revalidate forza un controllo dopo la scadenza e impedisce rinnovi indesiderati. Questo controllo si ripercuote direttamente sulle percentuali di accesso alla cache e sulla fiducia. Scala soprattutto durante i picchi di traffico.
Intestazioni surrogate e di bordo
Nelle configurazioni con rendering dei bordi, utilizzo anche intestazioni surrogate (ad es. Controllo surrogato) per impostare TTL e criteri di stale più specifici per il CDN senza modificare il comportamento del browser. In questo modo, separo rigorosamente l'utente finale dalla strategia edge e mantengo il controllo su entrambi i livelli.
Invalidazioni e rilasci
Pianifico deliberatamente l'invalidazione: le risorse con versioni hanno raramente bisogno di essere eliminate, mentre le rotte HTML e API ne hanno bisogno più spesso. Definisco routine chiare per:
- Eliminazione per URL/Modello per gli hotfix e gli errori.
- Epurazioni basate su tag (se supportato) per invalidare il contenuto tematico.
- Lancio a tappeDistribuire prima le risorse, poi l'HTML con i nuovi riferimenti: in questo modo si evitano i riferimenti interrotti.
WordPress: implementare la cache in modo sicuro
In WordPress, attivo le intestazioni tramite i plugin o il mio codice e osservo il Modello-Struttura. I file statici in wp-includes e uploads ricevono TTL lunghi e immutabili, le pagine ricevono no-cache con must-revalidate. Attenzione agli utenti loggati: i cookie privati e differenziati impediscono una personalizzazione errata nella cache. Elimino i tipici ostacoli con regole chiare e un'occhiata a queste Errore di caching di WordPress. Se necessario, aggiungo il caching della pagina lato server e OPCache per rendere l'esecuzione di PHP percepibile. diminuzioni.
<?php
function add_cache_headers() {
if (!is_admin()) {
header('Cache-Control: public, max-age=31536000, immutable', true);
}
}
add_action('send_headers', 'add_cache_headers');
Disinnescare la personalizzazione e i cookie
Mi assicuro che Set-Cookie non è impostato su tutte le pagine. I cookie non necessari impediscono il caching condiviso. Fornisco esplicitamente per gli utenti che hanno effettuato l'accesso:
# Esempio di intestazione per le sessioni loggate
Cache-Control: private, no-store, max-age=0
Vary: accettazione-codifica
Le pagine di elenco e di dettaglio prive di personalizzazione, invece, possono usufruire di tutta la potenza della CDN. Nei casi in cui la personalizzazione è necessaria, lavoro con frammenti di bordi o piccoli payload API e metto il resto in cache in modo aggressivo.
Errori comuni e come li risolvo
Troppo basso TTL genera un lavoro inutile del server e tempi di risposta più elevati. Intestazioni mancanti o contraddittorie costringono i browser a comportamenti euristici e costano in termini di prestazioni. Senza versioning, rischio di avere risorse obsolete nonostante le lunghe cache. Strategie ETag diverse su più server portano a errori; garantisco hash coerenti o disattivo gli ETag. Verifico anche se gli intermediari, come i gateway, hanno i loro Intestazione e sovrascrivere.
Evitare la cache euristica
Se non sono impostati né Cache-Control né Expires, i browser tirano a indovinare. Per questo motivo, disattivo sempre le direttive esplicite e ripulisco i problemi pregressi (p.es. Pragma: no-cache da vecchie deleghe) per ottenere un comportamento deterministico.
Stringhe di query e cache busting
Uso la cache busting tramite hash del nome del file (style.abc123.css) invece delle stringhe di query. Molte cache trattano le diverse query come oggetti separati e quindi aumentano il numero di oggetti; con i file invariati, invece, un nuovo hash porta a un'invalidazione pulita.
Monitoraggio, test e metriche
Misuro l'effetto e apporto correzioni mirate invece di fare cambiamenti radicali, perché i dati battono l'istinto. chiaro. Uso curl per controllare le intestazioni, DevTools per simulare prime e ripetute visualizzazioni e Lighthouse per valutare l'effetto sulle cifre chiave. Dal lato del server e del CDN, monitoro le percentuali di accesso alla cache, le quote 304, i salvataggi di byte e il TTFB. I log mi mostrano se l'HTML viene effettivamente riconvalidato e se le risorse vengono richieste raramente. Questo mi permette di riconoscere tempestivamente le lacune e di migliorarle. mirato.
Segnali diagnostici aggiuntivi
- Età-L'intestazione mostra il tempo di permanenza di un oggetto nella cache, ideale per controllare il tempo di permanenza nella cache.
- Stato della cache (se disponibile) rivela HIT/MISS/STALE e la fonte (BROWSER, CDN, ORIGIN).
- Tempistica del server Lo uso per i miei marcatori (ad esempio cache;desc=“revalidated“) per rendere visibili i percorsi negli strumenti.
Automatizzo i controlli nella pipeline CI/CD: Dopo ogni distribuzione, un piccolo catalogo di test convalida intestazioni, codici di stato e dimensioni delle risposte per i percorsi principali. Le regressioni vengono notate immediatamente.
Effetti SEO e commerciali
Una consegna più rapida rafforza i Core Web Vitals, riduce i rimbalzi e aumenta la Visibilità. Ogni viaggio di andata e ritorno evitato riduce i costi del server e il rischio di picchi di carico. Con i siti ad alta intensità di traffico, risparmio ogni mese una quantità notevole di volume di dati che, a seconda della tariffa, può raggiungere cifre a tre zeri in euro. Un elevato tasso di accesso alla cache stabilizza inoltre i tempi di risposta per le campagne e le vendite. Chi aumenta le prestazioni in modo prevedibile di solito aumenta anche la Conversione.
Lista di controllo pratica in 7 passi
(1) Inventariare i file e separare HTML, asset, API e risposte sensibili. Segmentazione facilita le regole. (2) Introdurre il versioning per CSS/JS/immagini; utilizzare hash nei nomi dei file e impostare l'immutabilità. (3) Impostare no-cache e must-revalidate per l'HTML; mantenere le pagine fresche e controllabili. (4) Definire TTL brevi per le API e stale-if-error per mitigare i fallimenti. soggiorno. (5) Attivare ETag o Last-Modified in modo consistente; controllare le quote 304. (6) Sincronizzare le intestazioni di CDN e Origin; utilizzare s-maxage per Edge. (7) Misurare le percentuali di successo, il TTFB e i salvataggi di byte; ottimizzare iterativamente e documentare le decisioni.
Casi pratici ed esempi aggiuntivi
- API con richieste condizionaliConsento esplicitamente le risposte GET/HEAD nella cache condivisa (pubblica) con un TTL breve e un ETag. Metto in cache le risposte POST solo se sono definite in modo preciso e invariate, mentre per impostazione predefinita rimangono non memorizzabili.
- File di grandi dimensioni e richieste di intervallo: Per i media fornisco Campi di accettazione: byte e TTL lunghi; Edge alleggerisce l'Origin quando riprende i download.
- Immagini reattiveSe emetto diverse varianti dell'immagine a seconda del dispositivo, eseguo una codifica specifica (ad esempio in base a DPR o Larghezza) ed evito una variazione incontrollata su troppi segnali.
- Nessuna trasformazioneSe la qualità dell'immagine o la crittografia sono fondamentali, utilizzo Cache-Control: no-transform, in modo che i proxy non modifichino la risorsa.
Riassunto da portare via
Uso Cache-Control specificamente per Prestazioni, per armonizzare tempestività e costi. TTL lunghi e versioning per gli asset, riconvalida per l'HTML e scadenze brevi per le API offrono risultati affidabili. ETag e Last-Modified riducono il traffico di dati, mentre le politiche di s-maxage e stale utilizzano la cache dei bordi. Il monitoraggio rende visibili gli effetti e mostra dove è necessario intervenire. In questo modo l'hosting rimane veloce, controllabile ed economico. attraente.
