Ordet cache dyker upp överallt i WordPress-sammanhang, men det används om minst tre olika saker som löser olika problem. Sidcache, objektcache och CDN är inte samma lager, och de hjälper inte mot samma flaskhals. Den här guiden förklarar de tre i klartext: vad var och en faktiskt gör, vilket problem den löser, och när den är värd att lägga till. Målet är att du ska kunna prata med din värd eller utvecklare och veta vad du ber om, i stället för att slå på allt och hoppas.
Sidcache: den största hävstången
Sidcache är det lager de flesta menar när de säger ”cache”. En vanlig WordPress-sida byggs om från grunden vid varje besök: PHP körs, databasen frågas, och HTML skapas på nytt varje gång. Med sidcache sparas den färdiga HTML-sidan efter första besöket och serveras direkt till nästa besökare, utan att PHP eller databasen ens startar. Det är därför sidcache ger mest effekt med minst arbete för de flesta sajter.
Haken är dynamiska sidor. En varukorg, en kassa eller en inloggad vy får inte serveras från cache, eftersom den är personlig. Lösningen är sidcache med regler: cacha allt utom de sidor och tillstånd som måste vara live. På Celestio är just det här hur plattformen är byggd, full sidcache där du styr reglerna så att kassor och inloggade vyer förblir dynamiska medan resten cachas.
Objektcache: för databasarbetet
Objektcache löser ett annat problem. Även när en sida inte kan sidcachas gör WordPress om samma databasfrågor gång på gång. Ett objektcache-lager, ofta byggt på Redis eller Memcached, sparar resultatet av de frågorna i minnet så att de inte behöver köras på nytt. Det hjälper särskilt på sajter med mycket dynamiskt innehåll, som en butik eller ett medlemsforum, där sidcache inte räcker.
Viktigt att förstå: ett beständigt objektcache är ett lager som körs på servern, inte ett plugin du bara installerar. Redis eller Memcached måste finnas och vara igång på värdnivå, och sedan kopplas WordPress till det. Det är därför objektcache är en fråga att ställa till din värd, inte något du löser i wp-admin på egen hand. På en enkel bloggsajt ger det sällan mycket, men på en tung, dynamisk sajt kan det vara skillnaden.
Sidcache tar bort arbetet med att bygga hela sidan. Objektcache tar bort arbetet med att fråga databasen om samma sak igen. CDN tar bort avståndet mellan servern och besökaren. Tre olika problem, tre olika lager.
CDN: för avståndet
Ett CDN, Content Delivery Network, löser ett geografiskt problem. Din server står på en plats, men dina besökare kan finnas var som helst. Ett CDN är ett nät av servrar runt om i världen som lagrar kopior av dina statiska filer, som bilder, CSS och JavaScript, och serverar dem från en plats nära besökaren. Det kortar avståndet och avlastar din ursprungsserver.
Ett CDN är ett separat lager du lägger framför sajten, ofta en egen tjänst du kopplar in. Det är mest värt när du har besökare spridda över flera länder eller mycket tung statisk media. Har du främst en lokal, svensk publik och en server som redan står i Sverige, gör ett CDN mindre skillnad, eftersom avståndet redan är kort. Bestäm utifrån var dina besökare faktiskt finns, inte för att det låter modernt.
Vilket lager löser ditt problem?
- Sidan är långsam för utloggade besökare? Börja med sidcache. Det är nästan alltid rätt första steg.
- Sidan är långsam inloggad, i admin eller i kassan? Här hjälper inte sidcache. Titta på objektcache och på databasen.
- Besökare långt bort upplever sajten som trög, men närliggande inte? Då är ett CDN värt att överväga.
- Osäker på vad som är flaskhalsen? Mät först. Cache på fel lager löser inte problemet.
Cache är inte en magisk knapp utan tre olika verktyg för tre olika problem. Förstår du skillnaden slösar du inte tid på fel lager. Vill du läsa mer om var tröghet faktiskt kommer ifrån har vi skrivit om varför en WordPress-sajt är långsam och om hur du klarar Core Web Vitals. Vår plattform levereras med full sidcache och regler du styr som en del av grunden, och du kan starta ett konto för att flytta över sajten.