Hyvä verkkosivuston vasteaika HTML-sivun ensimmäisen tavun aikana mitattuna on noin alle 200 millisekuntia välimuistista tarjoillulle sivulle ja alle 600 millisekuntia dynaamiselle sivulle. Googlen web.dev-ohjeistus pitää enintään 0,8 sekunnin ensimmäisen tavun aikaa hyvänä. Noin sekunnin jälkeen kävijät alkavat tuntea odotuksen ennen kuin ruudulle ilmestyy mitään. Luvut ovat nyrkkisääntöjä eivätkä ehdottomia rajoja: tärkeämpää on, että vasteaikasi on vakaa ja että huomaat, kun se alkaa liukua.
Tämä opas kertoo, mitä vasteaika mittaa, miten se eroaa sivun latausajasta, miksi valvontasi ja selaimesi näyttävät eri lukuja ja miten sitä seurataan, jotta hidastumiset korjataan ennen kuin niistä tulee katkoja.
Vasteaika ei ole sivun latausaika
Termit menevät usein sekaisin, mutta ne mittaavat eri asioita.
Vasteaika on se, kuinka kauan palvelimelta kestää vastata yksittäiseen pyyntöön. Valvonnassa se tarkoittaa yleensä aikaa pyynnön lähettämisestä siihen, kun vastaus on saapunut.
Sivun latausaika on se, kuinka kauan selaimelta kestää näyttää käyttökelpoinen sivu. Siihen sisältyy HTML-dokumentin vasteaika sekä CSS:n, JavaScriptin, fonttien ja kuvien lataaminen ja suorittaminen, usein kymmeniä lisäpyyntöjä.
Sivulla voi olla nopea vasteaika ja hidas lataus, esimerkiksi kun palvelin vastaa 150 millisekunnissa mutta sivu lataa sen jälkeen kolme megatavua JavaScriptiä. Vinkkimme nopeammin latautuvaan verkkosivustoon käsittelevät tätä käyttöliittymän puolta. Myös päinvastaista tapahtuu: hyvin optimoitu käyttöliittymä ei voi peittää palvelinta, jolta HTML:n tuottaminen kestää neljä sekuntia. Vasteaika on se osa, jota palvelimesi ja hostingisi hallitsevat. Lataus on se osa, jota käyttöliittymäsi hallitsee. Molemmat ovat tärkeitä, ja ne vaativat eri korjauksia. Latausta varten Uptimecheckin sivunopeuden valvonta ajaa Google Lighthousen joka päivä mobiilissa ja työpöydällä ja hälyttää, kun sivun mobiilipisteet putoavat asettamasi rajan alle.
Mitä ensimmäisen tavun aikaan sisältyy
Ensimmäisen tavun aika eli TTFB (time to first byte) on aika pyynnön alusta siihen, kun vastauksen ensimmäinen tavu saapuu. Se koostuu useasta vaiheesta:
DNS-haku: isäntänimen muuttaminen IP-osoitteeksi.
TCP-yhteys: edestakainen matka yhteyden avaamiseksi.
TLS-kättely: salauksesta sopiminen HTTPS:ää varten.
Palvelimen käsittely: sovellus suoritetaan, se kyselee tietokantaa ja rakentaa vastauksen.
Ensimmäinen tavu linjalla: vastauksen alku matkalla takaisin.
Näet jokaisen vaiheen omalle sivustollesi curlilla:
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/
Arvot ovat kumulatiivisia. Jos tls on 0,12 sekuntia ja ttfb 0,95 sekuntia, palvelin käytti sivun tuottamiseen noin 0,8 sekuntia. Siihen lukuun kannattaa tarttua. Jos DNS- tai yhteysvaihe on suuri, ongelma on etäisyydessä, verkossa tai DNS:ssä eikä sovelluksessasi. Uptimecheck jakaa jokaisen tarkistuksen vasteajan samoihin vaiheisiin: DNS, yhteys, TLS, palvelin ja lataus.
Miksi valvonta ja selaimet näyttävät eri lukuja
On normaalia, että käytettävyyden valvontasi, selaimen kehittäjätyökalut ja suorituskyvyn testityökalu näyttävät samalle sivulle eri vasteajat. Yleiset syyt:
Sijainti. Toiselta mantereelta tehty tarkistus lisää edestakaisia matkoja jokaiseen yllä olevaan vaiheeseen. Tukholmassa oleva palvelin vastaa tukholmalaiselle kävijälle nopeammin kuin Yhdysvaltain itärannikolta tehdylle tarkistukselle.
Yhteyksien uudelleenkäyttö. Selain pitää yhteydet auki ja käyttää niitä uudelleen. Valvonnan tarkistus avaa usein joka kerta uuden yhteyden, joten se maksaa DNS:n, TCP:n ja TLS:n jokaisessa pyynnössä.
Välimuisti. Selaimellasi voi olla sivu tai osa siitä välimuistissa, ja CDN voi tarjoilla välimuistikopion joillekin alueille mutta ei toisille.
Mitä mitataan. Yksi työkalu ilmoittaa TTFB:n, toinen koko vastauksen latausajan, kolmas koko sivun latauksen.
Evästeet ja kirjautumiset. Kirjautuneet käyttäjät ohittavat usein sivuvälimuistin, joten heidän vastauksensa ovat hitaampia kuin anonyymin tarkistuksen.
Mikään näistä ei tee yhdestä luvusta väärää. Tärkeintä on verrata samaa samaan: samaa tarkistusta samasta sijainnista ajan mittaan. Valvonta, joka mittaa saman pyynnön minuutin välein, antaa johdonmukaisen vertailutason, ja juuri siihen nähden tapahtuvat muutokset ovat niitä, joihin reagoidaan.
Kohtuulliset tavoitteet nyrkkisääntöinä
Alla olevat vaihteluvälit ovat nyrkkisääntöjä HTML-sivun tai API-kutsun palvelinvasteelle, kun mittaus tehdään kohtuullisen läheltä palvelinta. Ne ovat lähtökohta omalle vertailutasollesi, eivät standardi.
Vastauksen tyyppiHyväKannattaa selvittääVälimuistista tarjoiltu sivu tai staattinen tiedosto CDN:n kauttaalle 100–200 msyli 400 msDynaaminen sivu (CMS, verkkokauppa, sovellus)alle 300–600 msyli 1 sYksinkertainen API-lukurajapintaalle 100–300 msyli 800 msHaku, raportit, raskaat kyselytalle 1–2 syli 3 s
Kaksi huomiota taulukon lukemiseen. Ensinnäkin lisää verkkoetäisyys: toiselta mantereelta tehty tarkistus voi lisätä päälle muutaman sata millisekuntia, eikä sovelluksesi voi sille mitään. Toiseksi tärkein sarake on se, jonka asetat itse. Jos kassasi vastaa normaalisti 350 ms:ssa ja tänään 900 ms:ssa, jokin on muuttunut, vaikka 900 ms näyttää paperilla yhä hyväksyttävältä.
Mikä hidastaa vasteaikoja
Kun vasteaika kasvaa, syy on lähes aina jokin näistä:
Hitaat tietokantakyselyt: puuttuva indeksi, taulun koon mukana kasvava kysely tai lisäosa, joka ajaa kymmeniä kyselyitä sivua kohden.
Ei sivu- tai objektivälimuistia: jokainen pyyntö rakentaa saman sivun alusta.
Ulkoiset kutsut pyynnön aikana: maksu-, toimitus-, haku- tai analytiikkarajapintoja kutsutaan synkronisesti kävijän odottaessa.
Liian vähän workereita: pyynnöt jonottavat toistensa perässä, kun PHP-FPM:n, Noden tai sovelluspalvelimen workerit ovat kaikki varattuina.
Resurssipaine: prosessori äärirajoilla, muisti swappaa tai varmuuskopiot tai lokikirjoitukset kuormittavat levyn I/O:n täyteen.
Kylmäkäynnistykset: nollaan skaalautuneilta serverless-funktioilta ja konteilta kestää aikansa käynnistyä ensimmäistä pyyntöä varten.
Etäisyys: kävijät kaukana palvelimesta ilman välissä olevaa CDN:ää.
Jonot ovat syy siihen, miksi vasteajalla on merkitystä saatavuudelle. Kun vastaukset hidastuvat, jokainen pyyntö varaa workerin pidempään, pooli täyttyy ja uudet pyynnöt odottavat tai hylätään. Puolen sekunnin lisäviiveenä alkanut hidastuminen voi päättyä 503 Service Unavailable -virheeseen seuraavassa liikennepiikissä.
Seuraa trendiä, älä yksittäistä tarkistusta
Yksittäinen hidas tarkistus kertoo vähän. Verkkohäiriö, roskienkeruun tauko tai välimuistin ohilyönti voi hidastaa yhden pyynnön. Ongelmasta kertoo kuvio:
Porrasmainen muutos: vasteaika hyppää julkaisun, lisäosapäivityksen tai hosting-muutoksen jälkeen ja jää sille tasolle.
Hidas nousu: vasteaika kasvaa hieman joka viikko taulun tai lokin kasvaessa.
Päivittäinen kuvio: vasteaika piikkaa samaan aikaan joka päivä, usein varmuuskopion, tuonnin tai resursseista kilpailevan cron-ajon takia.
Alueellinen ero: yksi alue on hidas ja toinen kunnossa, mikä viittaa CDN:ään, reititykseen tai DNS:ään eikä palvelimeen.
Uptimecheck tallentaa jokaisen tarkistuksen vasteajan jokaiselle käytettävyyden valvonnalle ja API-valvonnalle, näyttää sen kaavioina mediaanin ja 95. persentiilin kanssa, ja viikoittaiset ja kuukausittaiset sähköpostiraportit kertovat keskimääräisen vasteajan käytettävyyden rinnalla. Tämän historian ansiosta näet porrasmaisen muutoksen samana päivänä eikä viikkoja myöhemmin.
Hälytä pitkittyneestä hitaudesta
Hälyttäminen jokaisesta hitaasta tarkistuksesta luo melua, ja meluisat hälytykset jätetään huomiotta. Hälytä hitaudesta, joka jatkuu. Käytännöllinen tapa:
Mittaa vertailutaso jokaiselle tärkeälle päätepisteelle viikon tai kahden ajalta.
Aseta varoitusraja selvästi normaalin vaihtelun yläpuolelle, esimerkiksi kahteen tai kolmeen kertaan tavanomainen vasteaika.
Hälytä vain, kun hitaus jatkuu useamman peräkkäisen tarkistuksen tai minuutin ajan.
Lähetä hitausvaroitukset tiimin kanavaan ja säästä puhelimen push-ilmoitukset varsinaisille vioille.
Aseta jokaiselle tarkistukselle aikakatkaisu. 30 sekuntia kestävä vastaus on kävijälle vika tilakoodista riippumatta.
Uptimecheckissä asetat hitaan vastauksen rajan valvontakohtaisesti. Kun kolme tarkistusta peräkkäin on rajaa hitaampia, saat hitaushälytyksen ja toisen, kun valvottava kohde nopeutuu taas. Hidasta aikaa ei lasketa käyttökatkoksi.
Samat periaatteet pätevät jokaiseen määrittämääsi hälytykseen. Oppaamme väärien hälytysten vähentämisestä käytettävyyden valvonnassa käsittelee vahvistusta ja kynnysarvoja tarkemmin, ja palvelinhälytysten kynnysarvojen valinta kertoo, miten rajat asetetaan prosessorille, muistille ja levylle. Kun vasteajat nousevat, palvelinvalvonta käytettävyystarkistusten rinnalla näyttää, onko palvelin syynä, joten sinun ei tarvitse arvailla tietokannan, verkon ja koodin välillä.
Vasteajan tarkistuslista
Mittaa tärkeimpien sivujesi ja päätepisteidesi TTFB curlilla palvelimesi läheltä.
Valvo samoja sivuja minuutin välein ja säilytä historia.
Kirjaa vertailutaso jokaiselle päätepisteelle ja vertaa siihen, älä yleiseen lukuun.
Selvitä porrasmaiset muutokset julkaisujen jälkeen ja viikkojen mittaan hitaasti kasvavat vasteajat.
Käytä välimuistia, missä voit, korjaa hitaat kyselyt ja siirrä ulkoiset kutsut pois pyynnön ajalta.
Hälytä pitkittyneestä hitaudesta ja aikakatkaisuista, älä yksittäisistä hitaista tarkistuksista.
Yhteenveto
Hyvä vasteaika on sivutyypilleen matala, lähellä omaa vertailutasoasi ja ajan mittaan vakaa. Nyrkkisääntönä tavoittele dynaamisille sivuille muutamaa sataa millisekuntia ja välimuistista tarjoilluille selvästi vähemmän. Mittaa se joka kerta samalla tavalla, seuraa trendiä ja pidä pitkittynyttä nousua varhaisena varoituksena, sillä tämän päivän hidas sivu on usein huomisen katko.
Uptimecheck tallentaa vasteajat jokaisesta tarkistuksesta, joten näet hidastumiset katkojen lisäksi. Kokeile ilmaiseksi 14 päivää, luottokorttia ei tarvita.