En bra svarstid för en webbplats, mätt som time to first byte för en HTML-sida, ligger ungefär under 200 millisekunder för en cachad sida och under 600 millisekunder för en dynamisk. Googles riktlinjer på web.dev räknar en time to first byte på 0,8 sekunder eller mindre som bra. Över ungefär en sekund börjar besökarna känna väntan innan något syns på skärmen. Siffrorna är tumregler, inte hårda gränser: det viktigare är att svarstiden är stabil och att du märker när den glider iväg.
Den här guiden förklarar vad svarstid mäter, hur den skiljer sig från sidans laddningstid, varför din övervakning och din webbläsare visar olika siffror och hur du följer svarstiden så att långsamhet åtgärdas innan den blir till avbrott.
Svarstid är inte samma sak som laddningstid
De två begreppen blandas ofta ihop, men de mäter olika saker.
Svarstid är hur lång tid servern tar på sig att besvara en enskild förfrågan. För en övervakning betyder det oftast tiden från att förfrågan skickas tills svaret har kommit fram.
Laddningstid är hur lång tid webbläsaren tar på sig att visa en användbar sida. Den omfattar svarstiden för HTML-dokumentet plus nedladdning och körning av CSS, JavaScript, typsnitt och bilder, ofta dussintals ytterligare förfrågningar.
En sida kan ha snabb svarstid och långsam laddning, till exempel när servern svarar på 150 millisekunder men sidan sedan laddar tre megabyte JavaScript. Våra tips för en webbplats som laddar snabbare tar upp den frontendsidan. Det omvända händer också: en välputsad frontend kan inte dölja en server som tar fyra sekunder på sig att ta fram HTML-koden. Svarstiden är den del som din server och ditt webbhotell styr. Laddningstiden är den del som din frontend styr. Båda spelar roll, och de kräver olika åtgärder. För laddningstiden kör Uptimechecks övervakning av sidhastighet Google Lighthouse varje dag för mobil och dator och larmar dig när en sidas mobilpoäng sjunker under din gräns.
Vad time to first byte omfattar
Time to first byte, eller TTFB, är tiden från att förfrågan startar tills svarets första byte kommer fram. Den består av flera steg:
DNS-uppslag: värdnamnet översätts till en IP-adress.
TCP-anslutning: rundresan för att öppna en anslutning.
TLS-handskakning: parterna kommer överens om krypteringen för HTTPS.
Serverbearbetning: applikationen körs, frågar databasen och bygger svaret.
Första byten på väg: början av svaret skickas tillbaka.
Du kan se varje steg för din egen sajt 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ärdena är kumulativa. Om tls är 0,12 sekunder och ttfb är 0,95 sekunder lade servern ungefär 0,8 sekunder på att ta fram sidan. Det är den siffran du ska arbeta med. Är DNS- eller anslutningsstegen stora ligger problemet i avstånd, nätverk eller DNS snarare än i din applikation. Uptimecheck delar upp svarstiden för varje kontroll i samma faser: DNS, anslutning, TLS, server och nedladdning.
Varför övervakning och webbläsare visar olika siffror
Det är normalt att din upptidsövervakning, webbläsarens utvecklarverktyg och ett verktyg för prestandatester visar olika svarstider för samma sida. De vanligaste orsakerna:
Plats. En kontroll från en annan kontinent lägger till rundresor för vart och ett av stegen ovan. En server i Stockholm svarar en besökare i Stockholm snabbare än en kontroll från USA:s östkust.
Återanvända anslutningar. Webbläsaren håller anslutningar öppna och återanvänder dem. En övervakningskontroll öppnar ofta en ny anslutning varje gång och betalar därför för DNS, TCP och TLS vid varje förfrågan.
Cachning. Webbläsaren kan ha sidan eller delar av den i cachen, och ett CDN kan leverera en cachad kopia till vissa regioner men inte till andra.
Vad som mäts. Ett verktyg rapporterar TTFB, ett annat den totala tiden för att ladda ner hela svaret, ett tredje hela sidladdningen.
Cookies och inloggningar. Inloggade användare går ofta förbi sidcachen, så deras svar är långsammare än en anonym kontroll.
Inget av detta gör någon av siffrorna fel. Det viktiga är att jämföra lika med lika: samma kontroll, från samma plats, över tid. En övervakning som mäter samma förfrågan varje minut ger dig en jämn baslinje, och det är förändringar mot den baslinjen du ska agera på.
Rimliga mål, som tumregler
Intervallen nedan är tumregler för serversvaret på en HTML-sida eller ett API-anrop, mätt från en plats som ligger hyfsat nära servern. De är en utgångspunkt för din egen baslinje, inte en standard.
Typ av svarBekvämtVärt att undersökaCachad sida eller statisk fil via CDNunder 100–200 msöver 400 msDynamisk sida (CMS, webbutik, app)under 300–600 msöver 1 sEnkel API-endpoint för läsningunder 100–300 msöver 800 msSökningar, rapporter, tunga frågorunder 1–2 söver 3 s
Två saker att tänka på när du läser tabellen. För det första tillkommer nätverksavståndet: en kontroll från en annan kontinent kan lägga till några hundra millisekunder, och det är inget din applikation kan åtgärda. För det andra är den viktigaste kolumnen den du sätter själv. Om kassan normalt svarar på 350 ms och i dag svarar på 900 ms har något ändrats, även om 900 ms fortfarande ser godtagbart ut på papperet.
Det här gör svarstiderna långsammare
När svarstiden stiger är orsaken nästan alltid någon av dessa:
Långsamma databasfrågor: ett index som saknas, en fråga som växer med tabellens storlek eller ett plugin som kör dussintals frågor per sida.
Ingen sid- eller objektcache: varje förfrågan bygger samma sida från grunden.
Externa anrop under förfrågan: API:er för betalning, frakt, sök eller analys som anropas synkront medan besökaren väntar.
För få workers: förfrågningar köar bakom varandra när alla workers i PHP-FPM, Node eller applikationsservern är upptagna.
Resursbrist: processorn vid taket, minne som swappar eller disk-I/O som är mättad av säkerhetskopior eller loggskrivningar.
Kallstarter: serverlösa funktioner och containrar som skalats ner till noll tar tid på sig att starta vid första förfrågan.
Avstånd: besökare långt från servern utan något CDN emellan.
Köer är anledningen till att svarstiden spelar roll för tillgängligheten. När svaren blir långsammare håller varje förfrågan en worker längre, poolen fylls och nya förfrågningar får vänta eller avvisas. En långsamhet som börjar som en extra halv sekund kan sluta som ett 503 Service Unavailable-fel vid nästa trafiktopp.
Följ trenden, inte en enskild kontroll
En enskild långsam kontroll säger inte mycket. En kort nätverksstörning, en paus för skräpinsamling eller en cachemiss kan göra en förfrågan långsam. Det som visar att något är fel är ett mönster:
Ett språng: svarstiden hoppar upp efter en driftsättning, en pluginuppdatering eller ett byte av webbhotell, och stannar där.
En långsam ökning: svarstiden växer lite varje vecka i takt med att en tabell eller en logg växer.
Ett dagligt mönster: svarstiden toppar vid samma tid varje dag, ofta en säkerhetskopiering, en import eller ett cron-jobb som konkurrerar om resurserna.
En regional skillnad: en region är långsam medan en annan fungerar bra, vilket pekar på ett CDN, routning eller DNS snarare än servern.
Uptimecheck sparar svarstiden för varje kontroll i varje upptidsövervakning och API-övervakning, visar den i diagram med median och 95:e percentil, och de veckovisa och månatliga e-postrapporterna tar med den genomsnittliga svarstiden bredvid upptiden. Det är den historiken som låter dig se ett språng samma dag som det inträffar i stället för veckor senare.
Larma vid ihållande långsamhet
Att larma vid varje långsam kontroll skapar brus, och brusiga larm ignoreras. Larma vid långsamhet som består. Ett praktiskt tillvägagångssätt:
Mät baslinjen för varje viktig endpoint under en eller två veckor.
Sätt varningsnivån tydligt över den normala variationen, till exempel två till tre gånger den vanliga svarstiden.
Larma bara när långsamheten håller i sig över flera kontroller eller minuter i rad.
Skicka varningar om långsamhet till en teamkanal, och spara pushnotiser till mobilen för rena fel.
Sätt en tidsgräns för varje kontroll. Ett svar som tar 30 sekunder är ett fel för en besökare, oavsett statuskod.
I Uptimecheck sätter du en gräns för långsamma svar per övervakning. När tre kontroller i rad är långsammare än gränsen får du ett larm om långsamhet, och ett till när övervakningen blir snabb igen. Långsam tid räknas inte som driftstopp.
Samma principer gäller för alla larm du ställer in. Vår guide om att minska falsklarm i upptidsövervakningen går igenom bekräftelser och tröskelvärden mer i detalj, och att välja tröskelvärden för serverlarm förklarar hur du sätter gränser för processor, minne och disk. När svarstiderna stiger visar serverövervakning bredvid dina upptidskontroller om det är servern som är orsaken, så att du inte behöver gissa mellan databasen, nätverket och koden.
Checklista för svarstid
Mät TTFB för dina viktigaste sidor och endpoints med curl, nära servern.
Övervaka samma sidor varje minut och spara historiken.
Skriv ner en baslinje per endpoint och jämför mot den, inte mot en generell siffra.
Undersök språng efter driftsättningar och långsamma ökningar över veckor.
Cacha det du kan, åtgärda långsamma frågor och flytta externa anrop ut ur förfrågan.
Larma vid ihållande långsamhet och vid timeouts, inte vid enstaka långsamma kontroller.
Sammanfattning
En bra svarstid är låg för sin typ av sida, nära din egen baslinje och stabil över tid. Som tumregel kan du sikta på några hundra millisekunder för dynamiska sidor och en bra bit under det för cachade. Mät på samma sätt varje gång, följ trenden och se en ihållande ökning som en tidig varning, eftersom dagens långsamma sida ofta är morgondagens avbrott.
Uptimecheck registrerar svarstiden vid varje kontroll, så att du ser långsamhet lika väl som avbrott. Prova gratis i 14 dagar, inget kreditkort behövs.