Hvad er det hurtigste webhotel? 7 ting du skal måle

Kort svar: Det hurtigste webhotel finder du ved at måle, ikke ved at læse produktark. Kør samme WordPress-site under samme forhold, og sammenlign TTFB på både cachede og ucachede sider samt feltdata for LCP, INP og CLS på mobil. Sigt efter LCP på højst 2,5 sek., INP på højst 200 ms og CLS på højst 0,1 på de sider, der skaber omsætning – også kurv og checkout.

Fagligt gennemgået: 2. oktober 2026

Et hurtigt webhotel er sjældent det, der vinder én enkelt PageSpeed-test. Det er den platform, der konsekvent leverer lav serverrespons og gode brugerdata på rigtige sider, rigtige enheder og rigtige besøg.

Når du måler rigtigt, bliver valget af webhotel langt mindre baseret på markedsføring og langt mere baseret på dokumenterbar performance. Det gælder især for WordPress og WooCommerce, hvor cache, databasekald og tredjepartsscripts hurtigt kan sløre, hvad hostingen faktisk bidrager med.

Det vigtigste kort fortalt

• Du finder det hurtigste webhotel ved at måle både TTFB og Core Web Vitals i feltdata – især LCP, INP og CLS – på det samme website under samme testforhold.
• TTFB viser serverens og forbindelsens første respons, men det er ikke en Core Web Vital og kan ikke alene afgøre, om brugeren oplever sitet som hurtigt.
• PageSpeed Insights kombinerer feltdata fra CrUX og labdata fra Lighthouse. Feltdata dækker de seneste 28 dage og vejer tungere end en enkelt lab-score, når du vælger webhotel.
• Google Search Console grupperer URL’er efter status og målepunkt. Har en URL-gruppe nok data, afgøres gruppens status af det dårligste målepunkt.
• Til WordPress og WooCommerce bør du især teste ucachede sider, kurv/checkout, mobiltrafik og den samme plugin-stack på tværs af udbydere.
• En praktisk tommelfingerregel er at sigte efter LCP ≤ 2,5 sek., INP ≤ 200 ms, CLS ≤ 0,1 og en stabil TTFB på de vigtigste landingssider.

Hvad betyder “hurtigste webhotel” egentlig?

Et hurtigt webhotel er en platform, hvor WordPress eller WooCommerce holder lav TTFB og stabile Core Web Vitals under reel trafik. Google vurderer ikke kun første byte, men også hvor hurtigt indhold vises, reagerer og holder sig stabilt.

I praksis betyder det, at du skal skelne mellem rå serverhastighed og oplevet hastighed. En server kan sende første byte hurtigt, men brugeren kan stadig vente længe på det største synlige element, kæmpe med træg interaktion eller opleve layout, der hopper rundt.

Hvis du kun måler forsiden, får du ofte et for pænt billede. De vigtige sider er tit kategorier, produktsider, søgning, login, kurv og checkout, fordi de belaster PHP, database og browser langt mere end en statisk landingsside.

Det er også værd at tænke i stabilitet. Et webhotel, der er hurtigt kl. 10 og ustabilt kl. 20, er ikke reelt hurtigt. Den mest pålidelige vurdering får du, når flere målinger peger i samme retning over tid.

Skal du måle TTFB eller Core Web Vitals først?

Du skal måle begge dele, men TTFB og Core Web Vitals svarer på to forskellige spørgsmål. web.dev og Google bruger TTFB som mål for server og forbindelse, mens Core Web Vitals vurderer den reelle oplevelse af indlæsning, interaktivitet og visuel stabilitet.

TTFB måler tiden fra navigationen starter, til den første byte af svaret begynder at ankomme. Målet er nyttigt, fordi det afslører, om flaskehalsen ligger i netværk, server, cache, PHP eller database, før browseren overhovedet kan komme videre.

Core Web Vitals går videre. LCP siger noget om, hvornår hovedindholdet er synligt. INP siger noget om responsivitet ved interaktion. CLS siger noget om visuel stabilitet. Mange forveksler en lav TTFB med et hurtigt site, men det er en klassisk fejl.

Hvis TTFB er høj, starter fejlsøgningen ofte på hostingen. Hvis TTFB er lav, men LCP eller INP stadig er dårlige, ligger problemet oftere i frontend, billeder, JavaScript, tredjepartstags eller tunge temaer.

Hvilke 7 ting skal du måle for at finde det hurtigste webhotel?

De syv vigtigste målinger kombinerer benchmark, serverrespons og reel brugeroplevelse. Brug dem samlet, ellers risikerer du at vælge et webhotel, der ser hurtigt ud i en test, men ikke i drift.

Først når du måler samme site, samme plugins og samme kritiske sidetyper, bliver sammenligningen fair. Derefter giver de enkelte målepunkter mening.

1. Samme WordPress-site på tværs af udbydere: Kør den samme installation hos fx Hostious og mindst én anden relevant udbyder, så du måler hosting og ikke forskelle i tema, plugins eller indhold.
2. TTFB: Mål serverens første respons på både cachede og ucachede sider.
3. LCP: Mål hvornår det største synlige element bliver gengivet, især på mobil.
4. INP: Mål hvor hurtigt sitet reagerer på klik, tryk og input; en god INP er 200 ms eller lavere.
5. CLS: Mål om layoutet flytter sig under indlæsning; en god grænse er 0,1 eller lavere.
6. Feltdata fra CrUX og Search Console: Se på faktiske brugere over tid, ikke kun en enkelt testkørsel.
7. Labdata og dynamiske sider uden cache: Test med Lighthouse eller lignende, men inkluder kurv, checkout, søgning og login, hvor cache ofte hjælper mindre.

Hvordan tester du TTFB korrekt på samme website?

En korrekt TTFB-test kræver identisk WordPress-stack, samme geografi og gentagne målinger. Hvis bare ét af de forhold ændrer sig, tester du ikke webhotellet rent.

Trin 1 er at standardisere miljøet. Brug samme PHP-version, samme WordPress-version, samme databaseindhold, samme plugins og samme CDN-status. Hvis den ene udbyder har ekstra optimeringslag slået til og den anden ikke har, bliver resultatet skævt fra start.

Trin 2 er at teste flere URL-typer. Start med forsiden, fortsæt med en tung produktside, en kategoriside og mindst én dynamisk side. På WooCommerce bør du se særskilt på kurv og checkout, fordi de ofte omgår fuld page cache.

Trin 3 er at måle flere gange fra samme region og gerne på forskellige tidspunkter af dagen. En enkelt hurtig måling kan være held. Et mønster på tværs af gentagelser er langt mere brugbart, især hvis du leder efter stabile svartider under belastning.

Sådan måler du TTFB i praksis

Du behøver ikke specielle værktøjer. I Chrome åbner du DevTools, vælger fanen Network, genindlæser siden og klikker på det første dokument. Under Timing står “Waiting for server response”, som er serverens del af TTFB. Fra en terminal kan du bruge curl og gentage målingen et par gange:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://ditdomaene.dk/

Tilføj en tilfældig parameter som ?nocache=123 til adressen, hvis du vil se en ucachet side, og tjek cache-headerne for at se, om svaret kom fra cachen. Læs mere om høj TTFB i WordPress.

Hvordan læser du PageSpeed Insights uden at forveksle labdata og feltdata?

PageSpeed Insights er kun nyttigt, hvis du skelner skarpt mellem CrUX og Lighthouse. Google viser begge, men de har forskellige formål og skal læses forskelligt (se også PageSpeed Insights vs. virkelige brugere).

Mange kigger først på den store score og stopper der. Det er ofte den forkerte genvej. Når du vurderer et webhotel, er den vigtigste indsigt normalt, om rigtige brugere får gode målinger over tid, ikke om en enkelt syntetisk test gav 96 i stedet for 89.

• Feltdata: Kommer fra CrUX og viser data fra rigtige brugere for FCP, INP, LCP og CLS over de seneste 28 dage.
• Labdata: Kommer fra Lighthouse og bruges til at genskabe fejl, teste ændringer og finde sandsynlige flaskehalse i et kontrolleret miljø.
• Mobil og desktop: Vurder dem hver for sig, fordi mobilens CPU, netværk og rendering ofte afslører problemer, som desktop skjuler.
• Praktisk læsning: Hvis feltdata er gode, men labdata er middelmådige, er brugeroplevelsen ofte stadig acceptabel. Hvis labdata er flotte, men feltdata er dårlige, bør du stole mest på feltet.

En god tommelfingerregel er at bruge labdata til diagnose og feltdata til beslutninger. Det er især vigtigt, når du skal vælge mellem to webhoteller, der begge ser fine ud i en demo.

Hvordan bruger du Google Search Console til at finde langsomme URL-grupper?

Google Search Console er mest nyttig til mønstre, ikke til enkeltstående anekdoter. Rapporten for Core Web Vitals grupperer URL’er efter status, målepunkt og URL-gruppe, så du kan se, hvor problemet faktisk ligger.

Trin 1 er at åbne rapporten og skelne mellem mobil og desktop. Hvis mobil er rød eller gul, mens desktop er grøn, er det et tydeligt signal om, at du skal optimere ud fra den svageste virkelighed, ikke den flotteste.

Trin 2 er at se på grupperne. Search Console vurderer kun LCP, INP og CLS i denne rapport, og hvis en URL-gruppe har nok data, afgøres gruppens status af det dårligste målepunkt. Det betyder, at en fin LCP ikke redder en gruppe med dårlig INP.

Trin 3 er at koble grupperne til sidetyper. Hvis det især er produktsider, der er langsomme, peger det ofte mod billeder, tema, produktwidgets eller databasekald. Hvis det især er checkout, peger det oftere mod dynamiske processer, scripts og sessioner.

Hvorfor kan et hurtigt webhotel stadig give dårlig INP?

Et hurtigt webhotel kan sagtens kombineres med dårlig INP, fordi INP ofte afslører frontend-arbejde, ikke kun serverarbejde. web.dev bruger INP som mål for responsivitet, og en god værdi er 200 ms eller lavere.

Når en bruger klikker, skal browseren have tid til at behandle hændelser, køre JavaScript, opdatere DOM og tegne ændringen. Hvis temaet er tungt, eller plugins lægger for meget på hovedtråden, bliver interaktionen sløv, selv når serveren svarer hurtigt.

Det er her, mange fejlfortolker performance. De skifter udbyder, ser bedre TTFB og forventer automatisk bedre respons på knapper, filtre og formularer. Det sker ikke altid. Hvis problemet ligger i scriptmængde, event handlers eller tredjepartstags, skal det løses i applikationen.

På WooCommerce ses det tit på produktfiltre, minikurv, variationer og eksterne scripts til tracking eller chat. Hvis TTFB er god, men INP stadig er svag, er næste skridt næsten altid at reducere JavaScript-arbejde og forsinke ikke-kritiske scripts (se dårlig INP i WordPress).

Hvad er forskellen på delt hosting, VPS og dedikerede servere for hastighed?

Delt hosting, VPS og dedikerede servere kan alle være hurtige, men de giver ikke samme forudsigelighed. Til WordPress og WooCommerce er ressourceisolering ofte lige så vigtig som rå CPU-kraft.

På delt hosting deler du miljø med andre kunder. Det kan fungere fint til mindre sites, men du er mere sårbar over for støjende naboer, varierende I/O og begrænset kontrol over caching, PHP-workers og serverstack.

En VPS giver mere kontrol og bedre isolation, men også større ansvar. Hvis den er underdimensioneret eller dårligt tunet, kan den levere ringere resultater end et stærkt administreret webhotel. Den klassiske misforståelse er, at VPS automatisk er hurtigere. Det afhænger af konfigurationen.

Dedikerede servere giver den mest stabile performanceprofil, især under tung WooCommerce-trafik, importjob eller mange samtidige processer. Ulempen er pris og kompleksitet, medmindre løsningen er administreret. Hvis du prioriterer forudsigelighed, er dedikeret eller stærkt isoleret hosting ofte det mest logiske sammenligningsgrundlag.

Hvordan isolerer du cache, CDN og databaseeffekt i din måling?

Du isolerer dem bedst ved at teste i lag. Først uden hjælpemidler, derefter med cache og til sidst på dynamiske flows, hvor page cache ikke skjuler problemerne.

Trin 1 er at måle origin-performance. Deaktiver eller omgå fuld page cache på en relevant testside, og se på TTFB og LCP. Det viser, hvor hurtigt server, PHP og database faktisk arbejder uden makeup.

Trin 2 er at måle med cache og CDN aktivt. Her ser du, hvad den færdige brugeroplevelse bliver for anonyme besøgende. Hvis brugere i mange lande er vigtige, kan et CDN forbedre svartiderne markant. Er målgruppen næsten kun dansk, skal origin stadig være stærk, fordi gevinsten ellers kan virke større på papiret end i salget.

Trin 3 er at teste sider, som cache ikke redder fuldt ud. På WooCommerce gælder det især login, konto, kurv og checkout. Tip: Hvis en udbyder kun viser dig flotte tal på den cachede forside, mangler du stadig svaret på den vigtigste del af sammenligningen.

Hvornår er et webhotel hurtigt nok til WordPress og WooCommerce?

Et webhotel er hurtigt nok, når de vigtigste sidetyper holder Googles grænser for “god” i feltdata ved 75. percentil og samtidig har fornuftig serverrespons på ucachede flows. Det er et langt stærkere mål end en pæn enkeltscore.

75. percentil betyder groft sagt, at vurderingen tager højde for, hvordan den langsommere del af de normale besøg performer. Du behøver ikke perfekte tal for hvert eneste besøg, men størstedelen af dine brugere skal have en god oplevelse.

Som praktisk minimum kan du bruge disse målepunkter:

• LCP på 2,5 sek. eller lavere
• INP på 200 ms eller lavere
• CLS på 0,1 eller lavere
• TTFB på 0,8 sek. eller lavere, som web.dev bruger som tommelfingerregel – og gerne en del lavere på en ukompliceret, cachet side

For WooCommerce bør du lægge ekstra vægt på kategori, produktside, søgning, kurv og checkout. Hvis kun forsiden er hurtig, men de sider, der skaber omsætning, er langsomme, er webhotellet ikke hurtigt nok til opgaven.

Hvilke røde flag viser, at benchmarken er misvisende?

En misvisende sammenligning afsløres ofte af uens testforhold, for få målinger eller en alt for pæn demoversion. Sammenligner du ikke på lige vilkår, får du en flot rapport, men en dårlig beslutning.

Det første røde flag er, at du sammenligner forskellige websites. Et let tema med få plugins vil næsten altid se bedre ud end en tung webshop, uanset udbyder. Det andet røde flag er, at du kun tester desktop. Mobil viser langt flere reelle problemer.

Det tredje røde flag er, at kun cachede sider indgår. Så tester du primært cachelaget, ikke hele webhotellets evne til at drive en applikation. Det fjerde er geografi. Hvis den ene test køres fra Frankfurt og den anden fra København, bliver TTFB forskellig af andre årsager end hostingen.

Det sidste røde flag er, at feltdata ignoreres. Hvis en udbyder ser stærk ud i Lighthouse, men Search Console stadig viser dårlige URL-grupper for LCP, INP eller CLS, bør du holde igen. Hvis samme site både får lavere TTFB og bedre feltdata hos en anden udbyder, har du et langt mere solidt grundlag for at skifte.

Hvad koster et langsomt webhotel din virksomhed?

Hastighed er ikke kun et teknisk tal. Hvis din virksomhed lever af leads, bookinger eller onlinesalg, mærkes et langsomt webhotel direkte på henvendelser og omsætning, længe før nogen kigger på en Lighthouse-rapport.

Brugernes tålmodighed er kort. Ifølge Cloudflare forventer besøgende sider, der loader på under 3 sekunder, og langsommere sider rammer både konverteringsrate, søgesynlighed og omsætning. Derfor er Googles grænse på 2,5 sek. for LCP ikke kun et SEO-krav, men også et forretningskrav.

Kobl derfor dine tekniske målinger til forretningstal. Når du sammenligner to webhoteller, så se ikke kun på TTFB og Core Web Vitals, men også på:

• Konverteringsrate pr. sidetype: Falder konverteringen på produktsider og checkout, når LCP eller INP stiger?
• Afvisningsprocent på mobil: Mobilbrugere forlader langsomme sider først, så her viser gevinsten ved et hurtigere webhotel sig tydeligst.
• Henvendelser og bookinger: Formularer og bookingflows er ofte dynamiske og dermed ucachede, så de afslører serverens reelle styrke.
• Tabte besøg i spidsbelastning: Kampagner, nyhedsbreve og sæsonsalg viser, om webhotellet holder svartiderne, når det gælder.

Er du i tvivl om, hvorvidt problemet overhovedet ligger i hostingen, så afklar først, om din hjemmeside er langsom på de sider, der skaber omsætning, og sammenlign derefter webhoteller.

Hvilke driftskrav skal følge med hastigheden?

Det webhotel, der er hurtigst på testdagen, er ikke nødvendigvis hurtigst om seks måneder. Hastighed skal vedligeholdes, og derfor bør din sammenligning også omfatte de værktøjer, der gør det muligt at holde sitet hurtigt uden at tage chancer i produktion.

Krav	Hvorfor det påvirker hastigheden over tid	Sådan tjekker du det
Staging	Cache-indstillinger, nye plugins og temaopdateringer kan ødelægge både TTFB og INP. Med et testmiljø måler du effekten, før ændringen rammer live-sitet.	Er staging inkluderet i den plan, du overvejer, og kan du kopiere begge veje?
Hyppig backup	Jo kortere vej tilbage efter en dårlig opdatering, desto mindre risiko behøver du at tage, når du optimerer.	Hvor ofte tages backup, hvor længe gemmes den, og hvor lang tid tager en gendannelse?
Cache og SSL uden ekstra opsætning	Serverbaseret cache og SSL, der virker fra start, giver stabile målinger fra dag ét i stedet for et ekstra lag, du selv skal tune.	Er cache og SSL med i prisen, og virker de uden manuel konfiguration?
Kontrolpanel med overblik	Overblik over PHP-version, cache og ressourcer gør det lettere at holde testforholdene ens og fejlsøge hurtigt.	Kan du selv styre PHP-version, cache-tømning og domæner?
Support hele døgnet	Et webhotel, der er langsomt kl. 20, hjælper ikke, hvis supporten først svarer i morgen.	Er der dansk support døgnet rundt, og har de teknisk indsigt i WordPress og WooCommerce?

For danske virksomheder bør du desuden tage GDPR og datahåndtering med i vurderingen. Et hurtigt webhotel, hvor persondata og backups håndteres uden klare rammer, løser ét problem og skaber et andet.

Vil du teste cache- og pluginændringer sikkert, kan du læse mere om staging i WordPress, før du ruller noget ud på live-sitet.

Hvornår giver det mening at skifte til et hurtigere webhotel?

Mange virksomheder bliver på et langsomt webhotel, fordi et skifte virker besværligt. Det er sjældent et godt argument, hvis målingerne er entydige. Et skifte er typisk det rigtige valg, når du kan genkende en eller flere af disse situationer:

• Din TTFB er høj på ucachede sider, selvom tema og plugins allerede er trimmet.
• Feltdata i Search Console viser røde eller gule URL-grupper på de sider, der skaber omsætning.
• Svartiderne svinger markant afhængigt af tidspunkt, hvilket peger på delte ressourcer og støjende naboer.
• Du kører WooCommerce på et generisk webhotel, der ikke er sat op til dynamiske sider og mange samtidige processer.
• Du har brug for at kunne skalere til VPS eller dedikeret server hos samme udbyder uden at flytte igen.

Sådan skifter du uden at tabe hastighed eller salg

1. Flyt en kopi først: Test den nye udbyder med en fuld kopi af sitet, før du ændrer DNS. Så måler du under ens forhold og har stadig det gamle site kørende.
2. Test de dynamiske flows: Gennemfør et testkøb, et login og en formularindsendelse hos den nye udbyder, ikke kun et besøg på forsiden.
3. Planlæg DNS-skiftet: Sænk TTL i god tid, og flyt på et tidspunkt med lav trafik, så du undgår unødig nedetid.
4. Mål igen efter 28 dage: Først når CrUX har en fuld periode med data fra den nye udbyder, ved du, om feltdata reelt er blevet bedre.

Spørg også, hvad udbyderen stiller op, hvis hastigheden eller oppetiden svigter. Konkrete aftaler om ansvar ved nedetid eller fejl siger mere om en udbyder end et løfte i salgsmaterialet.

Hos Hostious får du gratis migrering af hele sitet, så du kan måle på samme WordPress- eller WooCommerce-installation før DNS-skiftet. WordPress hosting starter ved 39 kr./md. ekskl. moms og WooCommerce hosting ved 59 kr./md. Alle planer kører på LiteSpeed og NVMe på servere i Europa med daglig backup, gratis SSL og dansk support døgnet rundt, og fra WP StartUp og Woo StartUp får du også staging.

Læs også

• Hub: WordPress performance og cache – alle guides om hastighed samlet ét sted
• Sådan vælger du hurtig hosting til WordPress
• Høj TTFB i WordPress: cache, PHP, database eller origin?
• PageSpeed, GTmetrix og Pingdom: Tre fartmålere, tre svar
• Webhotel hos Hostious – LiteSpeed, NVMe og dansk support
• Hastighedsoptimering af WordPress – vi finder og fjerner flaskehalsene for dig

Ofte stillede spørgsmål om hurtige webhoteller

Hvordan finder jeg det hurtigste webhotel til mit site?

Mål frem for at læse anmeldelser: test TTFB fra Danmark på rigtige sider hos udbyderen, og sammenlign feltdata i PageSpeed. Ét webhotel kan være hurtigt til statiske sider og svagt til WooCommerce – mål dit eget behov.

Hvad er en god TTFB for et dansk webhotel?

web.dev bruger 0,8 sekunder eller mindre som tommelfingerregel. Som praktisk pejlemærke er under 200 ms på cachede sider og under 600 ms på ucachede stærkt. Ligger tallene konsekvent langt over, bremser serveren – uanset hvad produktarket lover.

Betyder ‘ubegrænset trafik’ at webhotellet er hurtigt?

Nej. Ubegrænset gælder næsten altid mængden, ikke farten. De reelle grænser ligger i CPU, RAM og PHP-workers – og det er dem, du mærker, når trafikken stiger.

Gør et CDN mit webhotel hurtigere?

Et CDN gør statiske filer og cachede sider hurtigere for besøgende langt fra serveren. Det hjælper ikke på ucachede sider som kurv og checkout, så en langsom server bliver ikke hurtig af et CDN alene.