Core Web Vitals 2026: Vad du behöver veta för din Google-ranking

Vad är Core Web Vitals?

Core Web Vitals är en uppsättning specifika mätvärden som Google använder för att mäta den faktiska användarupplevelsen på en webbsida. De fokuserar på tre aspekter av laddnings- och interaktionsupplevelsen som forskning har visat är allra viktigast för användarna: hur snabbt huvudinnehållet laddas, hur snabbt sidan svarar på användarens interaktioner och hur visuellt stabil sidan är under inläsningen.

Google gjorde Core Web Vitals till en officiell rankningssignal 2021. Det som gör detta betydelsefullt är att data kommer från verkliga Chrome-användare - inte från kontrollerade laboratorieförhållanden. Google samlar in fältdata via Chrome User Experience Report (CrUX) och använder ett rullande fönster på 28 dagar. Det innebär att de förbättringar du gör idag kan ta upp till en månad innan de fullt ut syns i dina rankningssignaler.

I mars 2024 ersatte Google First Input Delay (FID) med Interaction to Next Paint (INP) som mätvärde för interaktivitet. FID mätte enbart fördröjningen för den allra första interaktion en användare gjorde med en sida. INP mäter alla interaktioner under hela sidans livscykel - varje klick, tryck och tangenttryckning, och hur snabbt sidan visuellt svarar på var och en av dem. Det gör INP till ett betydligt mer representativt mått på hur responsiv din sida känns.

LCP - Largest Contentful Paint

LCP mäter hur lång tid det tar för det största synliga innehållselementet på sidan att laddas in helt. Det är vanligtvis en hjältebild, en stor rubrik eller en banner. Google anser att ett LCP under 2.5 sekunder är bra, 2.5-4.0 sekunder behöver förbättras och över 4.0 sekunder är dåligt.

Varför spelar detta roll? Forskning visar gång på gång att användare överger sidor som tar för lång tid att ladda. En förbättring av laddningstiden med en sekund kan öka konverteringarna med 7-12%. LCP-måttet försöker fånga ögonblicket då användaren upplever att sidan har "kommit fram" - när huvudinnehållet är synligt.

De vanligaste orsakerna till dåligt LCP är långsamma svarstider från servern, stora okomprimerade bilder, renderingsblockerande JavaScript och CSS som laddas i dokumentets head, samt avsaknad av ett innehållsleveransnätverk (CDN) som levererar resurser närmare användarna.

För att förbättra LCP är de mest verkningsfulla åtgärderna oftast: att använda moderna bildformat som WebP eller AVIF i stället för JPEG eller PNG (vanligtvis 30-50% mindre filer), att lägga till explicita preload-hintar för ditt LCP-element så att webbläsaren hämtar det så tidigt som möjligt, att minska serverns svarstid (TTFB) genom att aktivera cachning och använda ett CDN, samt att skjuta upp all JavaScript som inte behöver köras innan sidan blir synlig.

INP - Interaction to Next Paint

INP mäter hur responsiv en sida är på användarens interaktioner. Mer specifikt mäter det tiden från att en användare gör en inmatning (klick, tryck eller tangenttryckning) till nästa gång webbläsaren ritar upp skärmen för att visa det visuella resultatet av interaktionen. Google anser att ett INP under 200 millisekunder är bra, 200-500ms behöver förbättras och över 500ms är dåligt.

Höga INP-värden ger känslan av en trög och oresponsiv sida. När du klickar på en knapp och ingenting tycks hända på en halv sekund är det dåligt INP. Detta är särskilt problematiskt för interaktiva applikationer - sådant som rullgardinsmenyer, filterkontroller, dragspel, formulärvalidering och alla JavaScript-tunga gränssnitt.

Den främsta orsaken till högt INP är långa uppgifter på webbläsarens huvudtråd. JavaScript är enkeltrådat, vilket innebär att om en uppgift tar lång tid att köra kan webbläsaren inte hantera någon användarinmatning eller rendera några uppdateringar förrän den är klar. Uppgifter som tar längre tid än 50 millisekunder räknas som "långa uppgifter" och är de största bovarna.

För att förbättra INP bör du fokusera på att identifiera och dela upp långa JavaScript-uppgifter. Använd webbläsarens utvecklarverktyg för att hitta uppgifter som blockerar huvudtråden. Skjut upp icke-kritiskt arbete med tekniker som setTimeout eller requestIdleCallback. Minimera påverkan från tredjepartsskript - varje analysverktyg, chattwidget och annonsnätverk du lägger till kör JavaScript som konkurrerar om tid på huvudtråden. Överväg att ladda dessa skript fördröjt tills efter att sidan har blivit interaktiv.

CLS - Cumulative Layout Shift

CLS mäter visuell stabilitet - hur mycket sidans layout oväntat förskjuts under inläsningen. Om du någonsin varit på väg att klicka på något och sidan plötsligt hoppar till så att du av misstag klickar på något annat, då har du upplevt ett högt CLS. Google anser att ett CLS under 0.1 är bra, 0.1-0.25 behöver förbättras och över 0.25 är dåligt.

De vanligaste orsakerna till layoutförskjutningar är bilder och inbäddade videor utan angivna dimensioner (webbläsaren vet inte hur mycket plats som ska reserveras förrän filen laddats), annonser och inbäddningar som expanderar efter inläsning, samt dynamiskt injicerat innehåll som trycker ner annat innehåll.

Lösningen är oftast okomplicerad: ange alltid attribut för width och height på bild- och videoelement. För responsiva bilder använder du i stället CSS aspect-ratio. För annonser och inbäddningar reserverar du deras minsta förväntade storlek med CSS innan de laddas. För webbtypsnitt använder du font-display: swap för att förhindra osynlig text, men kombinera det med preloading av typsnittet för att minimera den layoutförskjutning som uppstår när det anpassade typsnittet ersätter reservtypsnittet.

Varför fältdata skiljer sig från labbdata

En vanlig källa till förvirring är varför Lighthouse-poäng och data i Search Console visar så olika resultat. Lighthouse är ett labbverktyg - det körs i en kontrollerad miljö på en simulerad enhet med simulerade nätverksförhållanden. Fältdata i Search Console kommer från verkliga Chrome-användare med alla sina webbläsartillägg, varierande enhetsprestanda och verkliga nätverksförhållanden.

Dina målgruppsanvändare kan till största delen befinna sig på mobila enheter med långsammare processorer och mobilanslutningar. Din Lighthouse-poäng, uppmätt på en snabb stationär anslutning, återspeglar inte deras upplevelse. Titta alltid på Core Web Vitals-data i Search Console - filtrerad efter enhetstyp - för att förstå vad verkliga användare upplever.

Vanliga frågor

Hur mycket påverkar Core Web Vitals min Google-rankning? Google beskriver det som en "tiebreaker"-signal. När innehållets kvalitet och relevans i övrigt är likvärdiga kan bättre Core Web Vitals ge dig ett övertag. För konkurrensutsatta sökord kan det göra en påtaglig skillnad.

Min Lighthouse-poäng är 90+ men Search Console visar dålig fältdata. Vad är det som händer? Verkliga användare har långsammare enheter, tillägg som förbrukar processorkraft och verkliga nätverksförhållanden. Din labbpoäng mäter ett bästa tänkbara scenario. Prioritera att åtgärda de problem i fältdata som verkliga användare upplever.

Påverkar mitt JavaScript-ramverk Core Web Vitals? Ja, i hög grad. Ensidesapplikationer byggda med ramverk som React eller Angular gör ofta all sin rendering i JavaScript, vilket fördröjer LCP (sidan är tom tills JS har laddats och körts). Server-side rendering (SSR) eller statisk webbplatsgenerering (SSG) ger vanligtvis betydligt bättre LCP-poäng.

Hur lång tid tar det innan förbättringar syns i rankningen? Google samlar in fältdata över ett rullande fönster på 28 dagar. Förbättringar kan börja synas i Search Console inom 2-4 veckor. Förändringar i rankningen släpar vanligtvis efter med ytterligare 2-4 veckor.

Är det värt att optimera Core Web Vitals för min lilla webbplats? Ja - inte bara för rankningen utan för användarupplevelsen. Snabbare och mer responsiva webbplatser har högre konverteringsgrad, lägre avvisningsfrekvens och nöjdare användare, oavsett vad det innebär för SEO.