Core Web Vitals förklarat: LCP, INP och CLS på ren svenska

Core Web Vitals är inte ett personlighetstest för din webbplats

Core Web Vitals behandlas ofta som ett mystiskt betygskort. En sida får en röd siffra, någon postar en skärmbild i Slack och teamet börjar bråka om JavaScript-ramverk.

Det är inte särskilt användbart.

Ett bättre sätt att tänka på Core Web Vitals är enklare: de är tre mätningar av om en sida känns användbar för en verklig person på en verklig enhet. De fångar inte varje aspekt av prestanda, tillgänglighet eller kvalitet. Men de fångar tre vanliga källor till frustration:

• Huvudinnehållet tar för lång tid att visas.
• Sidan reagerar långsamt när användaren försöker göra något.
• Layouten hoppar runt medan användaren läser eller trycker.

Detta är de tre Core Web Vitals: LCP, INP och CLS.

Google använder dem som en del av sina signaler för sidupplevelse, men SEO-perspektivet är inte det bästa skälet att bry sig. Det bättre skälet är att långsamma, hoppiga och oresponsiva sidor slösar bort användarnas tid. De tenderar också att konvertera sämre, ge sämre stöd och åldras dåligt.

De tre mätvärdena i en mening vardera

Innan vi går in på detaljer kommer här versionen på ren svenska:

• LCP, eller Largest Contentful Paint, mäter hur lång tid det tar för det huvudsakliga synliga innehållet att laddas.
• INP, eller Interaction to Next Paint, mäter hur snabbt sidan svarar på användarinteraktioner under besöket.
• CLS, eller Cumulative Layout Shift, mäter hur mycket sidan oväntat flyttar på sig.

De vanliga tröskelvärdena är:

| Metric | Good | Needs improvement | Poor | |---|---:|---:|---:| | LCP | 2,5 s eller snabbare | 2,5 s–4,0 s | Över 4,0 s | | INP | 200 ms eller snabbare | 200 ms–500 ms | Över 500 ms | | CLS | 0,1 eller lägre | 0,1–0,25 | Över 0,25 |

Dessa siffror utvärderas normalt vid den 75:e percentilen av verkliga användarbesök. Det spelar roll. Du försöker inte skapa en perfekt labbkörning. Du försöker göra upplevelsen bra för de flesta användare, inklusive personer med långsammare telefoner och stökigare nätverk.

Om du stirrar på en automatisk rapport och inte vet var du ska börja hjälper det att skilja diagnos från panik. Vi har en separat guide om hur du läser en Lighthouse-rapport utan att få panik, som beskriver det arbetsflödet mer i detalj.

LCP: när känns sidan laddad?

Largest Contentful Paint mäter renderingstiden för det största synliga innehållselementet i viewporten. I praktiken är det ofta:

• en hero-bild,
• en stor rubrik,
• en utvald artikelbild,
• en produktbild,
• ett stort textblock.

LCP frågar inte när varje script, tracking pixel och bild nedanför viket har laddats klart. Det frågar: när blev det viktigaste som användaren kom för att se synligt?

Det gör LCP till ett mer mänskligt mätvärde än gammaldags ”page load time”. En sida kan tekniskt sett bli färdigladdad sent men ändå kännas snabb om huvudinnehållet visas snabbt. Motsatsen gäller också: en sida kan utlösa load-händelsen medan hero-ytan fortfarande är tom, suddig eller blockerad av en renderingsfördröjning.

Vanliga orsaker till dålig LCP

De flesta dåliga LCP-problem kommer från några förutsägbara ställen:

1. Långsam serversvarstid

Om HTML-dokumentet kommer sent börjar allt annat sent.

1. Renderingsblockerande CSS eller JavaScript

Webbläsaren har innehållet men kan ännu inte måla det.

1. Ooptimerade hero-bilder

Det största elementet är för stort, i fel format, inte prioriterat eller har av misstag lazy-loadats.

1. Web fonts som fördröjer textrendering

En stor rubrik kan vara LCP-elementet, och fontladdning kan fördröja eller visuellt förändra den.

1. Fördröjningar från rendering på klientsidan

Om sidan behöver ett stort JavaScript-paket innan den kan visa meningsfullt innehåll blir LCP lidande.

Så förbättrar du LCP

Börja med det faktiska LCP-elementet. Optimera inte slumpmässiga resurser innan du vet vad webbläsaren mäter.

Praktiska åtgärder är bland annat:

• Leverera HTML snabbt: cachelagra där det passar, minska backend-arbete och undvik långsamma omdirigeringar.
• Optimera LCP-bilden: använd rätt dimensioner, komprimering och format.
• Lazy-loada inte hero-bilden ovanför viket.
• Använd fetchpriority="high" med omsorg för huvudbilden när den verkligen är prioriterad.
• Inlina kritisk CSS endast när det minskar renderingsfördröjningen på ett meningsfullt sätt.
• Minska mängden JavaScript som behövs före den första meningsfulla renderingen.
• Använd font-display: swap eller en annan avsiktlig fontstrategi.

Bilder och fonter är ofta bovarna. För bilder handlar avvägningen inte bara om att ”liten fil är bra”. Formatval, kodningsinsats och webbläsarstöd spelar alla roll, vilket är anledningen till att vi har ett praktiskt beslutsträd för när AVIF slår WebP och när det inte gör det. För typografitunga sidor är web fonts fortfarande en av de enklaste prestandavinsterna eftersom många webbplatser skickar fler fontfiler än de använder.

INP: svarar sidan när man rör vid den?

Interaction to Next Paint mäter responsivitet. Mer specifikt tittar det på fördröjningen mellan en användarinteraktion och nästa visuella uppdatering efter att webbläsaren har behandlat den interaktionen.

Interaktioner omfattar sådant som:

• att klicka på en knapp,
• att trycka på en meny,
• att välja en kryssruta,
• att skriva i ett formulärfält,
• att öppna en accordion.

INP ersatte First Input Delay som en Core Web Vital under 2024. Det var en bra förändring. First Input Delay tittade bara på den första interaktionen. INP är bredare: det tar hänsyn till interaktioner under hela sidbesöket och rapporterar en interaktion med hög latens som sidans responsivitetsvärde.

På ren svenska: INP fångar sidor som ser laddade ut men känns fastfrusna.

Du har förmodligen använt en sådan sida. Den verkar redo. Du trycker på menyn. Ingenting händer på en halv sekund. Du trycker igen. Sedan händer två saker samtidigt. Det är ett INP-problem.

Vanliga orsaker till dålig INP

INP är vanligtvis ett problem på huvudtråden. Webbläsaren vill svara, men JavaScript, renderingsarbete eller layoutberäkning står i vägen.

Typiska orsaker är:

• stora JavaScript-paket,
• dyra event handlers,
• hydrering i appar som renderas på klienten,
• tredjepartsscript som konkurrerar om huvudtråden,
• långkörande tasks efter sidladdning,
• komplexa DOM-uppdateringar som utlöses av små interaktioner,
• layout thrashing, där kod upprepade gånger läser och skriver layoutvärden.

Marknadsföringstaggar, analytics, chattwidgetar och consent banners kan alla bidra. Det betyder inte ”ta bort allt”. Det betyder att varje script på sidan har en kostnad, och interaktionslatens är ofta där den kostnaden blir synlig.

Så förbättrar du INP

Att förbättra INP handlar mindre om ett magiskt attribut och mer om att minska konkurrensen om huvudtråden.

Användbara angreppssätt är bland annat:

• Dela upp långa JavaScript-tasks i mindre delar.
• Skjut upp icke-nödvändigt arbete tills efter att sidan är användbar.
• Ta bort oanvänt JavaScript i stället för att bara minifiera det.
• Håll event handlers små och förutsägbara.
• Undvik att rendera om stora delar av gränssnittet för små tillståndsändringar.
• Använd CSS för enkla visuella tillstånd där det är möjligt.
• Granska tredjepartsscript och ladda dem bara där de behövs.

Titta också på interaktionsdesign. En knapp som ger omedelbar visuell återkoppling kan kännas mer responsiv, även om efterföljande arbete tar längre tid. Det är ingen ersättning för prestanda, men det är en del av bra gränssnittsteknik. Vår checklista för tillgängliga webbknappar överlappar med detta: tydliga tillstånd, korrekt semantik och förutsägbart beteende hjälper både användare och webbläsare.

CLS: stannar sidan där användaren förväntar sig?

Cumulative Layout Shift mäter oväntade förflyttningar av synliga element. Om en användare börjar läsa ett stycke och en annons, bild eller banner laddas ovanför det och trycker ned texten, bidrar det till CLS.

CLS mäts inte i sekunder. Det är en poäng baserad på hur mycket innehåll som flyttades och hur långt det flyttades. Lägre är bättre.

Nyckelordet är oväntat. Layoutförändringar som orsakas av en användaråtgärd räknas vanligtvis inte på samma sätt. Om någon trycker på ”visa mer” och innehåll expanderar är det väntat. Om en nyhetsbrevsbanner dyker upp högst upp efter tre sekunder och trycker ned allt är det inte det.

Vanliga orsaker till dålig CLS

CLS-problem är ofta vardagliga:

• bilder utan width- och height-attribut,
• annonser eller embeds utan reserverat utrymme,
• cookie banners som infogas ovanför innehåll,
• web fonts som byts in med andra mått,
• sent laddade kampanjfält,
• dynamiskt injicerat innehåll nära sidans topp.

Lösningen är vanligtvis att reservera utrymme innan innehållet anländer. Webbläsaren bör känna till sidans form så tidigt som möjligt.

Så förbättrar du CLS

Börja med de synliga förskjutningarna. Titta på en inspelning eller använd webbläsarverktyg för att identifiera vilka element som flyttar sig.

Använd sedan de tråkiga lösningarna:

• Lägg till explicita width- och height-attribut på bilder.
• Använd CSS aspect-ratio för responsiva mediebehållare.
• Reservera fast eller minsta utrymme för annonser, embeds och iframes.
• Undvik att injicera banners ovanför befintligt innehåll efter laddning.
• Välj font-fallbacks med liknande mått som den slutliga fonten.
• Undvik animationer som ändrar layoutegenskaper som top, left, width eller height; föredra transforms.

CLS är ett av få prestandamätvärden där disciplin slår smarta knep. Om sidan har stabila boxar brukar den få bra resultat.

Fältdata och labbdata är båda användbara, men de svarar på olika frågor

En vanlig källa till förvirring är att olika verktyg visar olika siffror. Det är normalt.

Fältdata kommer från verkliga användare. De speglar faktiska enheter, nätverk, platser och webbläsarförhållanden. Googles Chrome User Experience Report är ett exempel på fältdata.

Labbdata kommer från en kontrollerad testmiljö. Lighthouse är det välbekanta exemplet. Det är upprepningsbart och användbart för felsökning, men det är inte samma sak som användarnas upplevda verklighet.

Använd fältdata för att avgöra om användare har ett verkligt problem. Använd labbdata för att återskapa och felsöka det problemet.

Kom också ihåg att Core Web Vitals vanligtvis bedöms per URL eller URL-grupp, inte som en enda abstrakt egenskap hos ditt varumärke. Din startsida, bloggartikel, prissida och checkout kan ha mycket olika flaskhalsar.

En vettig arbetsordning

Om alla tre mätvärdena är dåliga är frestelsen att börja överallt. Motstå den.

En praktisk ordning är:

1. Åtgärda uppenbar CLS först

Saknade bilddimensioner och instabila banners är ofta snabba vinster.

1. Förbättra LCP för viktiga mallar

Fokusera på sidor som spelar roll: produktsidor, landningssidor, artiklar, registreringsflöden.

1. Undersök INP med verkliga interaktioner

Klicka på det som användare faktiskt klickar på. Menyer, filter, formulär och checkout-kontroller avslöjar ofta mer än den inledande laddningsspårningen.

1. Granska tredjepartsscript

Behåll dem som motiverar sin kostnad. Ta bort eller fördröj dem som inte gör det.

1. Sätt en prestandabudget

Utan en budget förfaller prestandaförbättringar. Nya script, bilder och designkomponenter kommer tyst att göra arbetet ogjort.

Den viktiga poängen: optimera inte för ett märke. Optimera för användarresan. En marginell poängförbättring på en sida med låg trafik kan vara mindre viktig än en något ofullkomlig men mycket snabbare checkout-interaktion.

<!-- tool-cta:start -->

💡 Prova detta: Eftersom LCP oftast är ett bildproblem, minska storleken på din hero-resurs med Image Compressor som en första, enkel vinst.

<!-- tool-cta:end -->

Vad Core Web Vitals inte säger dig

Core Web Vitals är användbara, men ofullständiga.

De säger inte om ditt innehåll är bra. De säger inte om din navigering är begriplig. De garanterar inte tillgänglighet. De mäter inte integritet, säkerhet, förtroende, läsbarhet eller om sidan besvarar användarens fråga.

De ersätter inte heller omdöme. En sida kan klara Core Web Vitals och ändå vara obehaglig. En komplex applikation kan missa ett tröskelvärde men ändå vara ansvarsfullt konstruerad utifrån sina begränsningar.

Behandla LCP, INP och CLS som brandvarnare. När de larmar, undersök. När de är tysta, fortsätt underhålla byggnaden.