Caching

Caching innebär att lagra kopior av resurser för återanvändning, så att webbläsare eller server inte behöver hämta eller generera dem på nytt vid varje förfrågan. En korrekt implementerad cachestrategi kan reducera laddtiden med 50–80 procent för återkommande besökare.

Cachenivåer

Webbläsarcache

Webbläsaren lagrar CSS, JavaScript, bilder och typsnitt lokalt. Vid efterföljande besök hämtas resurserna från disk i stället för via nätverket. HTTP-headern Cache-Control styr beteendet:

# Statiska resurser: cachelagra i ett år
Cache-Control: public, max-age=31536000, immutable

# HTML: kort cache, validera sedan
Cache-Control: public, max-age=300, must-revalidate

Statiska resurser med fingeravtryck i filnamnet (eng. fingerprinting), exempelvis style.a3f8c2.css, kan cachelagras i ett år eftersom ett nytt filnamn genereras vid varje ändring. HTML bör cachelagras kort eller inte alls.

CDN-cache

Ett CDN (Content Delivery Network) cachelagrar innehåll på edge-noder nära besökaren. Det minskar latens, reducerar serverbelastning och förbättrar tillgänglighet vid trafikspikar. Cloudflare erbjuder CDN-funktionalitet utan kostnad.

Server-side cache

Servern kan lagra färdigrenderade sidor och databasresultat i stället för att generera dem vid varje förfrågan. Tre kompletterande nivåer:

• Helsidescache (eng. page cache) – lagrar fullständig HTML. Ger snabbast möjliga svar.
• Objekt-cache – lagrar databasresultat i minnet (Redis, Memcached). Reducerar databasfrågor.
• OPcode-cache – lagrar kompilerad PHP-kod (OPcache). Standard i moderna PHP-versioner.

Caching på svenska plattformar

Hur mycket kontroll du har över caching beror på plattformen. WordPress-sajter kräver manuell konfiguration — helsidescache (WP Super Cache, LiteSpeed Cache), objektcache (Redis) och CDN-integration måste var och en sättas upp. Mer om WordPress-specifik caching finns i guiden WordPress-optimering. Det ger maximal kontroll men också fler felkällor.

SaaS-plattformar som Sitevision och Optimizely hanterar server-side cache centralt. Det förenklar driften men begränsar möjligheten att finjustera cache-beteendet. Om plattformen returnerar en hög TTFB kan du sällan åtgärda det själv — det är leverantörens ansvar. Kontrollera alltid CDN-headern (cf-cache-status eller motsvarande) i svaret för att verifiera att caching faktiskt är aktiv.

En erfarenhet från arbetet med Laddtider.se: den mest effektiva cacheåtgärden var inte helsidescache utan att eliminera resurser som inte behövde laddas alls — externa fonter, inaktiva plugins och oanvänd CSS. Cache döljer problemet; att ta bort onödiga resurser löser det.

Cache-invalidering

Den tekniskt svåraste aspekten av caching är att säkerställa att besökare får uppdaterat innehåll. Två huvudstrategier:

1. Tidbaserad utgång – innehållet cachelagras en bestämd tid, sedan hämtas det på nytt. Enkelt men oprecist.
2. Fingerprinting – filnamnet ändras vid innehållsändring (exempelvis app.abc123.js). Webbläsaren behandlar det som en ny resurs. Exakt och tillförlitligt för statiska filer.

Påverkan på Core Web Vitals

Caching påverkar primärt LCP. En cachelagrad sida eliminerar väntetiden för serverrendering, och cachade resurser laddas utan nätverksfördröjning. En helsidescachad förfrågan besvaras typiskt på under 50 millisekunder, jämfört med 200–800 millisekunder utan cache. Effekten på ranking är indirekt men påtaglig — snabbare TTFB förbättrar LCP som i sin tur är en rankingsignal.

Rekommenderad cachestrategi

Resurstyp	Cache-Control	Motivering
HTML	max-age=0, must-revalidate	Färskt innehåll vid varje besök
CSS/JS (med hash)	max-age=31536000, immutable	Nytt filnamn vid ändring
Bilder	max-age=2592000 (30 dagar)	Sällan ändrade resurser
Typsnitt	max-age=31536000, immutable	Oförändrade resurser