...
logo di web hosting

WordPress e la cache del browser - spesso configurati in modo errato

Il caching del browser di WordPress spesso causa risposte lente, perché gli operatori devono Intestazione della cache impostati in modo errato o non controllati affatto. Vi mostrerò come le tipiche configurazioni errate restituiscano 200 invece di 304, perché i TTL sono mancanti e come sia possibile impostare correttamente il caching in WordPress. Prestazioni assetto.

Punti centrali

  • TTL lungo per le risorse statiche evita richieste inutili.
  • Separazione netta di percorsi statici e dinamici protegge l'amministrazione e il login.
  • Un sistema non mescolare plug-in di caching concorrenti.
  • Controllare le intestazioni con DevTools e lo stato 304.
  • Caching del server e la cache del browser.

Come funziona davvero la cache del browser in WordPress

Il browser memorizza localmente i file statici, evitando così di ricaricarli. Richieste HTTP. Alla seconda visita, legge immagini, CSS e JS dalla memoria locale e chiede al server solo le modifiche. In questo modo si riduce la quantità di dati, i tempi di risposta si riducono e lo scorrimento risulta immediatamente più reattivo. liquido on. Se non ci sono istruzioni chiare, il browser viene ricaricato completamente ogni volta e il tempo di interattività ne risente. Le intestazioni di controllo della cache impostate correttamente consentono di attivare le convalide 304, di ridurre la larghezza di banda e di ridurre il carico su PHP e sul database. Lo uso costantemente perché gli utenti ricorrenti, in particolare, traggono i maggiori vantaggi dalla cache persistente.

Perché la configurazione spesso fallisce

Molti siti consegnano file statici con una lunghezza ridicola. età massima-valori. Alcuni plugin sovrascrivono gli .htaccess degli altri e impostano direttive contraddittorie. Spesso il sito contrassegna i percorsi di amministrazione in modo errato, facendo sì che il contenuto di /wp-admin o /wp-login.php finisca involontariamente nella cache e che le sessioni si scontrino. Verifico anche la differenza tra la prima chiamata e quella ricorrente, perché questo spiega chiaramente le esperienze reali degli utenti; il confronto si inserisce in questo schema Prima chiamata vs. chiamante di ritorno. Se si utilizzano ancora le stringhe di query senza il versioning, si creeranno vecchi file in memoria e ci si chiederà se obsoleto Stili.

Impostare correttamente le intestazioni della cache di WP

Controllo la durata con Controllo della cache e Expires, ed evito ETag ambigui in ambienti multi-server. Per Apache, imposto Expires a valori significativi e definisco „public, max-age“ per le risorse. Per Nginx, aggiungo le direttive add_header e mi assicuro che l'HTML abbia tempi brevi o „no-store“ se il contenuto è personalizzato. Disattivo anche le intestazioni ETag se i bilanciatori di carico o i proxy non generano questi valori in modo coerente. In questo modo, impongo un comportamento chiaro nel browser ed evito di Riconvalide ad ogni clic.

ScadenzaAttiva On
  ExpiresByType image/jpeg "accesso più 1 anno".
  ExpiresByType image/png "accesso più 1 anno".
  ExpiresByType text/css "accesso più 1 mese
  ExpiresByType application/javascript "accesso più 1 mese".



  Header set Cache-Control "public, max-age=31536000" "expr=%{CONTENT_TYPE} =~ m#^(immagine/|font/|applicazione/javascript)#"
  Header set Cache-Control "no-cache, no-store, must-revalidate" "expr=%{REQUEST_URI} =~ m#(wp-admin|wp-login.php)#"
  Intestazione non impostata ETag
# Nginx
posizione ~* .(jpg|jpeg|png|gif|ico|webp|avif|css|js|woff2?)$ {
    add_header Cache-Control "public, max-age=31536000";
}
location ~* /(wp-admin|wp-login.php)$ {
    add_header Cache-Control "no-store";
}

Le direttive di controllo della cache estese nella vita quotidiana

Oltre a „max-age“ e „no-store“, le direttive moderne garantiscono una notevole stabilità. „immutable“ segnala al browser che un file non cambierà finché il nome del file rimarrà lo stesso, ideale per le risorse con versioni. „stale-while-revalidate“ permette di consegnare una copia scaduta mentre viene aggiornata in background. „stale-if-error“ mantiene una copia pronta se l'origine restituisce brevemente degli errori. „s-maxage“ è rivolto ai proxy/CDN e può avere valori diversi da „max-age“. Inoltre, è importante: „public“ consente la cache nei proxy condivisi; „private“ è limitato al browser. „no-cache“ non significa „non memorizzare nella cache“, ma „la memorizzazione nella cache è consentita, ma va riconvalidata prima dell'uso“ - una differenza fondamentale rispetto a „no-store“.

# Esempio di Apache 2.4 (cache delle risorse ancora più robusta)

  Header set Cache-Control "public, max-age=31536000, immutable, stale-while-revalidate=86400, stale-if-error=259200" "expr=%{REQUEST_URI} =~ m#.(css|js|woff2?|png|jpe?g|webp|avif)$#"
  Header set Cache-Control "no-cache, must-revalidate" "expr=%{CONTENT_TYPE} =~ m#^text/html#"
# Esempio Nginx (reindirizzamento 304/Include)
location ~* .(css|js|woff2?|png|jpe?g|webp|avif)$ {
    add_header Cache-Control "public, max-age=31536000, immutable, stale-while-revalidate=86400, stale-if-error=259200" sempre;
}
posizione ~* .html$ {
    add_header Cache-Control "no-cache, must-revalidate" sempre;
}

Durata della cache consigliata per tipo di file

Scelgo gli orari in base alla frequenza dei cambiamenti, non all'abitudine, perché Attività invecchiano in modo molto diverso. Le immagini, i loghi e le icone di solito rimangono aggiornati per molto tempo, mentre CSS/JS ricevono iterazioni più frequenti. I font web cambiano raramente, ma richiedono intestazioni CORS coerenti. L'HTML spesso funge da contenitore per contenuti dinamici e può quindi essere breve o solo riconvalidato. Le API devono essere dotate di regole chiaramente definite, in modo che i clienti possano lavorare correttamente con JSON evitare.

Tipo di file Raccomandazione cache-control Suggerimento
Immagini (jpg/png/webp/avif/svg) pubblico, età massima=31536000 Utilizzare la cache annuale con il versioning dei file
CSS/JS pubblico, max-age=2592000 Aggiungere la versione al nome del file per gli aggiornamenti
Caratteri (woff/woff2) pubblico, età massima=31536000 Impostare correttamente Access-Control-Allow-Origin
HTML (pagine) no-cache, must-revalidate o breve max-age Attenzione ai contenuti dinamici
API REST (json) private, max-age=0, must-revalidate Differenziare in base all'endpoint

Evitare conflitti con i plugin

Utilizzo al massimo Plugin di caching e verificare se l'hosting specifica già delle regole a livello di server. Combinazioni come W3 Total Cache e WP Super Cache spesso creano direttive duplicate che si annullano a vicenda. WP Rocket offre una configurazione rapida, ma necessita di chiare esclusioni per i percorsi dinamici e l'e-commerce. In ogni caso, controllo l'.htaccess generato dopo il salvataggio per riconoscere le intestazioni illogiche. Poi verifico che le pagine critiche, come quelle di checkout, login e dashboard personalizzate siano corrette. Bypassare.

Caching e cookie: utenti connessi, WooCommerce, sessioni

Il codice HTML degli utenti connessi non deve essere memorizzato nella cache pubblica. WordPress imposta cookie come wordpress_logged_in, WooCommerce integrato woocommerce_items_in_cart, wp_woocommerce_session_ e altri. Invece dell'eccesso di Variabile: Cookie Per tali richieste escludo completamente le cache. In questo modo i processi di pagamento sono stabili e le aree personalizzate sono corrette. Utilizzo anche regole lato server che impostano intestazioni più restrittive quando vengono riconosciuti i cookie.

# Apache: Riconoscimento dei cookie e impostazione delle intestazioni di bypass

  SetEnvIfNoCase Cookie "wordpress_logged_in_|woocommerce_items_in_cart|wp_woocommerce_session" has_session
  Header set Cache-Control "private, no-store" env=has_session
# Nginx: bypass basato sui cookie
se ($http_cookie ~* "(wordpress_logged_in|woocommerce_items_in_cart|wp_woocommerce_session)") {
    add_header Cache-Control "private, no-store" sempre;
}

Molti plugin di caching offrono caselle di controllo per questo (WooCommerce/Cart/Exclude checkout). Importante: Nonces (_wpnonce) nei moduli e l'API Heartbeat generano modifiche frequenti. Mi assicuro che l'HTML del frontend con i nonces non sia permanentemente memorizzato nella cache o funzioni tramite „no-cache, must-revalidate“.

Trattamento mirato dell'HTML: personalizzato vs. generale

Non tutte le pagine sono uguali. Gli articoli, le landing page e le pagine legali possono spesso essere memorizzate nella cache con un breve TTL o una riconvalida. Archivi, pagine di ricerca, dashboard, aree account e checkout rimangono dinamici. Se si tratta di cache di pagine, mi attengo alla seguente prassi: solo cache di HTML pubblico senza cookie, altrimenti „private“ o „no-store“. Se si sta testando il micro-caching (ad esempio 30-60 secondi per pagine molto frequentate e non personalizzate), è necessario definire esclusioni rigorose per i parametri di query e le sessioni. WordPress ha con DONOTCACHEPAGE una costante che i modelli possono impostare su pagine complesse; io la uso costantemente per evitare errori.

Combinare la cache lato server in modo sensato

La cache del browser termina nel client, ma alleggerisco anche il server con la cache delle pagine, degli oggetti e degli opcode per il vero e proprio Picchi di carico. La cache della pagina fornisce HTML statico prima ancora che PHP inizi. Redis o Memcached riducono le interrogazioni al database per le richieste ripetute e riducono sensibilmente il TTFB. OPcache fornisce frammenti di bytecode PHP precompilati, riducendo così il tempo di esecuzione. Alla fine, ciò che conta è una connessione pulita tra la cache del server e quella del browser, in modo che la seconda visita sia più o meno un successo. istantaneo funziona.

Integrazione CDN senza sorprese

I CDN utilizzano la propria logica TTL e rispondono a „s-maxage“. Pertanto, faccio una chiara distinzione: „max-age“ per i browser, „s-maxage“ per Edge. Se le distribuzioni sono in sospeso, attivo una pulizia mirata invece di distruggere globalmente „Cache Everything“. Importante: su Edge si memorizza nella cache solo l'HTML se non sono coinvolti i cookie. In caso contrario, si creano stati errati perché la cache di Edge condivide risposte personalizzate. Per gli asset, imposto TTL lunghi e mi affido al versioning dei nomi dei file. Le CDN possono ignorare le stringhe di query: un altro motivo per mantenere le versioni nel nome del file. La normalizzazione delle intestazioni (nessun valore „Vary“ superfluo, „Content-Type“ coerente) evita di gonfiare le chiavi della cache.

Passo dopo passo: installazione pulita

Comincio con un plugin e attivo la cache del browser per CSS, JS, immagini e font prima di attivare il programma di gestione dei file. .htaccess finalizzare. Imposto poi un'età massima elevata per le risorse statiche e fornisco HTML con tempi brevi o regole no-cache. Disattivo ETags se sono coinvolti più server e mi affido a Last-Modified più 304. Attivo quindi un preload in modo che le pagine importanti siano immediatamente disponibili come copie statiche. Infine, verifico i percorsi del negozio, del login e dell'amministrazione, in modo che nessun contenuto privato sia memorizzato nel file memoria temporanea terra.

Diagnostica pratica con CLI e controlli di intestazione

I DevTools sono obbligatori, ma io approfondisco i test con la CLI. A curl -I mostra l'intestazione senza download; con -H Simulo le condizioni. Ad esempio, verifico se le riconvalide restituiscono davvero 304, se „Age“ aumenta da un proxy/CDN e se i cookie disattivano la cache.

# Mostra intestazione
curl -I https://example.com/style.css

Simulare la riconvalida dell"# (If-Modified-Since)
curl -I -H "If-Modified-Since: Tue, 10 Jan 2023 10:00:00 GMT" https://example.com/style.css

Test # con cookie (dovrebbe forzare il bypass)
curl -I -H "Cookie: wordpress_logged_in_=1" https://example.com/

Mi assicuro che le risorse abbiano un lungo valore di „controllo della cache“, idealmente „immutabile“. L'HTML dovrebbe avere „no-cache“ o un TTL breve. Se ottengo ancora 200 invece di 304, spesso ci sono dei reindirizzamenti che invalidano ETags/Last-Modified. Inoltre, „add_header“ in Nginx si applica solo alle risposte 200 per impostazione predefinita - con „always“ imposto anche le intestazioni per 304 e 301/302.

Test e validazione delle intestazioni

Apro DevTools, ricarico la pagina una volta, cancello la cache e ricarico per ottenere 304 contro 304. 200 per osservare. Nel pannello di rete, controllo il controllo della cache, l'età, ETag/load-modified e le dimensioni delle risposte. Se ci sono ancora visite dirette invece di riconvalide, controllo se ci sono conflitti con i reindirizzamenti, i cookie o le stringhe di query. Per i casi più complicati, mi aiuta questo articolo sulle insidie delle intestazioni: Sabotare l'intestazione della cache. Ripeto il controllo dopo ogni aggiornamento del plugin, perché le modifiche alle regole vengono spesso apportate in modo silenzioso. passaggio.

Versioning, CDN e cache busting

Appendo il Versione ai nomi dei file (style.23.css invece di style.css?ver=23) in modo che i browser conservino lunghe cache e carichino comunque immediatamente i nuovi contenuti. Una CDN distribuisce i file statici a livello globale, imposta i propri TTL nei PoP periferici e riduce drasticamente gli RTT. Importante: memorizzare l'HTML nella cache della CDN solo se non è richiesta la personalizzazione, altrimenti si creeranno stati errati. Durante la distribuzione, modifico automaticamente il numero di versione, in modo che gli utenti non rimangano mai bloccati con script vecchi. Questo è il modo in cui combino il TTL del browser con la sicurezza Sfruttamento della cache.

Pulizia delle versioni nelle build di WordPress

Il più affidabile è una pipeline di compilazione che scrive gli hash nei nomi dei file (ad es. app.9f3c.css). WordPress carica quindi esattamente questo file - i browser possono conservarlo per un anno grazie a „immutable“. Come ripiego, se i nomi dei file non possono essere modificati, imposto il numero di versione dinamicamente dalla data del file. In questo modo le stringhe di query rimangono corrette e affidabili.

// functions.php (fallback versioning via filemtime)
add_action('wp_enqueue_scripts', function () {
    $css = get_stylesheet_directory() . '/dist/style.css';
    $ver = file_exists($css) ? filemtime($css) : null;
    wp_enqueue_style('theme', get_stylesheet_directory_uri() . '/dist/style.css', [], $ver);
});

Importante: se il nome del file contiene versioni, può essere impostato „immutabile“. Se si usano solo stringhe di query, i browser dovrebbero essere in grado di riconvalidare, in modo che gli aggiornamenti arrivino in modo affidabile. Mi assicuro anche che gli strumenti di compilazione puliscano i vecchi file, in modo che le CDN non memorizzino un numero inutilmente elevato di varianti.

Cache e caricamento corretto dei font web

I font web hanno bisogno di TTL lunghi, di intestazioni CORS corrette e di un precaricamento opzionale, in modo tale che Salti di layout non appaiono. Posiziono i file woff2 sullo stesso dominio o imposto Access-Control-Allow-Origin in modo pulito. Inoltre, definite font-display: swap in modo che il testo rimanga visibile immediatamente durante il caricamento del font. Se volete ottimizzare il tempo di caricamento dei vostri font, troverete consigli utili qui: Caricare i font web più velocemente. Con intestazioni di cache pulite e una preconnessione alle CDN, accorcio sensibilmente FOUT/FOIT e assicuro una coerenza Rendering-Risultati.

Sintonizzare correttamente i font, CORS e Vary

I caratteri provenienti da un'altra origine richiedono CORS. Ho impostato Controllo dell'accesso - Consenti origine (ad esempio, al proprio dominio o „*“ per il pubblico) ed evitare un'inutile Variare: Origine, che gonfia le chiavi della cache. Consigliato per i font: pubblico, max-age=31536000, immutabile. Il precarico migliora il First Paint, ma non cambia il TTL - il precarico e l'hard caching si completano a vicenda. Non dimentico inoltre che la consegna compressa (br/gzip) a Vary: Accept-Encoding è necessario per separare correttamente i proxy.

Modelli di errore tipici e soluzioni rapide

Se dopo un aggiornamento compare del codice vecchio, il Versione sul nome del file. Se il browser si ricarica completamente ogni volta, le intestazioni contengono istruzioni contraddittorie o i proxy le rimuovono durante il percorso. Se un checkout viene annullato, probabilmente il sito sta mettendo in cache le pagine lato sessione o le risposte API. Se i percorsi dell'amministrazione finiscono nella cache, mancano le esclusioni per wp-admin e login o un plugin sta facendo la cache a livello globale. Risolvo il problema disattivando passo dopo passo, consolidando le intestazioni, escludendo i percorsi critici e, infine, l'effetto con lo stato 304. confermare.

Dettagli spesso trascurati che fanno una grande differenza

  • Nginx add_header non si applica ai 304/reindirizzamenti senza „sempre“: le intestazioni della cache mancano per le convalide. Ho sempre impostato „sempre“.
  • Scadenza e controllo della cache: „Cache-Control“ ha la priorità, „Expires“ serve come ripiego per i vecchi client. Evitare informazioni duplicate e contraddittorie.
  • ETag in configurazioni multi-server: ETag incoerenti distruggono 304. Disabilito ETag o uso validatori deboli e mi affido a „Last-Modified“.
  • Variare al minimo: „Vary: Accept-Encoding“ è obbligatorio per la compressione, „Vary: Cookie“ gonfia le cache dei bordi: meglio bypassare i cookie.
  • SVG e tipo MIME: Corretto immagine/svg+xml impostare, dare un TTL lungo e considerare SVG inline per le icone critiche.
  • Evitare le catene di reindirizzamento: Ogni 301/302 può perdere i validatori e forzare 200 - URL puliti senza cascate.
  • Utilizzare priorità/precarico in modo mirato: fetchpriority="high" o il precaricamento delle risorse critiche accelera la prima chiamata; il caching è efficace per gli utenti che ritornano.
  • Differenziare REST-API: I JSON pubblici, che cambiano raramente, possono essere memorizzati nella cache per breve tempo; gli endpoint con token/cookie sono strettamente „privati“.

Riassumendo brevemente

Mi affido a una chiara RegoleTTL lunghi per le risorse, risposte HTML brevi o riconvalidate, versioning e un unico plugin per la cache. Poi combino la cache del browser con quella delle pagine, degli oggetti e degli opcode per ridurre il carico del server. Controllo DevTools, cerco 304, controllo le intestazioni ed elimino i conflitti con i reindirizzamenti o i cookie. Per il test pratico, confronto le misurazioni sulla prima chiamata e su quelle ripetute e mi concentro sui miglioramenti evidenti. Se seguite questi passaggi, potete portare WordPress a un livello affidabile di cache del browser. Velocità e fa felici gli utenti e i motori di ricerca.

Articoli attuali