Lær at forstå Google Core Web Vitals – og den vigtige forskel på Field- og Lab-data
Du er sikkert allerede opmærksom på Google’s Core Web Vitals og ved hvor vigtigt det er for både brugervenlighed og synlighed i Google. Men ved du hvad forskellen på Lab- og Field-data er? Hvorfor får du ikke de samme tal, og hvordan bruger du dem bedst?
I know – det her er i den absolut mest nørdede ende af SEO-arbejdet. Core Web Vitals er i sig selv lidt svært helt at forstå, og nu skal du så også forholde dig til lab- og field-data.
Ikke desto mindre er det faktisk vigtigt at forstå. For hvis du læser data forkert risikerer du enten ikke at få gjort noget ved alvorlige svagheder – eller spilde for meget krudt på detaljer der faktisk er OK.
I dette indlæg vil jeg forsøge at forklare lidt mere om alt dette på en måde så alle kan følge med. Læs – og spørg gerne i kommentarfeltet nedenfor, hvis du er i tvivl om noget.
Flere værktøjer – forskellig data
Der findes flere forskellige værktøjer, som kan måle og rapportere dit websites hastighed og Core Web Vitals. Tre af de mest udbredte er:
Som du måske har lagt mærke til giver de sjældent helt nøjagtigt de samme resultater, når de tester en side. Det er der flere gode grunde til – herunder:
- Nogle tester field-data – andre tester lab-data (det kommer jeg tilbage til om lidt)
- Der testes ikke nødvendigvis fra samme lokation eller enhed
Der er således ikke tale om en fejl, når de forskellige værktøjer viser forskellig data. Det er et udtryk for, at de måler noget forskelligt. Og det er derfor det er vigtigt, at du forstår lidt bedre hvad det faktisk er de måler.
Hvis vi f.eks. ser på et site som Matas.dk, ser den første del af resultatet således ud i Google PageSpeed Insight (for forsiden).
Det i sig selv kan ved første øjekast godt være et lidt forvirrende resultat. For hvorfor pokker får de kun en (mobil) score på 11 når de tilsyneladende lever op til alle Core Web Vitals krav i graferne nedenfor?
Forvirringen bliver ikke mindre, når vi ser på resultatet for desktop. For her får de en score på 91, selvom den detaljerede data ikke er ret meget bedre.
Hvis vi tjekker samme side i f.eks. GTMetrix bliver den umiddelbare forvirring blot endnu større.
Hvis vi ser lidt nærmere på resultatet fremgår det, at der er testet fra en server i Vancouver, Canada og med en desktop agent. Det i sig selv forklarer jo en del. Matas.dk er sikkert primært optimeret til hurtige resultater i Danmark. Forståeligt nok.
Hvis du har en konto hos GTMetrix kan du ændre både lokation, user agent og en masse andre detaljer.
Hvad der dog ikke fremgår helt så tydeligt er, at GTMetrix er baseret på lab-data fra Lighthouse. Resultaterne ovenfor fra Page Speed Insight er field-data (og bare rolig, jeg skal nok forklare meget mere om forskellen lige om lidt).
I Google Page Speed Insight kan vi faktisk også se lab-data. Det vises lidt længere nede på siden.
Hvis du læser beskrivelsen i bunden får du også forklaringen på, hvorfor Matas Page Speed Score (for mobil) kun er 11 – for den er baseret på lab-data, som jo ikke er så god.
Men hvorfor er der så kæmpe forskel på lab- og field data? Det skal vi se lidt nærmere på.
Core Web Vitals: Lab- og field data
For at forstå, hvorfor data kan være så forskelligt med de forskellige værktøjer er det vigtigt at kende forskellen på lab- og field-data.
Lab-data
Lab-data beregnes på basis af et prædefineret set af regler – herunder lokation og browser settings. Det er det, som vi betegner som lab- eller test-miljøet.
Normalt bruges Lighthouse til disse beregninger. Det gælder både for Google PageSpeed (nederst) og GTMetrix.
Formålet med lab-data tests er at kunne foretage og gentage konsistente målinger fra test til test.
Field-data
Field-data indsamles ved at monitorere rigtige brugeres faktiske besøg på websiden. Og netop fordi der indsamles data fra faktiske brugere, inkluderer den de konkrete browsere, netværksforbindelser geografiske lokationer de bruger.
I Google Page Speed Insight, og mange andre værktøjer, hentes denne data fra Chrome User Experience Report (CrUX).
En af de vigtigste ting at forstå med field-data er, at den ikke er baseret på blot en enkelt måling – men en række af målinger på tværs af mange brugere. Nogle brugere får måske vist siden hurtigt, og andre langsommere – afhængigt af blandt anden deres lokation, browser, netværksforbindelse osv. Field-data er den samlede data for alle (målte) brugere.
I Google Page Speed Insight vises hvordan resultaterne fordeler sig og den samlede vurdering baserer sig på hvad mindst 75% oplever. Lad os se lidt nærmere på denne rapport fra Matas igen.
Som du kan se oplever 87% en LCP på 1,9 sekunder. Men nogle (10%) ligger lidt over de anbefalede 2,5 sekunder (gul) og enkelte (3%) ligger over 4 sekunder (rød).
Lab-data for LCP viser i kontrast til ovenstående hele 11 sekunder!
Hvorfor er lab- og field-data så forskelligt?
Som vi kunne se ovenfor, i eksemplet, kan field- og lab-data være meget forskelligt. Men hvorfor?
Årsagen er faktisk meget enkel. Field-data inkluderer en masse forskellige netværk, browser typer, og et utal af forskellige måder brugerne bruger siderne på (hvad de klikker på, hvornår, om og hvornår de scroller osv). Alt sammen data fra de (måske mange) reelle brugere der har besøgt siden.
I modsætning til dette er lab-data helt bevidst begrænset til en række foruddefinerede forhold, som:
- En enkelt browser type
- En bestemt type netværk (og hastighed)
- En bestemt geografisk lokation
Lab-data repræsenterer ikke nødvendigvis den oplevelse som 75% af de reelle brugere får – som er det field-data fokuserer på.
Men hvorfor overhovedet have de to forskellige typer og hvad kan det bruges til?
Lab-data er godt, hvis du forud for udrulningen af nye features, designs og tilpasninger vil teste hvordan det påvirker dine Core Web Vitals. Det er også meget brugbart til debugging af svagheder der rapporteres i din field-data.
Du skal så bare være opmærksom på, at det resultat du får ikke nødvendigvis er identisk med det som dine reelle brugere vil opleve – på tværs af de (sikkert mange) forskellige browsere, netværk og lokationer de anvender. Tilsvarende måles med lab-data ikke de forskellige måder, som de besøgende bruger siderne på.
Udover de mere generelle forskelle på lab- og field-data, som beskrevet ovenfor, er der også en række mere specifikke forskelle på de forskelle datatyper, som det er godt at forstå. Så dem skal vi se lidt nærmere på.
- Largest Contentful Paint (LCP)
- First Input Delay (FID)
- Cumulative Layout Shift (CLS)
Largest Contentful Paint (LCP)
En lab-test af LCP giver meget sjældent det samme resultat som en field-test. Hvis du laver en lab-test af en side, vil den normalt give samme resultat hver gang. Hvis du laver en field-test vil resultatet variere over tid – som et resultat af de brugere der faktisk har besøgt siden.
Nedenstående faktorer kan være med til at give de forskellige resultater:
- Forskellige skærmstørrelser giver forskellige resultater da den synlige del af siden (viewport) ikke er identisk
- Hvis en bruger er logget ind, eller der er personificeret indhold kan LCP-elementer være meget forskellige for den enkelte bruger
- Tilsvarende, hvis der laves A/B eller multivariant tests af siden vil resultaterne også variere meget fra bruger til bruger
- Hvilke fonts der er installeret på brugerens computer – og dermed hvor meget de fylder, vil også påvirke resultatet
- Lab-tests udføres normalt på en “basis version” af siden uden parametre (?et-eller-anden=et-eller-andet) eller fragmenter (#et-fragment).. Men i den virkelige verden deler brugere ofte links til sider med fragtmenter, Google henviser nogle gange til dem direkte i søgeresultaterne og parametre kan ændre indholdet. Det påvirker LCP
Field-data beregnes som sagt på basis af hvordan top 75% af de reelle brugere oplever siden. Så hvis f.eks. en stor andel af disse brugere har et LCP-element der loader meget hurtigt – for eksempel et afsnit med en system-font de har, så vil det give en god LCP-score – også selvom op til 25% af brugerne oplever siden som langsommere.
Det modsatte kan også være tilfældet. En lab-test kan f.eks. vise at der er problemer med et LCP-element, fordi testen laves med en mobil bruger agent med en meget lille skærmstørrelse. I praksis kan det dog godt være at hovedparten af dine reelle brugere anvender større mobiltelefoner, eller mest sidder på desktop.
En anden forskel er caching
En lab-test loader som regel en side uden at have gemt cachede elementer. Men når rigtige brugere besøger en side, så kan de meget vel have cachet nogle af elementerne. Og så loader den meget hurtigere.
Det kan f.eks. være med til at forklare de meget store forskelle vi så i testen af Matas.dk. Matas har sikkert mange gengangere blandt deres brugere og de nyder så godt af cachingen. Til gengæld ser det lidt skidt ud for nye brugere – siderne loader markant langsommere for dem.
Så her er et rigtig godt eksempel på, hvordan du kan bruge lab- og field-tests. Det er jo godt at de fleste brugere oplever Matas.dk som hurtigt, men hvis de også vil tiltrække og fastholde nye, bør de gøre noget ved den meget langsommere oplevelse de får.
Nogle lab-tests kan godt simulere caching, men det er umuligt for dem at vide med sikkerhed hvor stor en andel af de faktiske brugere, der har gavn af det.
AMP og såkaldt “Signed Exchanges (SXG)” kan også have en indflydelse
Sites der har implementeret AMP eller Signed Exchanges (SXG) kan gøre at f.eks. Google kan pre-loade sider. Det kan give markant hurtigere sideoplevelser for de brugere der kommer ind den vej.
Det er dog værd at bemærke, at i forhold til SEO tyder alt på, at Google ikke bruger AMP-data i vurderingen af hastighed. Til gengæld viser mig erfaring, at AMP øger sandsynligheden for gode mobile rankings.
Lab-tests simulerer i reglen ikke den forbedrede hastighed der kan oplevelses med ovenstående metoder. Det kan indgå i field-data.
Bfcache påvirker også resultaterne
Bfcache er et udtryk for den caching browsere laver, så sider loader hurtigere, når der trykkes frem og tilbage i browseren. Du kan læse lidt mere og bfcache her – og hvad du som udvikler kan gøre for at sikre, at det udnyttes optimalt på dit website.
Lab-tests inkluderer ikke de hastighedsfordele brugerne kan opleve med bfcache. Field-data kan således vise bedre data, hvis mange brugere klikker frem og tilbage.
Brugerhandlinger påvirker også LCP
LCP måler hvor hrtigt det største billede eller tekst-blok renderer i en given skærmstørrelse (viewport). Men det største element kan ændre sig undervejs som den indlæses, eller nye elementer dynamisk tilføjes.
I en lab-test måles normalt først når siden er fuldt ud indlæst. Men i en field-test afbrydes målingen når en bruger f.eks. scroller ned eller på anden måde foretager noget aktivt på siden.
Det giver faktisk god mening. For typisk vil en bruger jo begynde at gøre ting på siden når den opleves som indlæst – selvom den måske teknisk set ikke er det. Resultatet er, at field-tests kan give meget bedre resultater, end lab-tests, hvis brugerne ofte handler på siden før den teknisk set er helt indlæst.
Dette kan også være en af årsagerne til de bedre field-data på Matas.dk. Men det er også noget, som de bør overveje at se lidt nærmere på. For det kan potentielt give funktionsproblemer på siderne, hvis de (nye) besøgende ikke venter på at alle funktioner er indlæst, inden de går i krig med den.
First Input Delay (FID)
FID forudsætter rigtig user interaktion. FID måler hvor responsivt en side er på det tidspunkt hvor de faktisk interagerer.
Den sidste del af den sætning er helt afgørende for i lab-test vil aldrig være i stand til forudse hvornår brugerne vælger at interagere med en side og kan derfor ikke måle FID korrekt.
TBT og TTI forholder sig ikke til brugerinteraktion
Time to Interact (TTI) og Total Blocking Time (TBT) er lab-data målepunkter. Dem finder du ikke i din field-data.
TBT og TTI kan hjælpe dig med at diagnosticere problemer med FID. De måler bl.a. hvor meget hovedtråden blokeres under indlæsning.
Hvis der f.eks. er en masse tunge synchronous JavaScript kan det blokere hovedtråden når brugeren første gang forsøger at interagere. På den anden side, hvis brugerne generelt venter på at siden er færdigindlæst, så kan FID være fin.
Hvornår brugerne vælger at interagere på en side afhænger i høj grad af hvornår den opleves som færdigindlæst. Det kan ikke måles med TBT og TTI.
Også på dette punkt ser det ud til at Matas har nogle udfordringer, som de bør gøre noget ved.
TBD og TTI inddrager ikke “tab-delay” i målingerne.
Hvis et website ikke er optimeret til mobile brugere vil en browser normalt tilføje 300 ms forsinkelse når der tapper på noget, før event handlers eksekveres. Det gør de for at have tid til at forstå, om en bruger er igang med at dobbelt-tappe på noget.
Denne forsinkelse kan tælle med i en sidens FID, da det er med til at forsinke oplevelsen. Men da denne forsinkelse teknisk set ikke er en “long task” påvirker det ikke TBT og TTI. Det betyder, at en side kan have en dårlig FID selvom den har en god TBT- og TTI-score.
Man kan udgå tab-delay issues ved altid klart at definere en mobil viewport.
Bafcache og FID
På samme måde som med LCP kan optimal caching også påvirke FID.
I den virkelige verden kan en bruger allerede have et JavaScript cachet i deres browser. Så vil det hurtigt kunne eksekveres og dermed give en mindre forsinkelse. Det samme gælder sider der er gemt i bfcache
Cumulative Layout Shift (CLS)
CLS i en lab-test måler måler udelukkende ustabile elementer i above-the-fold indhold under indlæsning, men CLS er mere end det.
I en field-test inkluderes alle ustabile elementer der opstår undervejs som en side bruges – i hele dens “levetid”. Det inkluderer bl.a. også ustabile elementer der opstår når brugerne scroller ned på siden, hvis de oplever langsomme netværk forbindelser når de interagerer osv.
F.eks. er det meget almindeligt at billeder lazy-loades , hvilket kan føre til layout skift – ustabile elementer, når en bruger scroller ned på siden. Dette vil sjældent blive opdaget i en lab-test.
Personificeret indhold og CLS
Personificeret indhold – f.eks. A7B-tests eller målrettede annoncer, har betydning for hvilket indhold der faktisk indlæses på en side og hvornår det sker. Det kan påvirke CLS.
I en lab-test indlæses en side typisk uden personificeret indhold, hvilket kan føre til andre resultater for CLS end for en rigtig bruger.
Da field-data inkluderer data for alle brugere vil alle sådanne ustablile elementer og deres indflydelse på CLS medregnes.
Selvom der i vores test af forsiden på Matas ikke er direkte problemer med CLS (de ligger under 0,1 på både lab- og field tests) er det dog værd at bemærke, at der er ret stor forskel. Lab-testen viser en CLS på 0,009 mens field testen er på 0,03 – altså 3-4 gange højere.
Da det er langt fra de 0,1, som alle sider bør ligge under er det som sagt ikke et konkret problem. Alligevel ville jeg, hvis jeg var dem, se lidt nærmere på det for i det mindst at blive helt bevidst om årsagen til forskellen – og måske reducere den.
Bfcache og CLS
To af de mest udbredte årsager til en høj CLS-score er billeder og iFrames der indlæses uden at dimensionerne på forhånd er defineret og langsomt indlæste webfonts. Begge disse forhold er mere tilbøjelige til at ramme nye besøgende med en tom cache, frem for gengangere hvor denne data kan være gemt.
Hvis en side er cachet i de besøgendes browser, eller genindlæst fra bfcache, kan browseren som regel rendere billeder og finte med det samme uden at skulle vente på at de downloader. Det kan give lavere CLS-scores i field-tests frem for lab-tests.
I Matas tilfælde er det så lige omvendt. Det kunne tyde på at deres caching politik kan forbedres.
Google: Oversigt over oprindelse
For at gøre dele hele en smule mere komplekst, så viser Google faktisk en rapport mere – udover det vi allerede har set på. Det er rapporten: “Oversigt over oprindelse” (eller hvis du bruger Page Speed Insight på engelsk: “Origin Summary”).
Hvis du klikker på linket folder denne skjule analyse sig ud.
Oversigt over oprindelse viser field-data for alle sider på dit website – som har data nok til at kunne rapporteres. Det er således et samlet billede af hele dit websites performance.
I Matas tilfælde kan vi så konstatere, at der for forsidens vedkommende er lidt flere brugere der får en dårligere FCP-, FID- og CLS-score end sitet som helhed. For LCP forholder de sig lige omvendt.
Da Matas.dk er et meget stort set, med mange sidetyper og enormt mange sider kan denne rapport ikke rigtig bruges til så meget i praksis – med mindre der er meget store udsving.
Den kan dog være godt at benchmarke enkelte sidetyper og imod – ligger de over eller under gennemsnittet for sitet som helhed. Ligger de under – som f.eks. forsiden gør, var det måske en ide, at se lidt nærmere på lige netop den.
Hvad skal du gøre når field- og lab-data er forskelligt?
Hvis du har både field- og lab-data for en given side vil jeg anbefale, at du først og fremmest fokuserer på, at få gode resultater på din field-data. Det er jo det som brugerne faktisk oplever.
På den anden side, hvis der er store forskelle imellem dine field- og lab-data, så bør du nok få set lidt nærmere på hvad det kan skyldes. For der kan være alvorlige problemer, som måske mest rammer nye besøgende. Og de skal jo også have en god oplevelse! Det er det vi ser på Matas.dk.
I forhold til SEO har Google mere eller mindre direkte officielt udmeldt at de primært bruger field-data. Jeg er dog ret sikker på, at det altid er tilfældet. Dels er der en forsinkelse på denne data, da den kun opdateres månedligt, og dels er der mange sites og enkelte sider, hvor der ikke er nok field-data til at lave en analyse – og de vurderes jo stadig af Google når der søges.
Så også i forhold til SEO vil jeg fortsat anbefale, at både field- og lab-data bruges. Kan du få gode scores på begge dele så er du under alle omstændigheder mere sikker på gode og stabile resultater.
Du skal så bare være opmærksom på at den overordnede Page Speed score alene beregnes på baggrund af lab-data, hvilken i grund er lidt paradoksalt, hvis Google – som de siger, primært bruger field -data som ranking signal.
Men nu skal man jo heller ikke altid tro på alt hvad Google siger 🙂
God fornøjelse med optimeringen …
Hvis du har spørgsmål er du meget velkommen til at stille dem i kommentarfeltet nedenfor. Og hvis du gerne vil have hjælp med at analysere eller optimere dit websites Core Web Vitals, så er du meget velkommen til at kontakte mig på: mikkel@demib.com eller telefon: 22 27 07 10.
Skriv kommentar