Core Web Vitals: vad som faktiskt flyttar siffrorna
Core Web Vitals är tre fältmätningar av hur en sida känns: hur lång tid det tar innan huvudinnehållet syns, hur mycket det hoppar under laddning, och hur snabbt sidan svarar på indata.
Den här guiden går igenom vad varje mätvärde mäter, de konkreta orsakerna bakom dåliga värden, och rättningarna som flyttar fältdata istället för bara labbvärden.
Vad de tre mätvärdena mäter#
Var och en har en tröskel för «bra» och en liten uppsättning vanliga orsaker. Notera att siffran som räknas för placering är fältdata från verkliga besökare, inte ett labbvärde från din laptop.
| Mätvärde | Bra | Mäter | Vanlig orsak vid dåligt värde |
|---|---|---|---|
| LCP | Under 2,5 s | Tid tills det största synliga elementet ritats | Ooptimerad huvudbild, långsam server, blockerande CSS |
| CLS | Under 0,1 | Hur mycket layouten hoppar under laddning | Bilder utan mått, inskjutna banners, sent laddade typsnitt |
| INP | Under 200 ms | Svarshastighet vid användarinteraktion | Långa JavaScript-uppgifter som blockerar huvudtråden |
Labbverktyg mäter en laddning på en maskin. Fältdata är 75:e percentilen av verkliga besök, inklusive gamla telefoner på dåliga nät — precis de besökare som lämnar snabbast.
Att rätta LCP#
LCP är nästan alltid en bild eller en rubrik som blockerats av något annat. Gå igenom punkterna i ordning; de två första löser de flesta webbplatser.
- Ta reda på vilket element som faktiskt är LCP-elementet i fältdata. Att optimera fel bild är det vanligaste bortkastade arbetet.
- Ladda aldrig LCP-bilden fördröjt. Ge den istället fetchpriority="high".
- Servera den i modernt format i den storlek den visas, med srcset för mindre skärmar.
- Förladda typsnittet för LCP-texten och använd font-display: swap.
- Ta bort renderingsblockerande CSS och JavaScript ur head; lägg kritisk CSS inline om sidan är liten nog.
- Sänk Time to First Byte med cache och CDN — inget frontendarbete kompenserar en långsam server.
- Skär ner tredjepartsskript på den kritiska vägen. Varje är en DNS-uppslagning, en anslutning och en oförutsägbar fil.
Att rätta CLS#
Hoppande layout går nästan helt att undvika och rättningarna är billiga. Det är också mätvärdet besökare känner starkast — det är det som får folk att trycka på fel sak.
- Sätt width- och height-attribut på varje bild och video så att webbläsaren reserverar plats.
- Reservera plats för annonser, inbäddningar och iframes med en behållare med fast bildförhållande.
- Skjut aldrig in innehåll ovanför befintligt efter laddning — cookiebanners hör hemma längst ned eller som överlägg.
- Anpassa reservtypsnittets mått till webbtypsnittet, eller använd size-adjust, så att bytet inte flyttar om sidan.
- Undvik att animera layoutegenskaper. Animera transform och opacity, som inte tvingar omräkning.
- Ge dynamiskt laddade sektioner en min-height så att de inte expanderar från noll.
Att rätta INP#
INP ersatte First Input Delay och är svårare, eftersom det mäter varje interaktion under besöket istället för bara den första. Dålig INP är nästan alltid för mycket JavaScript på huvudtråden.
| Orsak | Rättning |
|---|---|
| Stort paket som bearbetas vid laddning | Dela upp koden; ladda bara det sidan använder |
| Långa uppgifter över 50 ms | Dela upp arbetet och lämna tillbaka tråden |
| Dyra händelsehanterare | Debounce, och flytta tungt arbete ur interaktionsvägen |
| Tunga tredjepartstaggar | Ladda efter interaktion, eller ta bort — kontrollera vad var och en ger |
| Stor DOM, över 10 000 noder | Virtualisera långa listor; förenkla djup nästling |
| Layoutkamp i hanterare | Gruppera läsningar och skrivningar istället för att växla |
På innehållswebbplatser är den mest värdefulla INP-åtgärden oftast att ta bort JavaScript snarare än att optimera det. Fråga vad varje skript ger; tagghanterare samlar skript ingen minns att de lade till.
Vanliga frågor
Hur mycket påverkar Core Web Vitals placeringen?
De är en verklig men måttlig signal, och fungerar mer som skiljedomare vid oavgjort än som ersättning för relevans. En snabb sida om fel ämne slår inte en långsammare som besvarar frågan. Det starkare skälet att rätta dem är beteende: långsamma och hoppande sidor tappar besökare innan placering ens spelar in.
Varför har jag bra Lighthouse-värde och dålig fältdata?
För att Lighthouse simulerar en laddning på din maskin med din uppkoppling, medan fältdata är 75:e percentilen av verkliga besök — inklusive tre år gamla telefoner på överbelastade mobilnät. När de två motsäger varandra är det fältdata som gäller. Använd labbverktyg för att diagnostisera, inte för att få poäng.
Måste jag rätta alla tre mätvärdena?
Rätta de som fallerar, i ordning efter vad besökarna upplever. CLS är oftast billigast att rätta och mest irriterande för användaren, så det är en bra början. LCP har störst effekt på om folk väntar. INP betyder mest på interaktiva webbplatser och minst på statiska artiklar.
Hur lång tid tar det innan förbättringar syns?
Fältdata är ett rullande fönster på 28 dagar, så meningsfull rörelse tar ungefär fyra veckor efter att rättningen nått alla besökare. Bedöm inte en ändring efter tre dagar. Kontrollera däremot labbvärdena direkt för att bekräfta att rättningen gjorde det du förväntade dig.
core web vitalslcpclsinpsidhastighetwebbprestanda
