Teknisk SEO

Core Web Vitals: mätning och optimering

Core Web Vitals visar hur verkliga användare upplever webbplatsens laddning, responsivitet och visuella stabilitet. De aktuella måtten är Largest Contentful Paint (LCP), Interaction to Next Paint (INP) och Cumulative Layout Shift (CLS).

Hos oss på TribuSoft använder vi fältdata för att hitta de problem som påverkar användarna och labbdata för att hitta deras tekniska orsak. Därefter prioriterar vi åtgärder utifrån sidmall, användarresa, affärsvärde och tekniska beroenden.

Innehåll

Vad är Core Web Vitals?

Core Web Vitals är en avgränsad del av Web Vitals. Måtten fokuserar på tre användarcentrerade egenskaper: hur snabbt sidans huvudsakliga innehåll visas, hur snabbt sidan reagerar på interaktioner och om innehållet flyttar sig oväntat.

Core Web Vitals är en del av ett bredare arbete med sidupplevelse och Teknisk SEO för crawlning, indexering och prestanda. De ersätter inte relevant innehåll, tillgänglighet, fungerande design eller en tydlig användarresa. För oss är målet därför inte att jaga ett visst poängtal, utan att minska friktion för de användare och sidtyper som är viktiga för verksamheten.

FID, First Input Delay, är ett äldre mått som inte längre ingår i Core Web Vitals. INP ersatte FID den 12 mars 2024 och bedömer responsiviteten mer heltäckande under besöket.

LCP, INP och CLS: gränsvärden som gäller

För att en sida ska klara Core Web Vitals-bedömningen behöver samtliga tre mått ligga på nivån Bra vid den 75:e percentilen. Bedömningen görs separat för mobil och dator.

Den 75:e percentilen förklarad

Den 75:e percentilen betyder förenklat att minst tre av fyra sidvisningar ska nå målet eller bättre. Ett genomsnitt räcker alltså inte om en betydande andel användare har en sämre upplevelse.

Detta är en viktig anledning till att kontrollera mobil och dator var för sig. Mobilanvändare kan ha andra nätverk, enheter, skärmstorlekar och beteenden än datoranvändare. En webbplats kan därför ha bra värden på dator men problem på mobil.

Fältdata och labbdata fyller olika funktioner

Fältdata beskriver verkliga användares upplevelser. Den fångar variationer i enheter, nätverk, geografiska platser, cache, sidmallar och faktiska användarresor. Googles Chrome User Experience Report, CrUX, är en aggregerad källa till sådan data.

Labbdata skapas i en kontrollerad testmiljö. Den är särskilt användbar när ett problem ska reproduceras, när en resurs behöver identifieras eller när en föreslagen förändring ska utvärderas innan den släpps.

Vi ser inte fältdata och labbdata som konkurrerande facit. Fältdata svarar på om verkliga användare har ett problem. Labbdata hjälper oss att hitta flaskhalsen och kvalitetssäkra lösningen. Båda behövs i ett effektivt Core Web Vitals-arbete.

Varför skiljer sig resultaten mellan verktygen?

PageSpeed Insights visar både fältdata från CrUX och ett Lighthouse-test i samma vy. Fältdata omfattar de föregående 28 dagarna, medan Lighthouse-resultatet visar ett aktuellt test under specifika simulerade förhållanden. Ett lågt Lighthouse-poängtal innebär därför inte automatiskt att sidan misslyckas med Core Web Vitals i fältdata.

Search Console grupperar URL:er som bedöms ha liknande upplevelse. Ett rapporterat problem bör därför kontrolleras på flera representativa URL:er och sidmallar. Chrome DevTools Performance-panel hjälper sedan till att analysera lokala laddningar, interaktioner, långa JavaScript-uppgifter och layoutskiften.

En URL kan sakna egen fältdata om den har för låg trafik eller inte uppfyller kraven för CrUX-data. Då kan PageSpeed Insights i stället visa data för hela webbplatsens origin. Det är en övergripande signal, inte ett bevis på att just den testade URL:en har samma prestanda.

När behövs egen RUM?

Real User Monitoring, RUM, innebär att ni samlar in prestandadata från er egen webbplats. Det blir särskilt värdefullt när CrUX-data saknas, när ni behöver analysera specifika marknader eller när ni vill jämföra mallar, releaseversioner, enheter och användarsegment.

Med egen RUM kan vi koppla måtten närmare er tekniska miljö och era prioriterade flöden. Det kan exempelvis gälla produktlistor, produktsidor, filtrering, varukorgar, formulär eller B2B-landningssidor. Det officiella web-vitals-biblioteket kan användas för insamling i webbläsaren.

LCP: gör sidans huvudinnehåll tillgängligt snabbt

LCP mäter tiden tills det största kvalificerade bild- eller textinnehållet i den synliga delen av sidan har renderats. Elementet kan vara en herobild, en produktbild, en rubrik eller ett större textblock. Det kan också skilja sig mellan mobil och dator.

Vi delar normalt upp LCP i fyra delar: serverns första svarstid, fördröjningen innan LCP-resursen börjar laddas, själva resursens laddningstid och fördröjningen innan elementet kan renderas. Det gör att vi kan skilja en långsam serverrespons från exempelvis en sent upptäckt bild eller blockering i frontend.

Bildoptimering påverkar både LCP och CLS

Bilder påverkar ofta både hur snabbt huvudinnehållet visas och om sidan flyttar sig under laddning. Rätt format, responsiva bildvarianter, korrekta dimensioner och lämplig laddningsstrategi behöver fungera tillsammans.

För fördjupning kring bilder, format, dimensioner och bildkontext kan ni läsa vidare om Bild-SEO för synlighet och prestanda. På den här sidan fokuserar vi på hur bilderna påverkar Core Web Vitals-måtten.

INP: förbättra responsen vid interaktioner

INP mäter hur snabbt sidan reagerar när användaren klickar, trycker eller använder tangentbordet. Måttet tittar på kvalificerade interaktioner under hela sidbesöket och representerar normalt den långsammaste eller nära den långsammaste interaktionen.

Ett INP-problem kan uppstå i tre steg. Input delay är väntan innan händelsehanteringen får börja. Bearbetningstid är arbetet som utförs i hanteraren. Presentation delay är väntan innan webbläsaren kan visa nästa bildruta. Vi behöver identifiera vilket steg som är flaskhalsen innan vi väljer åtgärd.

TBT är diagnostik, inte samma sak som INP

Lighthouse rapporterar bland annat Total Blocking Time, TBT. Måttet kan ge en användbar signal om JavaScript-belastning under laddning, men det är inte samma sak som INP. En bra TBT garanterar inte bra responsivitet senare i användarresan.

För att felsöka INP behöver vi därför ofta genomföra verkliga eller manuellt simulerade interaktioner. DevTools Performance-panel kan visa långa uppgifter, händelsehantering, rendering och layout i anslutning till en specifik interaktion.

CLS: förhindra oväntade layoutskiften

CLS mäter omfattningen av oväntade förflyttningar av synligt innehåll. Det är ett poängvärde, inte en tid. Layoutskiften skapar ofta konkret friktion när användaren försöker läsa, klicka eller fylla i ett formulär och innehållet flyttar sig.

Ett kort labbtest kan missa CLS-problem som uppstår senare under besöket. Fältdata kan bland annat fånga skiften från annonser, samtyckesgränssnitt, dynamiska komponenter och innehåll som laddas vid scrollning.

Så prioriterar vi Core Web Vitals-arbetet

Vi börjar inte automatiskt med startsidan eller med den URL som har sämst enskilt labbresultat. Vi segmenterar först fältdata efter enhet, sidgrupp, mall och användarresa. Sedan väger vi problemets omfattning mot trafik, affärsvärde, teknisk insats, beroenden och risken att en förändring skadar funktion eller konvertering.

En gemensam åtgärd i en mall kan förbättra upplevelsen på många URL:er. Därför är produkt- och kategorimallar, formulärflöden och viktiga landningssidor ofta mer relevanta än en enskild sida med låg trafik. Exakt prioritering beror dock på webbplatsens struktur och mål.

Core Web Vitals är en viktig del av Teknisk SEO för crawlning, indexering och prestanda. Det bredare tekniska arbetet omfattar fler områden, medan denna sida fokuserar på de användarcentrerade prestandamåtten och hur de mäts.

Vårt arbetsflöde från baslinje till uppföljning

Core Web Vitals, SEO och affärsnytta

Bra Core Web Vitals kan bidra till en bättre sidupplevelse och ingår i Googles bredare system för att bedöma kvalitet i sökresultaten. Måtten är däremot inte en ensam eller dominerande garanti för högre ranking. Relevant och hjälpsamt innehåll är fortfarande avgörande.

En smidigare teknisk upplevelse kan minska friktion i viktiga flöden. Den garanterar ändå inte en viss ökning av konvertering, trafik eller omsättning. Utfallet påverkas av målgrupp, erbjudande, innehåll, design, konkurrens och vilka förändringar som genomförs samtidigt.

Ett Lighthouse-resultat på 100 är därför sällan det rätta affärsmålet. Vi fokuserar på stabilt bra fältvärden för relevanta användare och på förändringar som fungerar tillsammans med innehåll, tillgänglighet och konvertering.

Single-page applications och mjuka navigeringar

I single-page applications sker inte alltid en traditionell sidladdning när användaren byter vy. Mätning av så kallade soft navigations utvecklas och stöds i vissa tekniska miljöer, webbläsare och verktyg. Vi anpassar därför mätningen efter hur webbplatsen faktiskt fungerar, i stället för att anta att alla användarresor fångas på samma sätt.

När är det läge att ta in hjälp?

Extern hjälp är ofta motiverad när Search Console visar återkommande problem, när olika verktyg ger svårtolkade resultat eller när interna team saknar tid att både analysera och implementera förändringar. Det gäller också inför större lanseringar, redesign och plattformsbyten.

På TribuSoft kan vi arbeta från analys och mätstrategi till utveckling, teknisk SEO och driftrelaterade förbättringar. Det minskar risken att en PageSpeed-rapport blir en lista utan ägare. Insatsen anpassas efter er plattform, era sidmallar och era affärsmål.

Vanliga frågor

Vilka Core Web Vitals gäller nu?

De aktuella Core Web Vitals-måtten är LCP, INP och CLS. INP ersatte det äldre måttet FID den 12 mars 2024.

Måste alla tre Core Web Vitals vara bra?

Ja. För att klara den samlade bedömningen behöver LCP, INP och CLS vara på nivån Bra vid den 75:e percentilen. Mobil och dator bedöms separat.

Varför skiljer sig Search Console från PageSpeed Insights?

Search Console grupperar URL:er med liknande upplevelse och bygger på fältdata. PageSpeed Insights visar både fältdata och ett enskilt Lighthouse-test. Skillnader är vanliga och behöver tolkas utifrån datakälla, tidsperiod, enhet och sidgrupp.

Varför saknar min URL fältdata i PageSpeed Insights?

URL:en kan ha för lite kvalificerad trafik eller sakna tillräcklig offentlig upptäckbarhet för egen CrUX-data. Då kan verktyget visa origin-data för hela webbplatsen, vilket inte automatiskt beskriver just den URL:en.

Ska den största bilden lazy-loadas för bättre LCP?

Normalt inte om bilden sannolikt är LCP-elementet i första vyn. Lazy loading kan fördröja resursens start och försämra LCP. Kontrollera alltid vilket element som faktiskt är LCP på respektive enhet.

Behöver vi ett Lighthouse-poäng på 100?

Nej. Ett perfekt Lighthouse-poäng är inte samma sak som bra Core Web Vitals för verkliga användare. Prioritera stabila fältvärden och förbättringar som inte försämrar funktion, tillgänglighet eller konvertering.

Kan bättre Core Web Vitals garantera högre ranking eller konvertering?

Nej. Bra Core Web Vitals kan stödja användarupplevelse och ingår i Googles bredare bedömning av sidupplevelse, men de garanterar varken ranking, trafik, konvertering eller omsättning.

Kontakt

Få hjälp att mäta och förbättra Core Web Vitals

Vill ni veta vilka sidmallar, enheter och användarresor som har störst prestandaproblem? Vi hjälper er att gå från fältdata och teknisk diagnos till prioriterade förbättringar och kvalitetssäkrad implementation.

Kontakta oss på TribuSoft för en kostnadsfri offert eller för att inleda en dialog om företagets tillväxt.

Bli kontaktad