Browsercaching betyder, at browseren gemmer genbrugelige filer lokalt hos den besøgende. Ved næste besøg kan CSS, JavaScript, billeder og skrifter hentes fra disken i stedet for netværket. Det reducerer ventetid, båndbredde og belastning på serveren — især for tilbagevendende brugere.
Hvordan det styres
Serveren (eller et CDN) sender HTTP-headere som Cache-Control, evt. Expires og ETag. De fortæller, hvor længe filen må genbruges, og hvornår browseren skal spørge, om den stadig er gyldig. Lighthouse-anbefalingen Serve static assets with an efficient cache policy handler netop om for korte cache-tider på statiske filer.
Lange cache-tider kræver versionering: ændrer du en CSS-fil, skal URL’en også ændre sig (hash i filnavnet eller query-string), ellers risikerer brugere at se en gammel version.
Browsercache vs. andre cachelag
- Browsercache — hos brugeren, per fil/URL.
- Full page cache — færdig HTML på server/CDN.
- Object cache — data i Redis/Memcached inde i WordPress.
De tre lag løser forskellige problemer. God browsercache gør gentagne besøg hurtige; den erstatter ikke hurtig første HTML-levering.
Praktisk i WordPress
Host, CDN og cache-plugins sætter typisk headers for uploads, theme-assets og plugin-filer. Kontrollér i DevTools → Network, at statiske filer har max-age eller s-maxage i en fornuftig størrelsesorden (ofte måneder for versionerede assets). Undgå at cache HTML aggressivt i browseren, hvis indholdet skifter per bruger eller session.