Page speed handler om mere end indlæsningstid
En webside kan vise indhold hurtigt og stadig være langsom at bruge. Måske dukker teksten op med det samme, mens menuen først reagerer efter en mærkbar pause. Derfor beskriver page speed ikke kun, hvor lang tid det tager at indlæse hele siden.
Begrebet dækker flere dele af brugerens oplevelse: Hvor hurtigt kommer indholdet frem? Hvornår kan brugeren begynde at bruge siden? Og reagerer den hurtigt på klik og tryk?
Når en browser åbner en webside, sker der overordnet tre ting:
- Browseren kontakter serveren, som sender sidens HTML tilbage.
- Browseren henter ressourcer som billeder, skrifttyper, CSS og JavaScript.
- Browseren opbygger og viser siden. Det kaldes rendering.
Forsinkelser kan opstå i alle tre led. En hurtig server er derfor ikke nok, hvis store billeder eller tunge scripts forsinker indholdet og gør siden træg.
Sådan måles page speed
Der findes ikke ét tal, som fortæller alt om en sides hastighed. Forskellige målinger belyser forskellige dele af forløbet.
Time to First Byte (TTFB) måler eksempelvis tiden, indtil browseren modtager den første byte fra serveren. Det hjælper med at undersøge ventetiden, før browseren kan begynde at arbejde med sidens indhold.
Googles Core Web Vitals fokuserer på den oplevelse, brugeren får. De består aktuelt af tre målinger:
- Largest Contentful Paint (LCP) måler, hvor hurtigt det største synlige indholdselement bliver vist. Det kan eksempelvis være et stort billede eller en tekstblok. Google anbefaler højst 2,5 sekunder for en god oplevelse, mens over 4 sekunder vurderes som dårligt.
- Interaction to Next Paint (INP) måler, hvor hurtigt siden giver visuel respons på brugerens handlinger, eksempelvis et klik på en knap.
- Cumulative Layout Shift (CLS) måler uventede forskydninger i layoutet. Det kan være tekst eller knapper, der flytter sig, mens siden indlæses.
CLS er altså ikke en hastighedsmåling i sig selv. Den handler om visuel stabilitet, men indgår i den samlede vurdering af sideoplevelsen.
En webshop kan eksempelvis levere HTML hurtigt og stadig have dårlig LCP på grund af et tungt produktbillede. Samtidig kan meget JavaScript give langsom respons, når brugeren åbner et produktfilter.
Brug værktøjerne til forskellige formål
Google PageSpeed Insights bruges til at analysere en side og finde mulige forbedringer. Værktøjet kombinerer en kontrolleret test med data fra rigtige brugere, når der er tilstrækkelige brugerdata tilgængelige.
Her er forskellen afgørende:
- Labdata kommer fra en test under bestemte forhold. De er nyttige til fejlfinding og til at undersøge effekten af ændringer.
- Feltdata viser oplevelsen hos rigtige brugere med forskellige enheder, netværk og brugsmønstre.
En god testscore betyder derfor ikke nødvendigvis, at alle besøgende oplever siden som hurtig.
Lighthouse bruges til tekniske tests og optimeringsforslag. Google Search Console giver derimod overblik over Core Web Vitals på tværs af grupper af webadresser. Rapporten bygger på feltdata og opdeler resultaterne i god, kræver forbedring og dårlig.
Hvorfor page speed betyder noget for SEO og konverteringer
Ventetid skaber friktion. Hvis indholdet kommer langsomt frem, eller en knap ikke reagerer, bliver det sværere at læse en artikel, udfylde en formular eller gennemføre et køb.
Page speed er derfor både et SEO-emne og et spørgsmål om brugeroplevelse og konvertering. Google bruger Core Web Vitals i sine rangeringssystemer, men gode resultater garanterer ikke høje placeringer. Hastighed kan ikke erstatte relevant indhold, der besvarer brugerens søgning.
Målet er heller ikke alene at få en høj score i et værktøj. Målet er, at besøgende hurtigt kan finde og bruge det, de kom efter.
Sådan arbejder du med forbedringer i praksis
Start med at finde flaskehalsen frem for at optimere på må og få. Undersøg vigtige sidetyper som produktsider, artikler og landingssider, og se både på feltdata og konkrete testresultater.
Typiske indsatsområder er:
- Billeder: Reducér unødigt store filer, især billeder der fylder meget i den første skærmvisning.
- JavaScript og CSS: Fjern unødvendig kode, og undersøg ressourcer, som forsinker visningen eller brugerens handlinger.
- Serverrespons: Undersøg ventetiden, før browseren modtager sidens indhold.
Test igen efter ændringerne. Brug labdata til den løbende fejlfinding, og følg feltdata for at se, om forbedringerne også slår igennem hos de besøgende.