WordPress och webbläsarens cachelagring - ofta felaktigt konfigurerad

WordPress webbläsarcaching orsakar ofta långsamma svar, eftersom operatörerna måste Cache-huvud felaktigt inställd eller inte alls kontrollerad. Jag ska visa dig hur typiska felkonfigurationer returnerar 200 istället för 304, varför TTL saknas och hur jag kan ställa in cachelagring i WordPress korrekt. Prestanda trim.

Centrala punkter

• Lång TTL för statiska tillgångar förhindrar onödiga förfrågningar.
• Tydlig separation av statiska och dynamiska sökvägar skyddar admin och inloggning.
• Ett system blanda inte konkurrerande cachningsplugin-program.
• Kontrollera sidhuvud med DevTools och 304 status.
• Cachelagring på server och webbläsarens cache.

Så här fungerar webbläsarcaching i WordPress egentligen

Webbläsaren lagrar statiska filer lokalt, vilket gör att de inte behöver laddas om. HTTP-förfrågningar. Vid det andra besöket läser den bilder, CSS och JS från det lokala minnet och frågar bara servern om ändringar. Detta minskar mängden data, svarstiderna minskar och scrollningen känns omedelbart mer responsiv. vätska på. Om det inte finns några tydliga instruktioner laddas webbläsaren om helt och hållet varje gång och tiden till interaktivitet blir lidande. Korrekt inställda cache control-headers möjliggör 304-valideringar, minskar bandbredden och minskar belastningen på PHP och databasen. Jag använder detta konsekvent eftersom särskilt återkommande användare har störst nytta av ihållande cachelagring.

Varför konfigurationen ofta misslyckas

Många webbplatser levererar statiska filer med löjligt korta max-ålder-värden. Vissa plugins skriver över varandras .htaccess och anger motsägelsefulla direktiv. Webbplatsen markerar ofta administratörsvägar felaktigt, vilket gör att innehåll från /wp-admin eller /wp-login.php hamnar i cacheminnet oavsiktligt och sessioner kolliderar. Jag kontrollerar också skillnaden mellan det första och det återkommande anropet, eftersom detta tydligt förklarar verkliga användarupplevelser; jämförelsen passar in i detta Första samtal vs. återkommande samtal. Om du sedan använder frågesträngar utan versionshantering kommer du att skapa gamla filer i minnet och undra över föråldrad Stilar.

Ställ in WP-cacheheaders korrekt

Jag kontrollerar varaktigheten med Cache-kontroll och Expires, och jag undviker tvetydiga ETags i miljöer med flera servrar. För Apache ställer jag in Expires på meningsfulla värden och definierar „public, max-age“ för tillgångar. För Nginx lägger jag till add_header-direktiv och ser till att HTML får korta lagringstider eller „no-store“ om innehållet är personligt anpassat. Jag avaktiverar också ETag-rubriker om lastbalanserare eller proxyservrar inte genererar dessa värden konsekvent. På så sätt upprätthåller jag ett tydligt beteende i webbläsaren och undviker Revalideringar med varje klick.

ExpiresActive På
  ExpiresByType image/jpeg "tillgång plus 1 år"
  ExpiresByType image/png "tillgång plus 1 år"
  ExpiresByType text/css "tillgång plus 1 månad"
  ExpiresByType application/javascript "tillgång plus 1 månad"



  Header set Cache-Control "public, max-age=31536000" "expr=%{CONTENT_TYPE} =~ m#^(image/|font/|application/javascript)#"
  Header set Cache-Control "no-cache, no-store, must-revalidate" "expr=%{REQUEST_URI} =~ m#(wp-admin|wp-login.php)#"
  Huvuduppsättning av ETag
.

# Nginx
plats ~* .(jpg|jpeg|png|gif|ico|webp|avif|css|js|woff2?)$ {
    add_header Cache-kontroll "public, max-age=31536000";
}
plats ~* /(wp-admin|wp-login.php)$ {
    add_header Cache-kontroll "no-store";
}

Utökade direktiv för cache-kontroll i vardagslivet

Förutom „max-age“ och „no-store“ säkerställer moderna direktiv märkbar stabilitet. „immutable“ signalerar till webbläsaren att en fil inte kommer att ändras så länge filnamnet förblir detsamma - perfekt för versionshanterade tillgångar. „stale-while-revalidate“ gör att en utgången kopia kan levereras medan den uppdateras i bakgrunden. „stale-if-error“ håller en kopia redo om Origin kortvarigt returnerar fel. „s-maxage“ riktar sig till proxies/CDN:er och kan ha andra värden än „max-age“. Också viktigt: „public“ tillåter cachelagring i delade proxyer; „private“ är begränsat till webbläsaren. „no-cache“ betyder inte „cachelagra inte“, utan „cachelagring är tillåten, men revalidera före användning“ - en avgörande skillnad mot „no-store“.

# Apache 2.4 exempel (cache-tillgångar ännu mer robust)

  Cache-kontroll i rubrikuppsättning "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#"

# Nginx-exempel (304/Include-omdirigeringar)
plats ~* .(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" always;
}
plats ~* .html$ {
    add_header Cache-Control "no-cache, must-revalidate" alltid;
}

Rekommenderade cache-tider per filtyp

Jag väljer tiderna efter ändringsfrekvens, inte vana, eftersom Tillgångar åldras på väldigt olika sätt. Bilder, logotyper och ikoner förblir vanligtvis uppdaterade under lång tid, medan CSS/JS får mer frekventa iterationer. Webbtypsnitt ändras sällan, men kräver konsekventa CORS-headers. HTML fungerar ofta som en behållare för dynamiskt innehåll och kan därför vara kort eller bara revalideras. API:er bör ges tydligt definierade regler så att klienter kan arbeta korrekt med JSON undvika.

Filtyp	Cache-kontroll rekommendation	Ledtråd
Bilder (jpg/png/webp/avif/svg)	offentlig, max-ålder=31536000	Använd årlig cache med filversionering
CSS/JS	offentlig, max-age=2592000	Lägg till version till filnamn för uppdateringar
Teckensnitt (woff/woff2)	offentlig, max-ålder=31536000	Ställ in Access-Control-Allow-Origin korrekt
HTML (sidor)	no-cache, must-revalidate eller kort max-age	Var mycket försiktig med dynamiskt innehåll
REST API (json)	privat, max-age=0, måste-valideras	Differentiera enligt slutpunkt

Undvik konflikter med plugins

Jag använder som mest Plugin för cachning och kontrollera om webbhotellet redan specificerar regler på servernivå. Kombinationer som W3 Total Cache plus WP Super Cache skapar ofta dubbla direktiv som upphäver varandra. WP Rocket erbjuder en snabb installation, men behöver tydliga undantag för dynamiska sökvägar och e-handel. I vilket fall som helst kontrollerar jag den genererade .htaccess efter att ha sparat den för att upptäcka ologiska headers. Sedan testar jag kritiska sidor som kassa, inloggning och personliga instrumentpaneler för att se om de är korrekta. Förbikoppling.

Cachelagring och cookies: inloggade användare, WooCommerce, sessioner

HTML för inloggade användare får inte lagras i den publika cachen. WordPress ställer in cookies som wordpress_inloggad_i_, WooCommerce kompletterad woocommerce_artiklar_i_cart, wp_woocommerce_session och andra. Istället för över Vary: Cookie Jag kringgår helt cacheminnet för sådana förfrågningar. Detta gör att kassaprocesserna är stabila och att de personliga områdena är korrekta. Jag använder också regler på serversidan som ställer in mer restriktiva rubriker när cookies känns igen.

# Apache: Känner igen cookies och ställer in bypass-rubriker

  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: Cookie-baserad förbikoppling
if ($http_cookie ~* "(wordpress_logged_in|woocommerce_items_in_cart|wp_woocommerce_session)") {
    add_header Cache-Control "private, no-store" alltid;
}

Många caching-plugins erbjuder kryssrutor för detta (WooCommerce/Cart/Exclude checkout). Viktigt: Nonces (_wpnonce) i formulär och Heartbeat API genererar frekventa ändringar. Jag ser till att frontend-HTML med nonces inte är permanent cachad eller fungerar via „no-cache, must-revalidate“.

Riktad behandling av HTML: personligt anpassad eller generell

Alla sidor är inte likadana. Artiklar, landningssidor och juridiska sidor kan ofta cachas med en kort TTL eller revalidering. Arkiv, söksidor, instrumentpaneler, kontoområden och kassor förblir dynamiska. Om sidcachelagring är inblandad följer jag följande praxis: cachelagra endast publik HTML utan cookies, annars „privat“ eller „no-store“. Om du testar mikrocachelagring (t.ex. 30-60 sekunder för mycket besökta, icke-personaliserade sidor) bör du definiera strikta undantag för frågeparametrar och sessioner. WordPress har med DONOTCACHEPAGE en konstant som mallar kan ställa in på svåra sidor - jag använder detta konsekvent för att undvika fel.

Kombinera cachelagring på serversidan på ett förnuftigt sätt

Cachelagring i webbläsaren slutar i klienten, men jag avlastar också servern med sid-, objekt- och opcode-cache på riktigt Belastningstoppar. Cachelagring av sidor levererar statisk HTML innan PHP ens startar. Redis eller Memcached minskar databasförfrågningar för upprepade förfrågningar och minskar TTFB märkbart. OPcache tillhandahåller förkompilerade PHP-bytekodfragment och förkortar därmed exekveringstiden. I slutändan är det som räknas en ren anslutning mellan servercachen och webbläsarens cache så att det andra besöket är mer eller mindre en framgång. omedelbar arbeten.

CDN-integration utan överraskningar

CDN:er använder sin egen TTL-logik och svarar på „s-maxage“. Jag gör därför en tydlig åtskillnad: „max-age“ för webbläsare, „s-maxage“ för Edge. Om utplaceringar väntar utlöser jag en riktad rensning istället för att förstöra „Cache Everything“ globalt. Viktigt: Cacha endast HTML på Edge om inga cookies är inblandade. Annars skapas felaktiga tillstånd eftersom edge-cachen delar personliga svar. För tillgångar sätter jag långa TTL:er och förlitar mig på versionering av filnamn. CDN:er kan ignorera frågesträngar - ytterligare en anledning att behålla versionerna i filnamnet. Header-normalisering (inga överflödiga „Vary“-värden, konsekvent „Content-Type“) förhindrar uppblåsta cache-nycklar.

Steg-för-steg: ren installation

Jag börjar med ett plugin och aktiverar webbläsarcaching för CSS, JS, bilder och teckensnitt innan jag aktiverar .htaccess slutföra. Jag ställer sedan in max-age högt för statiska tillgångar och förser HTML med korta tider eller no-cache-regler. Jag avaktiverar ETags om flera servrar är inblandade och förlitar mig på Last-Modified plus 304. Jag utlöser sedan en förladdning så att viktiga sidor omedelbart finns tillgängliga som statiska kopior. Slutligen kontrollerar jag sökvägar för butik, inloggning och administration så att inget privat innehåll lagras i mellanlagring land.

Praktisk diagnostik med CLI och header-kontroller

DevTools är obligatoriska, men jag går djupare med CLI-tester. A curl -I visar rubrik utan nedladdning; med -H Jag simulerar förhållanden. Jag kontrollerar till exempel om revalideringar verkligen returnerar 304, om „Ålder“ ökar från en proxy/CDN och om cookies stänger av cachelagring.

# Visa rubrik
curl -I https://example.com/style.css

Simulera #-förnyad validering (If-Modified-Since)
curl -I -H "If-Modified-Since: Tue, 10 Jan 2023 10:00:00 GMT" https://example.com/style.css

#-test med cookie (bör tvinga fram förbikoppling)
curl -I -H "Cookie: wordpress_logged_in_=1" https://example.com/

Jag ser till att tillgångar har ett långt „cache control“-värde, helst „immutable“. HTML bör ha „no-cache“ eller en kort TTL. Om jag fortfarande får 200 istället för 304, finns det ofta omdirigeringar i spel som ogiltigförklarar ETags/Last-Modified. Dessutom gäller „add_header“ i Nginx bara för 200-svar som standard - med „always“ ställer jag också in rubrikerna för 304 och 301/302.

Testning och validering av headers

Jag öppnar DevTools, laddar om sidan en gång, rensar cacheminnet och laddar om för att få 304 vs. 200 för att observera. I nätverkspanelen kontrollerar jag cachekontroll, ålder, ETag/load-modified och svarsstorlekar. Om det fortfarande förekommer direktträffar i stället för revalideringar kontrollerar jag om det finns konflikter med omdirigeringar, cookies eller frågesträngar. För knepiga fall hjälper den här artikeln om fallgropar med headers mig: Sabotage av cachehuvud. Jag upprepar kontrollen efter varje plugin-uppdatering eftersom ändringar av regler ofta görs i det tysta. passera.

Versionering, CDN och cache-busting

Jag hänger Version till filnamn (style.23.css istället för style.css?ver=23) så att webbläsare behåller långa cachar och ändå laddar nytt innehåll omedelbart. Ett CDN distribuerar statiska filer globalt, ställer in sina egna TTL:er i edge PoPs och förkortar RTT:er drastiskt. Viktigt: Cacha bara HTML i CDN om det inte krävs någon personalisering, annars skapas felaktiga tillstånd. Under distributionen ändrar jag versionsnumret automatiskt så att användarna aldrig fastnar med gamla skript. Det är så jag kombinerar hårda TTL:er för webbläsare med säkra Cache-borttagning.

Ren versionshantering i WordPress-byggnader

Det mest tillförlitliga är en byggpipeline som skriver hashar i filnamn (t.ex. app.9f3c.css). WordPress laddar sedan exakt den här filen - webbläsare kan behålla den i ett år tack vare „immutable“. Om filnamn inte kan ändras ställer jag in versionsnumret dynamiskt från fildatumet som en reservlösning. Detta håller frågesträngarna korrekta och tillförlitliga.

// functions.php (fallback versionering via filemtime)
add_action('wp_enqueue_scripts', funktion () {
    $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);
});

Viktigt: Om filnamnet innehåller versioner kan „immutable“ vara inställt. Om du bara använder frågesträngar bör webbläsare kunna revalidera så att uppdateringar kommer fram på ett tillförlitligt sätt. Jag ser också till att byggverktyg rensar upp gamla filer så att CDN:er inte lagrar ett onödigt stort antal varianter.

Cache och ladda webbteckensnitt korrekt

Webbtypsnitt behöver långa TTL, korrekta CORS-headers och valfri förladdning så att Layout hoppar misslyckas med att visas. Jag placerar woff2-filer på samma domän eller ställer in Access-Control-Allow-Origin rent. Definiera dessutom font-display: swap så att texten förblir synlig omedelbart medan teckensnittet laddas. Om du vill optimera laddningstiden för dina teckensnitt hittar du användbara tips här: Ladda webbteckensnitt snabbare. Med rena cacheheaders och en föranslutning till CDN:er förkortar jag FOUT/FOIT märkbart och säkerställer konsekvent Rendering-Resultat.

Korrekt inställning av teckensnitt, CORS och Vary

Typsnitt från ett annat ursprung kräver CORS. Jag ställer in Access-kontroll-Allow-Origin (t.ex. till din egen domän eller „*“ för verkligt offentliga) och undvik onödiga Varierande: Ursprung, som blåser upp cache-nycklar. Rekommenderas för typsnitt: public, max-age=31536000, immutable. Preload förbättrar First Paint, men ändrar inte TTL - preload och hård cachelagring kompletterar varandra. Jag glömmer inte heller att komprimerad leverans (br/gzip) a Vary: Acceptera-kodning krävs för att proxyer ska separeras korrekt.

Typiska felmönster och snabba lösningar

Om gammal kod dyker upp efter en uppdatering Versionering på filnamnet. Om webbläsaren laddas om helt och hållet varje gång innehåller sidhuvudet motsägelsefulla instruktioner eller så tar proxyer bort dem på vägen. Om en utcheckning avbryts cachelagrar webbplatsen förmodligen sidor på sessionssidan eller API-svar. Om administratörssökvägar slinker in i cacheminnet saknas undantag för wp-admin och inloggning eller så cachar ett plugin globalt. Jag löser detta genom att avaktivera steg för steg, konsolidera rubriker, utesluta kritiska vägar och slutligen effekten med 304-status bekräfta.

Ofta förbisedda detaljer som gör stor skillnad

• Nginx add_header gäller inte för 304/redirects utan „alltid“ - cache-rubriker saknas då för valideringar. Jag ställer konsekvent in „alltid“.
• Expires vs. cache-kontroll: „Cache-Control“ har prioritet, „Expires“ fungerar som en reserv för gamla klienter. Undvik duplicerad, motsägelsefull information.
• ETag i konfigurationer med flera servrar: Inkonsekventa ETags förstör 304. Jag inaktiverar ETags eller använder svaga validerare och förlitar mig på „Last-Modified“.
• Variera till ett minimum: „Vary: Accept-Encoding“ är obligatoriskt för komprimering, „Vary: Cookie“ fyller på edge caches - bättre att kringgå cookie-baserade.
• SVG och MIME-typ: Korrekt image/svg+xml set, ge lång TTL och överväga inline SVG för kritiska ikoner.
• Undvik omdirigeringskedjor: Varje 301/302 kan förlora validatorer och tvinga 200 - rena webbadresser utan kaskader.
• Använd prioritet/preload på ett målinriktat sätt: hämtningsprioritet="hög" eller förladdning av kritiska tillgångar påskyndar det första anropet; cachelagring är effektivt för återkommande användare.
• Skillnad mellan REST-API: Offentliga JSON-filer som sällan ändras kan cachelagras kortvarigt; slutpunkter med tokens/cookies är strikt „privata“.

Kortfattat sammanfattat

Jag förlitar mig på tydliga Reglerlånga TTL:er för tillgångar, korta eller revaliderade HTML-svar, versionshantering och ett enda cache-plugin. Sedan kombinerar jag webbläsarcache med sid-, objekt- och opcode-cache för att minska serverbelastningen. Jag kontrollerar DevTools, letar efter 304, kontrollerar headers och eliminerar konflikter med omdirigeringar eller cookies. För det praktiska testet jämför jag mätningar vid det första och upprepade anrop och fokuserar på märkbara förbättringar. Om du följer dessa steg kan du WordPress till en tillförlitlig nivå av webbläsarcachelagring. hastighet och håller både användare och sökmotorer nöjda.