En god responstid for et nettsted, målt som time to first byte for en HTML-side, er grovt regnet under 200 millisekunder for en hurtigbufret side og under 600 millisekunder for en dynamisk side. Googles veiledning på web.dev regner en time to first byte på 0,8 sekunder eller mindre som bra. Over omtrent ett sekund begynner besøkende å merke ventetiden før noe vises på skjermen. Tallene er tommelfingerregler, ikke absolutte grenser: det viktigste er at responstiden er stabil, og at du merker det når den glir ut.
Denne guiden forklarer hva responstid måler, hvordan den skiller seg fra lastetid, hvorfor monitoren og nettleseren din viser ulike tall, og hvordan du følger med på den så treghet blir rettet før den blir til driftsavbrudd.
Responstid er ikke lastetid
De to begrepene blir ofte blandet sammen, men de måler forskjellige ting.
Responstid er hvor lang tid serveren bruker på å svare på én enkelt forespørsel. For en monitor betyr det som regel tiden fra forespørselen sendes til svaret er mottatt.
Lastetid er hvor lang tid nettleseren bruker på å vise en brukbar side. Den omfatter responstiden for HTML-dokumentet, pluss nedlasting og kjøring av CSS, JavaScript, fonter og bilder, ofte flere titalls ekstra forespørsler.
En side kan ha rask responstid og treg lasting, for eksempel når serveren svarer på 150 millisekunder, men siden deretter laster tre megabyte JavaScript. Tipsene våre for et nettsted som laster raskere dekker den frontend-siden. Det motsatte skjer også: en godt optimalisert frontend kan ikke skjule en server som bruker fire sekunder på å lage HTML-en. Responstiden er den delen serveren og hostingen din styrer. Lastetiden er den delen frontenden styrer. Begge er viktige, og de krever ulike tiltak. For lastetid kjører Uptimechecks overvåking av sidehastighet Google Lighthouse hver dag på mobil og desktop og varsler deg når mobilscoren til en side faller under grensen din.
Hva time to first byte består av
Time to first byte, eller TTFB, er tiden fra forespørselen starter til den første byten av svaret kommer frem. Den består av flere steg:
DNS-oppslag: vertsnavnet gjøres om til en IP-adresse.
TCP-tilkobling: rundturen for å åpne en tilkobling.
TLS-håndtrykk: enighet om kryptering for HTTPS.
Serverbehandling: applikasjonen kjører, spør databasen og bygger svaret.
Første byte på linja: starten på svaret på vei tilbake.
Du kan se hvert steg for ditt eget nettsted 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/
Verdiene er kumulative. Er tls 0,12 sekunder og ttfb 0,95 sekunder, brukte serveren omtrent 0,8 sekunder på å lage siden. Det er tallet du skal jobbe med. Er DNS- eller connect-stegene store, ligger problemet i avstand, nettverk eller DNS og ikke i applikasjonen. Uptimecheck deler responstiden for hver sjekk inn i de samme fasene: DNS, tilkobling, TLS, server og nedlasting.
Hvorfor monitorer og nettlesere viser ulike tall
Det er normalt at oppetidsmonitoren, utviklerverktøyene i nettleseren og et verktøy for ytelsestesting viser ulike responstider for samme side. De vanlige årsakene:
Lokasjon. En sjekk fra et annet kontinent legger til rundturer for hvert steg ovenfor. En server i Stockholm svarer en besøkende i Stockholm raskere enn en sjekk fra østkysten av USA.
Gjenbruk av tilkoblinger. Nettleseren holder tilkoblinger åpne og bruker dem om igjen. En overvåkingssjekk åpner ofte en ny tilkobling hver gang og betaler dermed for DNS, TCP og TLS ved hver forespørsel.
Hurtigbuffer. Nettleseren kan ha hele eller deler av siden i hurtigbufferen, og et CDN kan levere en hurtigbufret kopi til noen regioner og ikke til andre.
Hva som måles. Ett verktøy viser TTFB, et annet den totale tiden for å laste ned hele svaret, et tredje hele sidelastingen.
Informasjonskapsler og innlogging. Innloggede brukere går ofte utenom sidehurtigbufferen, så svarene deres er tregere enn en anonym sjekk.
Ingen av disse gjør ett av tallene feil. Det viktige er å sammenligne likt med likt: samme sjekk, fra samme lokasjon, over tid. En monitor som måler samme forespørsel hvert minutt, gir deg et stabilt referansenivå, og det er endringer mot det nivået du skal handle på.
Rimelige mål, som tommelfingerregler
Intervallene nedenfor er tommelfingerregler for serverens svar på en HTML-side eller et API-kall, målt fra en lokasjon rimelig nær serveren. De er et utgangspunkt for ditt eget referansenivå, ikke en standard.
Type svarKomfortabeltVerdt å undersøkeHurtigbufret side eller statisk fil via CDNunder 100–200 msover 400 msDynamisk side (CMS, nettbutikk, app)under 300–600 msover 1 sEnkelt API-endepunkt for lesingunder 100–300 msover 800 msSøk, rapporter, tunge spørringerunder 1–2 sover 3 s
To merknader om hvordan du leser tabellen. For det første: legg til nettverksavstand. En sjekk fra et annet kontinent kan legge til noen hundre millisekunder, og det er ikke noe applikasjonen din kan rette. For det andre er kolonnen som betyr mest, den du setter selv. Svarer kassen din normalt på 350 ms og i dag på 900 ms, har noe endret seg, selv om 900 ms fortsatt ser akseptabelt ut på papiret.
Hva som gjør responstiden tregere
Når responstiden øker, er årsaken nesten alltid en av disse:
Trege databasespørringer: en manglende indeks, en spørring som vokser med størrelsen på en tabell, eller en plugin som kjører dusinvis av spørringer per side.
Ingen side- eller objekthurtigbuffer: hver forespørsel bygger den samme siden fra bunnen av.
Eksterne kall under forespørselen: API-er for betaling, frakt, søk eller analyse som kalles synkront mens den besøkende venter.
For få workers: forespørsler stiller seg i kø bak hverandre når alle workers i PHP-FPM, Node eller applikasjonsserveren er opptatt.
Ressurspress: CPU på grensen, minne som swapper eller disk-I/O som er mettet av sikkerhetskopier eller loggskriving.
Kaldstarter: serverløse funksjoner og containere som er skalert ned til null, bruker tid på å starte ved første forespørsel.
Avstand: besøkende langt fra serveren uten CDN imellom.
Køer er grunnen til at responstid betyr noe for tilgjengeligheten. Når svarene blir tregere, holder hver forespørsel på en worker lenger, køen fylles opp, og nye forespørsler må vente eller blir avvist. En treghet som starter som et ekstra halvt sekund, kan ende som en 503 Service Unavailable-feil ved neste trafikktopp.
Følg trenden, ikke én enkelt sjekk
Én treg sjekk betyr lite. Et nettverksblaff, en pause for garbage collection eller en bom i hurtigbufferen kan gjøre én forespørsel treg. Det som forteller deg at noe er galt, er et mønster:
Et trinnvis hopp: responstiden hopper etter en deploy, en plugin-oppdatering eller et bytte av hosting, og blir liggende der.
En langsom stigning: responstiden øker litt hver uke etter hvert som en tabell eller en logg vokser.
Et døgnmønster: responstiden får topper på samme tid hver dag, ofte en sikkerhetskopi, en import eller en cron-jobb som konkurrerer om ressursene.
En regional forskjell: én region er treg mens en annen er fin, noe som peker mot et CDN, ruting eller DNS heller enn serveren.
Uptimecheck lagrer responstiden for hver sjekk for hver oppetidsmonitor og API-monitor, viser den i diagrammer med median og 95-persentil, og de ukentlige og månedlige e-postrapportene viser gjennomsnittlig responstid ved siden av oppetiden. Det er den historikken som gjør at du ser et trinnvis hopp samme dag som det skjer, i stedet for uker senere.
Varsle om vedvarende treghet
Varsler for hver treg sjekk skaper støy, og støyende varsler blir ignorert. Varsle om treghet som varer. En praktisk tilnærming:
Mål referansenivået for hvert viktig endepunkt over en uke eller to.
Sett varslingsnivået klart over den normale variasjonen, for eksempel to til tre ganger den vanlige responstiden.
Varsle bare når tregheten vedvarer over flere sjekker eller minutter på rad.
Send varsler om treghet til en teamkanal, og hold pushvarsler til mobilen for rene feil.
Sett en tidsavbruddsgrense på hver sjekk. Et svar som tar 30 sekunder, er en feil for en besøkende, uansett statuskode.
I Uptimecheck setter du en grense for treg respons per monitor. Når tre sjekker på rad er tregere enn grensen, får du et varsel om treghet, og et nytt når monitoren blir rask igjen. Treg tid teller ikke som nedetid.
De samme prinsippene gjelder for alle varsler du setter opp. Guiden vår om færre falske varsler i oppetidsovervåking går nærmere inn på bekreftelse og terskler, og valg av varslingsterskler for servere forklarer hvordan du setter grenser for CPU, minne og disk. Når responstidene stiger, viser serverovervåking ved siden av oppetidssjekkene om det er serveren som er årsaken, så du slipper å gjette mellom databasen, nettverket og koden.
Sjekkliste for responstid
Mål TTFB for de viktigste sidene og endepunktene med curl, fra et sted nær serveren.
Overvåk de samme sidene hvert minutt, og ta vare på historikken.
Skriv ned et referansenivå per endepunkt, og sammenlign mot det, ikke mot et generelt tall.
Undersøk trinnvise hopp etter deployer og langsomme stigninger over uker.
Hurtigbufre det du kan, rett trege spørringer og flytt eksterne kall ut av forespørselen.
Varsle om vedvarende treghet og om tidsavbrudd, ikke om enkeltstående trege sjekker.
Oppsummering
En god responstid er lav for den typen side det gjelder, nær ditt eget referansenivå og stabil over tid. Som tommelfingerregel bør du sikte på noen hundre millisekunder for dynamiske sider og godt under det for hurtigbufrede. Mål den på samme måte hver gang, følg trenden og se på en vedvarende økning som et tidlig varsel, for dagens trege side er ofte morgendagens driftsavbrudd.
Uptimecheck registrerer responstiden ved hver sjekk, så du ser treghet i tillegg til driftsavbrudd. Prøv gratis i 14 dager, uten kredittkort.