Core Web Vitals förklarade: LCP, INP och CLS — och vad som faktiskt räknas

Svar-först: Google räknar det som bra att LCP sker "within the first 2.5 seconds of the page starting to load", att ha "an INP of less than 200 milliseconds" och "a CLS score of less than 0.1" (Google Search Central). web.dev beskriver vad måtten fångar: LCP "measures loading performance", INP "measures interactivity" och CLS "measures visual stability" (web.dev, Web Vitals).

Måtten handlar alltså inte om abstrakta tekniska poäng utan om tre saker en besökare känner igen: att sidans huvudinnehåll visar sig, att den svarar när man klickar, och att den inte hoppar till precis när man ska trycka. Den här guiden går igenom vad varje mått mäter, hur du mäter dina egna värden — och hur mycket de egentligen väger.

Vad mäter LCP, INP och CLS — och var går tröskeln?

Trösklarna bedöms vid den 75:e percentilen av sidrenderingarna, med mobil och dator mätta separat (web.dev, Web Vitals). Det är alltså inte alla besök som ska klara tröskeln — utan den typiska upplevelsen för tre av fyra. En enstaka långsam besökare drar inte ner måttet; en systematiskt långsam sida gör det.

Varför räknas INP i stället för FID?

FID var med när måttsättningen byggdes, men är numera ersatt: "This is exactly what happened to FID as INP became a stable Core Web Vital metric in 2024" (web.dev, Web Vitals). För din del betyder det att interaktiviteten numera bedöms med INP — och att tröskeln du ska jaga är 200 millisekunder, inte ett FID-värde från en gammal rapport.

Hittar du gamla rapporter eller dashboards som pratar FID är slutsatsen enkel: måttet har bytts ut, och jämförelsen ska ske mot INP-tröskeln. Interaktivitet handlar i praktiken om det besökaren känner direkt: knappen som inte ger respons, formuläret som hänger, menyn som inte öppnas. Att den upplevelsen nu mäts är därför goda nyheter för sajter som redan vårdar detaljerna.

Hur mäter du dina egna värden?

Två källor räcker för de flesta:

• CrUX — fältdata. Chrome UX-rapporten samlar in data från verkliga besök, och det är i den formen trösklarna vid 75:e percentilen bygger på (web.dev, Web Vitals). Fältdata visar hur sajten mår i verkligheten — inte i en testmiljö.
• Search Console — per sidgrupp. I GSC ser du hur sajten presterar i Google Search, bekräftar att Google hittar och crawlar den och kan begära omindexering av nytt eller uppdaterat innehåll (Google, About Search Console); där finns även rapportering som grupperar sidorna efter Core Web Vitals-nivå.

Hur mycket väger Core Web Vitals för rankningen?

Core Web Vitals används av Googles rankningssystem: "Core Web Vitals are used by our ranking systems. We recommend site owners achieve good Core Web Vitals for success" (Google Search Central, page experience). Men sidupplevelsen är en av många faktorer Google väger in — inte en mirakelkur. Relevansen och hjälpsamheten i innehållet avgör fortfarande om sidan är värd att ranka alls.

Google säger också rakt ut att det inte finns några genvägar till första platsen: "There are no secrets here that'll automatically rank your site first in Google (sorry!)" (Google, SEO Starter Guide). Se därför Core Web Vitals som en kvalifikation, inte ett vapen: goda värden håller dig i matchen, innehållet avgör matchen.

För AI-synligheten är kedjan ännu tydligare: sidan måste vara indexerad för att överhuvudtaget kunna visas i Googles AI-funktioner (Google Search Central), och det är innehållet som citeras — hastigheten ser till att besöket och crawlern inte fastnar. Helheten om att bli en källa i AI-svar finns i Vad är GEO? och i GEO vs SEO.

Vilka symptom och åtgärder hör till vilket mått?

• LCP — sidan känns långsam. Symptom: huvudbilden eller huvudrubriken dröjer. Vanliga orsaker: ooptimerade bilder och tunga teman. Åtgärder: mät vilken bild som är LCP-element, komprimera och dimensionera den — och kontrollera att den inte laddas sent av lazy-loading.
• INP — sidan känns seg. Symptom: klick som inte ger respons, formulär som hänger. Vanliga orsaker: skripttunga tillägg och verktyg som tar över tråden medan besökaren väntar. Åtgärder: skär ner i tredjepartsskript och testa exakt de interaktioner besökaren gör — knapp, meny, kassa.
• CLS — sidan hoppar. Symptom: texten flyttar sig precis när man ska trycka. Vanliga orsaker: bilder och inbäddningar utan reserverad plats, element som skjuts in ovanför det läsaren håller på med. Åtgärder: sätt dimensioner på media och reservera utrymme för sena element.

Var börjar du när alla mått är röda?

Inte med att optimera sida för sida. Arbeta i den ordning som ger störst utdelning per timme:

1. Ta fram underlaget. Från CrUX och Search Console: vilka sidgrupper underpresterar, och på vilket av de tre måtten? Ett rött CLS på mobil och ett grönt LCP är två helt olika projekt.
2. Åtgärda på teman- och CMS-nivå. Bildhantering, temavikt, skript och tillägg gäller för hela sajten. En ändring där flyttar tusen sidor; en ändring i en textmall flyttar en.
3. Mät igen — och repetera. Trösklarna bedöms på fälldata, så effekten av en åtgärd syns först när den når verkliga besökare. Ändra en sak i taget, annars vet du inte vad som flyttade måttet.

Undvik omvänt den klassiska falloran: en långsam sajt som polisheras på enskilda texter i stället för på orsakerna. Orsakerna sitter nästan alltid under innehållet.

Vanliga frågor