En god svartid for et website, målt som time to first byte for en HTML-side, er cirka under 200 millisekunder for en cachet side og under 600 millisekunder for en dynamisk side. Googles vejledning på web.dev betragter en time to first byte på 0,8 sekunder eller mindre som god. Over omkring et sekund begynder besøgende at mærke ventetiden, før noget dukker op på skærmen. Tallene er tommelfingerregler, ikke faste grænser: det vigtigste er, at din svartid er stabil, og at du opdager det, når den glider.
Denne guide forklarer, hvad svartid måler, hvordan den adskiller sig fra sidens indlæsningstid, hvorfor din monitor og din browser viser forskellige tal, og hvordan du følger den, så langsomhed bliver rettet, før den bliver til nedbrud.
Svartid er ikke det samme som indlæsningstid
De to begreber bliver ofte blandet sammen, men de måler forskellige ting.
Svartid er, hvor lang tid serveren er om at besvare en enkelt forespørgsel. For en monitor betyder det som regel tiden fra forespørgslen sendes, til svaret er modtaget.
Indlæsningstid er, hvor lang tid browseren er om at vise en brugbar side. Den omfatter svartiden for HTML-dokumentet plus download og kørsel af CSS, JavaScript, skrifttyper og billeder, ofte snesevis af ekstra forespørgsler.
En side kan have en hurtig svartid og en langsom indlæsning, f.eks. når serveren svarer på 150 millisekunder, men siden derefter henter tre megabyte JavaScript. Vores tips til et hurtigere website dækker den frontend-side af sagen. Det modsatte sker også: en veloptimeret frontend kan ikke skjule en server, der bruger fire sekunder på at lave HTML’en. Svartiden er den del, din server og din hosting styrer. Indlæsningen er den del, din frontend styrer. Begge dele betyder noget, og de kræver forskellige løsninger. Til indlæsningen kører Uptimechecks overvågning af sidehastighed Google Lighthouse hver dag på mobil og desktop og giver dig besked, når en sides mobilscore falder under din grænse.
Hvad time to first byte omfatter
Time to first byte, eller TTFB, er tiden fra forespørgslen starter, til den første byte af svaret ankommer. Den består af flere trin:
DNS-opslag: værtsnavnet bliver til en IP-adresse.
TCP-forbindelse: turen frem og tilbage for at åbne en forbindelse.
TLS-handshake: aftalen om kryptering til HTTPS.
Serverbehandling: applikationen kører, spørger databasen og bygger svaret.
Første byte på vej: starten af svaret, der rejser tilbage.
Du kan se hvert trin for dit eget website med curl:
curl -o /dev/null -s -w “dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n” https://northwind.shop/
Værdierne er kumulative. Hvis tls er 0,12 sekunder og ttfb er 0,95 sekunder, brugte serveren omkring 0,8 sekunder på at lave siden. Det er tallet, du skal arbejde med. Hvis DNS- eller connect-trinnene er store, skyldes problemet afstand, netværk eller DNS snarere end din applikation. Uptimecheck deler svartiden for hvert tjek op i de samme faser: DNS, connect, TLS, server og download.
Hvorfor monitorer og browsere viser forskellige tal
Det er normalt, at din oppetidsmonitor, browserens udviklerværktøjer og et værktøj til ydeevnetest viser forskellige svartider for den samme side. De typiske årsager:
Lokation. Et tjek fra et andet kontinent lægger ture frem og tilbage oven i hvert trin ovenfor. En server i Stockholm svarer en besøgende i Stockholm hurtigere end et tjek fra USA’s østkyst.
Genbrug af forbindelser. Din browser holder forbindelser åbne og genbruger dem. Et overvågningstjek åbner ofte en ny forbindelse hver gang og betaler derfor for DNS, TCP og TLS ved hver forespørgsel.
Caching. Din browser har måske siden eller dele af den i cachen, og et CDN kan levere en cachet kopi til nogle regioner og ikke til andre.
Hvad der måles. Ét værktøj viser TTFB, et andet den samlede tid for at hente hele svaret, et tredje hele sidens indlæsning.
Cookies og login. Indloggede brugere springer ofte sidecachen over, så deres svar er langsommere end et anonymt tjek.
Ingen af disse gør ét tal forkert. Det vigtige er at sammenligne det sammenlignelige: det samme tjek, fra den samme lokation, over tid. En monitor, der måler den samme forespørgsel hvert minut, giver dig en ensartet baseline, og det er ændringer i forhold til den baseline, du skal handle på.
Rimelige mål, som tommelfingerregler
Intervallerne nedenfor er tommelfingerregler for serverens svar på en HTML-side eller et API-kald, målt fra en lokation rimeligt tæt på din server. De er et udgangspunkt for din egen baseline, ikke en standard.
Type svarKomfortabeltVærd at undersøgeCachet side eller statisk fil via CDNunder 100–200 msover 400 msDynamisk side (CMS, webshop, app)under 300–600 msover 1 sSimpelt API-endpoint til læsningunder 100–300 msover 800 msSøgning, rapporter, tunge forespørgslerunder 1–2 sover 3 s
To bemærkninger til tabellen. For det første skal du lægge netværksafstanden til: et tjek fra et andet kontinent kan lægge et par hundrede millisekunder oveni, og det kan din applikation ikke rette. For det andet er den kolonne, der betyder mest, den, du selv sætter. Hvis din kasse normalt svarer på 350 ms og i dag svarer på 900 ms, er noget ændret, selvom 900 ms stadig ser acceptabelt ud på papiret.
Hvad der gør svartiden langsommere
Når svartiden stiger, er årsagen næsten altid en af disse:
Langsomme databaseforespørgsler: et manglende indeks, en forespørgsel, der vokser med tabellens størrelse, eller et plugin, der kører snesevis af forespørgsler pr. side.
Ingen side- eller objektcache: hver forespørgsel bygger den samme side op fra bunden.
Eksterne kald under forespørgslen: betalings-, fragt-, søge- eller analyse-API’er, der kaldes synkront, mens den besøgende venter.
For få workers: forespørgsler står i kø bag hinanden, når alle workers i PHP-FPM, Node eller applikationsserveren er optaget.
Pres på ressourcerne: CPU ved grænsen, hukommelse, der swapper, eller disk-I/O, der er mættet af backups eller logskrivning.
Kolde starter: serverless-funktioner og containere, der er skaleret ned til nul, er længe om at starte den første forespørgsel.
Afstand: besøgende langt fra serveren uden et CDN imellem.
Køer er grunden til, at svartid betyder noget for tilgængeligheden. Når svarene bliver langsommere, holder hver forespørgsel på en worker længere, puljen bliver fyldt, og nye forespørgsler må vente eller bliver afvist. En langsomhed, der starter som et ekstra halvt sekund, kan ende som en 503 Service Unavailable-fejl ved næste trafiktop.
Følg udviklingen, ikke et enkelt tjek
Et enkelt langsomt tjek betyder ikke meget. Et netværksblip, en pause til garbage collection eller et cache-miss kan gøre én forespørgsel langsom. Det, der fortæller dig, at noget er galt, er et mønster:
Et spring: svartiden hopper op efter et deploy, en plugin-opdatering eller et skift af hosting og bliver der.
En langsom stigning: svartiden vokser lidt hver uge, efterhånden som en tabel eller en log vokser.
Et dagligt mønster: svartiden topper på samme tidspunkt hver dag, ofte på grund af en backup, en import eller et cron-job, der konkurrerer om ressourcerne.
En regional forskel: én region er langsom, mens en anden er fin, hvilket peger på et CDN, routing eller DNS frem for serveren.
Uptimecheck gemmer svartiden for hvert tjek for hver oppetidsmonitor og API-monitor, viser den i grafer med median og 95. percentil, og de ugentlige og månedlige e-mailrapporter viser den gennemsnitlige svartid ved siden af oppetiden. Den historik gør, at du ser et spring den dag, det sker, i stedet for uger senere.
Giv alarm ved vedvarende langsomhed
Alarmer ved hvert langsomt tjek skaber støj, og støjende alarmer bliver ignoreret. Giv alarm ved langsomhed, der varer ved. En praktisk fremgangsmåde:
Mål din baseline for hvert vigtigt endpoint over en uge eller to.
Sæt advarselsniveauet tydeligt over den normale variation, f.eks. to til tre gange den sædvanlige svartid.
Giv kun alarm, når langsomheden varer ved over flere tjek eller minutter i træk.
Send advarsler om langsomhed til en teamkanal, og hold push-notifikationer til telefonen til egentlige fejl.
Sæt en timeout på hvert tjek. Et svar, der tager 30 sekunder, er en fejl for en besøgende, uanset statuskoden.
I Uptimecheck sætter du en grænse for langsomme svar pr. monitor. Når tre tjek i træk er langsommere end grænsen, får du en alarm om langsomhed, og en til, når monitoren bliver hurtig igen. Langsom tid tæller ikke som nedetid.
De samme principper gælder for alle de alarmer, du sætter op. Vores guide om at reducere falske alarmer i oppetidsovervågning går mere i dybden med bekræftelse og tærskler, og valg af alarmtærskler for servere forklarer, hvordan du sætter grænser for CPU, hukommelse og disk. Når svartiderne stiger, viser serverovervågning ved siden af dine oppetidstjek, om serveren er årsagen, så du ikke skal gætte mellem databasen, netværket og koden.
Tjekliste til svartid
Mål TTFB for dine vigtigste sider og endpoints med curl, tæt på din server.
Overvåg de samme sider hvert minut, og gem historikken.
Skriv en baseline ned pr. endpoint, og sammenlign med den, ikke med et generelt tal.
Undersøg spring efter deploys og langsomme stigninger over uger.
Cache det, du kan, ret langsomme forespørgsler, og flyt eksterne kald ud af forespørgslen.
Giv alarm ved vedvarende langsomhed og ved timeouts, ikke ved enkelte langsomme tjek.
Opsummering
En god svartid er lav for sin type side, tæt på din egen baseline og stabil over tid. Som tommelfingerregel skal du sigte efter nogle hundrede millisekunder for dynamiske sider og et godt stykke under det for cachede sider. Mål den på samme måde hver gang, følg udviklingen, og betragt en vedvarende stigning som en tidlig advarsel, for dagens langsomme side er ofte morgendagens nedbrud.
Uptimecheck registrerer svartider ved hvert tjek, så du ser langsomhed såvel som nedbrud. Prøv det gratis i 14 dage, uden kreditkort.