Varje gång någon besöker en ocachad WordPress-sida bygger PHP om den från grunden: hundratals databasfrågor, temarendering, plugin-körningar. Cache betyder att det färdiga resultatet sparas och återanvänds — besökare två till tiotusen får en färdig sida på millisekunder istället för en nybyggd på sekunder. Ingen enskild åtgärd gör större skillnad för upplevd snabbhet.
Lagren, utifrån och in: webbläsarens cache (statiska filer hos besökaren), CDN-cache (kopior nära användaren), sidcache på servern (hela HTML-sidor — det stora lyftet), objektcache (databasresultat i Redis, guld för inloggade vyer och WooCommerce) och OPcache (kompilerad PHP). De kompletterar varandra; en snabb sajt använder alla.
Sidcachen är där valet av webbhotell märks mest. En cache-plugin som kör i PHP måste starta PHP för att leverera ur cachen — snabbare än obyggt, men fortfarande PHP. LiteSpeed-cache arbetar i själva webbservern: träffen serveras innan PHP ens väcks, vilket är varför LSCache konsekvent slår plugin-baserade lösningar i mätningar. Hos oss är den förkonfigurerad på alla planer.
Fallgrop ett: utgången cache och stale content. Kunden ser gamla priser, du ser dina ändringar men ingen annan gör det. Lösningen är riktig invalidering — LSCache rensar automatiskt berörda sidor när du uppdaterar ett inlägg eller en produkt, inte hela cachen (som tvingar varje sida att byggas om i onödan).
Fallgrop två: cache på fel saker. Varukorg, kassa och inloggade vyer får aldrig sidcachas — annars ser kund B kund A:s varukorg. Korrekt konfiguration undantar dessa via cookies och ESI-block; vår standardprofil för WooCommerce gör det åt dig. Och dubbla cache-plugins ovanpå varandra skapar bara konflikter: ett lager per nivå räcker.
Rimliga mål när allt sitter: TTFB under 200 ms ur cachen, LCP kring sekunden, och en WooCommerce som håller tempot även inloggad tack vare Redis-objektcache. Det är de nivåer vi konfigurerar mot vid varje gratis migrering — och varför '90+ i PageSpeed' är ett löfte vi vågar skriva på prissidan.