Korjaa ja tunnista Time to First Byte (TTFB) -ongelmat

Löydä ja korjaa Time to First Byte (TTFB) -ongelmat

Edellisessä artikkelissamme puhuimme Time to First Byte -metriikasta. Jos haluat tutustua perusteisiin, tämä on loistava paikka aloittaa!

Tässä artikkelissa keskityn erilaisten Time to First Byte -ongelmien tunnistamiseen ja sen jälkeen selitän, miten ne korjataan!

TTFB-VINKKI: useimmiten TTFB on huomattavasti huonompi ensikävijöillä, koska heillä ei ole DNS-välimuistia sivustollesi. TTFB:tä seuratessa on erittäin järkevää erottaa ensikävijät ja palaavat kävijät toisistaan

Vaihe 1: Tarkista TTFB Search Consolessa

"Ensimmäinen askel toipumiseen on ongelman myöntäminen". Joten ennen kuin teemme mitään Time to First Byte -metriikan korjaamiseksi, varmistetaan, että meillä todella on ongelma TTFB:n kanssa.

Valitettavasti Time to First Byte -metriikkaa ei raportoida Google Search Consolessa, joten meidän täytyy turvautua pagespeed.web.dev-palveluun sivustomme CrUX-datan kyselyyn. Onneksi vaiheet ovat helppoja: navigoi osoitteeseen pagespeed.web.dev, syötä sivusi URL ja varmista, että 'origin'-painike on valittuna (koska tarvitsemme koko sivuston dataa eikä pelkästään etusivun dataa). Vaihda nyt mobiili- ja työpöytänäkymän välillä ja tarkista Time to First Byte molemmille laitetyypeille

Alla olevassa esimerkissä näet sivuston, joka ei läpäise Core Web Vitals -testiä korkean TTFB:n vuoksi.

Vaihe 2: Ota käyttöön RUM-seuranta

Time to First Byte on hankala metriikka. Emme voi yksinkertaisesti luottaa synteettisiin testeihin TTFB:n mittaamisessa, koska tosielämässä muut tekijät vaikuttavat TTFB:n vaihteluihin. Saadaksemme vastaukset kaikkiin yllä oleviin kysymyksiin meidän täytyy mitata data tosielämässä ja kirjata kaikki ongelmat, joita Time to First Byte -metriikan kanssa saattaa esiintyä. Tätä kutsutaan Real User Monitoring -seurannaksi ja RUM-seurannan käyttöönottoon on useita tapoja. Olemme kehittäneet CoreDashin juuri näitä käyttötapauksia varten. CoreDash on edullinen, nopea ja tehokas RUM-työkalu, joka yksinkertaisesti hoitaa homman! Tietenkin markkinoilla on monia muitakin RUM- ratkaisuja ja nekin hoitavat tehtävän (tosin korkeammalla hinnalla)

Miten ajatella TTFB:tä: Kuvittele, että web-palvelin on ravintolan keittiö ja sivua pyytävä käyttäjä on nälkäinen asiakas, joka tekee tilauksen. Time to First Byte (TTFB) on ajanjakso tilauksen tekemisen ja keittiön ruoanvalmistuksen aloittamisen välillä.
TTFB EI siis kerro, kuinka nopeasti koko ateria on valmistettu (First Contentful Paint) ja tarjoiltu (Largest Contentful Paint), vaan pikemminkin kuinka reagoiva keittiö on alkuperäiseen pyyntöön. 
RUM-seuranta on verrattavissa asiakkaiden kyselytutkimukseen heidän ruokailukokemuksestaan. Saatat huomata, että kauempana keittiöstä istuvat asiakkaat saavat vähemmän huomiota tarjoilijalta ja heidät palvellaan myöhemmin, tai että vakioasiakkaat saavat etuoikeutetun kohtelun kun taas uudet kävijät joutuvat odottamaan pidempään pöytää 

Vaihe 3: Tunnista Time to First Byte -ongelmat

Vaikka Googlen Chrome User Experience Report (CrUX) tarjoaa arvokasta kenttädataa, se ei anna yksityiskohtaisia tietoja korkean TTFB:n syistä. TTFB:n tehokkaaseen parantamiseen meidän täytyy tietää tarkasti, mitä yksityiskohtaisemmalla tasolla tapahtuu. Tässä vaiheessa on järkevää erottaa kokonaisvaltaisesti epäonnistuva TTFB ja tietyissä olosuhteissa epäonnistuva TTFB (vaikka todellisuudessa näiden yhdistelmä on aina läsnä).

3.1 TTFB epäonnistuu kokonaisvaltaisesti

1. Tarkista yleiset heikot pyyntöajat: Heikot pyyntöajat tarkoittavat, että 'ongelma' liittyy aikaan, jonka palvelin tarvitsee sivun generoimiseen. Tämä on yleisin syy heikoille TTFB-tuloksille! 
2. Tarkista muut heikot TTFB:n osa-alueet: TTFB ei ole vain yksittäinen metriikka, vaan se voidaan jakaa useisiin osiin, joilla on omat optimointimahdollisuutensa. Jos odotusaika, välimuistiaika, DNS-hakuaika tai yhteysaika ovat hitaita, sinun tulisi todennäköisesti säätää palvelimen asetuksia tai alkaa etsiä laadukkaampaa hosting-ratkaisua. 

3.2 TTFB epäonnistuu tietyissä olosuhteissa

1. Maasegmentointi: Korkean TTFB:n maantieteellisen jakauman ymmärtäminen on tärkeää erityisesti globaalin yleisön sivustoille. Jos tarjoilet sivujasi yhdeltä palvelimelta vain yhdessä maassa (ilman CDN edge -välimuistia), käyttäjän sijainnin ja sivuston hosting-palvelimen välinen fyysinen etäisyys aiheuttaa kaikenlaisia viiveitä ja vaikuttaa TTFB:hen. 
   
2. Välimuistisegmentointi: Välimuistitus voi vähentää TTFB:tä ohittamalla palvelinpuolen HTML:n generoinnin. Valitettavasti on yleistä, että välimuistitus on poistettu käytöstä tai ohitettu monista syistä. Esimerkiksi välimuistitus voi olla poistettu käytöstä kirjautuneille käyttäjille, ostoskorisivuille, kyselyparametreja sisältäville sivuille (esim. Google Ads -kampanjoista), hakutulossivuille ja kassasivuille. Jos sivustosi käyttää (edge-)välimuistia, käytä RUM-seurantaa välimuistin osumaprosentin tarkistamiseen!
   
3. Sivu (klusteri) -segmentointi: Time to First Byte -suorituskyvyn erot (tai erojen puuttuminen) sivujen tai sivutyyppien välillä on toinen asia, joka meidän tulee selvittää. Tieto siitä, mitkä sivut epäonnistuvat TTFB-metriikassa, antaa arvokkaita näkemyksiä Time to First Byte -metriikan parantamiseen. 
   
4. Uudelleenohjaussegmentointi: Uudelleenohjausaika lisätään suoraan TTFB:hen. Jokainen uudelleenohjaus lisää ylimääräistä aikaa ennen kuin web-palvelin voi alkaa ladata sivua. Tarpeettomien uudelleenohjausten mittaaminen ja poistaminen voi auttaa parantamaan TTFB:tä.
   
5. Muu segmentointi: Vaikka yllä olevilla muuttujilla segmentointi kattaa tavanomaiset epäillyt, jokainen sivusto on ainutlaatuinen ja sillä on omat haasteensa. Onneksi RUM-seuranta on suunniteltu mahdollistamaan segmentointi monilla muillakin muuttujilla, kuten laitteen RAM, verkon nopeus, laitetyyppi, käyttöjärjestelmä, mukautetut muuttujat ja paljon muuta. 

Vaihe 4: Tarkenna ongelmiin ja korjaa!

Time to First Byte (TTFB) -metriikan osa-alueet ovat:

• Odotus + uudelleenohjaus (tai odotusaika)
  
• Worker + välimuisti (tai välimuistiaika)
• DNS (tai DNS-aika)
• Yhteys (tai yhteysaika)
• Pyyntö (tai pyyntöaika)