To sider kan få præcis samme score i en hastighedstest og alligevel opføre sig helt forskelligt for rigtige besøgende. Selve testen er let at køre. Det svære er at læse resultaterne rigtigt: hvilke tal der betyder noget, hvad de egentlig måler, og hvor du finder data fra virkeligheden i stedet for simulerede scorer. Her får du styr på, hvordan du kører en hastighedstest, hvad hvert tal i resultatet betyder, hvorfor simulerede scorer og tal fra rigtige besøgende ofte er forskellige, og hvordan du bruger resultaterne til forbedringer, som dine besøgende faktisk mærker.
En hastighedstest er mest nyttig, når du ved, hvad du skal bruge den til. En enkelt score ud af 100 siger ikke særlig meget. Det er de enkelte målinger bag scoren, og om de kommer fra en simulering eller fra rigtige besøgende, der afgør, om resultatet viser det, dine besøgende oplever. Vil du vide mere om, hvad målingerne dækker over, så læs artiklen om hvad sidens indlæsningstid er, og hvordan den måles.
Hvad måler en hastighedstest egentlig?
En hastighedstest indlæser en side i et kontrolleret miljø og registrerer, hvor lang tid bestemte dele af indlæsningen tager. Værktøjet måler blandt andet, hvor hurtigt serveren svarer, hvornår det første indhold dukker op på skærmen, hvornår det største synlige element er færdigindlæst, hvor meget layoutet rykker sig undervejs, og hvor lang tid der går, før siden reagerer på klik. Målingerne sammenlignes med faste grænseværdier, så du får en score og et overblik over, hvad der kan forbedres.
Laboratoriedata eller data fra virkeligheden
- Laboratoriedata: kommer fra et testværktøj. Siden indlæses fra et fast sted med en simuleret enhed og forbindelse. Resultaterne er kontrollerede og kan gentages, men de viser ikke alle de forhold, rigtige besøgende møder
- Data fra virkeligheden: indsamlet fra rigtige besøgende og samlet over et rullende vindue på 28 dage. Det er de data, søgemaskiner bruger til at bedømme Core Web Vitals og til placeringer
- En hjemmeside kan få 90 i en laboratorietest og stadig have dårlige Core Web Vitals i virkeligheden, hvis de besøgende bruger langsomme enheder, ustabile forbindelser eller bor langt fra serveren
- Tjek altid begge dele. Laboratoriedata er gode til at finde bestemte fejl. Data fra virkeligheden afgør, hvad det betyder for dine besøgende og din placering i søgeresultaterne
Hvordan kører du en hastighedstest rigtigt?
Test først på mobil
- Søgemaskiner bruger mobile-first-indeksering, så de vurderer siderne ud fra, hvordan de klarer sig på mobil
- Mobilscoren er næsten altid lavere end scoren på computer for den samme side, fordi mobiler har langsommere processorer og mere svingende forbindelser
- Kør både mobil- og computertest, men regn mobilresultatet for det vigtigste
Test de mest besøgte sider, ikke kun forsiden
- Forsiden er ofte den hurtigste side på en hjemmeside, fordi den som regel har færre billeder og scripts end undersiderne
- Produktsider, blogindlæg og landingpages får ofte en markant dårligere score og kan betyde mere for besøgende og placeringer
- Test de sider, der får mest trafik, og ikke dem, der har størst chance for at tage sig godt ud
Kør hver test mere end én gang
- Resultaterne kan variere fra kørsel til kørsel på grund af belastningen på serveren, netværket på teststedet og cachen
- Kør hver test to eller tre gange, og brug gennemsnittet som udgangspunkt i stedet for et enkelt resultat
Test før og efter ændringer
- Find en startscore, før du ændrer noget på hjemmesiden
- Kør den samme test efter hver forbedring, så du kan se, hvad den konkret har betydet
- For data fra virkeligheden skal du vente mindst 28 dage efter en ændring, før du vurderer effekten, fordi tallene er et rullende gennemsnit over 28 dage, som opdateres gradvist
Hvordan læser du resultatet af en hastighedstest?
Start med de målinger, der fejler, ikke med den samlede score
- En samlet score på 65 fortæller ikke, hvad du skal rette. De enkelte målinger, der fejler, gør
- Se efter, hvilke af Core Web Vitals der er i området "skal forbedres" eller "dårlig": LCP, INP og CLS
- Hver måling, der fejler, peger på en bestemt del af siden eller indlæsningen, du bør undersøge
Hvad hver måling, der fejler, peger på
- Høj Time to First Byte: serveren svarer langsomt. Se på kvaliteten af hostingen, caching på serveren og databasens ydeevne
- Langsom Largest Contentful Paint: det vigtigste synlige element er længe om at indlæse. Skyldes typisk uoptimerede billeder, ressourcer der blokerer visningen, eller langsomt serversvar
- Høj Total Blocking Time eller dårlig Interaction to Next Paint: JavaScript blokerer hovedtråden. Store scriptfiler og tredjepartsscripts er almindelige årsager
- Høj Cumulative Layout Shift: elementer rykker rundt, mens siden indlæses. Det skyldes billeder uden fastlagt størrelse, indhold der indsættes sent over andre elementer, eller bannere der tilføjes dynamisk
Sådan læser du anbefalingerne
- Testværktøjer viser konkrete anbefalinger sammen med et skøn over, hvor meget tid hver rettelse sparer
- Tag fat i anbefalingerne med den største tidsbesparelse først, så får du mest ud af indsatsen
- Nogle anbefalinger handler om tredjepartsscripts eller tjenester, du ikke selv styrer. Notér dem, men brug kræfterne på det, du kan ændre
Hvad er en god score i en hastighedstest?
Grænseværdier for Core Web Vitals
- Largest Contentful Paint under 2,5 sekunder: god
- Interaction to Next Paint under 200 millisekunder: god
- Cumulative Layout Shift under 0,1: god
Samlet score
- 90 til 100: god
- 50 til 89: skal forbedres
- 0 til 49: dårlig
Sådan bruger du målene i praksis
- Det er faste mål, men din score skal være bedre end de sider, du konkurrerer med om de samme søgeord, ikke bare over en generel grænse
- Søg på dit vigtigste søgeord, og test de sider, der rangerer over dig. Hvis din LCP er 3,2 sekunder og deres er 2,1, er det et tydeligere mål at gå efter end en forskel i score alene
Vil du have en grundig gennemgang af, hvad LCP, INP og CLS måler, og hvordan de bedømmes, så læs artiklen om hvad Core Web Vitals er.
Hvordan følger du hjemmesidens hastighed over tid?
Find et udgangspunkt, før du går i gang med at optimere
- Skriv dine nuværende scorer ned for de sider, du vil forbedre, før du ændrer noget
- Notér, hvilke målinger der fejler, og hvor meget
- Kør testene igen efter hver runde ændringer, og sammenlign med udgangspunktet, så du kan se den reelle forbedring
Tjek data fra virkeligheden jævnligt, ikke kun efter ændringer
- Data fra virkeligheden i ydeevnerapporter opdateres over et rullende vindue på 28 dage
- Tjek dem hver måned og efter større ændringer i indhold, kode eller hosting
- Et fald i scorerne falder ofte sammen med, at der er kommet et nyt stort billede på siden, at der er installeret et nyt tredjepartsscript, eller at hostingen er ændret
Test, når du udgiver nyt indhold
- Et nyt blogindlæg med uoptimerede billeder kan gøre netop den side meget langsommere uden at påvirke de andre
- En ny landingpage med tunge scripts kan give blokeringer, som en test af forsiden aldrig ville afsløre
- Når hastighedstest er en fast del af udgivelsen, undgår du, at problemerne hober sig op ubemærket
Vil du have en samlet guide til de mest effektive forbedringer ud fra dine testresultater, så læs artiklen om hvordan du reducerer din hjemmesides indlæsningstid. Har du problemer med billeder, så læs artiklen om hvordan du optimerer billeder, så siden indlæses hurtigere.
Sådan hjælper WEMASY med hastighedstest
WEMASY's analytics-oversigt viser Core Web Vitals for alle sider, der er bygget på platformen, baseret på data fra rigtige besøgende. Du kan se LCP, INP og CLS for hver side uden at køre eksterne tests. Sider, der ligger under grænsen for god, markeres med den måling, der fejler, så du kan gå direkte til problemet i stedet for at læse en hel rapport.
Platformen tager sig automatisk af billedkomprimering, caching, minificering og levering via CDN, så de mest almindelige årsager, eksterne hastighedstest peger på, allerede er dækket. Når du tester en hjemmeside bygget med WEMASY, finder du som regel problemer i selve indholdet og ikke i platformen, og dem er det lettere at gøre noget ved.
Se, hvad der er med, hos WEMASY Hjemmesidebygger, eller se mulighederne på siden Priser.
Ofte stillede spørgsmål
Hvordan tester jeg min hjemmesides hastighed?
Indsæt din hjemmesides adresse i et hastighedstestværktøj. Værktøjet indlæser siden under kontrollerede forhold og giver scorer for hver måling på mobil og computer. Se på de enkelte målinger sammen med den samlede score: de målinger, der fejler, viser, hvor du skal sætte ind. Vil du se tal fra rigtige besøgende, så brug din ydeevne- eller analytics-oversigt, hvis den har Core Web Vitals-data fra virkeligheden. Med WEMASY's hjemmesidebygger kan du sætte det op direkte på din hjemmeside.
Hvad er en god hastighedsscore for en hjemmeside?
En score på 90 eller derover regnes for god, 50 til 89 skal forbedres, og under 50 er dårlig. For Core Web Vitals er målene Largest Contentful Paint under 2,5 sekunder, Interaction to Next Paint under 200 millisekunder og Cumulative Layout Shift under 0,1. En side består kun vurderingen af Core Web Vitals, når alle tre målinger er i det gode område ud fra data fra rigtige besøgende.
Hvorfor varierer min score fra gang til gang?
Scorerne i laboratorietests varierer, fordi forholdene ændrer sig mellem kørslerne: belastningen på serveren, netværket hos testudbyderen og cachen påvirker alle resultatet. Når du kører testen flere gange og tager gennemsnittet, får du et mere pålideligt udgangspunkt. Data fra virkeligheden, som bygger på 28 dages målinger fra rigtige besøgende, er mere stabile og et bedre tegn på jævn ydeevne i forhold til placeringer.
Hvorfor er min mobilscore lavere end min score på computer?
Mobiltests simulerer langsommere processorer og mobilnetværk, og det giver en lavere score for den samme side end på computer. Søgemaskiner bruger mobile-first-indeksering, så det er sidens ydeevne på mobil, der tæller for placeringerne. Regn mobilscoren for det vigtigste resultat at optimere efter, også selvom scoren på computer ser fin ud.
Hvad er forskellen på laboratoriedata og data fra virkeligheden i en hastighedstest?
Laboratoriedata kommer fra en simuleret test under kontrollerede forhold fra et fast sted og med en fast enhed. De er ensartede og gode til at finde bestemte fejl. Data fra virkeligheden kommer fra rigtige besøgende, samlet over et rullende vindue på 28 dage, og viser alle de enheder, forbindelser og steder, dine besøgende faktisk bruger. Søgemaskiner bruger data fra virkeligheden til at bedømme Core Web Vitals. En hjemmeside kan få en god score i laboratoriet og alligevel have dårlige data fra virkeligheden, hvis de besøgendes forhold adskiller sig meget fra testmiljøet.
Hvor ofte bør jeg køre en hastighedstest?
Kør en test efter hver større ændring af din hjemmeside: når du tilføjer store billeder, installerer nye scripts, skifter hosting eller udgiver en ny type side. Til almindelig overvågning er det nok at se på data fra virkeligheden i din analytics- eller ydeevne-oversigt en gang om måneden. Tallene opdateres over et rullende vindue på 28 dage, så du behøver ikke teste hele tiden, men en månedlig gennemgang hjælper dig med at opdage tilbagegang, før den påvirker placeringer eller besøgendes oplevelse.