Kodėl jūsų Time to First Byte yra lėtas ir ką su tuo daryti

Pradėkite nuo to, ką TTFB iš tikrųjų matuoja

Time to First Byte, paprastai trumpinama kaip TTFB, yra laikas nuo momento, kai naršyklė paprašo ištekliaus, iki momento, kai gauna pirmą atsakymo baitą.

Tai skamba kaip serverio metrika, bet ji nėra vien serverio metrika. TTFB apima kelis žingsnius:

• DNS paiešką, jei prieglobos vardas dar neišspręstas
• TCP ryšio užmezgimą
• TLS derybas HTTPS atveju
• Užklausos kelionės laiką iki serverio arba CDN krašto
• Eiliavimą ir apdorojimą serveryje
• Atsakymo kelionės laiką atgal į naršyklę

Todėl didelis TTFB gali reikšti, kad jūsų backend yra lėtas. Taip pat tai gali reikšti, kad naudotojas yra toli nuo jūsų origin serverio, jūsų CDN sukonfigūruotas netinkamai, talpykla nuolat nepataiko arba serveris per ilgai sprendžia, ką siųsti.

Tai svarbu, nes TTFB yra arti įkėlimo grandinės pradžios. Jei HTML dokumentas atkeliauja vėlai, naršyklė taip pat vėlai aptinka CSS, JavaScript, šriftus ir vaizdus. Galite turėti puikią front-end optimizaciją, bet vis tiek atrodyti lėti, jei pirmojo dokumento atsakymas užtrunka 1,5 sekundės.

Kas laikoma lėtu TTFB?

Nėra universalaus skaičiaus, tinkančio kiekvienai svetainei, regionui ir architektūrai. Vis dėlto praktinės ribos padeda.

Google web.dev gairėse geru TTFB laikomas mažesnis nei 800 ms, 800–1800 ms intervalas reiškia, kad reikia tobulinti, o daugiau nei 1800 ms laikoma prastu rezultatu. Gerai talpykloje laikomam rinkodaros puslapiui, aptarnaujamam netoli naudotojo, dažnai galima pasiekti gerokai geresnį rezultatą. Sudėtingam autentifikuotam skydeliui, atliekančiam dinaminį darbą, priimtinas skaičius gali būti didesnis, bet jis vis tiek turėtų būti paaiškinamas.

Svarbiausias įprotis — segmentuoti skaičių. 900 ms pasaulinis vidutinis TTFB gali paslėpti 150 ms atsakymą naudotojams netoli jūsų CDN krašto ir 2200 ms atsakymą naudotojams kitame regione. Lygiai taip pat jūsų pradžios puslapis gali veikti gerai, o paieškos, kategorijų ar prisijungusių naudotojų puslapiai tyliai kelti skausmą.

Matuokite ne vienoje vietoje

Nediagnozuokite TTFB pagal vieną Lighthouse paleidimą. Lighthouse yra naudingas, bet tai vienas testas vienoje aplinkoje. Jei dar tik mokotės jį interpretuoti, pradėkite nuo ramaus paaiškinimo, kaip skaityti Lighthouse ataskaitą nepanikuojant — pagrindinė pamoka yra atskirti laboratorinius signalus nuo realybės lauke.

TTFB atveju jums reikia bent trijų perspektyvų:

1. Naršyklės kūrėjo įrankiai

Atidarykite Network skydelį, perkraukite puslapį išjungę talpyklą ir patikrinkite pagrindinio dokumento užklausą. Laiko išskaidymas rodo DNS, ryšio, TLS, laukimo ir atsisiuntimo fazes. „waiting“ fazė dažnai yra tai, ką žmonės vadina backend laiku, nors ji gali apimti ir upstream delsą.

2. Sintetiniai testai iš kelių regionų

Paleiskite testus iš vietų, esančių arti jūsų naudotojų ir toli nuo jų. Jei TTFB viename regione mažas, o kitame didelis, prieš perrašydami aplikacijos kodą įtarkite geografiją, CDN maršrutizavimą, origin vietą arba talpyklos aprėptį.

3. Real user monitoring arba serverio žurnalai

Lauko duomenys parodo, ką realūs naudotojai patiria skirtinguose įrenginiuose, tinkluose ir sesijose. Serverio žurnalai gali parodyti, ar origin greitai sugeneravo atsakymą. Skirtumas tarp kliento stebimo TTFB ir origin apdorojimo laiko dažnai yra vieta, kur išryškėja CDN ir tinklo problemos.

Įprastos lėto TTFB priežastys

Jūsų HTML nėra talpinamas talpykloje

Tai dažniausia problema turinio ir ecommerce svetainėse. Statiniai ištekliai talpinami agresyviai, bet HTML dokumentas — tai, ko naršyklei reikia pirmiausia — generuojamas kiekvienai užklausai.

Kartais tai būtina. Dažnai — ne.

Jei viešas puslapis keičiasi kelis kartus per dieną, tikriausiai kiekvienam anoniminiam lankytojui nereikėtų naujo duomenų bazės renderinimo. Kur tinkama, naudokite viso puslapio talpyklą, edge caching, statinį generavimą arba stale-while-revalidate modelius.

Patikrinkite atsakymo antraštes, ieškodami signalų, tokių kaip Cache-Control, CDN-Cache-Status, Age, Vary ir Set-Cookie. Puslapis, kuris kiekvienam lankytojui siunčia unikalų slapuką, gali netyčia pats tapti netalpinamas talpykloje. Jei jums reikia praktiško būdo mąstyti apie šį sluoksnį, tie patys derinimo įpročiai iš mūsų vadovo apie peradresavimus ir HTTP antraštes produkcijoje tiesiogiai tinka TTFB darbui.

Jūsų CDN talpina tik išteklius

Daugelis komandų prideda CDN ir mano, kad našumo darbas baigtas. Tačiau jei CDN aptarnauja tik vaizdus, CSS ir JavaScript, pirmoji HTML užklausa vis tiek gali keliauti iki vieno origin serverio.

Tai gali būti priimtina vietinio verslo svetainei su vietiniais naudotojais. Tai nėra priimtina tarptautinei auditorijai. Kuo toliau naudotojas yra nuo origin, tuo daugiau delsos sumokate dar prieš prasidedant backend darbui.

Gera CDN konfigūracija TTFB atžvilgiu paprastai reiškia:

• Talpinti viešą HTML ten, kur saugu
• Gerbti sąmoningas apėjimo taisykles autentifikuotiems arba personalizuotiems puslapiams
• Vengti nereikalingų Vary antraščių, kurios per smulkiai suskaido talpyklą
• Naudoti talpyklos išvalymą arba pakartotinį patvirtinimą, užuot visiškai išjungus talpyklą
• Patvirtinti, kad edge vietos iš tikrųjų aptarnauja pataikymus, o ne persiunčia kiekvieną užklausą

CDN nėra magija. Tai talpyklos ir maršrutizavimo sluoksnis. Elkitės su juo kaip su tokiu.

Jūsų serveris prieš atsakydamas daro per daug

Lėtas backend kelias gali susidėti iš daugelio mažų vėlavimų: duomenų bazės užklausų, API kvietimų, šablonų renderinimo, feature flag patikrų, autentifikavimo, personalizavimo, žurnalavimo ir cold start.

Blogiausias modelis yra nuoseklus priklausomybių darbas. Pavyzdžiui:

1. Gauti puslapio duomenis
2. Tada gauti susijusius produktus
3. Tada gauti kainodarą
4. Tada kviesti rekomendacijų paslaugą
5. Tada renderinti HTML

Jei kiekvienas žingsnis laukia ankstesnio, TTFB greitai auga. Lygiagretinkite nepriklausomą darbą, pašalinkite neesminius kvietimus iš pirmojo atsakymo ir talpinkite brangius rezultatus.

Naudinga taisyklė: jei naudotojas negali rezultato iš karto matyti ar naudoti, jis tikriausiai neturėtų blokuoti pirmojo baito.

Duomenų bazės užklausos yra lėtos arba nenuspėjamos

Duomenų bazės dažnai sukelia TTFB problemas, nes kūrimo aplinkoje jos elgiasi gerai, o esant realiam srautui — prastai. Trūkstami indeksai, dideli join, N+1 užklausos, užraktų konkurencija ir per dideli rezultatų rinkiniai visi pasirodo kaip „serveris lėtas“.

Čia nespėliokite. Fiksuokite lėtų užklausų query timings. Žiūrėkite į p95 ir p99, ne tik į vidurkius. Puslapis, kuris paprastai atsako per 120 ms, bet kartais užstringa 4 sekundėms, vis tiek sukurs blogą naudotojo patirtį.

Dažni pataisymai:

• Pridėti arba pataisyti indeksus
• Pašalinti N+1 užklausų modelius
• Talpinti daug skaitomus duomenis
• Puslapiuoti dideles užklausas
• Perkelti ataskaitų ar analitikos užklausas iš užklausos vykdymo laiko
• Nustatyti protingus timeout downstream kvietimams

Jūsų aplikacija turi cold start

Serverless ir konteinerizuotos platformos gali būti puikios, bet cold start gali pakenkti TTFB, kai srautas yra šuolinis arba regionams trūksta resursų.

Jei pirmoji užklausa po neveiklumo yra daug lėtesnė nei vėlesnės, ištirkite cold start. Gali reikėti provisioned concurrency, mažesnių bundle, mažiau paleidimo priklausomybių, pašildytų funkcijų arba kitokios diegimo formos delsai jautriems maršrutams.

Tai nėra argumentas prieš serverless. Tai argumentas prieš apsimetimą, kad vykdymo modelis yra nematomas.

Peradresavimai švaisto pirmąją užklausą

Peradresavimas prideda dar vieną užklausos–atsakymo ciklą prieš naršyklei gaunant galutinį dokumentą. Vienas peradresavimas iš http:// į https:// gali būti neišvengiamas seniems saitams, bet grandinės yra švaistymas.

Dažnos grandinės:

• http://example.com → https://example.com → https://www.example.com
• pasvirojo brūkšnio pabaigoje normalizavimas po protokolo normalizavimo
• geo arba kalbos peradresavimai prieš talpyklos paiešką
• seni kampanijų saitai, šokinėjantys per kelis URL

Kur įmanoma, pataisykite šaltinio nuorodas, sujunkite peradresavimo taisykles ir padarykite kanoninius URL tiesioginius. Peradresavimo laikas ne visada pateikiamas kaip galutinės užklausos TTFB, bet naudotojas vis tiek už jį sumoka.

Praktinė derinimo seka

Kai TTFB atrodo lėtas, naudokite šią tvarką. Ji padeda išvengti dažnos klaidos — optimizuoti aplikacijos kodą dar nepatvirtinus talpyklos ir maršrutizavimo elgsenos.

1 žingsnis: testuokite pagrindinį dokumentą, ne tik visą puslapį

Raskite HTML dokumento užklausą. Užfiksuokite bendrą TTFB ir laiko išskaidymą. Pakartokite su naršyklės talpykla ir be jos. Jei aktualu, testuokite viešą puslapį, dinaminį puslapį ir prisijungusio naudotojo puslapį.

2 žingsnis: palyginkite regionus

Paleiskite tą patį URL iš kelių geografinių vietų. Jei lėti regionai koreliuoja su atstumu nuo origin, prioritetą teikite CDN ir edge caching. Jei lėtas kiekvienas regionas, žiūrėkite į backend apdorojimą ir origin pajėgumus.

3 žingsnis: patikrinkite atsakymo antraštes

Ieškokite talpyklos antraščių, slapukų, Age, CDN būsenos ir Vary. Trūkstama Age antraštė arba pasikartojantys talpyklos nepataikymai yra užuominos. Plati Vary: Cookie antraštė viešam HTML dažnai žudo talpyklą.

4 žingsnis: patikrinkite origin laiką

Pridėkite serverio laiko instrumentavimą. Server-Timing antraštė gali parodyti backend fazes, tokias kaip duomenų bazės laikas, renderinimo laikas ir upstream API laikas. Net paprastos etiketės yra naudingos:

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

Dabar naršyklės laikai gali parodyti, ar serveris 300 ms praleido atlikdamas realų darbą, ar vėlavimas įvyko prieš užklausai pasiekiant jūsų aplikaciją.

5 žingsnis: taisykite didžiausią patvirtintą vėlavimą

Tai skamba akivaizdžiai, bet komandos dažnai taiso tai, kas pažįstama, o ne tai, kas išmatuota. Jei dominuoja talpyklos nepataikymai, taisykite talpyklą. Jei dominuoja duomenų bazė, taisykite užklausas. Jei pasauliniams naudotojams dominuoja TLS ir ryšio užmezgimas, taisykite maršrutizavimą, CDN aprėptį arba origin geografiją.

Front-end darbas vis tiek svarbus. Šriftai, vaizdai ir JavaScript veikia tai, kas vyksta po HTML atvykimo. Bet jie nėra greito pirmojo atsakymo pakaitalai. Jei taip pat dirbate su renderinimo našumu, web fonts daugelyje svetainių tebėra vienas lengviausių laimėjimų, nes jie veikia, kaip greitai tekstas tampa naudojamas po dokumento atvykimo.

Pataisymai, kurie paprastai veikia

Talpinkite viešą HTML krašte

Rinkodaros puslapiams, dokumentacijai, blogams, nukreipimo puslapiams ir kategorijų puslapiams edge caching dažnai yra didžiausias TTFB pagerinimas. Naudokite trumpus TTL, jei turinys dažnai keičiasi. Naudokite stale-while-revalidate, jei šiek tiek pasenęs turinys priimtinas, kol talpykla atnaujinama fone.

Būkite atsargūs su personalizavimu. Jei puslapis skiriasi pagal valiutą, kalbą, prisijungimo būseną ar eksperimento grupę, aiškiai apibrėžkite tuos variantus. Atsitiktinis kintamumas kiekvienam naudotojui sunaikina talpyklos efektyvumą.

Perkelkite neesminį darbą iš užklausos kelio

El. laiškų siuntimas, analitikos praturtinimas, rekomendacijų generavimas, webhook kvietimai ir sunkus žurnalavimas retai turėtų blokuoti pirmą baitą. Dėkite juos į eiles arba vykdykite po to, kai atsakymas pradėtas.

Sumažinkite backend priklausomybių grandines

Lygiagretinkite nepriklausomus kvietimus. Talpinkite lėtų API atsakymus. Nustatykite timeout. Kurkite atsarginį turinį paslaugoms, kurios naudingos, bet nebūtinos.

Lėtas rekomendacijų valdiklis neturėtų uždelsti viso produkto puslapio.

Priartinkite skaičiavimus prie naudotojų

Jei jūsų naudotojai pasauliniai, o origin yra viename regione, delsa yra struktūrinė. CDN talpykla gali didelę dalį to paslėpti viešam turiniui. Dinaminiam turiniui apsvarstykite regioninius diegimus, edge rendering tinkamiems maršrutams arba API perkėlimą arčiau auditorijos.

Peradresavimus laikykite nuobodžius

Kanonizuokite URL vienu šuoliu. Atnaujinkite vidines nuorodas, kad naudotojai ir crawler tiesiogiai eitų į galutinę paskirties vietą. Audituokite senus kampanijų URL ir platformų migracijas. Peradresavimus lengva ignoruoti, nes kai jie veikia, jie nematomi, bet jie vis tiek kainuoja laiką.

Ko nedaryti

Nesivaikykite tobulo TTFB skaičiaus kiekvienam maršrutui. Autentifikuota ataskaita, atliekanti realius skaičiavimus, nesielgs kaip talpykloje esantis blogo įrašas.

Nenaudokite vidutinio TTFB kaip vienintelės metrikos. Procentiliai svarbūs. Geografija svarbi. Puslapio tipas svarbus.

Nemanykite, kad CDN reiškia, jog jūsų HTML talpinamas talpykloje. Patikrinkite.

Ir nelaikykite TTFB atskiru nuo produkto sprendimų. Personalizavimas, eksperimentavimas, realaus laiko atsargos ir trečiųjų šalių paslaugos visos turi delsos kainą. Kai kurios jos vertos. Kai kurios tėra įprotis.

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

💡 Išbandykite tai: Diagnozuojant TTFB, Get Headers atskleidžia talpyklos būseną, serverio laikus ir peradresavimus, kurie dažnai paaiškina, iš kur kyla vėlavimas.

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

Rami plano versija

Lėtas TTFB paprastai pataisomas, kai nustojate jį laikyti miglota „serverio problema“. Išmatuokite dokumento užklausą. Segmentuokite pagal regioną ir puslapio tipą. Patikrinkite antraštes. Palyginkite kliento laiką su origin laiku. Tada taisykite didžiausią patvirtintą kliūtį.

Daugumai svetainių nereikia egzotiškos architektūros. Joms reikia mažiau išvengiamų talpyklos nepataikymų, mažiau blokuojančio backend darbo, švaresnių peradresavimų ir aiškesnio supratimo, kas turi įvykti prieš išsiunčiant pirmą baitą.