Core Web Vitals guide

Core Web Vitals är tre mätvärden som Google använder för att bedöma hur snabb och stabil din webbplats är: LCP (laddning av största elementet), INP (interaktivitet) och CLS (visuell stabilitet). Bra värden ger bättre ranking och högre konvertering. Mät med fältdata, inte bara labbtest.

1) Mät rätt först

Första steget är att skilja på fältdata och labbdata. Fältdata kommer från Chrome User Experience Report (CrUX) och visar hur riktiga besökare har upplevt sidan under de senaste 28 dagarna. Labbdata kommer från verktyg som Lighthouse och visar hur sidan beter sig i en simulerad miljö. Google bedömer din webbplats på fältdata, så det är där du ska börja.

• Field data (CrUX) visar verklig prestanda.
• Lighthouse är labbdata, bra för debug.
• Följ upp på mall-sidor, inte bara startsidan.

Öppna rapporten Core Web Vitals i Search Console för att se vilka sidgrupper som klarar sig och vilka som är underkända. Kör sedan PageSpeed Insights på en representativ sida per mall, till exempel en tjänstesida, en artikel och startsidan. Där får du CrUX-data och en Lighthouse-analys i samma vy.

Gränsvärdena mäts vid den 75:e percentilen, alltså den upplevelse som minst tre av fyra besökare får. Att sidan är snabb ibland räcker inte.

2) LCP - största innehållet

Largest Contentful Paint mäter tiden från att sidan börjar laddas tills det största synliga elementet är på plats, oftast hero-bilden eller huvudrubriken. Det är måttet på hur snabb sidan känns vid första intrycket.

De vanligaste orsakerna till dålig LCP är långsam serverrespons, render-blockerande CSS och JavaScript samt tunga bilder som laddas utan prioritet. Så angriper du dem:

• Optimera hero-bilder (format, dimensioner).
• Fetchpriority på LCP-bilden.
• Critical CSS för första vyn.
• Servera bilder i WebP eller AVIF i rätt storlek för skärmen.
• Korta serverns svarstid med cachning och snabbt webbhotell.
• Lazy-loada aldrig LCP-bilden, den ska laddas direkt.

3) INP - interaktivitet

Interaction to Next Paint ersatte FID som Core Web Vital i mars 2024. INP mäter tiden från att besökaren klickar, trycker eller skriver tills skärmen reagerar, och sidan bedöms på sina långsammaste interaktioner. En meny som öppnas trögt eller ett formulär som hakar upp sig drar alltså ner hela betyget.

• Minska JS och tredjepartsskript.
• Defer/async rätt.
• Undvik långa main-thread tasks.

Börja med att inventera tredjepartsskripten. Chattwidgets, spårningspixlar och externa fonter kostar ofta mer än den egna koden. Ta bort det som inte används, ladda resten med defer och dela upp tunga beräkningar i mindre delar. I Performance-fliken i Chrome DevTools ser du exakt vilka tasks som blockerar main thread.

4) CLS - layoutstabilitet

Cumulative Layout Shift mäter hur mycket innehållet flyttar sig medan sidan laddas. Varje gång en bild, banner eller font knuffar ner texten registreras ett skift, och summan blir din CLS-poäng. Det är måttet bakom irritationen när du ska klicka på en knapp och träffar något annat.

• Width/height på alla bilder och video.
• Reservera plats för banners och formulär.
• Undvik att injecta element ovanför content.

Webbfonter är en vanlig bov. När fonten byts efter laddning ändras textens mått och allt hoppar till. Förladda de viktigaste fontfilerna och använd font-display swap med en fallback som liknar originalet. Cookiebanners och kampanjrutor ska ha en fast yta reserverad från start i stället för att trycka ner sidan när de dyker upp.

Arbetsgång som fungerar i praktiken

1. Öppna Core Web Vitals-rapporten i Search Console och notera vilka sidgrupper som är underkända.
2. Kör PageSpeed Insights på en sida per mall och identifiera det största problemet.
3. Åtgärda en sak i taget, störst effekt först, och verifiera i Lighthouse.
4. Vänta in fältdatan. CrUX bygger på ett rullande 28-dagarsfönster, så full effekt syns först efter ungefär en månad.
5. Bevaka att nya releaser inte försämrar värdena, till exempel med ett återkommande Lighthouse-test.

Vanliga misstag

• Att optimera bara i Lighthouse.
• För stora hero-bilder utan dimensioner.
• För mycket tredjeparts-js.
• Att jaga 100 poäng i labbtest i stället för godkänd fältdata.
• Att bara mäta startsidan när trafiken landar på undersidor.
• Att glömma mobilen, där de flesta underkända värden finns.

Sitter problemet i koden eller på servern? Vi felsöker och åtgärdar båda delarna, läs mer om support och felsökning eller webbhotell och drift.