🇸🇪 När cache blir fienden – varför moderna webbläsare inte behöver gamla cache-plugin till hemsidan längre
Av Christine Djerf, Akademía Nyhetseko.se
Under många år har “cache” betraktats som lösningen på alla prestandaproblem.
Tunga sidor skulle snabba upp, servrar avlastas och användarupplevelsen bli mjukare.
Men de senaste åren har spelplanen förändrats i grunden.
Det som tidigare var en nödvändig mellanlagring har i dag blivit ett problem i sig – särskilt för moderna nyhets- och innehållssajter som uppdateras kontinuerligt.
Jag upptäckte det här i praktiken när Nyhetseko.se började uppföra sig märkligt:
nya artiklar publicerades, men de syntes inte på förstasidan.
I webbläsarens anonyma läge fanns de där direkt – men inte i vanlig vy.
Efter flera felsökningar visade det sig att ett gammalt cache-skript låg kvar i en av mina egna plugin-mappar på servern, trots att själva tillägget för länge sedan tagits bort.
När jag tog bort filen dök den senaste artikeln upp omedelbart.
Problemet var inte WordPress. Det var cache-logiken själv.
Dubbel cache – dubbla låsningar
Det moderna webblandskapet har två separata men överlappande cache-nivåer:
- Server- och CMS-nivån – där WordPress eller plugin som WP Super Cache, LiteSpeed eller W3 Total Cache lagrar färdig HTML.
- Webbläsarens egen cache – där Chrome, Edge, Firefox och Safari sparar inte bara filer utan hela dokumentstrukturer, service-workers, bilder och skript.
När båda dessa nivåer försöker “hjälpa till” uppstår en cache-deadlock:
Servern tror att webbläsaren ska uppdatera, och webbläsaren tror att servern redan har gjort det.
Resultatet blir att ingenting uppdateras.
För en statisk företagssida märks det kanske inte.
Men för en redaktionell webbplats – där färska nyheter är kärnan – blir det katastrofalt.
Läsaren får gamla versioner, statistik blir missvisande och redaktören tror att publiceringen misslyckats.
Webbläsarna har redan gått förbi
Fram till omkring 2015 var plugin-baserad cache logisk.
Webbläsarna hämtade varje fil separat och hade ingen större förståelse för hur resurser hängde ihop.
Sedan kom HTTP/2, lokal lagring (localStorage), stale-while-revalidate, prefetching och service-workers.
Det betyder att själva webbläsaren i dag är en fullvärdig cache-motor – ofta betydligt effektivare än ett plugin.
När ett cache-plugin dessutom försöker lägga sig ovanpå detta, uppstår konflikter:
gamla kopior sparas i onödan, sidversioner blandas, och datorns minne fylls med överlappande kopior.
Det som skulle spara resurser gör i stället att CPU och RAM-användning skenar.
Ett mönster av överoptimering
De flesta cache-plugin är utvecklade under en tid då webben var långsam.
De antar fortfarande att webbläsaren är “dum”.
Men dagens Chrome och Edge har redan mekanismer för:
- automatisk cache-validering,
- prioritering av innehåll,
- bakgrundsladdning av bilder,
- och till och med förutsägelse av användarens nästa klick.
När vi då lägger till ytterligare ett lager via PHP- eller JavaScript-baserade cache-lösningar, skapas vad jag kallar ett cache-stack-kollaps – ett system som försöker optimera sig självt till stillestånd.
Effekten på moderna nyhetssajter
För en webbplats som Nyhetseko.se, där nytt material publiceras flera gånger i veckan, är överdriven caching direkt skadlig:
- Nya artiklar syns inte förrän besökaren tömt sin egen cache.
- RSS-flöden visar gammal data.
- Statistiksystem tror att inga besök sker (eftersom sidor laddas lokalt).
- Webbläsaren börjar tugga tungt av alla sparade versioner.
Jag har sett samma mönster i flera “optimeringsplugin” – även kommersiella.
De lovar snabbare laddning men levererar i praktiken fastfrusna sajter och överbelastade webbläsare.
Rekommendation: minimera cache, maximera logik
För dagens webben räcker det med en enda effektiv cache-nivå, och det är den som redan finns i webbläsaren.
| Nivå | Behåll | Avlägsna |
|---|---|---|
| Server | Kortlivad HTTP-cache (t.ex. via .htaccess) | Tunga PHP-cachar och “preloaders” |
| Webbläsare | Statisk filcache (bilder, CSS, JS) | HTML-cache, service-workers utan behov |
| WordPress | Transienter för specifika databasfrågor | Generella “page cache”-tillägg |
Det viktigaste är att inte låta HTML-sidor cache-lagras längre än några sekunder.
De bör levereras med:
Cache-Control: no-store, no-cache, must-revalidate
Resten – bilder, skript och stilmallar – kan lugnt ligga kvar i 30 dagar.
På så sätt får man snabba laddtider utan att låsa innehållet.
Cachning är inte längre en universallösning – den har blivit en rest från en tidigare teknisk epok.
I dag orsakar den ofta mer problem än den löser.
Med moderna webbläsare, snabbare servrar och distribuerade skyddsnät som Project Shield, är behovet av extra cache-plugin inte bara överflödigt – det är rent av riskabelt.
För mig personligen blev lärdomen tydlig:
När allt blir statiskt fel, är det inte datorn som hänger sig – det är logiken.
Och ibland är den mest avancerade optimeringen att ta bort det som inte längre behövs!