En långsam WordPress-sajt kostar dig besökare, konverteringar och placeringar i Google. Den goda nyheten är att de flesta prestandaproblem går att lösa med en handfull konkreta åtgärder. Här går vi igenom dem i prioritetsordning, så att du kan börja med det som ger mest effekt och arbeta dig nedåt. Vill du mäta resultatet efteråt hittar du fler guider på Pagespeed.se.
Hitta boven: mät innan du gissar
Innan du börjar installera plugin i blindo lönar det sig att ta reda på var tiden faktiskt tar vägen. Två grepp räcker långt för de flesta.
Börja med ett hastighetstest som visar serverns svarstid, alltså tiden innan sidan ens börjar laddas. Ligger den högt är det webbhotellet eller cachen du ska titta på först, inte bilderna. Vilket verktyg som visar vad går vi igenom i vår jämförelse av verktyg för att mäta sidhastighet.
Vill du veta exakt vilka plugin som tynger just din sajt kan du installera det kostnadsfria felsökningspluginet Query Monitor. Det visar hur lång tid sidan tar att bygga, hur många databasfrågor som körs och, framför allt, vilket plugin eller tema som står för dem. Då slipper du gissa och kan avinstallera eller ersätta just det som drar ner farten. Kom ihåg att stänga av verktyget igen när felsökningen är klar, eftersom det självt lägger på en liten belastning.
Börja med grunden: bra webbhotell
Ingen plugin i världen kan kompensera för ett långsamt webbhotell. Servern är fundamentet, och står den och trampar vatten så gör hela sajten det. Delade billiga paket, där hundratals sajter samsas om samma resurser, är den vanligaste orsaken till sega svarstider.
Leta efter ett webbhotell som erbjuder modern PHP, tillräckligt med minne och gärna en serverlösning byggd för WordPress. En snabb serverrespons, det vill säga tiden innan sidan ens börjar laddas, lägger grunden för allt annat. Överväg dedikerad eller hanterad WordPress-hosting om trafiken är hög. Byter du från ett trögt paket till ett snabbare märks skillnaden ofta direkt, även om exakt hur mycket beror på din sajt.
Installera ett cache-plugin
Cache är den enskilt mest effektiva mjukvaruåtgärden. Utan cache bygger WordPress om varje sida från grunden vid varje besök, vilket belastar både databas och PHP. Ett cache-plugin sparar färdiga versioner av sidorna och serverar dem direkt, vilket brukar minska tiden det tar att generera en sida rejält.
Tre plugin dominerar valet: WP Rocket, LiteSpeed Cache och W3 Total Cache. De presenteras oftast som tre jämnstarka alternativ, men de arbetar på olika nivåer, och ett av dem kräver en viss sorts webbserver för att cacha över huvud taget. Vad som faktiskt skiljer dem åt går vi igenom strax nedan.
En viktig regel: kör aldrig flera cache-plugin samtidigt. De skapar krockande regler och oförutsägbart beteende. Välj ett, aktivera sidcache och stäng av resten.
WP Rocket, LiteSpeed Cache eller W3 Total Cache: vad skiljer dem åt?
Frågan brukar ställas som en tävling och besvaras med en topplista. Det är fel utgångspunkt. De tre pluginen är inte tre varianter av samma produkt, utan tre olika svar på frågan var i kedjan det färdiga svaret ska sparas. Den skillnaden avgör mer än någon enskild inställning inne i pluginet, och den förklarar också varför ett plugin som gör susen hos en kollega kan göra nästan ingenting hos dig.
Ett svar kan levereras från fyra olika ställen
När någon begär en sida kan svaret komma från fyra lager, och de ligger olika långt från besökaren. Längst in finns objektcachen, till exempel Memcached eller Redis, som sparar enskilda databasresultat så att PHP slipper fråga databasen om samma sak igen. Ett steg ut ligger sidcachen i PHP, där pluginet sparar färdig HTML men WordPress ändå måste starta för att hitta filen och skicka den. Ytterligare ett steg ut ligger sidcachen i själva webbservern, som kan svara med den sparade filen utan att PHP startar alls. Längst ut ligger proxy- och CDN-lagret, som svarar innan förfrågan ens når din server. Lagren i sig går vi igenom mer utförligt i genomgången av caching och CDN.
Av det följer en regel som är enkel men obekväm. Ett lager som ligger längre ut kan aldrig bli långsammare än ett som ligger längre in, eftersom det hoppar över allt arbete som annars hade utförts. Ett plugin som cachar i PHP kan därför aldrig bli lika snabbt som ett lager som svarar innan PHP startar. Det handlar inte om kodkvalitet utan om var i kedjan koden får sitta.
LiteSpeed Cache spelar inte på samma plan som de andra
Här ligger den viktigaste skillnaden, och den saknas i nästan alla jämförelser. LiteSpeed Cache lägger inte sidcachen i PHP utan i webbservern, men bara om webbservern faktiskt är LiteSpeed. Det är ingen detalj i det finstilta. LiteSpeed skriver rakt ut i sin egen installationsdokumentation att den som kör Apache eller nginx är fri att använda alla optimeringsfunktioner, men att ingen av cachningsfunktionerna blir tillgänglig, och att cachning inte fungerar utan en LiteSpeed-server eller tjänsten QUIC.cloud.
Notera vad det betyder. Pluginet faller inte tillbaka på ett svagare cachelager när servern är av fel sort. Sidcachen finns helt enkelt inte. Kvar blir bildoptimering, minifiering, lat inladdning och databasstädning, som är nyttiga funktioner men något helt annat än det pluginet är känt för. Samma sak uttrycks på pluginets sida i WordPress plugin-katalog, där de exklusiva funktionerna anges kräva OpenLiteSpeed, en kommersiell LiteSpeed-produkt, LiteSpeed-baserad hosting eller QUIC.cloud, medan de allmänna funktionerna fungerar på vilken webbserver som helst. På samma sida beskriver LiteSpeed sin cache som en cache på servernivå och därför snabbare än cachelösningar på PHP-nivå.
Ta alltså reda på vilken webbserver ditt webbhotell kör innan du väljer. Gör du inte det riskerar du att jämföra ett serverlager med ett PHP-lager i tron att du jämför två plugin.
WP Rocket cachar i PHP, men kan lämna över till servern
WP Rocket sparar färdig HTML på disk. Hur den filen sedan levereras beror på servern. Enligt WP Rockets egen dokumentation om sidcache serveras cachefilerna antingen av omskrivningsregler i .htaccess eller i nginx-konfigurationen, eller av PHP-filer när de reglerna saknas. Samma dokumentation beskriver att sidcachen gör sajten snabbare genom att minimera PHP-arbetet, ta bort databasanropen och spara innehållet i HTML-filer.
Skillnaden mellan de två lägena är verklig. Ligger omskrivningsreglerna på plats svarar webbservern direkt ur filen, alltså på ungefär samma nivå som LiteSpeed gör på sin egen server. Saknas de måste WordPress starta vid varje besök, leta rätt på filen och skicka den. Det är snabbare än att bygga om sidan, men långsammare än att aldrig starta PHP. Att kontrollera att reglerna verkligen kom på plats är därför en av de mer värdefulla sakerna du kan göra efter installationen.
W3 Total Cache är det enda som täcker flera lager på egen hand
W3 Total Cache är byggt annorlunda. Det är inte ett cache-plugin utan en samling cachelager som slås på var för sig: sidcache, objektcache, databascache, fragmentcache, webbläsarcache och CDN-koppling. Enligt pluginets katalogsida kan lagren läggas på lokal disk, Redis, Memcached, APC, APCu, eAccelerator, XCache eller WinCache.
Det är samtidigt styrkan och fällan. Har servern redan Redis eller Memcached kan du använda det utan ett extra plugin, och lägga sidcachen på disk medan objektcachen ligger i minnet. Saknar du den vanan, och slår på lagren för att de finns, får du en sajt som är svår att felsöka. Där kommer ryktet om att pluginet är krångligt ifrån: det ger dig ratten till varje lager, även de du inte behöver.
Värt att veta är att de andra två inte gör det här åt dig. WP Rocket skriver i sin dokumentation att pluginet inte har någon interaktion med Memcached, som beskrivs som ett helt separat cachesystem. LiteSpeed anger i sin cachedokumentation att pluginet inte tillhandahåller objektcache direkt, utan stödjer en extern sådan som Memcached, Redis eller LiteSpeeds egen ersättare LSMCD. Vill du ha objektcache tillsammans med något av dem behöver du alltså ett plugin till, eller ett webbhotell som redan satt upp det.
Överlappet är den verkliga fällan
Alla tre gör betydligt mer än att cacha sidor. De minifierar CSS och JavaScript, skjuter upp skript, laddar bilder senare, plockar ut kritisk CSS och städar databasen. Det är i de funktionerna de flesta problem uppstår, inte i sidcachen.
Två plugin som båda minifierar samma stilmall ger ett trasigt utseende. Ett plugin som skjuter upp JavaScript ovanpå ett tema som redan gör det ger knappar som slutar svara. Och lägger du ett PHP-baserat cache-plugin ovanpå en cache som redan sitter i webbservern får du två lager som måste tömmas i rätt ordning varje gång du publicerar. Missar du ett av dem ser läsaren en gammal version, och felet är svårt att hitta just för att sidan ser korrekt ut för dig som är inloggad och normalt går förbi sidcachen.
Regeln ovan om att bara köra ett cache-plugin gäller alltså även funktionerna vid sidan av själva cachen. Slå på en sak i taget och mät emellan.
Vad de kostar
Två av de tre finns gratis i WordPress plugin-katalog. LiteSpeed Cache anges där ha över sju miljoner aktiva installationer och W3 Total Cache över 900 000, avläst i slutet av juli 2026. W3 Total Cache har därutöver en betald Pro-version med extrafunktioner som fragmentcache och fullständig sajtleverans.
WP Rocket är kommersiellt och finns inte i katalogen alls, utan säljs direkt av utvecklaren med licens per antal sajter och år. Priser ändras, så kontrollera aktuell nivå på WP Rockets prissida i stället för att lita på en siffra i en artikel. Var också vaksam på jämförelser som redovisar exakta procenttal för hur mycket snabbare ett visst plugin är. De kommer nästan alltid från sidor som får provision på köpet, mätningen går sällan att upprepa, och resultatet beror mer på servern under än på pluginet.
Vad vi själva ser i drift
En egen observation, eftersom den sällan kommer med i jämförelserna. Vi driver ett par hundra WordPress-sajter i en uppsättning där sidcachen ligger i webbservern och objektcachen i Memcached, med ytterligare ett proxylager framför. I den miljön besvaras en vanlig sidvisning innan PHP har startat. Ingen plugin-kod körs alls för den förfrågan, vilket betyder att valet av cache-plugin inte påverkar den snabba vägen över huvud taget.
Det pluginet fortfarande påverkar är tillfällena när cachen inte träffar: det första besöket efter en publicering, sidor som medvetet undantagits och inloggade användare. Det är en liten del av trafiken men en stor del av felsökningen. Vår praktiska slutsats är att när ett snabbare lager redan finns ovanför är den viktigaste egenskapen hos ett cache-plugin inte hur snabb dess egen sidcache är, utan hur pålitligt den töms i takt med lagret ovanför. Vi har inga publicerbara mätsiffror på hur de tre pluginen skiljer sig åt i just den uppsättningen, och påstår därför ingen sådan skillnad.
Så väljer du
Börja med webbservern, inte med pluginet. Kör webbhotellet LiteSpeed eller OpenLiteSpeed är LiteSpeed Cache det naturliga valet, eftersom du då får cache på servernivå utan extra kostnad. Kör det Apache eller nginx faller LiteSpeed Cache bort som cachelösning, hur bra det än är i övrigt.
Står valet mellan de två andra handlar det om hur mycket du vill styra själv. WP Rocket är gjort för att ge ett bra resultat med få inställningar, och kostar pengar för den bekvämligheten. W3 Total Cache ger dig varje lager separat och kostar i stället tid och kunskap. Har din server redan Redis eller Memcached, och vill du utnyttja det, väger det tungt för W3 Total Cache.
Mät sedan effekten på riktiga besökare i stället för på magkänsla. En fungerande sidcache syns tydligast i serverns svarstid och därmed i LCP, medan de skriptrelaterade funktionerna slår mot INP. Vad de måtten mäter och vilka värden som räknas som godkända går vi igenom i guiden till Core Web Vitals.
Optimera bilderna
Bilder är oftast det tyngsta på en sida och en av de vanligaste anledningarna till att sidor laddar långsamt. Här finns tre saker att göra, och de går att kombinera.
Komprimera och skala rätt
Ladda aldrig upp en bild som är bredare än den visas. En bild på 4 000 pixlar som visas i 800 pixlar tvingar besökaren att hämta hem massor av data i onödan. Komprimera bilderna innan eller vid uppladdning, gärna med ett plugin som gör det automatiskt. Läs vår fördjupning om att komprimera och optimera bilder för webben för konkreta steg.
Använd moderna format
Formatet WebP ger ofta märkbart mindre filer än äldre JPEG och PNG vid likvärdig visuell kvalitet. Många optimeringsplugin kan konvertera dina bilder till WebP automatiskt och servera det gamla formatet till de få webbläsare som saknar stöd.
Lat inladdning
Lat inladdning, på engelska lazy loading, innebär att bilder längre ned på sidan hämtas först när besökaren skrollar dit. Då blir den första vyn snabbare. WordPress har inbyggd lat inladdning för bilder, men kontrollera att den inte krockar med ditt cache- eller optimeringsplugin.
Välj ett lätt tema
Temat avgör hur mycket kod som lastas på varje sida. Tunga alltiettema med hundratals inbyggda funktioner och stora sidbyggare drar ofta med sig mängder av skript och stilmallar, även på sidor som inte använder funktionerna. Ett lätt och välkodat tema laddar mindre och ger en snabbare grund.
Byter du tema, testa alltid i en kopia av sajten först och mät före och efter. Ett snyggt tema som är byggt för prestanda slår nästan alltid ett tungt tema med många tillägg.
Rensa bland dina plugin
Varje aktivt plugin kan lägga till kod, databasfrågor och externa anrop. Det är inte antalet plugin i sig som avgör, utan hur tunga de är, men en välstädad sajt är lättare att hålla snabb. Gå igenom listan och avinstallera det du inte använder. Var särskilt vaksam på plugin som laddar skript på alla sidor fast de bara behövs på en enda.
Lägg till ett CDN
Ett innehållsleveransnätverk, CDN, lagrar kopior av dina filer på servrar runt om i världen. Besökaren hämtar då bilder och skript från en server nära sig, vilket kortar avståndet och därmed laddtiden. Har du besökare på flera orter eller i flera länder gör ett CDN ofta stor skillnad, särskilt för statiska filer som bilder, skript och stilmallar.
Håll allt uppdaterat
Kör alltid en aktuell version av WordPress, temat och dina plugin. Nya versioner rättar inte bara säkerhetshål utan innehåller ofta prestandaförbättringar. En modern PHP-version på servern är också viktig, eftersom varje ny PHP-generation brukar köra WordPress snabbare än den förra. Ta för vana att uppdatera regelbundet, men gör en säkerhetskopia först.
Checklista för en snabbare WordPress
- Webbhotell: byt från trögt delat paket till snabb eller hanterad WordPress-hosting.
- Cache: installera ett cache-plugin och aktivera sidcache, men bara ett.
- Bilder: komprimera, skala rätt, konvertera till WebP och slå på lat inladdning.
- Tema: välj ett lätt, prestandabyggt tema i stället för ett tungt alltiettema.
- Plugin: avinstallera det du inte använder och undvik tunga tillägg.
- CDN: lägg till ett innehållsleveransnätverk för statiska filer.
- Uppdateringar: håll WordPress, tema, plugin och PHP aktuella.
Sammanfattning
Snabbare WordPress handlar sällan om ett enda trick, utan om att lägga flera åtgärder på varandra. Börja med en stabil grund i form av bra hosting, lägg på cache, ta hand om bilderna och skala bort onödig kod. Mät före och efter varje steg så ser du vad som faktiskt hjälper just din sajt. Gör du det arbetet metodiskt får du en sajt som både besökare och Google uppskattar.
Senast faktagranskad: 31 juli 2026