PageSpeed, GTmetrix og Pingdom: Tre fartmålere, tre svar

Kort svar: PageSpeed Insights, GTmetrix og Pingdom måler under forskellige forhold og svarer derfor forskelligt – uden at nogen af dem tager fejl. PageSpeed Insights kombinerer en Lighthouse-labtest med feltdata fra rigtige Chrome-brugere (CrUX), når der er nok data. GTmetrix er værkstedet, der viser requests, waterfall og rendering i detaljer. Pingdom er stopuret til hurtige syntetiske målinger og løbende overvågning. Brug feltdata til at prioritere, labtests til at diagnosticere og ens testforhold til at bevise, at en ændring faktisk hjalp.

Fagligt gennemgået: 2. oktober 2026

PageSpeed giver dig 58. GTmetrix kvitterer med B. Pingdom siger 1,3 sekunder. Hvem lyver? Sandsynligvis ingen. Du har bare sendt den samme hjemmeside ud på tre forskellige baner med tre forskellige stopure og tre forskellige regelsæt.

Problemet begynder først, når du prøver at gøre alle tre dommere lige glade. Så bliver et helt almindeligt WordPress-site hurtigt udsat for unødig kirurgi: endnu et cacheplugin, tilfældig JavaScript-forsinkelse, preload på alt med en filendelse og måske en font, ingen længere kan læse.

Dit mål er ikke at samle grønne badges. Dit mål er en hjemmeside, hvor besøgende ikke skal vente, før menuen, formularen eller checkout reagerer. Her får du metoden til at læse PageSpeed Insights, GTmetrix og Pingdom Website Speed Test uden at gøre hastighedsoptimering til en jagt på tilfældige flueben. Alle testtal i eksemplerne er illustrative og ikke målinger af hostious.io.

Tre fartmålere – tre forskellige job

En score er ikke hastighed. Den er et sammendrag af en bestemt test, kørt under bestemte forhold og vægtet efter et bestemt regelsæt. Derfor er det mere nyttigt at spørge „hvad kan dette værktøj hjælpe mig med?“ end „hvilket værktøj har det pæneste tal?“.

Værktøj	Brug det især til	Det stærkeste kort	Husk begrænsningen
PageSpeed Insights	Core Web Vitals, mobiloplevelse og Lighthouse-diagnose	Viser både feltdata fra CrUX og en labtest, når der findes nok feltdata	Én labkørsel er ikke alle dine brugeres virkelighed
GTmetrix	Teknisk fejlfinding og før/efter-tests	Detaljeret waterfall, rendering, historik og reproducerbare testvalg	Resultatet afhænger stadig af sted, enhed, netværk og cache
Pingdom	Hurtigt syntetisk overblik og løbende overvågning	Load time, sidestørrelse, requests, waterfall og gentagne kontroller	Karakteren er ikke en Google- eller Core Web Vitals-dom

PageSpeed Insights: færdselskontrollen

PageSpeed Insights har to verdener på samme side. Den ene er feltdata fra Chrome UX Report (CrUX): aggregerede målinger fra kvalificerede Chrome-brugere samlet i et rullende 28-dages vindue, når URL’en eller domænet har tilstrækkelige data. Den anden er labdata: en Lighthouse-test, som simulerer en bestemt enhed og netværksforbindelse her og nu.

Feltdata fortæller, hvordan trafikken faktisk kører, mens labtesten giver dig en prøvekørsel og en liste over mulige årsager. Den længere forklaring finder du i guiden til PageSpeed-labdata kontra CrUX-feltdata.

De tre nuværende Core Web Vitals er LCP, INP og CLS. „God“ betyder ved 75-percentilen: LCP på højst 2,5 sekunder, INP på højst 200 millisekunder og CLS på højst 0,1. PageSpeed viser også blandt andet FCP og TTFB, men de er diagnosetal – ikke ekstra Core Web Vitals, uanset hvor alarmerende et rødt ikon ser ud.

GTmetrix: mekanikeren med motorhjelmen åben

GTmetrix bruger Lighthouse til sin labtest og giver dig et mere værkstedsagtigt blik på siden. Waterfall-diagrammet viser hver request, dens størrelse, domæne, status og timing. Det er her, du ser, om hero-billedet er alt for tungt, om et chatscript belaster browserens main thread, eller om en redirectkæde sender browseren en omvej.

GTmetrix kan også vise CrUX-feltdata, når der findes tilstrækkelige data, men labdelen er stadig én kontrolleret kørsel. Brug den til at reproducere et problem, sammenligne før og efter og læse request-rækkefølgen. Brug ikke bogstavet alene som årsagsanalyse. Et B fortæller, at du bør kigge nærmere – ikke hvilken skrue du skal dreje på.

Pingdom: stopuret og nattevagten

Pingdoms gratis test er god til et hurtigt syntetisk øjebliksbillede: load time, sidestørrelse, antal requests og waterfall fra en valgt testregion. Den betalte overvågning kan gentage tests og vise historik, så en vigtig side ikke langsomt bliver tungere, mens alle har travlt med noget andet.

Pingdoms tal kan være lavere end PageSpeeds mobiltest, fordi vilkårene er anderledes. Det betyder ikke, at Pingdom er „for positiv“, eller at PageSpeed er „sur“. En bil kører hurtigere på motorvej end op ad en våd brostensbakke. Begge observationer kan være rigtige.

Sådan tester du uden at snyde dig selv

Den største fejl i hastighedsoptimering er ikke et dårligt plugin, men en dårlig sammenligning. Hvis „før“ er en kold mobiltest fra USA, og „efter“ er en varm desktoptest fra Europa, har du ikke dokumenteret en forbedring. Du har dokumenteret geografi.

1. Vælg de rigtige URL’er. Test ikke kun forsiden. Medtag en typisk artikel, en vigtig landingsside, en formular og – for en webshop – produkt, kurv og checkout. Skabeloner og funktioner har forskellige flaskehalse.
2. Gem en baseline. Notér URL, værktøj, teststed, enhed, netværksprofil, samtykketilstand, cachetilstand og tidspunkt. Guiden til at gøre en WordPress-side hurtigere starter netop med diagnose før plugins.
3. Kør mindst tre labtests. Brug medianen – ikke den ene kørsel, der tilfældigvis ramte en rolig periode.
4. Lav én reversibel ændring. Ændrer du cache, billeder, CSS og JavaScript på én gang, ved du bagefter kun, at „noget“ skete.
5. Gentag under samme forhold. Sammenlign de samme målinger, ikke bare totalscoren.
6. Test funktionerne. Menu, formular, søgning, samtykke, login, kurv og checkout skal stadig virke på mobil og desktop. Forsvinder checkout, er siden ikke blevet hurtigere – den er holdt op med at drive forretning.

Derfor er værktøjerne uenige

Når resultaterne er forskellige, så sammenlign testvilkårene, før du sammenligner tallene. De hyppigste forklaringer er:

• Testplacering: afstand til serveren påvirker DNS, forbindelse og TTFB.
• CPU og netværk: en langsom simuleret mobil arbejder anderledes end en hurtig testmaskine.
• Mobil kontra desktop: layout, billeder og endda LCP-element kan skifte.
• Kold kontra varm cache: første besøg og gentagne besøg er ikke samme opgave for serveren.
• Cookies og samtykke: chat, tracking og annoncer kan være fraværende før samtykke og aktive bagefter.
• Sluttidspunkt: værktøjerne kan være uenige om, hvornår siden er „færdig“, især når scripts fortsætter efter onload.
• Dynamisk indhold: annoncer, personalisering, embeds og tredjepartsservere varierer fra kørsel til kørsel.
• 28 dage kontra lige nu: CrUX-feltdata ændrer sig gradvist; en labtest kan se din rettelse med det samme.

Derfor giver det heller ikke mening at skrive „vores hjemmeside loader på 0,8 sekunder“ uden at nævne URL, sted, enhed og målepunkt. Det er som at sige, at turen til Aarhus tager 42 minutter, men glemme at fortælle, hvor du startede.

Fra advarsel til rigtig handling

Rapporterne er gode til at pege, men de kender ikke hele dit WordPress-site, din forretning og dine undtagelser. Oversæt derfor hver advarsel til et konkret spørgsmål, før du ændrer noget.

Fund i rapporten	Undersøg først	Undgå refleksen
Høj TTFB	Cache HIT/MISS, origin, PHP og database. Se guiden til høj TTFB i WordPress.	At installere endnu et cacheplugin på mistanke
Dårlig LCP	Find det faktiske LCP-element og dets requestkæde. Brug LCP-guiden.	At preloade alle billeder og håbe på held
Høj TBT eller dårlig INP	Profilér lange JavaScript-opgaver og den konkrete interaktion. Se INP-guiden.	At forsinke alt JavaScript i blinde
Dårlig CLS	Reservér plads til billeder, embeds og bannere, og stabilisér fontskift. Find kilden med CLS-guiden.	At skjule hoppet med animation
Store billeder	Dimensioner, responsive varianter, WebP/AVIF og rimelig kvalitet. Følg rækkefølgen for billedoptimering.	At gøre produktbilleder grødede for to point
Renderblokerende kode	Bevar kritisk CSS; udskyd kun dokumenteret ikke-kritisk kode	At ødelægge menu, formular eller checkout
Mange tredjepartsrequests	Hvilke funktioner skaber de, og hvad koster de? Kortlæg GTM, chat, tracking og andre tredjepartsscripts.	At forsøge at optimere en fremmed server, du ikke styrer
Redirects eller 404-filer	Fjern egne kæder og ødelagte kald ved kilden	At bruge timer på en uundgåelig ekstern redirect
Komprimeringsadvarsel	Kontrollér response headers, og om Brotli eller gzip allerede er aktiv	At „rette“ noget, som allerede er komprimeret

Og en vigtig sproglig fælde: TBT er ikke INP. Total Blocking Time er en labmåling, som kan pege på JavaScript-problemer. Interaction to Next Paint måler faktiske interaktioner i feltdata. De kan pege i samme retning, men de er ikke det samme tal.

Den rigtige rækkefølge i WordPress

Du får normalt mest ud af at arbejde fra fundamentet og op. Den præcise flaskehals bestemmer indsatsen, men denne rækkefølge holder dig væk fra de dyreste omveje:

1. Serverrespons og redirects. Hvis HTML-svaret er sent, kan et perfekt billedformat ikke redde starten. Mål cachet og ucachet TTFB, og fjern unødige redirectkæder.
2. Cachelagene. Page cache, browsercache, CDN/edge-cache og objektcache løser forskellige opgaver. Kortlæg hvilket cachelag der ejer hvad. To overlappende page cache-plugins er sjældent dobbelt så hurtigt – oftere giver de fejl, der er svære at finde.
3. Det synlige hovedindhold. Optimér hero- og produktbilleder, lever passende dimensioner, og lad ikke LCP-billedet vente i en lazy load-kø bag billeder langt under folden.
4. JavaScript og plugins. Fjern funktioner, der ikke skaber værdi. Delay/defer kan hjælpe, men kun når menu, søgning, formular, samtykke og checkout er testet bagefter.
5. Fonte og CSS. Brug de fonte og vægte, designet faktisk behøver. Fjern eller udskyd kun CSS, når du kan bevise, at dynamiske tilstande og mobilvisning stadig fungerer.
6. Tredjepart. Chat, video, tracking og embeds kan koste mere end resten af siden. Behold det, der har et forretningsformål.

Den officielle WordPress-vejledning om performance fremhæver også hosting, software, cache, billeder, plugins, komprimering og database som forskellige lag. Pointen er, at „WordPress er langsomt“ ikke er en diagnose, men begyndelsen på et spørgsmål.

Mini-case: Alle tre har ret

Forestil dig en webshop med disse illustrative resultater:

• PageSpeed Insights’ mobiltest giver 62 i labtesten, men CrUX viser grønne Core Web Vitals.
• GTmetrix giver B og afslører, at et chatscript bruger meget tid på browserens main thread.
• Pingdom måler 1,2 sekunders load time fra en europæisk testplacering.

Det ligner tre vidner, der burde have talt sammen. Men der er ingen reel modsigelse. Feltdata siger, at de fleste faktiske brugere har en god oplevelse. GTmetrix har fundet en konkret optimeringsmulighed i chatten. Pingdom bekræfter, at siden under den valgte syntetiske test har en kort load time.

Den fornuftige handling er ikke at skille webshoppen ad for at få PageSpeed fra 62 til 100. Den er at teste chatten: Hvad koster den? Skaber den salg eller supportværdi? Kan den indlæses efter samtykke eller interaktion uden at skade funktionen? Lav ændringen, gentag de samme tests, og følg feltdata over de næste uger.

Når feltdata mangler

Mindre sites har ofte ikke nok trafik til, at CrUX viser feltdata for den enkelte URL – eller for domænet. Så viser PageSpeed Insights kun labtesten, og det er fristende at behandle scoren som facit. Gør det ikke. Brug i stedet labtesten til at finde konkrete flaskehalse, og suppler med egne målinger:

• Følg Core Web Vitals-rapporten i Search Console, der grupperer lignende URL’er og kan have data, selv når den enkelte side ikke har.
• Brug browserens udviklerværktøjer med netværks- og CPU-begrænsning for at efterligne en almindelig mobil.
• Overvej real user monitoring (RUM), hvis du har brug for løbende data fra egne besøgende – men husk samtykke, hvis værktøjet sætter cookies eller sender persondata til tredjepart.

Hvornår er du færdig?

Du er færdig, når den vigtige brugeroplevelse er god, acceptable resultater kan gentages for de centrale URL’er, og dine funktioner virker. Ikke når hvert værktøj viser det samme tal – det kommer de ikke til – og heller ikke når den sidste gule anbefaling er væk.

Google bruger Core Web Vitals i sine rangeringssystemer, men de er kun en del af det samlede billede, og perfekte værktøjsscores garanterer ikke topplaceringer. Prioritér derfor i denne rækkefølge: alvorlige brugerproblemer, forretningskritiske funktioner, dokumenterede flaskehalse og til sidst kosmetiske scorepoint.

Husk: En 100-score er et flot trofæ. En hurtig side, der stadig sælger, modtager formularer og virker efter næste opdatering, er en forretning.

Få en diagnose – ikke endnu en karakter

Har du tre rapporter og stadig ingen forklaring? Se, hvordan Hostious arbejder med hastighedsoptimering, eller se vores WordPress hosting med LiteSpeed og NVMe. Det vigtige er at finde den dokumenterede flaskehals, ændre sikkert og måle igen under de samme forhold.

Kilder

• Chrome for Developers: CrUX-data i PageSpeed Insights
• web.dev: Sådan er Core Web Vitals-grænserne defineret
• GTmetrix: Sådan læses den aktuelle rapport
• Pingdom: Page Speed Monitoring
• Google Search Central: Page experience i søgeresultater

Læs også

• Hub: WordPress performance og cache
• PageSpeed Insights vs. virkelige brugere: lab-data og CrUX
• Core Web Vitals-rapporten i Search Console
• Høj TTFB i WordPress: cache, PHP, database eller origin?
• Hastighedsoptimering hos Hostious – find og ret den dokumenterede flaskehals

Ofte stillede spørgsmål om PageSpeed, GTmetrix og Pingdom

Hvilken hastighedstest er mest pålidelig?

Ingen test dækker alt. Brug PageSpeed-feltdata til at vurdere den faktiske brugeroplevelse, GTmetrix til teknisk diagnose og Pingdom til hurtige syntetiske målinger og løbende overvågning.

Hvorfor viser værktøjerne forskellige resultater?

De kan bruge forskellige serverplaceringer, enheder, netværksforhold, cachetilstande, beregninger og sluttidspunkter. PageSpeed kan desuden sammenholde en aktuel labtest med 28 dages feltdata. Sammenlign derfor ikke karaktererne direkte, og kør mindst tre tests under samme forhold før og efter en ændring.

Skal min PageSpeed-score være 100?

Nej. En Lighthouse-score på 90–100 er grøn, men Core Web Vitals, stabil funktion og besøgendes oplevelse er vigtigere end de sidste point. Et sikkert 92-tal slår et skrøbeligt 100-tal, hvis det sidste kræver, at vigtige funktioner forsinkes eller fjernes.

Hvorfor er mobilscoren lavere?

PageSpeed Insights’ mobiltest simulerer typisk langsommere CPU og netværk. Mobilen kan også få et andet layout, en anden billedfil og et andet LCP-element end desktop. En lavere mobilscore er derfor ikke mærkelig, men den er værd at undersøge, fordi mange besøgende kommer fra mobil.

Kan hosting alene løse en dårlig PageSpeed-score?

Hosting kan forbedre fundamentet, især serverrespons, cache og stabilitet. Tunge billeder, JavaScript, fonte, tredjepartsressourcer og layoutskift skal fortsat løses i selve sitet, og flere overlappende optimeringsplugins gør det sjældent bedre.