Core Web Vitals

Core Web Vitals är tre mått som Google använder för att beskriva hur snabbt, responsivt och stabilt en sida känns för den som besöker den. Måtten heter LCP, INP och CLS och mäter laddning, interaktion respektive visuell stabilitet, var och en med ett eget tröskelvärde. Det speciella är att Google inte gissar utifrån ett enskilt labbtest, utan hämtar siffrorna från riktiga besökare i Chrome och bedömer sidan på hur de faktiskt upplever den. Det gör arbetet besläktat med bredare optimering av sidhastighet.

Du stöter oftast på begreppet i PageSpeed Insights eller i Google Search Console, där en sida får en färg som speglar dess status: grön när måttet är bra (good), gul när det behöver förbättras (poor needs improvement) och röd när det är dåligt (poor). Den här sidan går igenom vad varje mått betyder, vilka värden som räknas som bra, hur du mäter och vad du gör för att flytta en sida från rött till grönt.

Vad de tre måtten faktiskt mäter

Core Web Vitals är inte ett enda värde utan tre separata mått som var och ett fångar en del av användarupplevelsen. En sida kan vara snabb att ladda men ändå kännas trög när du klickar, eller snabb och responsiv men så hoppig att du trycker fel. Genom att mäta tre saker var för sig fångar Google fler sätt som en sida kan irritera besökaren på, och måtten ingår i en bredare bedömning av sidupplevelse tillsammans med signaler som mobilanpassning och säker anslutning.

Det är värt att skilja på två datakällor från start, eftersom de svarar på olika frågor och ofta visar olika resultat för samma sida. Fältdata kommer från riktiga besökare och samlas enligt Google i Chrome User Experience Report, ofta förkortat CrUX, över ett rullande fönster på 28 dagar. Labbdata kommer i stället från ett enskilt testkörningstillfälle i Lighthouse med fasta inställningar. Det är fältdatan som Google faktiskt rankar på, men labbdatan är ofta lättare att felsöka i.

De tre måtten i korthet

• LCP (Largest Contentful Paint): hur snabbt huvudinnehållet syns.
• INP (Interaction to Next Paint): hur snabbt sidan svarar vid interaktion.
• CLS (Cumulative Layout Shift): hur stabilt innehållet ligger under laddning.
• Alla tre mäts på 75:e percentilen, alltså för tre av fyra besökare.
• Alla tre hämtas i fält från riktiga användare (how real users) via Chrome och CrUX.

Snabbreferens för tröskelvärden

• LCP: grönt under 2,5 s, gult 2,5 till 4 s, rött över 4 s.
• INP: grönt under 200 ms, gult 200 till 500 ms, rött över 500 ms.
• CLS: grönt under 0,1, gult 0,1 till 0,25, rött över 0,25.
• Saknas färg: sidan har för lite fältdata för att Google ska kunna bedöma den.

Så läser du av färgerna i rapporten

• Grön: sidan klarar tröskeln för minst tre av fyra besökare.
• Gul: värdet ligger i gränslandet och bör ses över.
• Röd: värdet är klart över tröskeln och påverkar upplevelsen.

LCP och så förbättrar du det

LCP står för Largest Contentful Paint och mäter hur lång tid det tar innan sidans största synliga element är klart, vilket oftast är en hjältebild, en stor rubrik eller en videoram. Enligt Google räknas ett LCP under 2,5 sekunder som grönt, mellan 2,5 och 4 sekunder som gult och över 4 sekunder som rött. Långsam LCP beror oftast på tunga bilder eller en server som dröjer innan första byten skickas.

Vanliga orsaker till långsam LCP:

• Tunga, okomprimerade bilder som laddas i full upplösning på mobil.
• En server eller ett webbhotell som dröjer innan första byten skickas.
• Render-blockerande CSS och JavaScript högt upp i dokumentet.
• Typsnitt som laddas sent och tvingar fram en omritning av texten.
• Saknad cachning eller inget CDN nära besökaren.

Så förbättrar du LCP:

• Komprimera och beskär hjältebilden, och servera moderna format som WebP eller AVIF.
• Lägg in fetchpriority="high" på det element som blir LCP.
• Använd ett Content Delivery Network så att innehållet ligger nära besökaren.
• Skjut upp eller ladda render-blockerande resurser asynkront.
• Aktivera cachning på servern så att återkommande besökare får sidan snabbare.

Kör du WordPress sitter de tyngsta LCP-problemen ofta i temat, och de hör hemma i det bredare arbetet med teknisk SEO.

INP och så gör du sidan mer responsiv

INP står för Interaction to Next Paint och ersatte enligt Google FID som det officiella måttet för responsivitet i mars 2024. Där ett gammalt FID-värde (fid score) bara mätte fördröjningen på din första interaktion tittar INP på alla interaktioner under besöket och rapporterar i praktiken den sämsta. Enligt Google är ett INP under 200 ms grönt, 200 till 500 ms gult och över 500 ms rött. Det som tynger ner måttet är nästan alltid att huvudtråden har för mycket att göra (tasks) just när besökaren vill ha svar.

Vanliga orsaker till hög INP:

• Tunga JavaScript-uppgifter som blockerar huvudtråden vid klick.
• Tredjepartsskript för chatt, analys och annonser (ads) som körs samtidigt.
• Stora event-lyssnare som gör för mycket arbete vid varje interaktion.
• Layoutomritningar som triggas av en liten förändring i DOM:en.

Du vänder på det genom att lätta på huvudtråden:

• Dela upp långa uppgifter i mindre bitar så att tråden hinner svara mellan dem.
• Ladda in tredjepartsskript senare eller bara när de faktiskt behövs.
• Skär ner mängden JavaScript som körs redan vid sidladdning.
• Lägg arbete som kan vänta på requestIdleCallback så att det körs när webbläsaren är ledig.

Tidigare mätte man besläktade saker med Total Blocking Time i labbmiljö, och TBT (Total Blocking Time) är fortfarande en bra proxy när du felsöker, eftersom det fångar samma trögkörda JavaScript som ofta drar ner INP i fält.

CLS och så stabiliserar du layouten

CLS står för Cumulative Layout Shift och mäter hur mycket innehållet flyttar sig oväntat medan sidan laddar. Du känner förmodligen igen problemet från när du ska klicka på en länk, en annons laddar in ovanför och du plötsligt trycker på fel sak. CLS uttrycks som ett tal utan enhet, där enligt Google under 0,1 är grönt, 0,1 till 0,25 gult och över 0,25 rött.

Det här orsakar hopp i layouten:

• Bilder utan angivna mått (width och height) som reserverar fel utrymme.
• Annonser och inbäddningar (reserve space for ads) som skjuts in utan reserverad plats.
• Webbtypsnitt som byts ut sent och ändrar textens storlek.
• Innehåll som injiceras dynamiskt högt upp på sidan efter laddning.

Så förbättrar du CLS:

• Ange alltid width och height, eller aspect-ratio, på bilder och videor.
• Reservera plats för annonser i förväg så att de inte knuffar innehåll.
• Förladda typsnitt och använd font-display: optional eller swap medvetet.
• Undvik att lägga in nytt innehåll ovanför det besökaren redan tittar på.

Varför måtten spelar roll för ranking och besökare

Ja, Core Web Vitals påverkar rankningen, men effekten är mindre än många befarar: måtten är enligt Google en av flera kvalitetssignaler (quality signals) i bedömningen av sidupplevelsen och inte en huvudfaktor, och relevant innehåll väger fortfarande tyngst. Det realistiska sättet att se det är som tungan på vågen: när två sidor är likvärdiga i innehåll kan bättre värden ge ett litet övertag, vilket gör måtten till en pusselbit i en bredare innehållsstrategi.

Den andra och ofta viktigare anledningen handlar inte om Google alls, utan om dina besökare och dina kunder (customers):

• Snabba och stabila sidor håller kvar besökare längre och sänker andelen som lämnar direkt.
• En bättre upplevelse (better user experiences) hjälper konverteringen oavsett vad Google gör med signalen.
• En sajt som lever på att förvandla besökare till kunder tjänar på upplevelsen i sig.
• Effekten gäller lika mycket för en butik som för en sajt med nyheter (News) eller en community.

Hur måtten landar i dina nyckeltal

Poängen med bättre värden är inte färgen i ett verktyg, utan vad den färgen speglar: en sida som känns bra att använda. De här sambanden brukar synas i praktiken:

• Lägre LCP gör att fler hinner se huvudinnehållet innan de tröttnar och lämnar.
• Lägre INP gör att formulär, filter och knappar känns direkta i stället för tröga.
• Lägre CLS gör att besökare slipper trycka fel när annonser eller bilder laddar.
• Bättre upplevelse stöttar konvertering, vilket i sin tur stärker dina egna KPIs.

Snabb på desktop men rött på mobil

Det är ett av de vanligaste klagomålen, och förklaringen är nästan alltid datakällan. Din egen dator har snabb processor och fast bredband, men fältdatan väger in besökare på äldre mobiler och svajigt mobilnät, och det är deras upplevelse som avgör betyget. En lokal aktör som ofta möter kunder på mobilnät bör därför titta på just fältdatan, till exempel inom SEO i Stockholm. Testa alltid i PageSpeed Insights mobilläge och titta på fältdatan, inte bara på den snabba siffran du själv ser.

Så mäter du Core Web Vitals i praktiken

Du behöver inga betalverktyg för att komma igång, och de flesta gratisalternativ (Free Tools) bygger ofta på samma öppna data och pagespeed-bibliotek under huven. Gör så här i ordning:

1. Öppna PageSpeed Insights och klistra in din URL för att se både fält- och labbdata.
2. Logga in i Google Search Console och öppna rapporten för en samlad bild av alla sidor.
3. Gruppera de sidor som är röda eller gula och börja med de mest besökta.
4. Använd fliken Performance i Chrome (Lighthouse) för att felsöka en enskild sida på djupet.
5. Mät om efter varje ändring, men ge fältdatan några veckor att hinna uppdateras.

För större sajter crawlar Screaming Frog hela domänen och pekar ut sidmallar med problem, vilket är effektivare än att kontrollera sida för sida.

Verktyg och vad de är bra på

Tänk på dem som olika linser på samma data: vissa visar fält, andra labb, och några sveper över hela sajten på en gång.

• PageSpeed Insights (and PageSpeed Insights): snabbast för en enskild URL, visar både fält och labb.
• Google Search Console: samlad statusöversikt för alla sidor på din domän.
• Chrome (Lighthouse): djup felsökning av en sida med labbdata.
• Screaming Frog: crawlar hela domänen och pekar ut problematiska sidmallar.

Fältverktyg och labbverktyg

• Fältverktyg läser hur real users experience sidan över tid, via CrUX.
• Labbverktyg analyzes (analyzes) ett enskilt testkörningstillfälle i en kontrollerad miljö.
• Fältet ger sanningen om upplevelsen, labbet ger reproducerbar diagnos.
• Använd båda parallellt: fältet pekar ut problemet, labbet hjälper dig hitta orsaken.

Vad du bör göra först

Den här startordningen ger mest effekt för minst arbete:

• Hitta sidans LCP-element och se till att det laddar snabbt.
• Komprimera de tyngsta bilderna och servera moderna format.
• Ge alla bilder och inbäddningar fasta mått så att CLS sjunker.
• Skjut upp tunga eller icke-kritiska JavaScript-skript.
• Lägg de mest besökta sidorna först, eftersom de väger tyngst i fält.

En åtgärdsordning per mått

Den här ordningen löser de vanligaste problemen utan att du behöver vara utvecklare:

• Börja med LCP: komprimera hjältebilden och prioritera den i hämtningen.
• Fortsätt med CLS: ge bilder, annonser och inbäddningar reserverad plats.
• Avsluta med INP: skär ner och skjut upp tung JavaScript på sidan.
• Mät om i fält efter varje steg innan du går vidare till nästa mått.

Vanliga missförstånd om Core Web Vitals

Det första många tror är att Core Web Vitals bara är ett annat ord för sidhastighet, men det stämmer inte: INP mäter responsivitet och CLS mäter visuell stabilitet, två saker som en ren hastighetsmätning missar helt. En sida kan ladda blixtsnabbt och ändå få underkänt på INP om den hackar vid interaktion. Ett annat vanligt misstag är att stirra sig blind på Lighthouse-poängen, för det är fältdatan från riktiga besökare som Google väger in. Måtten är inte heller huggna i sten: Google har redan bytt ut FID mot INP, så det lönar sig att följa hur de utvecklas i community och dokumentation.

De vanligaste myterna

Här är de missförstånd som oftast leder fel, samlade så att du snabbt kan stryka dem från din lista:

• “Core Web Vitals är samma sak som sidhastighet.” Nej, INP och CLS mäter annat.
• “En hög Lighthouse-poäng räcker.” Det är fältdatan som Google rankar på.
• “Snabb på desktop betyder snabb överallt.” Mobilfältet avgör betyget.
• “Måtten ändras aldrig.” FID byttes mot INP, så de utvecklas över tid.
• “Bra värden garanterar topplacering.” Det är en av flera kvalitetssignaler.

Plattformsspecifika fällor i WordPress

För dig som kör WordPress finns ofta de största vinsterna i temat (theme) och i plugin-floran snarare än i någon enstaka rad CSS, eftersom ett tungt tema ensamt kan dra ner alla tre måtten:

• WordPress-teman som lastar in tunga skript och sliders på varje sida.
• Plugin som dubblerar bibliotek eller laddar fonter i onödan.
• Tredjepartsbäddningar som ignorerar din reserverade plats.
• Saknad bildoptimering i mediabiblioteket.

Mät om innan du firar

Ge CrUX några veckor på sig och kontrollera sedan om i Search Console innan du drar slutsatsen att en sidmall är åtgärdad.

Core Web Vitals belönar inte den snabbaste sidan i ett labb, utan den sida som känns bra för flest riktiga besökare, så bygg för dem och låt siffrorna följa med.

Hela poängen är att flytta sidan från rött till grönt där det räknas, alltså i fält. Vill du jämföra dig med dem du tävlar mot är upplevelsen dessutom något du kan väga in i en konkurrentanalys, eftersom långsamma rivaler ofta lämnar ett tydligt fönster öppet.