Få koll på Googles CrUX-data och Core Web Vitals från Chrome UX Report

Klagar användare på att er webbplats är långsam, men både du och utvecklarna tycker det går snabbt? Det låter som att du behöver titta på Chrome User Experience Report!

Sammanfattning:

CrUX-data visar verklig användarupplevelse. Chrome User Experience Report samlar in data från riktiga Chrome-användare och visar hur de faktiskt upplever din webbplats, till skillnad från syntetiska tester som körs under optimala förhållanden.
Core Web Vitals mäter tre nyckelaspekter: LCP (laddningshastighet), INP (responsivitet vid interaktion) och CLS (visuell stabilitet). Dessa baseras på den 75:e percentilen, alltså gränsen där den sämsta fjärdedelen av upplevelserna börjar.
Med verktyg som CrUX Vis, PageSpeed Insights och Webperf Premium kan du följa din webbplats prestanda över tid och jämföra den med konkurrenter, vilket hjälper både UX-arbete och sökmotoroptimering.

Hoppa till avsnitt:

Chrome User Experience Report
Fokusera inte på de mest lyckosamma!
Vad är Core Web Vitals och hur hänger det ihop med CrUX?
Har du Webperfs Premium? Då finns CrUX-data redan i din instrumentpanel!
- Historisk data per mätvärde

Ingen användare bryr sig egentligen om hur snabb en webbplats är enligt dess utvecklare eller oss ansvariga när vi testar hastigheten. De blir inte heller imponerade av diverse siffror vi gräver fram från syntetiska tester som Google Lighthouse, Sitespeed eller liknande. Däremot bryr de sig om hur bra det funkar när de själva försöker använda webbplatsen. Det är ju då det spelar roll för dem!

För 10 år sedan skrev jag boken Webbanalys och där ironiserade jag över de optimistiska antaganden vi ibland gör om att användare av webbplatser har en lika optimal upplevelse som vi själva. Jag kallade denna anti-persona för Ergonomiska Egon:

”Egon använder bara webben på kontoret, med väl intrimmade datortillbehör han själv nogsamt valt ut. Han har förstås en högupplöst stor skärm med bred betraktningsvinkel och inga fönster som ger blänk i skärmen. Snabb trådad uppkoppling helt utan begränsningar.”

Chrome User Experience Report

Men vet du vad? Inom just hastighet behöver du inte gissa hur andra har det! Du har antagligen lite CrUX-data att använda för att utmana dina egna antaganden och dessa data kan också nyansera de där irriterande diskussionerna när någon påstår hur alla upplever en webbplats. CrUX står för Chrome User Experience Report och är en datakälla på hur användare i realiteten upplever en webbplats.
→ Kolla din egen CrUX-data på CrUX Vis

Ifall du inte hittar din data där kan det bero på att det varit för få besökare så Google inte lyckats samla in tillräckligt med underlag. Du är inte ensam med att sakna data, det finns en handfull svenska kommun-webbar som inte heller lyckats.

Fokusera inte på de mest lyckosamma!

Istället för att fokusera på din egen eller kollegornas upplevelse kan du kolla era CrUX-data. De är relativt öppna och du kanske redan sett dem på PageSpeed Insights under rubriken Upptäck vad de faktiska användarna upplever?

Istället för att utgå från din egen, eller ens den genomsnittliga användarupplevelsen, är det i fallet med CrUX så att användarupplevelsen klassificeras utifrån brytpunkten där fjärdelen med sämst upplevelse börjar. Det kallas för percentil på statistikspråk. Närmare bestämt heter det P75 i det här fallet då det handlar om att vi först efter de 75% mest välfungerande upplevelserna sätter en gräns och plockar fram våra mätvärden.
→ Varför använda den 75:e percentilen för webbprestandamätning? (Webperf, 2025)

P75 är en bra början om man är lite ny på området. Men, att det finns en konferens om P99 är talande för att andra går mycket längre. Närmare bestämt att försöka optimerade så pass mycket att det i vardagen ska märkas för minst 99% av användarnas upplevelse. För de som vägrar avfärda saker som edge cases är det här inget konstigt. De har säkert redan läst Sara Wachter-Boettchers bok Technically Wrong och hennes samarbete med Eric Meyer med boken Design for Real Life som går att läsa gratis på nätet numera.

“…a design process that vet new features, content, or interaction against less-than-ideal user scenarios”
– Design for Real Life

Samtidigt är det värt att påminna om styrkorna med P75. Det är en lämplig nivå att börja på och då det är vad Google valt för CrUX har det den enorma fördelen att du kan göra efterforskning om hur andra webbplatser klarar sig enligt samma måttstock. När du är varm i kläderna finns inget som stoppar dig från att börja förbättra för den mer olycksaliga fjärdedelen av dina användare. Du som jobbar med att bättra på din omvandlingsgrad inser nog snabbt vilken möjlighet det är att kunna börja konvertera 25% av de befintliga användarna.

Vad är Core Web Vitals och hur hänger det ihop med CrUX?

Core Web Vitals är en uppsättning mätvärden som Google har tagit fram för att mäta hur verkliga användare upplever en webbsida. Fokus ligger på tre grundläggande aspekter av användarupplevelsen, nämligen laddningsprestanda, interaktivitet och visuell stabilitet. Dessa mätvärden bygger på faktisk data från användare som besöker webbplatser, och de data Google har tillgång till via sin webbläsare Chrome på datorer, mobiler och surfplattor.
Det innebär att Google samlat in data om hur snabbt och smidigt en sida faktiskt fungerar i praktiken av verkliga användare när de försökt använda en webbplats. Oavsett om scenariot är enkelt eller svårt.

Att arbeta med dessa mätvärden handlar i grunden om att ta ansvar för besökarnas upplevelse och säkerställa att webbplatsen lever upp till befintliga förväntningar på webbprestanda.

I Core Web Vitals (2026) finns tre mätvärden:

Largest Contentful Paint (LCP)
Interaction to Next Paint (INP)
Cumulative Layout Shift (CLS)

Largest Contentful Paint (LCP)

Largest Contentful Paint fokuserar på upplevd laddningshastighet. Måttet anger tidpunkten då sidans huvudsakliga innehåll sannolikt har laddats färdigt, vilket ger användaren en tydlig signal om att sidan är redo att användas. Ett snabbt LCP bidrar till att besökaren känner förtroende för att webbplatsen fungerar väl.

Genom forskning och diskussioner inom W3C Web Performance Working Group har man kommit fram till att det mest tillförlitliga sättet att mäta när huvudinnehållet har laddats är att titta på när det största elementet har renderats.

Hur elementstorlek bestäms

Storleken på ett element som rapporteras för LCP är vanligtvis den storlek som är synlig för användaren inom visningsytan. Om ett element sträcker sig utanför visningsytan, eller om delar av elementet är klippta eller dolda genom overflow, räknas dessa delar inte med i elementets storlek. För bilder som har skalats från sin ursprungliga storlek rapporteras antingen den synliga storleken eller den ursprungliga storleken, beroende på vilken som är minst. För textelement beaktar LCP den minsta rektangel som kan innehålla alla textnoder. Marginaler, utfyllnad och ramar som applicerats via CSS räknas inte in i storleken.

När rapporteras LCP?

Webbsidor laddas ofta i etapper. Vilket innebär att det största elementet på sidan kan förändras under laddningsprocessen. För att hantera detta skickar webbläsaren en prestandapost av typen largest-contentful-paint så snart den har ritat den första bildrutan, och identifierar då det största innehållselementet. Om det största elementet sedan ändras efter att efterföljande bildrutor har renderats skickas en ny prestandapost.

Webbläsaren slutar rapportera nya poster så snart användaren interagerar med sidan, eftersom användarinteraktion ofta förändrar vad som är synligt. Om det största innehållselementet tas bort från visningsytan eller från dokumentstrukturen förblir det ändå det största elementet såvida inte ett större element renderas.

Vad är ett bra LCP-värde?

För att erbjuda en god användarupplevelse bör webbplatser sträva efter att ha ett LCP på 2,5 sekunder eller mindre. Värden över 4 sekunder betraktas som dåliga och indikerar att användare sannolikt upplever sidan som långsam.

Det är värt att notera att LCP-värdet inkluderar tid för uppkopplingstid, omdirigeringar och andra fördröjningar relaterade till Time To First Byte. Dessa faktorer kan vara betydande och kan leda till skillnader mellan RUM-mätningar och syntetiska mätningar.

Vanliga orsaker till långsamt LCP

Det finns flera faktorer som kan bidra till ett långsamt LCP-värde. Långsamma serversvarstider påverkar direkt hur snabbt innehållet kan börja laddas. Renderingsblockerande resurser som CSS och Javascript kan fördröja när webbläsaren kan börja visa innehåll.
Långsam resursladdning, särskilt för stora bilder som ofta utgör LCP-elementet, är en annan vanlig orsak. Samtidigt kan klientsidans rendering innebära att viktigt innehåll inte visas förrän Javascript har körts.

Att arbeta systematiskt med dessa områden genom att optimera serverkonfiguration, prioritera kritiska resurser, komprimera, dimensionera bilder samt minimera beroenden av klientsidans rendering kan ge betydande förbättringar.
→ Mer om Largest Contentful Paint (web.dev)

Interaction to Next Paint (INP)

Interaction to Next Paint fokuserar på responsivitet. Måttet bedömer hur snabbt en webbsida svarar på användarinteraktioner genom att observera fördröjningen för alla klick, tryck och tangentbordsinmatningar som sker under en användares besök på sidan. Det slutliga INP-värdet representerar den längsta interaktionen som observerats.

Ett lågt INP-värde innebär att sidan konsekvent kunde svara snabbt på alla eller nästan alla användarinteraktioner.

Data från Google Chrome visar att 90 procent av en användares tid på en webbsida spenderas efter att den har laddats färdigt. Därför är det viktigt att mäta responsivitet genom hela sidans livscykel, inte bara under den initiala laddningen. Det är precis detta som INP är utformat för att bedöma.

God responsivitet innebär att en sida svarar snabbt när användaren interagerar med den. När en sida svarar på en interaktion presenterar webbläsaren visuell återkoppling i nästa bildruta som ritas upp. Denna återkoppling talar om för användaren att något händer, exempelvis att en produkt verkligen läggs till i varukorgen, att en mobilnavigering öppnas eller att ett inloggningsformulär bearbetas. Ifall den visuella återkopplingen fördröjs kan användaren få intrycket att sidan inte svarar tillräckligt snabbt, vilket skapar en negativ upplevelse.

Vilka interaktioner mäts

För INP observeras endast vissa typer av interaktioner. Dessa inkluderar klick med mus, tryck på enheter med pekskärm samt tangenttryckningar på fysiska eller virtuella tangentbord. Andra sätt att interagera med sidan, såsom scrollning, hovring eller zoomning, räknas inte in i INP.

Interaktioner sker både i huvuddokumentet och i inbäddade iframes, exempelvis när någon klickar på ”spela” för en inbäddad video. Slutanvändare är vanligtvis inte medvetna om vad som finns i en iframe eller inte, och därför behövs INP-mätningar inom iframes för att ge en rättvisande bild av användarupplevelsen för hela webbsidan.

Vad är ett bra INP-värde?

För att säkerställa en god användarupplevelse bör webbplatser sträva efter att ha ett INP på 200 millisekunder eller mindre. Värden mellan 200 och 500 millisekunder indikerar att sidans responsivitet behöver förbättras. Värden över 500 millisekunder innebär att sidan har dålig responsivitet.

För att säkerställa att de flesta användare får en bra upplevelse rekommenderas att man mäter den 75:e percentilen av sidladdningar, uppdelat på mobila och stationära enheter.
Att sätta etiketter som "bra" eller "dålig" på ett responsivitetsmått är en utmaning. Å ena sidan vill man uppmuntra utvecklingsmetoder som prioriterar god responsivitet. Å andra sidan måste man ta hänsyn till den betydande variationen i kapacitet hos de enheter som människor använder, för att sätta uppnåbara förväntningar.

Varför INP är viktigt

Att arbeta med INP handlar om att ta ansvar för användarens upplevelse av sidans responsivitet. När en sida svarar långsamt på interaktioner kan användare bli frustrerade och klicka upprepade gånger (rage clicks) i tron att något är fel. Detta kan leda till oväntade beteenden när sidan sedan hinner ikapp och bearbetar alla de fördröjda inmatningarna.
→ Mer om Interaction to Next Paint (web.dev)

Cumulative Layout Shift (CLS)

Cumulative Layout Shift fokuserar specifikt på visuell stabilitet. Mätvärdet hjälper till att kvantifiera hur ofta användare upplever oväntade förskjutningar i sidans layout under tiden de interagerar med en webbplats. En låg CLS innebär att sidan beter sig förutsägbart och att innehållet inte hoppar omkring på ett sätt som stör eller förvirrar besökaren.

Oväntade layoutförskjutningar kan påverka användarupplevelsen negativt på flera sätt. En person som läser en artikel kan plötsligt tappa bort sig när texten flyttas. Ännu värre är situationer där någon försöker klicka på en knapp men träffar fel element eftersom layouten oväntat ändrades i samma ögonblick.

I extrema fall kan detta leda till oönskade konsekvenser, exempelvis att en användare av misstag bekräftar en stor beställning som de egentligen tänkte avbryta.

Att arbeta aktivt med CLS handlar därför om att ta ansvar för att besökarna ska kunna lita på att webbsidan fungerar som förväntat.

När uppstår layoutförskjutningar?

Oväntade förflyttningar av sidinnehåll sker ofta när resurser laddas asynkront eller när element läggs till dynamiskt i dokumentstrukturen innan befintligt innehåll har stabiliserats. Vanliga orsaker till layoutförskjutningar är bilder eller videor utan angivna dimensioner, typsnitt som renderas i en annan storlek än det initiala reservtypsnittet, samt tredjepartsannonser eller widgets som dynamiskt ändrar sin storlek.

Ett särskilt problem är att webbplatser ofta beter sig annorlunda i utvecklingsmiljön jämfört med hur verkliga användare senare kommer att uppleva dem. Under utveckling finns bilder ofta redan i webbläsarens cache, vilket gör att de laddas omedelbart. För en besökare som kommer till sidan för första gången tar samma bilder längre tid att hämta, och under den tiden kan layouten förskjutas väsentligt.

På samma sätt kan API-anrop som körs lokalt vara så snabba att eventuella fördröjningar inte märks, medan samma anrop i produktion kan orsaka märkbara förskjutningar.
Personaliserat innehåll och tredjepartskomponenter beter sig också ofta annorlunda i test jämfört med i verkligheten. Denna skillnad mellan utvecklarens upplevelse och användarens faktiska upplevelse gör det extra viktigt att mäta CLS med data från riktiga besökare.

Hur beräknas CLS?

CLS mäter den största samlade layoutförskjutningen som sker under sidans livscykel. Tekniskt sett identifieras så kallade sessionsfönster, vilket är serier av förskjutningar som sker i snabb följd med mindre än en sekund mellan varje och en maximal total längd på fem sekunder. CLS-värdet utgörs av den högsta sammanlagda poängen inom ett sådant fönster.

Varje enskild layoutförskjutning får en poäng som beräknas genom att multiplicera två faktorer. Impact fraction mäter hur stor del av visningsytan som påverkas, medan distance fraction mäter hur långt elementet förflyttats i förhållande till skärmens storlek.

Det rekommenderade tröskelvärdet för god användarupplevelse är att hålla CLS under 0,1, medan värden över 0,25 indikerar betydande stabilitetsproblem som bör åtgärdas.
→ Cumulative Layout Shift (web.dev)

God praxis att jobba med Core Web Vitals – både för UX och SEO

Att följa upp och förbättra sina Core Web Vitals är numera en del av god praxis inom både webbutveckling och sökmotoroptimering. Google tillhandahåller verktyg som rapporten för Core Web Vitals i Google Search Console (kallas för Viktiga webbvärden på svenska) där man kan se hur ens sidor presterar baserat på fältdata. Det finns goda möjligheter att identifiera problem och arbeta metodiskt med förbättringar.

Genom att ta dessa mätvärden på allvar visar man respekt för användarnas tid och förväntningar samtidigt som man följer de riktlinjer som sökmotorer värderar högt. Och vill du jämföra din webbplats med andra finns tjänsten CrUX Vis där du kan mata in dina konkurrenter och se hur bra de presterar på Core Web Vitals.

Har du Webperfs Premium? Då finns CrUX-data redan i din instrumentpanel!

För dig med Premium-tjänsten loggar du in på premium.webperf.se och på Instrumentpanel hittar du Google CrUX-data om [webbplats] i boxen om din webbplats.

Bild 1: CrUX-data för Webperf.se, med sammanfattning av måtten CLS, INP och LCP för datoranvändare. Samt genomsnittliga mätvärden för alla webbplatser som listas av Webperf.

Till att börja med så finns det upp till tre formfaktorer. Den du ser aktiv i ovanstående skärmdump från Premium är Dator, men det finns också Mobil och Surfplatta. Beroende på trafikmängd är det inte säkert att det existerar tillräckligt med data för alla tre formfaktorerna.

De tre boxarna CLS (Cumulative Layout Shift), INP (Interaction to Next Paint) och LCP (Largest Contentful Paint) är inte där av en slump, de ger dig snabbt en uppfattning om webbplatsens Core Web Vitals. Stapeln i respektive box visar andel upplevelser som var bra, behöver förbättring eller rent utav var dålig. Det här är för den senaste mätperioden som Webperf hämtat in.

För din jämförelse med de tusentals andra webbplatserna som Webperf följer har du genomsnittsvärden för alla andra.

Historisk data per mätvärde

För varje mätvärde där det finns data kan du både visuellt och i en tabell följa utvecklingen de senaste 25 veckorna. Du får mätvärdet vid P75 men också procentuell andel som var bra, borde förbättras eller kanske var dålig.

Bild 2: Historisk data för datorer och måttet Largest Contentful Paint. Linjegraf med P75 som varierar mellan 700 millisekunder och under 20.