Core Web Vitals & Technical UX

I SEO er markedslederne ikke dem, der bare er bedst til at skabe content af høj kvalitet. Heller ikke dem, der blot er bedst til linkbuilding. Det er dem, der også er bedst til at bruge Googles værktøjer til at forstå og optimere en hjemmesides tekniske helbred.

→ Download gratis template til on-page optimering

Et af de vigtigste værktøjer til domæneejere og SEO-specialister er Google Search Console (GSC). Med GSC får du præcise målinger på alt fra performance i antal klik til mobilvenlighed.

Du får også et overblik over en sides page experience (sideoplevelse), som er på vej til at blive en af de vigtige ranking faktorer for søgemaskinen. Dette er allerede i gang med at blive rullet ud her fra midten af juni.

Endnu vigtigere, så er Google Search Console hjem til Core Web Vitals-rapporten.

Core Web Vitals

Core Web Vitals (CWV) giver dig målbare og enkle rapporter for din hjemmeside ud fra tre forskellige faktorer. Disse faktorer har alle det samme mål: at vise den faktiske brugeroplevelse af din hjemmeside. På dansk kendes den som Vigtige netstatistikker.

De tre faktorer er:

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

Hver for sig giver disse målinger dig ikke rigtig nogen værdi i forhold til din hjemmesides performance. Når de sammenholdes får du til gengæld et enormt brugbart overblik over hvordan dine brugere oplever din hjemmeside. Det giver altså en rapport over hvordan forskellige elementer af din hjemmeside har en effekt på brugeradfærd.

Largest Contentful Paint (LCP)

Den første faktor, LCP, måler hvor lang tid det tager at vise den største billede- eller tekstblok på skærmen. Dette udregnes i forhold til hvornår siden begynder at loade. Førhen har fokus været på First Contentful Paint (FCP), men der er sket et skifte i retning af at Largest er mere vigtig for brugeroplevelsen. LCP måles i sekunder og ses som acceptabel når den er på under 2,5 sekunder.

Du kan læse mere om Largest Contentful Paint her.

Interaction to Next Paint (INP)

Den anden faktor, INP, måler hvor hurtigt din side responderer på brugerens interaktioner. INP skal gerne være under 200 millisekunder.
En interaktion i dette tilfælde kan være et klik eller et forsøg på et scroll.

INP har nyligt erstattet FID og det er nu den nyeste metric til at måle responstid på interaktion.

Du kan læse mere om Interaction to Next Paint her.

Cumulative Layout Shifts (CLS)

Den sidste måling, CLS, er en estimering af en sides visuelle stabilitet - eller rettere, ustabilitet. CLS dækker over uforventede skift i din sides layout. Det straffer dig altså ikke for designvalg. Da CLS er en temmelig abstrakt måling bliver den ikke beregnet i sekunder eller centimeter. I stedet får du en layout shift score, som er en sammenregning af hvordan layoutet skifter og hvor meget. En hjemmeside har en god CLS når den har en måling på under 0,1.

Du kan læse mere om Cumulative Layout Shift her.

Sådan bruger du Core Web Vitals i teknisk SEO

I Bonzer bruger vi CWV til at undersøge, analysere og eksekvere.

I denne artikel bruger vi Brödernas som case. Det er et af Sveriges foretrukne steder for gode burgere og lækre øl. Ifølge PageSpeed Insights led Brödernas hjemmeside under problemer inden for alle tre kategorier: LCP, FID (nu INP) og CLS.

Undersøg

Vi undersøgte hjemmesiden for store problemer og problematiske URL’er. Ved at undersøge de URL’er der blev fremhævet af CWV-rapporten i Search Console blev det klart at det største problem de havde var deres CLS.

Analysér

Så analyserede vi URL’erne der havde en for høj måling på CLS. Denne analyse gav os et overblik over hvilke elementer, der påvirkede hjemmesidens dårlige måling og i hvor høj grad de elementer var skyld i problemerne.

Videre analyse af de udvalgte URL’er ledte os til Pagespeed Insights. Her kunne vi bekræfte at sidens primære problem faktisk var CLS. Vi kunne også se de specifikke elementer der lavede ballade på siden.

Ved at navigere til Avoid large layout shifts/Undgå store layoutskift i Pagespeed Insights kunne vi endeligt udpege det problematiske element.

Eksekver

På baggrund af det kunne vi sammen med Brödernas eksekvere på den rigtige måde for at reparere CLS-målingen på den side og på resten af hjemmesiden.

Mange af CLS-problemerne var skabt af billedfiler i uddaterede formater (PNG & JPG) der krævede alt for mange ressourcer at fremvise. Det gjorde, at de dukkede op sent på siden og rykkede rundt på sidens layout. Ved at eksekvere her - ved at minimere og opdatere billederne til de rette formater - kunne vi sikre at Brödernas havde en god CLS-måling.

Disse ændringer på baggrund af Core Web Vitals har været en del af deres store SEO-fremskridt inden for det svenske restaurant-marked.

Vigtigheden af CWV på hjemmesider som Brödernas kan ikke siges højt nok. Hvor andre Google-værktøjer som Pagespeed Insights giver et øjebliksbillede af sidens tekniske sundhed, og herunder CWV, så er den ikke god nok til at give indsigt i de problemer som er spredt gennem hele domænet.

Den sande værdi kommer først frem når værktøjerne bruges sammen. Her kan hver af deres styrker udnyttes, deres svagheder elimineres. På den måde kan du faktisk identificere den rigtige vej fremad i forhold til at forbedre din sides brugeroplevelse.

Et værktøj for fremtiden

Page Experience som en rankingfaktor er lige rundt om hjørnet. Officielt er det udrullet helt i slutningen af august, men kender vi Google ret kan det sagtens bliver forsinket. Men faktum er, at sidens oplevelse og derfor brugerens oplevelse kommer til at fylde mere og mere i SEO. Sideoplevelsen dækker over flere nøgleaspekter af en sides tekniske sundhed.

Dette inkluderer brugen af HTTPS, fokus på mobilvenlighed, sidehastighed og meget mere. For at forberede sig til dette skifte bør webmastere, content managers, SEO specialister og andre der arbejder med digital marketing gå efter at mestre CWV så de kan give deres brugere en meget bedre oplevelse.

Et godt værktøj i jagten på mestring og viden er Googles Lighthouse Scoring Calculator. Dette værktøj viser vægten af hver måling overfor hinanden som de ville være i beregningen af Pagespeed Insights’ performance score.

I den perfekte verden er der uendelige ressourcer, og fejl og mangler udbedres som de opstår. Men sådan er det nok ikke i din virksomhed. Begrænsede ressourcer og timer tvinger dig til at prioritere optimeringer og arbejdsfordelinger. Lighthouse Scoring Calculator kan hjælpe dig ved at visualisere de opnåede effekter af tiltag lavet på specifikke Web Vitals-faktorer.

Sidste tanker

Du kan gøre alt det rette, lave de rigtige tiltag og træffe de korrekte beslutninger når det kommer til at skabe et solidt fundament for din hjemmeside.

Men hvis du ikke har et vågent øje på din sides helbred og ydeevne, så bliver du efterladt i støvet af dine konkurrenter. Men du har her fået alle de nødvendige værktøjer du skal bruge til at forbedre din hjemmesides Core Web Vitals.

Du kan måle og overvåge din hjemmesides helbred, hastighed og brugeroplevelse fra et enkelt værktøj. Derudover, så interagerer CWV med de fleste markedsførende værktøjer, så du kan have et detaljeret overblik uden at du mister muligheden for at dykke ned i specifikke rapporter og analyser som du kan bruge til at skabe en bedre sundhed og stabilitet for din hjemmeside.

I takt med at sideoplevelsen bliver en større faktor for ranking bliver det mere og mere vigtigt for optimering. Og det er heldigvis lavet sådan, at Core Web Vitals-indikatorerne er blevet vævet tæt ind i Search Consoles analyse af din hjemmeside.

En ting er i hvert fald sikkert: Brödernas er nu optimeret og klar til page experience-opdateringen.

Ønsker du at lære mere om teknisk SEO? Læs vores guide til teknisk SEO her.

Hvad er INP og TTFB?

I sommeren af 2021 kom brugeroplevelsen endnu højere på Googles prioriteringsliste, da Core Web Vitals blev introduceret som en målbar score. En score, som kan medvirke til at afgøre en sides rangering blandt søgeresultaterne.

En stor opdatering med mange store begeæber - og uden tvivl mange søvnløse nætter for SEO-nørder, der vil være på forkant med udviklingen.

Måned for måned lærte man mere omkring de tre nye metrics; CLS, FID og LCP og det stod hurtigt ret klart, at langt de fleste hjemmesider bestod FID (First Input Delay) med kryds og slange. Noget som fik de store hoveder til at tænke, om der var noget galt med den her måleenhed.

Derfor kommer nu to nye Core Web Vitals metrics, som kan erstatte FID med henblik på at øge den tekniske kvalitet af sider. Den primære forskel går her ud på at måle grupper af individuelle interaktioner inden for en handling frem for en enkelt interaktion.

FID vs INP - Hvad er forskellen?

First Input Delay måler forsinkelsesdelen af den tidsramme der er mellem, at en bruger interagerer med siden, og til at sidens event-handlers begynder at bearbejde klikket. Det vil sige, at der ikke måles på den totale tid, der går fra klik til handling, men rettere hvor forsinket hjemmesiden reagerer på klikket.

Husk at på dette stadie kan brugeren ikke nødvendigvis se en respons, da der kun måles på forsinkelsen, og at efter forsinkelsen er der stadig noget bearbejdelses-tid før brugeren ser noget ske som resultat af deres klik.

Den nye metric, kaldet INP (Interaction to Next Paint) er en ny, eksperimentel* måleenhed, som vurderer, hvor responsiv en side er. Den laver et logarkiv over alle interaktioner på hele sidens livscyklus fra start af indlæsning, til alt er færdigt. Den højeste værdi af alle disse interaktioner vil udvælges til at repræsentere sidens INP.

*tiden som bruges til at vurdere “good”, “needs improvement” og “poor” kan ændres over tid, da NPM er eksperimentel og kan blive fintunet senere.

FID er altså en måling for den første interaktion på hjemmesiden, det måler kun forsinkelsen før proces-tiden og tager dermed ikke højde for proces-tiden eller rendering-delay’et.

Modsat dækker INP over alle interaktioner på siden og giver en score baseret på den længste interaktions varighed.
Denne varighed er en sammenlagt måling af input delay, den tid det tager at bearbejde klikket, samt den tid det tager at rendere den første frame som viser en respons.

Det er nemlig noget, som passer til Googles vision om at forbedre brugervenligheden. Det skyldes, at med INP måles alle interaktioner, hvor hjemmesidens performance vurderes mere holistisk, i stedet for at give en score baseret på førstehåndsindtrykket.

Hvad er en interaktion?

Alle interaktioner på hjemmesiden måles i events. Det er alt helt ned til, at musen bevæger sig eller tilmed blot befinder sig inden for hjemmesidens rammer. Så hvis en hjemmeside under indlæsning er i gang med at bearbejde et større script (lad os sige et script til at vise relaterede produkter i din webshop), og du klikker mens denne handling er I gang, kan bearbejdelsen af det script blokere for det du klikkede på. Det vil være indtil handlingen er ovre.

Efter input delay kan klikkets effekt bearbejdes. Her måles typiske HTML events som pointerup, mouseup, click, osv. Det er essentielt en instruktionsliste til serveren, der agerer som en liste over, hvad brugeren har gjort, og hvilket input den skal bearbejde.

Sidst er der det, som kaldes præsentations-forsinkelse, hvilket er noget simplere. Det er tiden, det tager for siden at rendere og vise billedet på brugerfladen. Det vil sige, at det først er efter præsentations-forsinkelsen, at brugeren kan se noget være sket som resultat af deres klik.

Kort sagt så består html-events altid af tre faser; input delay, proces tid, og presentation delay.

Varigheden af en interaktions associerede event-callbacks er derfor summen, totalen, af den tid som bruges til alle tre faser.

Sådan måles INP

INP kan ligesom andre Core Web Vitals metrics måles både med field og lab data.

Lab-data

Lab-data er når en side måles under kontrollerede forhold, hvor der bruges en simuleret computer med standardiserede specifikationer, en begrænset internet hastighed samt andre betingelser for at give et konservativt estimat af, hvordan en bruger muligvist oplever siden. Det kaldes lab data, eller “syntetisk data”, fordi det ikke er baseret på virkelige oplevelser men en simulation.

Field data

Field data er derimod en måling, der foretages af brugerene på siden, når man indlæser siden normalt. Fordi at field-data er baseret på virkelige brugerbesøg, så reflekterer det rigtige enheder, netværk og geografiske udfordringer, som folk måtte have. Dette er typisk også data, du kan finde i Googles CRuX rapport

Det anbefales så at måle INP med field data, hvilket selvsagt giver god mening, da det i så fald også vil vise et nærmere billede af sidens overall performance i relation til de funktioner brugere benytter.

Sådan forbedres INP

Før vi starter, så skal jeg understrege, at målet fremadrettet bør være at sprede hjemmesidens funktionalitet ud, så det som skal ske i starten, sker i starten, og ting som ikke er nødvendige lige med det samme får lov til at vente.

Nogen gange under indlæsning kan det ske, at en bruger forsøger at interagere med siden, mens den stadig er under indlæsning og derved henter javascripts.

Det betyder, at hjemmesiden stadig initierer event handlers og ikke engang har leveret den hensete interaktivitet for siden at være funktionel.
Af den grund vil den interaktion nødvendigvis måtte vente til de tre faser er overstået og drastisk forøge din INP score, så hvordan kommer du rundt om det?

1. En ting som kan give et godt overblik over, hvor du har lidt albuerum for at fjerne ubrugt kode, er ved at tilgå Chrome DevTools’ coverage tool

Her kan en hjemmeside indlæses, hvor der så laves en visualisering over, hvor stor en procentdel og hvor mange bytes tilhører funktioner, som ikke endnu er blevet eksekveret - her, desto rødere barren er, jo større en portion af den givne funktion er ikke eksekveret.

Klikkes på den røde barre, kan der ses den eksakte del af koden, som ikke endnu er eksekveret.

2. Hvis du gør brug af mange javascripts, kan det gavne at splitte ens javascripts ind i små etaper og derved kun sende det, som er absolut nødvendigt i starten af sidens indlæsning.

Javascript bundling er et stort emne, og det er et emne til en helt anden dag. Dog kan mere læses på denne guide om code splitting.

3. Undersøg, hvilke scripts du bruger og kig især efter, om nogle af dem er langsomme

4. Undersøg, om der er Long tasks du kan optimere.

Her kan du med fordel benytte Chrome DevTool’et igen til at se long tasks. Her skal du ind i Performance, og trykke på pilen, som kører i ring for at genindlæse siden. Så får du en behændig timeline over sidens indlæsning.

5. Efter startup kan det også være en god idé at skemalægge ikke-essentielt arbejde til efter browseren er færdig med indlæsning.
Her har PhilipWalton.com en super grundig artikel om, hvordan man kan opnå dette ved at bruge en requestIdleCallBack funktion.

6. Sørg for, at funktioner, som ikke er strengt nødvendige såsom menu toggles, fade-in animationer, hover effekter og transforms, ikke kommer til at tage førsteprioritet over almen sidefunktionalitet.

TTFB - en redegørelse for netværksproblemer

Udover INP er der også introduceret endnu et metric, som ikke så meget har at gøre med CWV i det store hele, men som rettere er en måde at redegøre for eventuelle netværks eller serverproblemer.

TTFB udregnes som en sum af den tid som der bruges på hhv:

• Redirects
• DNS lookup
• Bestemmelse af forbindelse og TLS forhandling (den proces hvor hjemmesider og servere udveksler SSL certifikater for at fastslå, at trafikken sendes gennem en sikker forbindelse)
• Server requesting (hentning af ting fra tredjeparter, eksempelvist scripts og integrationer)

Så snart den første byte af serverens svar på den oprindelige anmodning er modtaget, så stopper målingen og giver resultatet, så det er altså derfra, der sendes en anmodning, til at den allerførste byte kommer retur.

Det metric kan allerede ses på nogle website testere som fx. Webpagetest.org

Udover det vil den også kunne ses som del af CRuX rapporten og i netværkspanelet af chrome’s dev tools.

Sådan forbedres TTFB

TTFB er en af de metrics, som i stor grad afhænger af din hosting-udbyder [one.com, simply.com, godaddy, mv.], og hvilken backend der bruges.

Hvis du er en SEO-nørd, der sidder derude og bedst muligt vil gardere dig imod det her, så er det anbefalet at starte med at skabe overblik hos den tekniske afdeling og sørge for, at hjemmesiden ikke har adskillige redirects på samme kæder.

Her har du en kæmpe fordel, hvis du endnu ikke har et website, fordi så kan du fra start vælge en hurtig webserver med solid infrastruktur.

Ellers så taler vi om tommelfingerregler, hvor ting som redirect chains bør undgås.
Hvis en side har to eller flere redirects, så vises det som del af Lighthouse rapporten og er en betydelig faktor, som kan gøre, at din TTFB ender med at ligge i den høje ende.

En stor fordel kan også indhentes i at gøre brug af HTTP/2 og HTTP/3, da det er en langt mere effektiv måde at levere ressourcer på.

Preconnect ressourcer

Sørg også for, at påkrævede ressourcer bliver preconnected - her taler vi selvfølgelig om fonte, stylesheets, javascripts mv.
Det virker måske som en handling, som umuligt kan medføre betydelige resultater, men en undersøgelse fra Splunk.com viser, at de formåede at sænke deres time-to-interactive med 37% ved at benytte resource hints såsom

Nu ved du lidt mere omkring INP og TTFB, og forhåbentligt er du blevet klædt lidt bedre på til at svare på spørgsmål, der måtte komme din vej!

Core Web Vitals-rapporten i Search Console

Som led i Googles fokus på bedre page experience, har de opgraderet Google Search Console til at have en teknisk rapport baseret på netop page experience. Denne rapport indeholder fire overordnede områder, hvor tre af dem blev en del af Googles ranking faktorer i 2021.

Google har siden hen i 2023 tilføjet en ekstra Core Web Vital med forkortelsen "INP", som du kan læse om her.

Menupunktet ‘Core Web Vitals’, opdaterer sig løbende, og indeholder også de eksakte URL’er, som kræver forbedring.

En god brugeroplevelse består af mange dele. På udviklingsfronten har Google identificeret disse fundamentale elementer, som skal øge brugeroplevelsen nu og i fremtiden​.

De tre elementer - udover INP - er LCP, FID og CLS:

• Loading Experience

Largest Contentful Paint (LCP)​ - Google bruger dette metric til at måle den formodede hastighed for, hvor hurtigt main content er om at loade på en side.

Læs Googles retningslinjer her: ​Largest Contentful Paint (LCP)​.

• Interaktivitet

First Input Delay (FID): ​Google bruger dette metric til at måle, hvordan brugere kan interagere med siden. FID måler ting som, hvor responsiv siden er - med andre ord er det den tid det tager før, at der opstår interaktivitet på en side.

Læs Googles retningslinjer her: ​First Input Delay (FID)​.

• Visual Stability

​Cumulative Layout Shift (CLS)​: Google bruger dette metric til at måle, hvor stabilt side layoutet er. Med andre ord, hvor meget ændrer layout sig uhensigtsmæssigt for en bruger på siden.

Læs Googles retningslinjer her: ​Cumulative Layout Shift (CLS)​.