Kort svar: PageSpeed Insights er bedst til at kombinere en kontrolleret Lighthouse-test med aggregerede målinger fra kvalificerede Chrome-brugere, når der er nok data. GTmetrix er mekanikeren, der åbner motorhjelmen og viser requests, waterfall og rendering. Pingdom er stopuret og nattevagten, der især er nyttig 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.
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 mere kirurgi end en kendis før prisuddelingen: endnu et cacheplugin, lidt tilfældig JavaScript-delay, et 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 tage en kaffepause, før menuen, formularen eller checkout reagerer. Her får du den praktiske metode til at læse PageSpeed Insights, GTmetrix og Pingdom Website Speed Test uden at gøre hastighedsoptimering til en olympisk disciplin i tilfældige flueben.
Kontrolramme: Værktøjernes aktuelle beskrivelser og Core Web Vitals-grænser er kontrolleret 2. september 2026. Alle testtal i eksemplerne er illustrative og er ikke målinger af hostious.io.
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 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. Den korte version er, at 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 vores guide 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 kan også vise blandt andet FCP og TTFB, men de er diagnosetal – ikke ekstra Core Web Vitals, uanset hvor meget et rødt ikon ser ud som en personlig fornærmelse.
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 vejer som en campingvogn, om et chatscript starter en lille festival på main thread, eller om en redirect-kæde sender browseren på sightseeing.
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; det fortæller ikke, hvilken skrue du skal dreje på.
Pingdoms gratis test er god til et hurtigt syntetisk snapshot: 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”. Det svarer til, at en bil kører hurtigere på motorvej end op ad en våd brostenstrappe. Begge observationer kan være rigtige; kun den ene er en lidt sær køretur.
Den største fejl i hastighedsoptimering er ikke et dårligt plugin. Det er 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.
Når resultaterne er forskellige, så sammenlign testvilkårene før du sammenligner tallene. De hyppigste forklaringer er:
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 lidt som at sige, at turen til Aarhus tager 42 minutter, men glemme at fortælle, hvor du startede.
Rapporterne er gode til at pege. De er mindre gode til at kende 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å det bedste |
| Høj TBT eller dårlig INP | Profilér lange JavaScript-opgaver og den konkrete interaktion. Se INP-guiden. | At forsinke alt JavaScript blindt |
| 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 den rigtige rækkefølge for billedoptimering. | At gøre produktbilleder til grødet mosaik 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-assets | 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 bedre |
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 tvillinger, og de deler ikke pas.
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:
Den officielle WordPress-vejledning om performance fremhæver også hosting, software, cache, billeder, plugins, komprimering og database som forskellige lag. Pointen er netop, at “WordPress er langsomt” ikke er en diagnose. Det er begyndelsen på et spørgsmål.
Forestil dig en webshop med disse illustrative resultater:
Det ligner tre forklaringer fra tre vidner, der burde tale sammen på gangen. Men der er ingen reel modsigelse. Feltdata siger, at langt 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 demontere webshoppen 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. Mysteriet er løst, og checkout overlevede afhøringen.
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 rankingsystemer, 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.
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.
Ingen test er bedst til 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.
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.
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.
Kør mindst tre labtests under samme forhold før og efter ændringen, og sammenlign medianen. Følg derefter feltdata over de følgende uger, fordi CrUX er et rullende 28-dages vindue.
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 faktisk kommer fra mobil.
Hosting kan forbedre fundamentet, især serverrespons, cache og stabilitet. Tunge billeder, JavaScript, fonte, tredjepartsressourcer og layoutskift skal fortsat løses i selve sitet.
Kun når du ved, hvilken flaskehals det skal løse. Flere overlappende optimeringsplugins kan skabe dobbelt cache, ødelagte scripts og vanskelig fejlfinding. Mål først, vælg ét ansvarligt lag, og eftertest.
Har du tre rapporter og stadig ingen forklaring? Se, hvordan Hostious arbejder med hastighedsoptimering, eller se vores WordPress-hosting. Det vigtige er at finde den dokumenterede flaskehals, ændre sikkert og måle igen under de samme forhold.
