Når en browser eller anden klient sender en forespørgsel til en server, går der altid lidt tid, før noget kommer tilbage. Server response time er den tid, der går fra forespørgslen sendes, til den første del af svaret når tilbage. I praksis ser man ofte på, hvornår den første byte modtages.
Målingen er central, fordi den viser, hvor hurtigt serveren begynder at reagere. En høj svartid kan skyldes tung behandling, langsom database eller presset drift, og den kan gøre siden mærkbart langsommere for brugeren.
I teknisk SEO er server response time vigtig, fordi den påvirker både crawl, brugeroplevelse og den samlede hastighed. Den fortæller ikke alt om indlæsningen, men den er et vigtigt udgangspunkt, når man vil finde flaskehalse og forbedre performance.
De to begreber bliver ofte brugt næsten som synonymer, men de dækker ikke helt det samme. Svartid fra serveren beskriver typisk, hvor lang tid serveren bruger på at modtage en anmodning, behandle den og begynde at sende et svar. TTFB (time to first byte) måler derimod tiden fra browseren eller klienten sender anmodningen, til den første byte modtages. Derfor omfatter TTFB ikke kun selve serverens behandlingstid, men også netværksforsinkelse og andre led på vejen.
Overlapet er stort, og i daglig tale bruger mange TTFB som en praktisk indikator for serverens svartid. Det giver mening, fordi en høj TTFB ofte skyldes en langsom server, tunge databasekald eller manglende cache. Men begreberne bør ikke sidestilles helt. Hvis netværket er langsomt, kan TTFB være høj, selv om serveren arbejder hurtigt. Omvendt kan en server have lang behandlingstid, som tydeligt løfter TTFB.
I praksis kan en måling for eksempel vise en TTFB på 900 ms. Her kan 600 ms skyldes serverbehandling, mens 300 ms kommer fra netværk og forbindelsesoprettelse. Når man arbejder med SEO og performance, er det derfor nyttigt at bruge TTFB som et målepunkt, men analysere videre, hvis man vil finde den præcise flaskehals.
Når en server er længe om at svare, bliver hele siden langsommere allerede før browseren kan begynde at hente indholdet. Det er ikke kun et teknisk driftsproblem. En høj server response time kan påvirke, hvor effektivt søgemaskiner kan crawle et website, og den kan samtidig gøre oplevelsen mere træg for rigtige brugere.
Fra et SEO-perspektiv handler det især om crawlbudget og tilgængelighed. Hvis mange sider reagerer langsomt, kan søgemaskiners crawlere nå færre webadresser inden for den tid og de ressourcer, de afsætter til sitet. Det kan betyde, at nye eller opdaterede sider bliver opdaget og genbesøgt senere. Langsom serverrespons er ikke i sig selv et løfte om dårligere placeringer, men den kan gøre det sværere for søgemaskiner at behandle indholdet effektivt.
For brugeren mærkes problemet som ventetid, før siden overhovedet begynder at vise noget meningsfuldt. Det kan forringe den oplevede performance og skubbe vigtige målepunkter i den forkerte retning, især Largest Contentful Paint (LCP). Hvis serveren svarer sent, bliver det sværere at levere det største synlige element hurtigt. Konsekvensen kan være flere afbrudte besøg, lavere engagement og en side, der føles langsom, selv hvis design og kode ellers er optimeret.
Høj svartid opstår sjældent uden en konkret flaskehals. Ofte ligger problemet i selve hostingen, hvor en langsom server, for få ressourcer eller delt kapacitet med andre websites gør, at svar tager for lang tid. Hvis CPU, hukommelse eller disk er presset, bliver selv en enkel side langsommere. Det samme gælder, hvis serveren er sat forkert op eller kører for langt fra brugerne.
En anden hyppig årsag er tunge databaseforespørgsler. Når et website skal hente store mængder data, søge i dårligt optimerede tabeller eller udføre mange forespørgsler på én gang, stiger ventetiden hurtigt. Applikationslogik kan også bremse svartiden. Det sker for eksempel, når systemet udfører unødigt mange beregninger, indlæser for meget indhold eller bruger plugins og moduler, der hver især lægger lidt ekstra forsinkelse oven i det samlede svar.
Tredjepartskald er en overset synder. Hvis siden undervejs skal vente på eksterne tjenester til betaling, statistik, annoncer eller andre integrationer, kan én langsom leverandør forsinke hele svaret. Manglende caching gør problemet større. Uden caching skal serveren gentage de samme processer igen og igen, selv når indholdet sjældent ændrer sig. Derfor bør man altid undersøge, om forsinkelsen kommer fra hostingmiljøet, databasen, applikationen, eksterne kald eller fravær af cache, før man forsøger at løse problemet.
Den vigtigste pointe er at finde den måling, der viser, hvor hurtigt serveren begynder at sende det første indhold tilbage til browseren. I praksis ser du ofte på TTFB (Time to First Byte), som er den mest udbredte indikator for serverens responstid. Tallet siger ikke alt om sidens hastighed, men det viser, hvor lang tid der går, før serveren reagerer på en forespørgsel.
I Lighthouse og PageSpeed Insights vil serverens svartid typisk indgå i diagnosticeringer eller anbefalinger, ofte formuleret som at serverens responstid bør reduceres. Her skal du især kigge efter TTFB eller formuleringer om den indledende serverrespons. Hvis tallet er højt, peger det på forsinkelser i hosting, databasekald, backend-logik eller cache. Rapporterne viser altså ikke kun et tal, men også en indikation af, om problemet sandsynligvis ligger på serversiden.
I GTmetrix finder du lignende målinger under vandfaldsvisning og ydeevnedata. Her kan du se, hvor stor en del af ventetiden der ligger, før den første byte modtages. Det er nyttigt, fordi du kan skelne mellem langsom serverrespons og andre flaskehalse som tunge filer, scripts eller billeder. Målingen skal derfor læses som en del af helheden, men TTFB er som regel det mest direkte sted at begynde.
De største gevinster kommer som regel fra de mest grundlæggende valg. Start med hosting og servermiljø, fordi en langsom eller overbelastet server løfter svartiden for alle forespørgsler. Hvis dit website ligger på billig, delt hosting, kan et skifte til en hurtigere løsning med flere ressourcer give en mærkbar forbedring. Dernæst bør du aktivere caching, så serveren ikke skal bygge samme side igen og igen. Eksempelvis kan fuld sidecache eller objektcache reducere svartiden markant på sider med mange gentagne opslag.
Næste prioritet er et CDN, især hvis du har brugere flere steder i landet eller internationalt. Et CDN aflaster den oprindelige server ved at levere statiske filer som billeder, CSS og JavaScript fra noder tættere på brugeren. Det forbedrer ikke kun indlæsningstiden, men kan også sænke presset på serveren og dermed den initiale responstid.
Derefter bør du gennemgå database og applikationslogik. Langsomme databaseforespørgsler, manglende indekser og tunge plugins er typiske flaskehalse. Ryd op i unødige kald, forkort komplekse forespørgsler, og fjern funktioner, der kører ved hver sidevisning uden reel værdi. Jo lettere applikationen er, desto hurtigere kan serveren sende første svar. Arbejd derfor i denne rækkefølge: hurtigere hosting, caching, CDN og til sidst målrettet optimering af kode og database.
En måling giver først mening, når den sættes ind i den rigtige sammenhæng. Som tommelfingerregel opfattes en server response time ofte som god, når den er lav og stabil, men der findes ikke ét tal, der gælder for alle websites. En enkel informationsside kan forventes at svare hurtigere end en webshop, et loginområde eller en side med tung personalisering.
I praksis vil mange se værdier under cirka 200 ms som stærke, mens 200-500 ms ofte er acceptable afhængigt af løsning og belastning. Kommer svartiden ofte over dette niveau, kan det være et tegn på flaskehalse i server, database, kode eller cache. Men en højere måling er ikke altid et problem i sig selv.
Vurderingen afhænger også af teknologi, trafikmønstre og geografi. Brugere langt fra serverens placering kan opleve længere svartider, og målinger kan variere mellem værktøjer og tidspunkter. Se derfor på mønstre over tid frem for at behandle én enkelt værdi som et universelt facit.
Ikke helt. Server response time beskriver normalt, hvor hurtigt serveren reagerer på en forespørgsel, mens TTFB måler tiden, til den første byte faktisk når frem til browseren.
Derfor kan TTFB også være påvirket af netværk, forbindelsesoprettelse og afstand til serveren. I praksis bruges TTFB dog ofte som den mest anvendelige indikator for serverens svartid.
Det afhænger af typen af website, men en lav og stabil responstid er målet. Mange vil betragte under cirka 200 ms som meget godt, mens 200-500 ms ofte er acceptabelt for mere komplekse løsninger.
Hvis svartiden ofte ligger højere, bør du undersøge hosting, cache, database og backend-kode. Det vigtigste er ikke ét enkelt tal, men om niveauet er konsekvent og passer til sidens formål.
Den mest almindelige måde er at se på TTFB i værktøjer som Lighthouse, PageSpeed Insights eller GTmetrix. Her får du et mål for, hvor lang tid der går, før browseren modtager den første del af svaret.
Du kan også bruge browserens udviklingsværktøjer og se på netværksfanen. Det giver et mere detaljeret billede af, om forsinkelsen opstår på serveren, i netværket eller senere i indlæsningen.
Langsom serverrespons kan gøre det sværere for søgemaskiner at crawle mange sider effektivt. Hvis serveren bruger lang tid på at svare, kan det begrænse, hvor meget indhold der bliver gennemgået inden for det tilgængelige crawlbudget.
Derudover påvirker svartiden brugeroplevelsen og kan forsinke andre hastighedsmålinger, som søgemaskiner også tager højde for indirekte gennem performance og tilgængelighed.
Hvis serveren er længe om at svare, bliver hele indlæsningen skubbet. Browseren kan først begynde at hente og vise indhold, når det første svar kommer frem, og det kan forsinke LCP mærkbart.
Det betyder, at selv et ellers optimeret design kan føles langsomt. Serverrespons er ikke det eneste, der påvirker Core Web Vitals, men det er ofte en tidlig flaskehals i kæden.
Hosting har stor betydning, fordi serverens ressourcer, konfiguration og belastning direkte påvirker svartiden. Billig delt hosting kan give højere responstid, især hvis mange websites deler de samme ressourcer.
En hurtigere hostingløsning med bedre CPU, hukommelse og disk kan ofte give en mærkbar forbedring. Placeringen af serveren spiller også ind, fordi større geografisk afstand kan øge den samlede ventetid.
Ja, i mange tilfælde markant. Caching gør, at serveren kan levere et færdigt eller delvist færdigt svar uden at opbygge siden fra bunden hver gang.
Det reducerer belastningen på både applikation og database. Især sidecache, objektcache og korrekt cache af ofte brugt indhold kan sænke responstiden tydeligt.
Ja. Langsomme eller mange databaseforespørgsler er en klassisk årsag til høj serverrespons. Hvis serveren skal vente på tunge opslag eller dårligt optimerede forespørgsler, bliver svaret forsinket.
Problemet opstår ofte ved manglende indekser, unødigt komplekse forespørgsler eller for mange kald pr. sidevisning. Derfor er databaseoptimering ofte en vigtig del af arbejdet med at sænke svartiden.
Det kan være begge dele. Nogle gange skyldes det et presset hostingmiljø eller for få serverressourcer, og andre gange ligger årsagen i tung backend-kode, langsomme plugins eller ineffektive databasekald.
Derfor bør du ikke gætte. Se på målinger, logfiler og performance-data, så du kan afgøre, om flaskehalsen ligger i infrastrukturen, applikationen eller en kombination.