Miksi Time to First Byte on hidas ja mitä sille voi tehdä

Aloita siitä, mitä TTFB oikeasti mittaa

Time to First Byte, yleensä lyhennettynä TTFB, on aika selaimen resurssipyynnön ja vastauksen ensimmäisen tavun vastaanottamisen välillä.

Se kuulostaa palvelinmittarilta, mutta se ei ole pelkästään palvelinmittari. TTFB sisältää useita vaiheita:

• DNS-haku, jos isäntänimeä ei ole vielä ratkaistu
• TCP-yhteyden muodostus
• TLS-neuvottelu HTTPS-yhteyttä varten
• Pyynnön kulkuaika palvelimelle tai CDN:n reunalle
• Jonotus ja käsittely palvelimella
• Vastauksen kulkuaika takaisin selaimeen

Korkea TTFB voi siis tarkoittaa, että taustajärjestelmäsi on hidas. Se voi myös tarkoittaa, että käyttäjä on kaukana alkuperäpalvelimestasi, CDN on määritetty väärin, välimuisti menee jatkuvasti ohi tai palvelin käyttää liian kauan päättäessään, mitä lähettää.

Tällä on merkitystä, koska TTFB on latausketjun alkupäässä. Jos HTML-dokumentti saapuu myöhässä, selain löytää myös CSS:n, JavaScriptin, fontit ja kuvat myöhässä. Etupään optimointi voi olla erinomaista, mutta sivusto tuntuu silti hitaalta, jos ensimmäisen dokumenttivastauksen saaminen kestää 1,5 sekuntia.

Mikä lasketaan hitaaksi TTFB:ksi?

Ei ole yhtä yleispätevää lukua, joka sopisi jokaiseen sivustoon, alueeseen ja arkkitehtuuriin. Käytännölliset raja-arvot kuitenkin auttavat.

Google web.dev -ohjeistus luokittelee hyvän TTFB:n alle 800 ms:iin, 800–1800 ms parannusta vaativaksi ja yli 1800 ms heikoksi. Hyvin välimuistitetulla markkinointisivulla, joka palvellaan lähellä käyttäjää, voit usein päästä tätä selvästi parempaan. Monimutkaisessa todennetussa hallintanäkymässä, joka tekee dynaamista työtä, hyväksyttävä luku voi olla korkeampi, mutta sen pitäisi silti olla selitettävissä.

Tärkeä tapa on segmentoida luku. 900 ms:n globaali keskimääräinen TTFB voi piilottaa 150 ms:n vasteen käyttäjille CDN-reunan lähellä ja 2200 ms:n vasteen käyttäjille toisella alueella. Samoin etusivusi voi olla kunnossa, kun taas haku-, kategoria- tai sisäänkirjautuneiden sivut ovat huomaamatta tuskallisia.

Mittaa useammasta kuin yhdestä paikasta

Älä diagnosoi TTFB:tä yhden Lighthouse-ajon perusteella. Lighthouse on hyödyllinen, mutta se on yksi testi yhdestä ympäristöstä. Jos sen tulkinta on sinulle uutta, aloita rauhallisesta katsauksesta siihen, miten Lighthouse-raporttia luetaan panikoimatta — pääoppi on erottaa laboratoriohavainnot kentän todellisuudesta.

TTFB:n kohdalla tarvitset vähintään kolme näkymää:

1. Selaimen kehittäjätyökalut

Avaa Network-paneeli, lataa sivu uudelleen välimuisti poistettuna käytöstä ja tarkastele päädokumentin pyyntöä. Ajoituserittely näyttää DNS-, yhteys-, TLS-, odotus- ja latausvaiheet. “Odotus”-vaihe on usein se, mitä ihmiset tarkoittavat taustajärjestelmän ajalla, vaikka se voi sisältää myös ylävirran viivettä.

2. Synteettiset testit useilta alueilta

Aja testejä sijainneista, jotka ovat lähellä käyttäjiäsi ja kaukana heistä. Jos TTFB on matala yhdellä alueella ja korkea toisella, epäile maantiedettä, CDN-reititystä, alkuperäpalvelimen sijaintia tai välimuistin kattavuutta ennen kuin kirjoitat sovelluskoodia uudelleen.

3. Todellisten käyttäjien seuranta tai palvelinlokit

Kenttädata kertoo, mitä oikeat käyttäjät kokevat eri laitteilla, verkoissa ja istunnoissa. Palvelinlokit voivat kertoa, tuottiko alkuperäpalvelin vastauksen nopeasti. Asiakkaan havaitseman TTFB:n ja alkuperäpalvelimen käsittelyajan välinen ero on usein paikka, jossa CDN- ja verkko-ongelmat näkyvät.

Hitaan TTFB:n tavalliset syyt

HTML:ää ei välimuistiteta

Tämä on yleisin ongelma sisältösivustoilla ja verkkokaupoissa. Staattiset resurssit välimuistitetaan aggressiivisesti, mutta HTML-dokumentti — asia, jonka selain tarvitsee ensin — luodaan jokaisella pyynnöllä.

Joskus se on välttämätöntä. Usein ei ole.

Jos julkinen sivu muuttuu muutaman kerran päivässä, sen ei todennäköisesti pitäisi vaatia tuoretta tietokantarenderöintiä jokaiselle anonyymille kävijälle. Käytä tilanteen mukaan koko sivun välimuistia, reunavälimuistia, staattista generointia tai stale-while-revalidate-malleja.

Tarkista vastausotsakkeista signaaleja, kuten Cache-Control, CDN-Cache-Status, Age, Vary ja Set-Cookie. Sivu, joka lähettää yksilöllisen evästeen jokaiselle kävijälle, voi vahingossa tehdä itsestään välimuistittamattoman. Jos tarvitset käytännöllisen tavan ajatella tätä kerrosta, samat virheenjäljitystavat oppaassamme uudelleenohjauksista ja HTTP-otsakkeista tuotannossa pätevät suoraan TTFB-työhön.

CDN välimuistittaa vain resurssit

Moni tiimi lisää CDN:n ja olettaa, että suorituskykytyö on tehty. Mutta jos CDN palvelee vain kuvia, CSS:ää ja JavaScriptiä, ensimmäinen HTML-pyyntö voi yhä kulkea koko matkan yhdelle alkuperäpalvelimelle.

Se voi olla aivan hyväksyttävää paikalliselle yrityssivustolle, jolla on paikallisia käyttäjiä. Se ei ole hyväksyttävää kansainväliselle yleisölle. Mitä kauempana käyttäjä on alkuperäpalvelimesta, sitä enemmän viivettä maksat ennen kuin taustajärjestelmän työ edes alkaa.

Hyvä CDN-määritys TTFB:tä varten tarkoittaa yleensä:

• Välimuistita julkinen HTML siellä, missä se on turvallista
• Kunnioita tarkoituksellisia ohitussääntöjä todennetuille tai personoiduille sivuille
• Vältä tarpeettomia Vary-otsakkeita, jotka pilkkovat välimuistin liian hienoksi
• Käytä välimuistin tyhjennystä tai uudelleenvalidointia sen sijaan, että poistaisit välimuistin kokonaan käytöstä
• Varmista, että reunasijainnit todella palvelevat osumia eivätkä välitä jokaista pyyntöä eteenpäin

CDN ei ole taikuutta. Se on välimuisti- ja reitityskerros. Kohtele sitä sellaisena.

Palvelin tekee liikaa ennen vastaamista

Hidas taustajärjestelmäpolku voi syntyä monista pienistä viiveistä: tietokantakyselyistä, API-kutsuista, mallipohjien renderöinnistä, feature flag -tarkistuksista, todennuksesta, personoinnista, lokituksesta ja kylmäkäynnistyksistä.

Huonoin malli on sarjallinen riippuvuustyö. Esimerkiksi:

1. Hae sivun data
2. Hae sitten liittyvät tuotteet
3. Hae sitten hinnoittelu
4. Kutsu sitten suosittelupalvelua
5. Renderöi sitten HTML

Jos jokainen vaihe odottaa edellistä, TTFB kasvaa nopeasti. Rinnakkaista riippumaton työ, poista ei-kriittiset kutsut ensimmäisestä vastauksesta ja välimuistita kalliit tulokset.

Hyödyllinen sääntö: jos käyttäjä ei voi nähdä tai käyttää tulosta välittömästi, sen ei todennäköisesti pitäisi estää ensimmäistä tavua.

Tietokantakyselyt ovat hitaita tai arvaamattomia

Tietokannat aiheuttavat usein TTFB-ongelmia, koska ne käyttäytyvät hyvin kehityksessä ja huonosti oikean liikenteen alla. Puuttuvat indeksit, suuret liitokset, N+1-kyselyt, lukituskilpailu ja liian suuret tulosjoukot näkyvät kaikki muodossa “palvelin on hidas”.

Älä arvaile tässä. Tallenna kyselyajoitukset hitaille pyynnöille. Katso p95- ja p99-arvoja, älä vain keskiarvoja. Sivu, joka yleensä vastaa 120 ms:ssa mutta välillä jumittuu 4 sekunniksi, luo silti huonon käyttökokemuksen.

Yleisiä korjauksia ovat:

• Indeksien lisääminen tai korjaaminen
• N+1-kyselymallien poistaminen
• Lukupainotteisen datan välimuistitus
• Suurten kyselyjen sivutus
• Raportointi- tai analytiikkakyselyjen siirtäminen pois pyyntöhetkestä
• Järkevien aikakatkaisujen asettaminen alavirran kutsuille

Sovelluksellasi on kylmäkäynnistyksiä

Serverless- ja konttipohjaiset alustat voivat olla erinomaisia, mutta kylmäkäynnistykset voivat heikentää TTFB:tä, kun liikenne on piikikästä tai alueet ovat alimitoitettuja.

Jos ensimmäinen pyyntö käyttämättömän ajan jälkeen on paljon hitaampi kuin myöhemmät pyynnöt, tutki kylmäkäynnistyksiä. Saatat tarvita varattua rinnakkaisuutta, pienempiä paketteja, vähemmän käynnistysriippuvuuksia, lämpimämpiä funktioita tai toisenlaisen käyttöönottomallin viiveherkille reiteille.

Tämä ei ole argumentti serverlessiä vastaan. Se on argumentti sitä vastaan, että ajonaikaisen mallin teeskennellään olevan näkymätön.

Uudelleenohjaukset hukkaavat ensimmäisen pyynnön

Uudelleenohjaus lisää uuden pyyntö-vastaus-kierroksen ennen kuin selain saa lopullisen dokumentin. Yksi uudelleenohjaus http://:stä https://:ään voi olla väistämätön vanhoille linkeille, mutta ketjut ovat tuhlausta.

Yleisiä ketjuja ovat:

• http://example.com → https://example.com → https://www.example.com
• loppuviivan normalisointi protokollan normalisoinnin jälkeen
• geo- tai kieliuudelleenohjaukset ennen välimuistihakua
• vanhat kampanjalinkit, jotka hyppivät useiden URL-osoitteiden kautta

Korjaa lähdelinkit mahdollisuuksien mukaan, tiivistä uudelleenohjaussäännöt ja tee kanonisista URL-osoitteista suoria. Uudelleenohjausaikaa ei aina raportoida lopullisen pyynnön TTFB:nä, mutta käyttäjä maksaa siitä silti.

Käytännöllinen virheenjäljitysjärjestys

Kun TTFB näyttää hitaalta, käytä tätä järjestystä. Se välttää yleisen virheen, jossa sovelluskoodia optimoidaan ennen välimuisti- ja reitityskäyttäytymisen varmistamista.

Vaihe 1: Testaa päädokumentti, ei vain koko sivua

Etsi HTML-dokumentin pyyntö. Kirjaa kokonais-TTFB ja ajoituserittely. Toista selaimen välimuistin kanssa ja ilman sitä. Testaa julkinen sivu, dynaaminen sivu ja sisäänkirjautuneen sivu, jos se on olennaista.

Vaihe 2: Vertaa alueita

Aja sama URL useista maantieteellisistä sijainneista. Jos hitaat alueet korreloivat etäisyyden kanssa alkuperäpalvelimeen, priorisoi CDN ja reunavälimuisti. Jos jokainen alue on hidas, katso taustajärjestelmän käsittelyä ja alkuperäpalvelimen kapasiteettia.

Vaihe 3: Tarkista vastausotsakkeet

Etsi välimuistiotsakkeita, evästeitä, Age, CDN-tila ja Vary. Puuttuva Age-otsake tai toistuvat välimuistihudit ovat vihjeitä. Laaja Vary: Cookie -otsake julkisessa HTML:ssä on usein välimuistin tappaja.

Vaihe 4: Tarkista alkuperäpalvelimen ajoitus

Lisää palvelinajoituksen instrumentointi. Server-Timing-otsake voi paljastaa taustajärjestelmän vaiheita, kuten tietokanta-ajan, renderöintiajan ja ylävirran API-ajan. Jopa yksinkertaiset tunnisteet ovat hyödyllisiä:

Server-Timing: db;dur=82, render;dur=41, api;dur=210

Nyt selaimen ajoitukset voivat näyttää, käyttikö palvelin 300 ms todelliseen työhön vai tapahtuiko viive ennen kuin pyyntö saavutti sovelluksesi.

Vaihe 5: Korjaa suurin varmistettu viive

Tämä kuulostaa ilmeiseltä, mutta tiimit korjaavat usein sitä, mikä on tuttua, eivät sitä, mikä on mitattu. Jos välimuistihudit hallitsevat, korjaa välimuisti. Jos tietokanta hallitsee, korjaa kyselyt. Jos TLS ja yhteyden muodostus hallitsevat globaaleilla käyttäjillä, korjaa reititys, CDN-kattavuus tai alkuperäpalvelimen maantiede.

Etupään työ on yhä tärkeää. Fontit, kuvat ja JavaScript vaikuttavat siihen, mitä tapahtuu HTML:n saapumisen jälkeen. Ne eivät kuitenkaan korvaa nopeaa ensimmäistä vastausta. Jos työstät myös renderöintisuorituskykyä, web-fontit ovat edelleen yksi helpoimmista voitoista monilla sivustoilla, koska ne vaikuttavat siihen, kuinka nopeasti tekstistä tulee käyttökelpoista dokumentin saapumisen jälkeen.

Korjaukset, jotka yleensä toimivat

Välimuistita julkinen HTML reunalla

Markkinointisivuilla, dokumentaatiossa, blogeissa, laskeutumissivuilla ja kategoriasivuilla reunavälimuisti on usein suurin TTFB-parannus. Käytä lyhyitä TTL-arvoja, jos sisältö muuttuu usein. Käytä stale-while-revalidate-mallia, jos hieman vanhentunut sisältö on hyväksyttävää sillä aikaa, kun välimuisti päivittyy taustalla.

Ole varovainen personoinnin kanssa. Jos sivu vaihtelee valuutan, kielen, kirjautumistilan tai kokeiluryhmän mukaan, määrittele nämä variantit selkeästi. Tahaton käyttäjäkohtainen vaihtelu tuhoaa välimuistin tehokkuuden.

Siirrä ei-kriittinen työ pois pyyntöpolulta

Sähköpostien lähetys, analytiikan rikastaminen, suositusten generointi, webhook-kutsut ja raskas lokitus eivät juuri koskaan saisi estää ensimmäistä tavua. Laita ne jonoihin tai aja ne sen jälkeen, kun vastaus on aloitettu.

Vähennä taustajärjestelmän riippuvuusketjuja

Rinnakkaista riippumattomat kutsut. Välimuistita hitaiden APIen vastaukset. Aseta aikakatkaisut. Suunnittele varasisältö palveluille, jotka ovat hyödyllisiä mutta eivät välttämättömiä.

Hitaan suosittelu-widgetin ei pitäisi viivästyttää koko tuotesivua.

Vie laskenta lähemmäs käyttäjiä

Jos käyttäjäsi ovat globaaleja ja alkuperäpalvelimesi on yhdellä alueella, viive on rakenteellista. CDN-välimuisti voi piilottaa tästä suuren osan julkisessa sisällössä. Dynaamisessa sisällössä harkitse alueellisia käyttöönottoja, reunarenderöintiä sopiville reiteille tai APIen siirtämistä lähemmäs yleisöä.

Pidä uudelleenohjaukset tylsinä

Kanonisoi URL-osoitteet yhdellä hypyllä. Päivitä sisäiset linkit niin, että käyttäjät ja indeksoijat menevät suoraan lopulliseen kohteeseen. Auditoi vanhat kampanja-URLit ja alustamigraatiot. Uudelleenohjaukset on helppo sivuuttaa, koska ne ovat näkymättömiä toimiessaan, mutta ne maksavat silti aikaa.

Mitä ei kannata tehdä

Älä jahtaa täydellistä TTFB-lukua jokaiselle reitille. Todennettu raportti, joka tekee oikeaa laskentaa, ei käyttäydy kuin välimuistitettu blogikirjoitus.

Älä käytä keskimääräistä TTFB:tä ainoana mittarinasi. Persentiileillä on merkitystä. Maantieteellä on merkitystä. Sivutyypillä on merkitystä.

Älä oleta, että CDN tarkoittaa HTML:n olevan välimuistissa. Varmista se.

Äläkä käsittele TTFB:tä irrallaan tuotepäätöksistä. Personoinnilla, kokeiluilla, reaaliaikaisella varastosaldolla ja kolmannen osapuolen palveluilla on kaikilla viivekustannuksia. Osa on sen arvoisia. Osa on vain tapa.

<!-- tool-cta:start -->

💡 Kokeile tätä: TTFB:tä diagnosoitaessa Get Headers paljastaa välimuistin tilan, palvelimen ajoitukset ja uudelleenohjaukset, jotka usein selittävät, mistä viive johtuu.

<!-- tool-cta:end -->

Suunnitelman rauhallinen versio

Hidas TTFB on yleensä korjattavissa, kun lakkaat käsittelemästä sitä epämääräisenä “palvelinongelmana”. Mittaa dokumenttipyyntö. Segmentoi alueen ja sivutyypin mukaan. Tarkista otsakkeet. Vertaa asiakkaan ajoitusta alkuperäpalvelimen ajoitukseen. Korjaa sitten suurin varmistettu pullonkaula.

Useimmat sivustot eivät tarvitse eksoottista arkkitehtuuria. Ne tarvitsevat vähemmän vältettävissä olevia välimuistihuteja, vähemmän estävää taustajärjestelmätyötä, siistimmät uudelleenohjaukset ja selkeämmän käsityksen siitä, mitä täytyy tapahtua ennen kuin ensimmäinen tavu lähetetään.