Sidhastighet optimering med PageSpeed Insights och Core Web Vitals

Lär dig sidhastighet optimering med PageSpeed Insights och Core Web Vitals. Fixa bilder, JavaScript och server – konkreta steg du kan ta direkt.

En besökare klickar in på din sida från ett mobilnät på bussen. Tre sekunder senare ser besökaren fortfarande en vit skärm, suckar och backar till nästa träff i listan. Det där tappet syns aldrig som ett felmeddelande, men det kostar dig kunder varje dag, och det är precis den sortens läckage som arbetet med sidhastighet ska täppa till.

Att optimera laddtid handlar inte om att jaga en perfekt siffra i ett testverktyg, utan om att människor stannar, läser och handlar i stället för att ge upp halvvägs. Den här guiden visar hur du mäter laddtid rätt med PageSpeed Insights, hittar de tyngsta bromsklossarna och tar dem i en vettig ordning, oavsett om sajten körs på WordPress eller något annat CMS.

Varför snabb laddtid är värd din tid

Google har gjort mätbara mått av användarupplevelse genom Core Web Vitals, och de handlar om hur snabbt det viktigaste syns, hur snabbt sidan reagerar på klick och hur mycket innehållet hoppar runt medan det laddar. En sajt som klarar dessa tre ger en lugnare upplevelse, och lugna besökare stannar i regel betydligt längre än stressade.

Det finns en affärssida som ofta glöms bort när tekniken tar över samtalet. En trög sida tenderar att få fler besökare att ge upp innan de gör något, och för en lokal verksamhet i Stockholm eller Malmö som lägger pengar på SEM och annonser betyder det att du betalar för klick som studsar bort innan sidan ens hunnit visa sig. Innan du gräver i tekniken bör du därför bestämma vad du faktiskt ska prioritera, och en enkel turordning sparar mycket tid:

1. Sidor med mest trafik, eftersom det är där flest besökare hinner märka en snabbare upplevelse.
2. Sidor med tydligast affärsvärde, alltså produkt-, tjänste- och kontaktsidor som genererar intäkter eller leads.
3. Resten, där arkiv och äldre inlägg får vänta tills de viktiga sidorna sitter ordentligt.

Vad mäter Core Web Vitals egentligen?

De tre måtten beskriver olika delar av samma upplevelse, och du behöver hålla isär dem för att veta vad du ska åtgärda och i vilken ordning.

• Largest Contentful Paint (LCP, hur snabbt det största synliga elementet laddar) bör ligga under 2,5 sekunder på mobil.
• Interaction to Next Paint (INP, hur snabbt sidan svarar när någon klickar eller skriver) avgör hur följsam den känns.
• Cumulative Layout Shift (CLS, hur mycket innehållet flyttar sig under laddningen) irriterar besökaren mest precis när hen ska trycka.

Largest Contentful Paint

Det här måttet fångar när den största synliga ytan, ofta en hjältebild eller en stor rubrik, är klar på skärmen, och så länge värdet ligger under 2,5 sekunder upplever de flesta besökare sidan som snabb. I PageSpeed Insights kör du testet och tittar under diagnostiken efter raden om Largest Contentful Paint-elementet, där det exakta elementet pekas ut så att du vet vad som bör prioriteras först.

Så hittar du LCP-elementet

När du vet vilket element det är kan du agera riktat. Är det en hjältebild: servera den i WebP, i rätt storlek, och låt den ladda tidigt med attributet fetchpriority=“high” i stället för lazy-loading. Är det en rubrik eller ett textblock handlar det oftare om att teckensnittet eller en blockerande CSS- eller JavaScript-fil står i vägen.

Interaction to Next Paint

INP mäter hur följsam sidan känns att använda i praktiken. Klickar du på en knapp och inget händer på en halv sekund är det INP som är boven, ofta på grund av tung JavaScript som blockerar webbläsaren just när besökaren vill agera. I Lighthouse hittar du orsakerna under förslaget om att minska arbetet på huvudtråden. Sikta på ett INP under ungefär 200 millisekunder – då upplevs sidan som följsam och svarar i praktiken direkt på en knapptryckning.

Cumulative Layout Shift

De där irriterande hoppen där du ska trycka på en knapp och en bild plötsligt skjuter ner allt innehåll – det är vad CLS fångar. Det löser du oftast genom att sätta fasta mått på bilder och annonser så att webbläsaren reserverar plats redan innan filerna laddats klart.

Var sidhastighet passar in i SEO

Sökmotoroptimering består av flera lager: teknik, innehåll och länkar. Hastighet hör till tekniken och fungerar som ett golv, och är golvet trasigt spelar det mindre roll hur bra innehållet är, eftersom besökaren aldrig hinner läsa det. Men ett blankputsat golv lyfter inte en tom sida, så se snabb laddtid som en av flera saker som ska sitta, inte som hela arbetet med din SEO. Google visar dessutom allt oftare svar i en AI Overview högst upp, och en seg sida har sämre förutsättningar att plockas upp som källa där.

En snabb sida vinner sällan ett toppläge på egen hand, men en långsam sida tappar besökare som du redan betalat för att locka dit.

Mät laddtid med PageSpeed Insights

Det vanligaste misstaget är att börja fippla med inställningar utan att veta var problemet sitter, så att du gissar, ändrar något och sedan inte vet om det hjälpte. Ordningen är enkel: mät först, prioritera sedan och åtgärda sist. Det finns två sorters data du behöver hålla isär, där fältdata visar hur riktiga besökare upplever sajten över tid medan labbdata kommer från ett kontrollerat test och passar bra för att felsöka enskilda sidor medan du jobbar.

Gratisverktyg som ger bäst mätdata

Du behöver inte betala för en enda licens för att komma igång med din mätning. Börja med PageSpeed Insights eftersom det kombinerar fält- och labbdata med konkreta förslag, och det är ofta det enda verktyg en mindre sajt behöver i början. När du vill se hur hela sajten mår över tid kompletterar du med rapporten Core Web Vitals i Search Console, som bygger på riktiga besökares upplevelser, och medan du faktiskt sitter och ändrar saker är Lighthouse i Chrome smidigt eftersom det testar en enskild sida direkt i webbläsaren. De olika verktygen kompletterar varandra på var sitt sätt:

• PageSpeed Insights ger både fält- och labbdata med åtgärdsförslag för en enskild sida.
• Search Console visar hur Core Web Vitals utvecklas för hela sajten över tid.
• Lighthouse i Chrome testar en sida direkt i webbläsaren medan du arbetar.
• WebPageTest ger den nivå av detalj du behöver när du vill se exakt vad som laddar och i vilken ordning.

Fältdata mot labbdata

Skillnaden mellan de två datatyperna avgör hur du tolkar siffrorna, och det är värt att lägga det på minnet:

• Fältdata kommer från riktiga besökares enheter och uppkopplingar och visas i PageSpeed Insights och Search Console.
• Labbdata mäts i en kontrollerad miljö i Lighthouse och blir ungefär samma resultat varje gång.
• Använd labbdata för snabb felsökning och fältdata för att bekräfta att riktiga besökare faktiskt märker skillnaden.

De vanligaste bromsklossarna

När du har mätt brukar samma tre saker återkomma gång på gång, oavsett om sajten är byggd i WordPress, en annan sidbyggare eller ett egenbyggt CMS, och det är där du ska lägga din första insats.

Bilder du bör optimera först

Bilder är nästan alltid den största delen av en sidas vikt, och en enda okomprimerad produktbild kan väga lika mycket som hela resten av sidan tillsammans. Vilka sidor du börjar med beror på vad de ska uträtta – en genomgång av grunderna i sökordsanalys hjälper dig att se vilka sidor och sökord som bär affären, så att du lägger optimeringen där den gör mest nytta. Börja sedan med de tyngsta bilderna och jobba dig nedåt:

• Spara foton som WebP (ett modernt bildformat) i stället för stora JPEG-filer, eftersom formatet komprimerar hårdare utan synlig kvalitetsförlust.
• Skala bilden till den storlek den faktiskt visas i på sidan, inte 4000 pixlar bred i onödan.
• Lägg på lazy-loading så att bilder under skärmkanten laddas först när besökaren scrollar ner till dem.
• Sätt alltid bredd och höjd på bilden så att layouten inte hoppar medan den laddar.

Moderna bildformat

Moderna bildformat som WebP och AVIF komprimerar betydligt hårdare än JPEG utan synlig kvalitetsförlust, och i praktiken brukar arbetsgången se ungefär likadan ut oavsett sajt:

• Hitta de tyngsta bilderna i PageSpeed Insights under förslagen längst ner.
• Konvertera dem till WebP, eller AVIF om ditt CMS stödjer formatet.
• Ta bort gamla mediefiler du inte längre använder så att de inte ligger kvar och tynger.

I WordPress sköter en bildplugin ofta konverteringen till WebP automatiskt vid uppladdning, men bygger du själv kan Squoosh, ett gratis bildverktyg från Google som körs direkt i webbläsaren, konvertera enstaka bilder utan installation. Driver du sajten på just WordPress hittar du fler plattformsspecifika råd i guiden om SEO för WordPress.

JavaScript och plugins som bromsar

Varje skript måste laddas ner, tolkas och köras innan sidan blir interaktiv, och plugins, chattbubblor, spårningsskript och cookies-banners staplar på sig snabbare än man tror. Tung JavaScript är ofta orsaken bakom ett dåligt INP-värde, eftersom långa uppgifter blockerar webbläsaren när besökaren vill klicka, och i Lighthouse hittar du dessa under förslagen om att minska JavaScript-körning och arbetet på huvudtråden.

• Avinstallera plugins du inte längre använder eller bara installerade en gång för att testa.
• Ladda tredjepartsskript fördröjt eller asynkront så att de inte konkurrerar med det viktiga.
• Slå ihop och minifiera filer där det går utan att något slutar fungera.

Tredjepartsskript att fördröja

Tredjepartsskript är ofta de tyngsta gästerna på sidan, och de flesta av dem behövs inte den första halvsekunden. Dessa bör du särskilt hålla koll på:

• Spårning som Google Analytics och annonspixlar som laddar i bakgrunden.
• Chattbubblor och bokningswidgetar som drar in extern kod.
• Banners för cookies och inbäddade kartor som tynger den första vyn.

De flesta av dessa kan laddas fördröjt utan att besökaren märker något. Många cache- och optimeringsplugins har en inställning för att skjuta upp tredjepartsskript tills besökaren scrollar eller interagerar, och mätningen fångar fortfarande sidvisningen samtidigt som skriptet inte längre konkurrerar med det som ska synas direkt. Testa i PageSpeed Insights före och efter så att du ser att LCP faktiskt blev bättre.

Serverresponstid och webbhotell

Sitter du på det billigaste delade webbhotellet kan serverns svarstid ensam äta upp en sekund innan något ens börjar laddas, och en cache som sparar färdiga sidor löser ofta det mesta. För en liten sajt med måttlig trafik räcker ett delat webbhotell oftast gott så länge svarstiden är rimlig, men märker du i PageSpeed Insights att serverns svarstid är hög trots cache är det ett tecken på att hotellet är översålt.

• Ett delat webbhotell duger så länge svarstiden ligger under ett par hundra millisekunder och cachen fungerar.
• Är svarstiden hög även på en avskalad testsida har du i regel växt ur paketet.
• Då gör ett snabbare webbhotell eller en VPS (en egen virtuell server som du inte delar med andra) mer nytta än ännu en optimeringsplugin.

När gör en CDN nytta?

En CDN är ett nätverk av servrar som lagrar kopior av dina filer geografiskt nära besökaren, och den hjälper mest om du har en publik utanför Sverige, exempelvis i USA eller övriga Europa. Har du nästan bara svensk trafik och en server i Norden märks en CDN knappt för en besökare i Göteborg eller Örebro, eftersom avståndet redan är kort. Vinsten kommer först när besökarna är spridda över flera kontinenter, så för en lokal verksamhet är det sällan första steget. Lägg hellre tiden på bilder och skript, där effekten syns direkt även för dina lokala kunder.

Optimera i rätt ordning

Här är ordningen jag brukar följa, eftersom den ger mest effekt per insats och du ser resultat snabbt utan att riskera att slå sönder något som redan fungerar.

Snabba vinster i WordPress

Kör du WordPress finns några åtgärder som nästan alltid ger effekt, och det lönar sig att ta dem i den här turordningen:

1. Aktivera en cache-plugin och ställ in den ordentligt innan du gör något annat.
2. Installera en bildplugin som automatiskt konverterar nya bilder till WebP vid uppladdning.
3. Gå igenom plugin-listan och avinstallera allt du inte längre använder.
4. Byt en tung sidbyggare mot ett lättare tema om själva grundbygget är segt.

Cache är nästan alltid det första steget, men det löser sällan allt på egen hand, eftersom stora bilder och tung JavaScript fortfarande bromsar. När sidan väl är snabb vill du dessutom att Google hittar och indexerar de optimerade sidorna:

• Se till att alla viktiga sidor finns med i din sitemap.
• Skicka in sitemap-filen i Search Console om du inte redan gjort det.
• Kontrollera att inga viktiga sidor blockeras av robots-regler.

Bör du fixa det själv eller ta hjälp?

De flesta små företag klarar vänstra kolumnen själva med gratisverktyg, och det är ofta där den största vinsten ligger. Det är dags att ta hjälp först när du redan komprimerat bilder och cachat men sidan ändå är seg, när PageSpeed Insights pekar på problem i temats kod, eller när servern svarar långsamt även på en avskalad testsida.

Följ upp i Search Console

Att optimera utan uppföljning är bara gissningar, så mät samma sidor på samma sätt som innan, så att du jämför äpplen med äpplen. Tänk på att fältdata i Search Console släpar efter, ofta flera veckor, eftersom den bygger på riktiga besökares upplevelser över tid, och bli därför inte orolig om siffrorna inte rör sig redan dagen efter att du ändrat något.

• Jämför LCP före och efter på dina tre viktigaste sidor.
• Följ Core Web Vitals i Search Console under några veckor framåt.
• Håll koll på avvisningsfrekvens och tid på sidan i din analys.
• Notera om antalet besökare som faktiskt hör av sig eller handlar rör sig uppåt.

Ett konkret före och efter

Ett typiskt mönster ser ofta ut ungefär så här. Tänk dig en sajt där startsidans LCP ligger runt 4,5–5 sekunder på mobil, mest på grund av en okomprimerad hjältebild och en chattwidget som laddar direkt. Veckorna efter en uppstädning brukar utvecklingen följa ungefär den här gången:

1. Vecka 1: hjältebilden komprimeras till WebP och chattwidgeten fördröjs, varpå labbtestet i Lighthouse direkt visar ett LCP runt 2–2,5 sekunder.
2. Vecka 2 till 3: cache aktiveras och ett par oanvända plugins som legat kvar sedan tidigare rensas bort.
3. Vecka 4 till 6: fältdatan i Search Console hinner ikapp och rör sig från “behöver förbättras” mot “bra”.

Poängen är att labbtestet ger besked redan samma dag, men att fältdatan tar en dryg månad på sig innan den bekräftar samma sak. För att hålla koll månad för månad utan att drunkna i siffror räcker en handfull värden:

• LCP på dina tre viktigaste sidor i PageSpeed Insights.
• Andelen webbadresser som klassas som bra i rapporten Core Web Vitals.
• Serverns svarstid, så att du fångar ett översålt webbhotell tidigt.
• Konvertering eller antal kontakter - det som till slut avgör om arbetet lönade sig.

Realistiska förväntningar

Att gå från 6 sekunder till 2 sekunder märks tydligt i både upplevelse och konvertering, men att finslipa från 1,4 till 1,2 sekunder märks knappt och är sällan värt timmarna. Lägg krutet där sajten faktiskt är trög, och nöj dig när den känns snabb för en vanlig besökare på mobil. Vill du att den snabbare sidan också ska få mer att säga till om är nästa steg att stärka själva innehållet – där hjälper guiden om innehållsstrategi dig att bygga sidor som både laddar snabbt och svarar på det besökaren söker.

Nästa steg

Mät dina tre viktigaste sidor i PageSpeed Insights i kväll, skriv ner de tre tyngsta problemen och fixa det enklaste först. När bilderna är komprimerade och en cache är på plats har du redan tagit den största delen av jobbet med din sidhastighetsoptimering, och du kan följa effekten i Search Console under veckorna som kommer. Vill du gräva vidare hittar du nästa naturliga steg i guiderna om SEO för WordPress och innehållsstrategi, samt en närmare titt på E-E-A-T i ordlistan.