Så optimerar du WordPress för bästa laddtid

Du har installerat WordPress, kanske lagt till ett par plugins och valt ett tema du gillar, men sajten känns seg. Sidor tar för lång tid att ladda och du är inte säker på vad som är problemet. Det är ett av de vanligaste frustrationsmomenten i WordPress-livet, och det beror nästan aldrig på en enda orsak.

Prestandaoptimering för WordPress sker på två nivåer, och det är viktigt att förstå distinktionen. Nivå 1 är det du kontrollerar i WordPress självt, med temaval, plugins, bilder och databasen som de viktigaste faktorerna. Nivå 2 är det ditt webbhotell måste leverera: serverarkitektur, cachingtyp och HTTP-protokoll. Båda nivåerna måste fungera. Ett väloptimerat WordPress på en långsam server ger ändå ett mediokert resultat, och en snabb server räddar inte en sajt som är tungt belastad av dåligt valda plugins och okomprimerade bilder.

Den här artikeln täcker WordPress-specifika åtgärder. Om du letar efter generella prestandatips som gäller alla webbplatser, oavsett plattform, finns det i en separat guide. Har du inte gjort de grundläggande åtgärderna för din WordPress-sajt ännu är det rätt ställe att börja.

En sak till: laddtid spelar faktiskt roll, och inte bara för besökarnas tålamod. Sökmotorer väger in sidprestanda i rankingen, och upplevelsen påverkas märkbart av varje extra sekund. Googles data visar att 53 procent av mobila besökare lämnar en sida som tar mer än tre sekunder att ladda. Det är skäl nog att ta det på allvar.

Snabbguide: De viktigaste åtgärderna för snabbare WordPress

Här är de nio åtgärder som ger störst effekt på de flesta WordPress-sajter. Om du bara har tid att skumma artikeln börjar du lämpligast här. Resten av artikeln förklarar varför och hur i detalj.

1. Byt till ett lättviktigt tema. Ett tungt tema med många inbyggda funktioner är ofta grundproblemet. Välj ett tema byggt för prestanda med minimal CSS- och JavaScript-belastning. Det är svårare att kompensera för ett tungt tema med plugins än att börja rätt.
2. Installera ett cachningsplugin, men kontrollera att ditt webbhotell stöder det. Server-side caching (som LiteSpeed Cache på en LiteSpeed-server) är överlägsen pluginbaserad caching. Kontrollera vilken webbserver ditt webbhotell kör och välj plugin därefter.
3. Optimera bilderna. Bilder är den vanligaste enskilda prestandaboven. WebP-konvertering minskar filstorleken med 60-70 procent. Komprimera, konvertera och aktivera lazy loading för bilder utanför det synliga området. Ladda inte LCP-bilden med lazy load.
4. Kontrollera att LCP-bilden har fetchpriority="high". WordPress 6.3 och senare lägger till detta attribut automatiskt, men teman kan åsidosätta det. Det säger till webbläsaren att prioritera den viktigaste bilden och snabbar upp LCP märkbart.
5. Rensa WordPress-databasen regelbundet. Gamla revisioner, skräppostkommentarer och övergiven plugindata samlas i databasen och bromsar förfrågningar. En rensning kan krympa en uppsvälld databas med 50 till 90 procent. Det tar minuter.
6. Begränsa antalet aktiva plugins och välj säkerhetsplugin med omsorg. Varje plugin är potentiell extra belastning. Avinstallera det du inte använder. Tänk också på att säkerhetsplugins varierar kraftigt i hur de belastar servern.
7. Fråga ditt webbhotell om LiteSpeed, HTTP/3 och server-side caching. Dessa är hostingfunktioner du inte kan lägga till själv. Din server måste stödja dem. Om ditt webbhotell inte erbjuder dem är det värt att jämföra alternativ.
8. Kontrollera och begränsa externa förfrågningar. Varje extern tjänst din sajt kontaktar vid sidladdning lägger till latens. Ladda ned resurser lokalt där det är möjligt.
9. Mät innan och efter varje åtgärd. Använd Google PageSpeed Insights eller GTmetrix för att se vad som faktiskt är ditt flaskhals och bekräfta att dina åtgärder hjälper. Gissa inte.

Mät först och förstå ditt flaskhals innan du åtgärdar

Det vanligaste misstaget i prestandaoptimering är att hoppa direkt på åtgärdslistan utan att förstå vilket problem man faktiskt har. En sajt vars problem är okomprimerade bilder hjälps inte av att man noggrant konfigurerar cachningspluginets avancerade inställningar. Mät först, åtgärda sedan.

Två gratis verktyg räcker för att komma igång. Google PageSpeed Insights analyserar din sajt och presenterar resultat på ett sätt som nybörjare kan förstå, med konkreta diagnosförslag specifika för just din sajt. GTmetrix ger liknande analys med något mer teknisk detaljnivå och möjlighet att välja testplats, vilket är värdefullt om du vill testa från en server i Sverige.

Det här är de tre mätdimensionerna du bör känna till. Den första är hur snabbt något börjar synas på skärmen. I tekniska termer kallas det Largest Contentful Paint, LCP, och det mäter när den viktigaste synliga innehållsbiten på sidan är laddad. Den andra är hur stabilt sidan är layoutmässigt när den laddar. Hoppar rubriker och bilder runt? Det kallas Cumulative Layout Shift, CLS. Den tredje mäter hur snabbt sajten svarar när du klickar eller trycker på något och benämns Interaction to Next Paint, INP. Märk att INP ersatte FID som officiellt Core Web Vital i mars 2024. Det är nu det mått som Google faktiskt väger in.

Mätresultaten visar din prioritetsordning. Åtgärda det som har störst effekt för din specifika sajt, inte det som råkar stå överst i en generisk guide. Och ett konkret råd: testa från Sverige om du har svenska besökare. Ett test från en server i USA ger ett annat resultat än ett test från Stockholm.

En vanlig missuppfattning är att en PageSpeed-poäng på 100 är målet. Förbättringen från 55 till 80 kan vara mer meningsfull för dina besökare än resan från 90 till 100. Verkliga besökares upplevelse väger tyngre än ett laboratorietal.

Nivå 1. Vad du gör i WordPress

Dessa åtgärder ligger inom din kontroll och kräver varken serveråtkomst eller byte av webbhotell. De är ordnade ungefär efter typisk effekt, men mätverktygens diagnos ska styra din prioritering, inte den här listan.

Välj ett lättviktigt tema

Temat är ett av de viktigaste prestandabesluten du fattar för din WordPress-sajt, och det är ett beslut som är svårt att kompensera för i efterhand. Vid varje sidvisning laddar temat CSS-filer, JavaScript och ofta externa typsnitt och ikonpaket. Ett tungt tema kan enkelt fördubbla laddningstiden jämfört med ett lättviktigt, och mängden CSS och JavaScript som laddas in är i princip omöjlig att reducera med ett cachningsplugin. Det sätter sidor i kö och minskar väntan, men mängden data som behöver laddas förändras inte.

Block-teman, som bygger på WordPress eget block-system (Gutenberg), tenderar att generera lättare kod än äldre teman som kräver en sidbyggare. WordPress egna standardteman är ett legitimt utgångsalternativ för enklare sajter. De är byggda med prestanda som designprincip och underhålls av kärnteamet.

Sidbyggare med drag-and-drop-gränssnitt är en kategori att vara medveten om. De genererar generellt mer kod än ett handkodat tema, vilket inte nödvändigtvis gör dem oanvändbara, men det är en faktor att ta med i kalkylen. Gör ett mättest med och utan sidbyggarens extra inläsningar om du är osäker.

Viktigt att veta: ett dyrt premiumtema är inte automatiskt prestandaoptimerat. Pris och prestanda korrelerar dåligt i WordPress-temavärlden. Kolla verkliga prestandatester snarare än marknadsföringstexten.

Har du redan ett tungt tema är rådet att börja med de övriga åtgärderna och mäta effekten. Temabyte är det mest resurskrävande alternativet. En sajt med mycket anpassning i temat innebär risk för att designelement och innehåll behöver återskapas, vilket kan vara väl investerat, men det är rätt att veta kostnadens storlek innan man fattar beslutet.

Installera ett cachningsplugin och förstå vad det faktiskt gör

WordPress bygger normalt varje sida dynamiskt för varje besökare. Det innebär databasförfrågningar, PHP-kod som exekveras och en hel sida som sätts samman från grunden. Caching sparar en färdig version av sidan och levererar den direkt vid nästa besök, utan att WordPress behöver göra allt det arbetet igen. Sidcaching ger typiskt sett runt 34 procent snabbare laddtid, enligt mätningar från olika prestandastudier. Resultatet är snabbare svarstider och lägre serverbelastning.

Här finns en viktig distinktion. Plugincaching innebär att WordPress genererar sidan en gång, sparar resultatet och levererar det till nästa besökare. Server-side caching innebär att servern själv hanterar cachen. WordPress behöver knappt köras alls för cachade sidor. Server-side caching är generellt snabbare, men kräver att webbhotellet stöder det.

Om ditt webbhotell kör LiteSpeed-webbservern finns ett cachningsplugin, LiteSpeed Cache (LSCache), som kommunicerar direkt med servern via ett eget protokoll. Det gör server-side caching sömlöst tillgängligt från WordPress-sidan och är ett av de effektivaste alternativen. Märk dock att LSCache fungerar fullt ut bara på LiteSpeed-servrar. På servrar som kör Apache eller Nginx aktiveras bara pluginets generella PHP-baserade funktioner, vilket fortfarande kan vara värdefullt, men server-side caching-delen faller bort.

Kontrollera vilken webbserver ditt webbhotell kör innan du väljer cachningsplugin. Den informationen finns ofta i kontrollpanelen eller i webbhotellets tekniska specifikationer.

Ett bra cachningsplugin erbjuder mer än bara sidcache. Object cache sparar resultaten av databasförfrågningar och minskar belastningen vid upprepade sökningar. Det kan ge upp mot 32 procent snabbare sidgenerering på sajter med mycket databasaktivitet. Minifiering komprimerar CSS och JavaScript. Lazy loading av bilder skjuter upp inladdningen av bilder som inte syns direkt. Och browser cache instruerar besökarens webbläsare att spara statiska resurser lokalt.

En sak att undvika: fler cachningsplugins är inte bättre. Att köra flera parallellt orsakar konflikter och kan faktiskt försämra prestandan. Välj ett, konfigurera det noggrant och håll dig till det.

Optimera bilderna och åtgärda den vanligaste prestandaboven

Okomprimerade bilder är på de flesta sajter den enskilt tyngsta komponenten. En sida med fem okomprimerade JPEG-bilder kan lätt väga flera megabyte, vilket inget cachningsplugin kan kompensera för.

Filformat spelar stor roll. WebP ger en filstorleksminskning på 60-70 procent jämfört med traditionella JPEG-filer och stöds av alla moderna webbläsare. AVIF är ett modernare format med ännu bättre komprimering, men stödet varierar fortfarande i äldre webbläsare, så kontrollera kompatibiliteten för din målgrupp innan du sätter det som standard. Det finns pluginkategorier för automatisk bildoptimering som komprimerar bilder direkt vid uppladdning.

Bildstorlek är lika viktigt som format. Ladda aldrig upp en bild som är 3 000 pixlar bred om den visas i 800 pixlar. Du skickar ut tre gånger mer data än vad webbläsaren använder. Skala ned bilden till rätt storlek före uppladdning. WordPress genererar automatiskt flera bildstorlekar och ett välkonfigurerat tema väljer rätt storlek för rätt kontext med hjälp av srcset.

Lazy loading är aktiverat som standard i WordPress sedan version 5.5. Bilder utanför det synliga området laddas inte förrän besökaren scrollar dit, vilket fungerar bra för de flesta bilder. Undantaget är LCP-bilden, den bild som dominerar sidan ovanför viken, typiskt en hjältebild eller en stor rubrikbild. Den ska laddas direkt, utan lazy loading. Om ditt tema eller plugin av misstag lägger lazy loading på alla bilder utan undantag bromsar det din viktigaste prestandamätning och kan påverka SEO negativt.

Sedan WordPress 6.3 läggs attributet fetchpriority="high" automatiskt till på LCP-bilden. Det är en instruktion till webbläsaren att prioritera just den bilden i nerladdningskön. Teman kan dock åsidosätta detta, medvetet eller av misstag. Kolla källkoden för din LCP-bild och kontrollera att attributet faktiskt är på plats.

Rensa och optimera WordPress-databasen

Varje gång du redigerar ett inlägg i WordPress sparas en revision. Publicerar du ofta och redigerar fritt kan ett enstaka inlägg ha tiotals revisioner. Lägg till det skräppostkommentarer i papperskorgen, data från avinstallerade plugins och gamla transientvärden, och du har en databas som vuxit rejält utan att innehållet växt i proportion. En uppsvälld databas ger längre svarstider på varje databasförfrågan. På en aktiv sajt som aldrig städats kan en rensning krympa databasen med 50 till 90 procent och ge märkbar effekt på svarstiderna.

Det som är säkert att rensa utan teknisk bakgrund är gamla revisioner utöver de tre till fem senaste per inlägg, skräppost och raderat innehåll i papperskorgen, samt data från plugins du har avinstallerat, förutsatt att du är säker på att du inte behöver datan. Det finns pluginkategorier för databasoptimering som gör rensningen med några klick. Ta alltid en säkerhetskopia av databasen före.

WordPress schemalägger bakgrundsuppgifter via ett system som kallas WP-Cron, och det aktiveras när någon besöker sajten. Plugins kan lägga till schemalagda uppgifter, och om många plugins gör det kan det bidra till att enstaka sidvisningar drar extra lång tid. Det är möjligt att granska och städa bland schemalagda jobb via debuggingverktyg, men det är ett steg som kräver lite mer teknisk känsla.

Databasrensning är underhåll, inte en engångshändelse. En aktiv sajt tjänar på att göra det regelbundet.

Begränsa plugins och externa förfrågningar

Plugins är inte per definition dåliga för prestanda. Ett välkodat plugin med ett specifikt syfte och minimalt fotavtryck påverkar inte laddtiden märkbart. Det är ackumulationen, och i synnerhet plugins med dålig kod som genererar onödigt många databasförfrågningar, som skadar.

Den praktiska tumregeln är att avinstallera allt du inte aktivt använder. Avaktivering är inte tillräckligt. Inaktiverade plugins tar inte plats vid sidladdning, men datan de har sparat i databasen finns kvar och tyngden kvarstår. Avinstallera, och rensa sedan databasen.

Externa förfrågningar är en faktor som ofta förbises. Varje extern tjänst din sajt kontaktar vid en sidvisning, t.ex. Google Fonts, analytics-skript, inbäddade sociala medieplugins eller reklamskript, lägger till en nätverksförfrågan med latens. Det handlar inte om några enstaka millisekunder utan potentiellt om hundratals per förfrågan om DNS-lookup, uppkoppling och nedladdning räknas in. Kör PageSpeed Insights och titta på vilka externa domäner din sajt kontaktar vid varje sidvisning.

Google Fonts är ett bra konkret exempel. Typsnittsfiler kan laddas ned och serveras lokalt från ditt eget webbhotell istället för från Googles server. En extern förfrågan elimineras och sidladdningen är inte längre beroende av en tredje parts svarstid. Det är en åtgärd som tar en kvart och ger bestående effekt.

Vill du veta vilka plugins som genererar flest databasförfrågningar specifikt på din sajt finns det debuggingverktyg i pluginkategorin för prestandaanalys som visar det. För en djupare genomgång av hur man utvärderar pluginkvalitet, se vår guide om hur du väljer rätt WordPress-plugins.

Säkerhetsplugins och deras prestandapåverkan

Säkerhet är icke-förhandlingsbart, men valet av säkerhetsplugin påverkar prestandan mer än de flesta räknar med. Det är ett område som sällan tas upp i prestandaguider, trots att konsekvenserna är påtagliga.

Wordfence är det mest installerade säkerhetsplugin och erbjuder realtidsskanning och en brandvägg direkt i WordPress. Kostnaden är att skanningen sker på din server, vilket belastar processorresurserna märkbart, framför allt på delat webbhotell. All-In-One WP Security har ett lättare fotavtryck och påverkar prestandan betydligt mindre. Sucuri löser problemet på ett annat sätt. Dess skanning sker off-server, vilket innebär att den tyngre analysen inte tar serverresurser från sidleveransen.

Det finns alltså en avvägning att göra: ett robustare skydd kan innebära högre serverbelastning. Vad som är rätt val beror på din sajts exponering, trafik och vilken typ av hosting du har. Poängen här är att du bör mäta laddtiden med och utan ditt säkerhetsplugin aktivt, så att du vet vad det faktiskt kostar prestandamässigt.

WordPress 6.8 och nyare prestandafunktioner

WordPress Core-teamet arbetar löpande med prestandaförbättringar, och de senaste versionerna har fört med sig funktioner som förtjänar att nämnas. Dessa fångas inte upp av de flesta äldre guider på nätet.

Speculative Loading introducerades i WordPress 6.8 via Speculation Rules API. Funktionen gör att webbläsaren börjar ladda nästa sida redan när besökaren hovrar över en länk, innan de faktiskt klickar. I praktiken innebär det att navigering mellan sidor på sajten kan kännas nästan omedelbar. Funktionen är inbyggd och aktiveras utan tilläggsplugins på sajter som kör WordPress 6.8 eller senare.

Det här är en av de mer påtagliga UX-förbättringarna på länge, och den kostar ingenting att aktivera. Uppdatera till senaste WordPress-version om du inte redan har gjort det.

fetchpriority="high" nämndes redan under bildoptimering, men det förtjänar att upprepas i ett bredare sammanhang. Attributet ingår i WordPress kärnfunktionalitet sedan 6.3 och är ett konkret exempel på hur WordPress Core-teamets arbete med Performance Lab-projektet omsätts i praktiska förbättringar. Håller du WordPress uppdaterat och använder ett tema som inte åsidosätter kärnbeteendet får du dessa förbättringar utan extra konfiguration.

Gzip- och Brotli-komprimering av textfiler (HTML, CSS, JavaScript) hanteras på servernivå men är värt att nämna i sammanhanget. Brotli ger typiskt sett 15-25 procent bättre komprimering än Gzip. Sammanlagt kan komprimering minska dataöverföringen med mer än 50 procent för texttungt innehåll. Kontrollera om ditt webbhotell aktiverar Brotli som standard.

Nivå 2. Vad ditt webbhotell måste leverera

Det finns ett tak för hur snabb din WordPress-sajt kan bli med åtgärder på plugin- och temanivå. Taket sätts av den serverinfrastruktur som ditt webbhotell tillhandahåller. Rätt hostingval multiplicerar effekten av allt arbete du lagt ned på nivå 1. Fel hostingval gör att du optimerar mot en vägg.

Webbservern: LiteSpeed, Nginx och Apache

De flesta webbhotell kör en av tre webbservrar. Apache är den traditionella med bred kompatibilitet och ett väl etablerat ekosystem. Nginx är populär för sajter med hög trafik och effektiv på att servera statiska filer. LiteSpeed är byggd för att hantera dynamiska CMS-plattformar som WordPress, med ett eget cachingprotokoll som integrerar djupare med applikationslagret.

LiteSpeed-fördelen för WordPress handlar framför allt om hur LSCache-pluginet och webbservern kommunicerar. De talar ett eget protokoll som gör att server-side caching fungerar mer sömlöst och effektivt för WordPress än vad alternativen erbjuder. Det är anledningen till att LiteSpeed ofta dyker upp som svar på frågan om vilket webbhotell som är snabbast för WordPress.

En viktig sak att hålla isär: LiteSpeed är webbservern, alltså hostinginfrastrukturen. LSCache är pluginet du installerar i WordPress. Pluginet fungerar bäst på LiteSpeed-servrar, men har generella funktioner som aktiveras oavsett webbserver. Installerar du LSCache på ett webbhotell som kör Nginx får du plugincaching men inte server-side caching via LiteSpeed-protokollet.

LSCache-pluginet har dessutom inbyggd integration med QUIC.cloud, ett CDN byggt specifikt för LiteSpeed-miljöer. QUIC.cloud hanterar bildoptimering, CSS- och JavaScript-minifiering och CDN-leverans via samma protokoll som LSCache kommunicerar med servern. Kombinationen av LiteSpeed-server, LSCache och QUIC.cloud ger extrema hastighetsförbättringar som är svåra att matcha med andra uppsättningar. QUIC.cloud har en gratis nivå som räcker för mindre sajter.

Bland svenska webbhotell som kör LiteSpeed finns Oderland, Inleed och Miss Hosting. Alla tre stöder LSCache-pluginet fullt ut, vilket betyder att du får server-side caching och möjligheten att koppla på QUIC.cloud utan extra konfiguration. Se vår jämförelse av WordPress-optimerade webbhotell för en bredare översikt.

Kontrollera vilken webbserver ditt nuvarande webbhotell kör. Den informationen finns ofta i kontrollpanelen, i webbhotellets tekniska specifikationer, eller så kan du fråga supporten direkt.

Server-side caching, HTTP/3 och CDN

Det finns tre hostingfunktioner med stor prestandapåverkan som du inte kan lägga till med ett WordPress-plugin. De kräver antingen att webbhotellet tillhandahåller dem eller att du byter.

Server-side caching via Redis, Memcached eller LSCache innebär att servern hanterar cachen utan att WordPress behöver exekveras. Det är snabbare än pluginbaserad caching av det enkla skälet att färre rörliga delar är inblandade. Om ditt webbhotell erbjuder Redis eller Memcached som tillägg bör du aktivera det och konfigurera ditt cachningsplugin att använda det.

HTTP/3 är det senaste HTTP-protokollet. Det förbättrar hanteringen av parallella förfrågningar och märks särskilt på mobila nätverk där paketförlust är vanligare. Du kan kontrollera i PageSpeed Insights eller i webbläsarens utvecklingsverktyg om din sajt levereras via HTTP/3. Om inte, fråga ditt webbhotell om de stöder det och om det är aktiverat för din hostingplan.

CDN (Content Delivery Network) innebär att statiska resurser som bilder, CSS och JavaScript serveras från den server i ett globalt nätverk som är geografiskt närmast besökaren. För en sajt med uteslutande svenska besökare och en server i Sverige är vinsten av CDN mer begränsad jämfört med en global sajt, men det finns fortfarande fördelar. Kontrollera om ditt webbhotell inkluderar CDN i ditt paket.

De fyra frågor du bör ställa ditt webbhotell är: Kör ni LiteSpeed? Stöder ni HTTP/3? Ingår server-side caching med Redis, Memcached eller LSCache? Har ni inbyggt CDN? Om svaret är nej på alla fyra är det värt att jämföra alternativ. Se vår jämförelse av snabba webbhotell och WordPress-optimerade webbhotell.

PHP-version och serverresurser

PHP-versionen din sajt kör på är en prestandafaktor som är lätt att kontrollera och enkel att åtgärda. WordPress rekommenderar alltid senaste aktiva PHP-version, och skillnaden i exekveringshastighet mellan en gammal och en ny PHP-version är märkbar. Äldre PHP-versioner är dessutom ett säkerhetsproblem eftersom de inte längre får säkerhetsuppdateringar. Kontrollera din PHP-version i webbhotellets kontrollpanel och uppgradera om du ligger efter. De flesta webbhotell låter dig byta version med ett klick.

PHP-minnesgränsen är en annan inställning värd att kolla. Om WordPress inte har tillräckligt med PHP-minne kan du få felmeddelanden eller sidkrascher, framför allt med tunga plugins eller teman. Ser du felmeddelanden om minnesbrist är det en enkel åtgärd att höja gränsen i kontrollpanelen.

Delat webbhotell innebär att du delar serverresurser med andra sajter på samma maskin. Hög last från en granne kan tillfälligt bromsa din sajt, och det är en inneboende begränsning av hostingmodellen. Det är ett av skälen till att sajter som växer i trafik ofta behöver uppgradera till en hostingform med isolerade resurser. Skillnaderna mellan delat webbhotell, VPS och dedikerad server behandlas mer utförligt i vår guide om skillnaden mellan delat webbhotell och VPS.

Testa i staging-miljö innan det går live

Prestandaändringar är inte riskfria. Ett nytt tema, en ändrad cachingkonfiguration eller ett pluginbyte kan oavsiktligt bryta funktioner, förändra layouten eller skapa konflikter som inte syns förrän något är i produktion. Staging löser det problemet.

En staging-miljö är en kopia av din sajt där du kan testa fritt utan att påverka det verkliga innehållet. De flesta kvalitetswebbhotell erbjuder staging med ett klick från kontrollpanelen. Du testar ändringen, bekräftar att allt fungerar, och för sedan över resultatet till den riktiga sajten.

Det är framför allt viktigt vid temabyte, uppgradering av WordPress Core eller installation av plugins som ändrar hur cachen fungerar. Att testa direkt på produktionssajten genom trial and error är ineffektivt och onödigt riskabelt när det finns ett bättre alternativ.

Mät igen och bekräfta att åtgärderna hjälpte

När du har genomfört åtgärder är det dags att stänga loopen. Kör PageSpeed Insights igen och jämför resultaten med det du mätte innan. Gör gärna en åtgärd i taget och mät emellan. Det är det enda sättet att verkligen veta vad som hade effekt och vad som knappt rörde nålen.

En praktisk iakttagelse: testresultat varierar beroende på tidpunkt, serverbelastning och testnätverk. Kör två till tre tester och titta på genomsnittet, inte på enstaka mätpunkter.

Ärlig förväntan är att alla sajter ser olika ut. En sajt med många bilder och lite dynamiskt innehåll tjänar mest på bildoptimering. En sajt med många plugins och databasintensiva funktioner tjänar mest på caching och databasrensning. Det finns inget universellt recept som fungerar lika bra på alla sajter, och det är anledningen till att vi ägnade inledningen åt att mäta och identifiera just ditt flaskhals.

Om du har genomfört åtgärderna på nivå 1 och mätresultaten fortfarande är svaga är nästa steg att undersöka hostingnivån. TTFB, Time to First Byte, mäter den tid det tar för servern att börja svara och är ett bra isolerat mätvärde för serverprestanda. En lång TTFB pekar mot problem på hostingnivå, och då räcker det sällan med att optimera ytterligare på WordPress-sidan.

Google Search Console är ett komplement till laboratorietesterna. Det visar Core Web Vitals-data från verkliga besökare på din sajt, vilket är mer representativt för den faktiska användarupplevelsen. Det är ett bra sätt att kontrollera att förbättringar i laboratorietester också syns i verklig användning.

Prestandaoptimering är inte en engångshändelse. Sajter förändras, nya plugins installeras, nytt innehåll läggs till och trafiken växer. En enkel mätning en gång per kvartal är rimligt underhåll för en aktiv sajt.

Nästa steg. Välj rätt hosting som bas

Om du har gått igenom åtgärderna på nivå 1 och fortfarande ser en seg sajt är hostinggrunden troligen det återstående hindret. De hostingegenskaper som har störst prestandapåverkan för WordPress är en LiteSpeed-webbserver med LSCache, HTTP/3-stöd, server-side caching med Redis eller Memcached, PHP på senaste rekommenderade version och geografisk serverplacering i Sverige för svenska besökare. Det är en konkret kravlista att checka av mot ditt nuvarande webbhotell.

Tre handlingsmoment att ta med sig från den här artikeln:

1. Genomför stegen på nivå 1 om du inte redan gjort det: tema, caching, bilder, databas och plugins.
2. Kontrollera om ditt nuvarande webbhotell erbjuder LiteSpeed, HTTP/3 och server-side caching.
3. Om svaret är nej, jämför alternativen i vår lista över snabba webbhotell och vår samling av WordPress-optimerade webbhotell.

Vill du ha en mer handsfree-lösning där webbhotellet tar ett större ansvar för hostingkonfigurationen är managed WordPress-hosting ett alternativ. Templ är en svensk leverantör byggd specifikt för WordPress med servrar i Stockholm och inbyggd prestanda-optimering. Kinsta kör på Google Cloud med en egen infrastruktur optimerad för WordPress och erbjuder bland annat inbyggt CDN och automatisk bildoptimering. Båda hanterar caching, säkerhetsuppdateringar och servertuning åt dig. Läs mer i vår guide om managed hosting för WordPress.

En avslutande iakttagelse att ta med sig: ett webbhotellbyte löser inte prestandaproblem automatiskt. Ett snabbt webbhotell förstärker en välkonfigurerad sajt men räddar inte en sajt som är fundamentalt belastad av ett tungt tema eller felkonfigurerade plugins. Gör jobbet på båda nivåerna, i rätt ordning.