...
webhosting-logo

WordPress og browser-caching - ofte konfigureret forkert

WordPress browser-caching forårsager ofte langsomme svar, fordi operatørerne skal Cache-overskrift indstillet forkert eller slet ikke kontrolleret. Jeg vil vise dig, hvordan typiske fejlkonfigurationer returnerer 200 i stedet for 304, hvorfor TTL'er mangler, og hvordan jeg kan opsætte caching i WordPress korrekt. Ydelse trim.

Centrale punkter

  • Lang TTL for statiske aktiver forhindrer unødvendige anmodninger.
  • Klar adskillelse af statiske og dynamiske stier beskytter admin og login.
  • Et system Bland ikke konkurrerende cache-plugins.
  • Tjek overskrifter med DevTools og 304 status.
  • Server-caching og browserens cache.

Sådan fungerer browser-caching i WordPress i virkeligheden

Browseren gemmer statiske filer lokalt, så det ikke er nødvendigt at genindlæse dem. HTTP-anmodninger. Ved det andet besøg læser den billeder, CSS og JS fra den lokale hukommelse og beder kun serveren om ændringer. Det reducerer mængden af data, svartiderne bliver kortere, og det føles straks mere responsivt at scrolle. flydende på. Hvis der ikke er klare instruktioner, genindlæses browseren helt hver gang, og tiden til interaktion lider. Korrekt indstillede cache control headers muliggør 304-valideringer, reducerer båndbredden og reducerer belastningen på PHP og databasen. Jeg bruger dette konsekvent, fordi især tilbagevendende brugere har mest gavn af vedvarende caching.

Hvorfor konfiguration ofte mislykkes

Mange websteder leverer statiske filer med latterligt korte max-alder-værdier. Nogle plugins overskriver hinandens .htaccess og indstiller modstridende direktiver. Webstedet markerer ofte admin-stier forkert, hvilket får indhold fra /wp-admin eller /wp-login.php til at ende i cachen utilsigtet, og sessioner kolliderer. Jeg tjekker også forskellen mellem det første og det tilbagevendende kald, da dette tydeligt forklarer reelle brugeroplevelser; sammenligningen passer med dette Første opkald vs. tilbagevendende opkald. Hvis du derefter bruger forespørgselsstrenge uden versionering, vil du oprette gamle filer i hukommelsen og undre dig over Forældet Stilarter.

Indstil WP-cache-headers korrekt

Jeg kontrollerer varigheden med Cache-kontrol og Expires, og jeg undgår tvetydige ETags i miljøer med flere servere. For Apache indstiller jeg Expires til meningsfulde værdier og definerer „public, max-age“ for aktiver. For Nginx tilføjer jeg add_header-direktiver og sørger for, at HTML får kort tid eller „no-store“, hvis indholdet er personaliseret. Jeg deaktiverer også ETag-headere, hvis load balancere eller proxyer ikke genererer disse værdier konsekvent. På denne måde håndhæver jeg en klar adfærd i browseren og undgår Revalideringer med hvert klik.

.
  ExpiresActive On
  ExpiresByType image/jpeg "adgang plus 1 år"
  ExpiresByType image/png "adgang plus 1 år"
  ExpiresByType text/css "adgang plus 1 måned"
  ExpiresByType application/javascript "adgang plus 1 måned"
.


  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)#"
  Header uindstillet ETag
.
# Nginx
placering ~* .(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";
}

Udvidede direktiver om cache-kontrol i hverdagen

Ud over „max-age“ og „no-store“ sikrer moderne direktiver mærkbar stabilitet. „immutable“ signalerer til browseren, at en fil ikke ændres, så længe filnavnet forbliver det samme - ideelt til versionerede aktiver. „stale-while-revalidate“ gør det muligt at levere en udløbet kopi, mens den opdateres i baggrunden. „stale-if-error“ holder en kopi klar, hvis Origin kortvarigt returnerer fejl. „s-maxage“ er rettet mod proxyer/CDN'er og kan have andre værdier end „max-age“. Også vigtigt: „public“ tillader caching i delte proxyer; „private“ er begrænset til browseren. „no-cache“ betyder ikke „ikke cachelagring“, men „cachelagring tilladt, men revalider før brug“ - en afgørende forskel fra „no-store“.

# Apache 2.4-eksempel (cache-aktiver endnu mere robust)

  Header-sæt 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#"
.
# Nginx-eksempel (304/Include-omdirigeringer)
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" always;
}
location ~* .html$ {
    add_header Cache-Control "no-cache, must-revalidate" always;
}

Anbefalede cache-varigheder efter filtype

Jeg vælger tidspunkterne efter ændringsfrekvens, ikke efter vane, fordi Aktiver ældes meget forskelligt. Billeder, logoer og ikoner forbliver normalt opdaterede i lang tid, mens CSS/JS får hyppigere iterationer. Webfonte ændres sjældent, men kræver ensartede CORS-overskrifter. HTML fungerer ofte som en container for dynamisk indhold og kan derfor være kort eller kun revalideret. API'er bør have klart definerede regler, så klienter kan arbejde korrekt med JSON undgå.

Filtype Cache-kontrol-anbefaling Hint
Billeder (jpg/png/webp/avif/svg) offentlig, max-alder=31536000 Brug årlig cache med filversionering
CSS/JS offentlig, max-age=2592000 Tilføj version til filnavn for opdateringer
Skrifttyper (woff/woff2) offentlig, max-alder=31536000 Indstil Access-Control-Allow-Origin korrekt
HTML (sider) no-cache, must-revalidate eller kort max-age Vær meget forsigtig med dynamisk indhold
REST API (json) privat, max-age=0, must-revalidate Differentier efter endepunkt

Undgå konflikter med plugins

Jeg bruger højst Caching-plugin og tjek, om hostingen allerede specificerer regler på serverniveau. Kombinationer som W3 Total Cache plus WP Super Cache skaber ofte dobbelte direktiver, der ophæver hinanden. WP Rocket tilbyder en hurtig opsætning, men har brug for klare undtagelser for dynamiske stier og e-handel. Under alle omstændigheder tjekker jeg den genererede .htaccess, når jeg har gemt den, for at finde ulogiske overskrifter. Derefter tester jeg kritiske sider som checkout, login og personaliserede dashboards for at se, om de er korrekte. Omgåelse.

Caching og cookies: indloggede brugere, WooCommerce, sessioner

HTML for indloggede brugere må ikke gemmes i den offentlige cache. WordPress sætter cookies som f.eks. wordpress_logged_in_., WooCommerce suppleret woocommerce_items_in_cart, wp_woocommerce_session_. og andre. I stedet for over Variabel: Cookie Jeg går helt uden om cacher for sådanne anmodninger. Det holder betalingsprocesserne stabile og de personaliserede områder korrekte. Jeg bruger også regler på serversiden, der sætter mere restriktive overskrifter, når cookies genkendes.

# Apache: Genkender cookies og indstiller bypass-overskrifter

  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-baseret bypass
if ($http_cookie ~* "(wordpress_logged_in|woocommerce_items_in_cart|wp_woocommerce_session)") {
    add_header Cache-Control "private, no-store" always;
}

Mange caching-plugins tilbyder afkrydsningsfelter til dette (WooCommerce/Cart/Exclude checkout). Vigtigt: Nonces (_wpnonce) i formularer og Heartbeat API genererer hyppige ændringer. Jeg sørger for, at frontend-HTML med nonces ikke caches permanent eller fungerer via „no-cache, must-revalidate“.

Målrettet behandling af HTML: personlig vs. generel

Ikke alle sider er ens. Artikler, landingssider og juridiske sider kan ofte caches med en kort TTL eller revalidering. Arkiver, søgesider, dashboards, kontoområder og checkouts forbliver dynamiske. Hvis der er tale om sidecaching, følger jeg følgende praksis: Cach kun offentlig HTML uden cookies, ellers „privat“ eller „no-store“. Hvis du tester mikrocaching (f.eks. 30-60 sekunder for meget besøgte, ikke-personaliserede sider), bør du definere strenge undtagelser for forespørgselsparametre og sessioner. WordPress har med DONOTCACHEPAGE en konstant, som skabeloner kan indstille på vanskelige sider - jeg bruger den konsekvent for at undgå fejl.

Kombiner caching på serversiden på en fornuftig måde

Browsercaching slutter i klienten, men jeg aflaster også serveren med side-, objekt- og opcode-cache for real Belastningsspidser. Sidecaching leverer statisk HTML, før PHP overhovedet starter. Redis eller Memcached reducerer databaseforespørgsler for gentagne anmodninger og reducerer TTFB mærkbart. OPcache leverer præ-kompilerede PHP-bytecode-fragmenter og forkorter dermed udførelsestiden. I sidste ende er det, der tæller, en ren forbindelse mellem servercachen og browsercachen, så det andet besøg er mere eller mindre en succes. øjeblikkeligt arbejder.

CDN-integration uden overraskelser

CDN'er bruger deres egen TTL-logik og reagerer på „s-maxage“. Jeg skelner derfor klart: „max-age“ for browsere, „s-maxage“ for Edge. Hvis implementeringer afventer, udløser jeg en målrettet oprydning i stedet for at ødelægge „Cache Everything“ globalt. Vigtigt: Cach kun HTML på Edge, hvis der ikke er cookies involveret. Ellers skabes der forkerte tilstande, fordi Edge-cachen deler personaliserede svar. For aktiver sætter jeg lange TTL'er og stoler på versionering af filnavne. CDN'er kan ignorere forespørgselsstrenge - endnu en grund til at beholde versioner i filnavnet. Header-normalisering (ingen overflødige „Vary“-værdier, konsekvent „Content-Type“) forhindrer oppustede cachenøgler.

Trin for trin: ren installation

Jeg starter med et plugin og aktiverer browsercaching for CSS, JS, billeder og skrifttyper, før jeg aktiverer .htaccess afslutte. Derefter sætter jeg max-age højt for statiske aktiver og forsyner HTML med korte tider eller no-cache-regler. Jeg deaktiverer ETags, hvis flere servere er involveret, og stoler på Last-Modified plus 304. Derefter udløser jeg en preload, så vigtige sider straks er tilgængelige som statiske kopier. Endelig kontrollerer jeg shop-, login- og admin-stier, så der ikke gemmes privat indhold i buffer land.

Praktisk diagnosticering med CLI og header-tjek

DevTools er obligatoriske, men jeg går mere i dybden med CLI-tests. A curl -I viser header uden download; med -H Jeg simulerer betingelser. For eksempel tjekker jeg, om revalideringer virkelig returnerer 304, om „alder“ stiger fra en proxy/CDN, og om cookies slår caching fra.

# Vis overskrift
curl -I https://example.com/style.css

Simuler #-revalidering (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 (burde tvinge bypass)
curl -I -H "Cookie: wordpress_logged_in_=1" https://example.com/

Jeg sørger for, at aktiver har en lang „cache control“-værdi, ideelt set „immutable“. HTML bør have „no-cache“ eller en kort TTL. Hvis jeg stadig får 200 i stedet for 304, er der ofte omdirigeringer i spil, som ugyldiggør ETags/Last-Modified. Desuden gælder „add_header“ i Nginx som standard kun for 200-svar - med „always“ indstiller jeg også overskrifterne for 304 og 301/302.

Test og validering af overskrifter

Jeg åbner DevTools, genindlæser siden én gang, tømmer cachen og genindlæser for at få 304 vs. 200 for at observere. I netværkspanelet tjekker jeg cachekontrol, alder, ETag/load-modified og svarstørrelser. Hvis der stadig er direkte hits i stedet for revalideringer, tjekker jeg for konflikter med omdirigeringer, cookies eller forespørgselsstrenge. I vanskelige tilfælde hjælper denne artikel om faldgruber med headers mig: Sabotage af cache-header. Jeg gentager kontrollen efter hver plugin-opdatering, fordi ændringer i reglerne ofte sker lydløst. passere.

Versionering, CDN og cache-busting

Jeg hænger den Version til filnavne (style.23.css i stedet for style.css?ver=23), så browsere bevarer lange cacher og stadig indlæser nyt indhold med det samme. Et CDN distribuerer statiske filer globalt, indstiller sine egne TTL'er i edge PoPs og forkorter RTT'erne drastisk. Vigtigt: Cach kun HTML i CDN'et, hvis der ikke er behov for personalisering, ellers vil der blive oprettet forkerte tilstande. Under implementeringen ændrer jeg automatisk versionsnummeret, så brugerne aldrig sidder fast med gamle scripts. Sådan kombinerer jeg hårde browser TTL'er med sikker Cache-brydning.

Ren versionering i WordPress-builds

Det mest pålidelige er en build-pipeline, der skriver hashes i filnavne (f.eks. app.9f3c.css). WordPress indlæser derefter præcis denne fil - browsere kan beholde den i et år takket være „immutable“. Hvis filnavne ikke kan ændres, indstiller jeg versionsnummeret dynamisk ud fra fildatoen. Dette holder forespørgselsstrengene korrekte og pålidelige.

// functions.php (fallback-versionering 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);
});

Vigtigt: Hvis filnavnet indeholder versioner, kan „immutable“ indstilles. Hvis du kun bruger forespørgselsstrenge, bør browsere være i stand til at revalidere, så opdateringer kommer pålideligt frem. Jeg sørger også for, at build-værktøjer rydder op i gamle filer, så CDN'er ikke gemmer et unødigt stort antal varianter.

Cache og indlæs webfonte korrekt

Webfonte har brug for lange TTL'er, korrekte CORS-headere og valgfri forudindlæsning, så Spring i layout vises ikke. Jeg placerer woff2-filer på det samme domæne eller indstiller Access-Control-Allow-Origin rent. Derudover skal du definere font-display: swap, så teksten forbliver synlig med det samme, mens skrifttypen indlæses. Hvis du vil optimere indlæsningstiden for dine skrifttyper, kan du finde nyttige tips her: Indlæs webfonte hurtigere. Med rene cache-headere og en forudgående forbindelse til CDN'er forkorter jeg FOUT/FOIT mærkbart og sikrer konsekvent Rendering-Resultater.

Korrekt indstilling af skrifttyper, CORS og Vary

Skrifttyper fra en anden oprindelse kræver CORS. Jeg indstiller Adgangskontrol-Allow-Origin (f.eks. til dit eget domæne eller „*“ for virkelig offentlig) og undgå en unødvendig Varierer: Oprindelse, som puster cachenøgler op. Anbefales til skrifttyper: offentlig, max-age=31536000, uforanderlig. Preload forbedrer First Paint, men ændrer ikke TTL - preload og hard caching supplerer hinanden. Jeg glemmer heller ikke, at komprimeret levering (br/gzip) a Vary: Accept-kodning er nødvendig for, at proxyer kan adskilles korrekt.

Typiske fejlmønstre og hurtige løsninger

Hvis der vises gammel kode efter en opdatering, vil Versionering på filnavnet. Hvis browseren genindlæses helt hver gang, indeholder headers modstridende instruktioner, eller proxyer fjerner dem undervejs. Hvis en checkout annulleres, cacher webstedet sandsynligvis sider på sessionssiden eller API-svar. Hvis admin-stier glider ind i cachen, mangler der eksklusioner for wp-admin og login, eller et plugin cacher globalt. Jeg løser dette ved at deaktivere trin for trin, konsolidere overskrifter, udelukke kritiske stier og til sidst effekten med 304-status bekræfte.

Ofte oversete detaljer, der gør en stor forskel

  • Nginx add_header gælder ikke for 304/redirects uden „always“ - så mangler der cache-headers til validering. Jeg indstiller konsekvent „altid“.
  • Udløber vs. cache-kontrol: „Cache-Control“ har prioritet, „Expires“ fungerer som en fallback for gamle klienter. Undgå dobbelt, modstridende information.
  • ETag i opsætninger med flere servere: Inkonsistente ETags ødelægger 304. Jeg deaktiverer ETags eller bruger svage validatorer og stoler på „Last-Modified“.
  • Varier til et minimum: „Vary: Accept-Encoding“ er obligatorisk for komprimering, „Vary: Cookie“ opblæser edge caches - bedre at omgå cookie-baseret.
  • SVG og MIME-type: Korrekt image/svg+xml sæt, giv lang TTL og overvej inline SVG'er til kritiske ikoner.
  • Undgå omdirigeringskæder: Hver 301/302 kan miste validatorer og fremtvinge 200 - rene URL'er uden kaskader.
  • Brug prioritet/preload på en målrettet måde: fetchpriority="høj" eller forudindlæsning af kritiske aktiver fremskynder det første opkald; caching er effektivt for tilbagevendende brugere.
  • Gør forskel på REST-API: Offentlige, sjældent skiftende JSON'er kan caches kortvarigt; slutpunkter med tokens/cookies er strengt „private“.

Kort opsummeret

Jeg er afhængig af klare Reglerlange TTL'er for aktiver, korte eller revaliderede HTML-svar, versionering og et enkelt cache-plugin. Derefter kombinerer jeg browsercache med side-, objekt- og opcode-cache for at reducere serverbelastningen. Jeg tjekker DevTools, kigger efter 304, tjekker headers og eliminerer konflikter med omdirigeringer eller cookies. Til den praktiske test sammenligner jeg målinger på det første og de gentagne kald og fokuserer på mærkbare forbedringer. Hvis du følger disse trin, kan du bringe WordPress op på et pålideligt niveau for browsercaching. Hastighed og gør både brugere og søgemaskiner glade.

Aktuelle artikler