Google Lighthouse annab 45 punkti. Leht laadib kolm sekundit. Pildid on optimeeritud, cache on peal, plugin nimekiri on puhastatud – aga leht on ikka aeglane. Miks?
Vastus on sageli TTFB – Time To First Byte. See üks number selgitab rohkem kui ükski teine mõõdik, miks leht on aeglane isegi siis, kui kõik muu on tehtud õigesti.
Mis on TTFB
TTFB mõõdab aega alates hetkest, kui brauser saadab serverile päringu, kuni hetkeni, mil server hakkab vastust tagasi saatma. Mitte kogu lehe laadimine – ainult esimese baidi kättesaamine.
See on serveri reaktsiooniaeg. Kui TTFB on suur, ei ole probleem sinus – mitte piltides, mitte pluginates, mitte koodis. Probleem on serveris.
Mõelge nii: olete restoranis ja teete tellimuse. TTFB on aeg tellimusest kuni hetkeni, mil kokk alustab toiduvalmistamist. Kui see aeg on viis minutit, ei aita see, et kokk ise töötab kiiresti – lõpptulemus tuleb ikka hilja.
Mõõdikud:
- Alla 200ms – suurepärane
- 200–500ms – hea, vastuvõetav
- 500–800ms – märgatav, tasub uurida
- Üle 800ms – probleem, mis mõjutab Google skoori ja kasutajakogemust
- Üle 1500ms – kriis
Kuidas TTFB mõõta
Google PageSpeed Insights (PSI) on lihtsaim ja kõige kättesaadavam tööriist. Sisesta URL, vajuta analüüsi – TTFB kuvatakse “Server Response Time” all. PSI mõõdab reaalset kasutajakogemust Chrome’i kasutajate andmete põhjal, mis teeb sellest usaldusväärseima näitaja.
GTmetrix annab detailsema ülevaate – waterfall graafik näitab täpselt, mis millal laadib ja kui kaua TTFB võtab. Saab valida testserveri asukoha, mis on oluline – Eesti leht peaks reageerima kiiresti Euroopa serverist testides.
WebPageTest on tehniline tööriist neile, kes tahavad sügavamat analüüsi – mitme samaaegse testi võrdlus, erinevad ühenduskiirused, mobiili emulatsioon.
Igapäevaseks monitooringuks piisab PSI-st ja GTmetrixist.
Mis TTFB-d mõjutab
TTFB ei ole üks asi – see on mitme teguri summa.
Server ja majutus on kõige suurem mõjutaja. Haldatud WordPress hosting kvaliteetsel platvormil versus odav jagatud majutus – vahe võib olla 10ms ja 800ms vahel. See ei ole liialdus, see on mõõdetav reaalsus.
Praktika näitab: Zone.ee hästi seadistatud virtuaalserver annab stabiilselt 0ms TTFB – PSI ei suuda isegi mõõta, nii kiire on. Sama tulemus on saavutatud ka veebimajutus.ee stabiilses serveris. Ebastabiilses klastris langeb sama platvorm 80–100ms peale, mis on juba märgatav kõrvalekalle.
WordPress teema ja kood on teine suur tegur, mida tihti alahindatakse. Raske page builder koos suure tootekataloogiga võib TTFB üksinda viia 4–8 millisekundi peale isegi hea serveri peal. See kõlab väikesena, aga kui sama leht peaks olema 0ms, on see märgatav degradatsioon. Divi teema koos suure WooCommerce poega on klassikaline näide – PHP peab töötlema rohkem koodi enne kui saab vastata.
HeadRehvid.ee näide on siin illustratiivne: optimeeritud custom teema Zone’i serveril annab 0ms TTFB igas mõõtmises. Sama leht Divi peal oleks oluliselt aeglasem – mitte serveri, vaid teema keerukuse tõttu.
Andmebaas on kolmas tegur. WordPress teeb igal lehe laadimisel mitu andmebaasipäringut – menüü, vidinad, postitused, seadistused. Optimeerimata andmebaas aeglaste päringutega lisab TTFB-le märgatavalt aega. Redis Object Cache lahendab selle – puhverdab päringute tulemused mällu, nii et andmebaasi ei pea iga kord minema. Sellest räägime eraldi artiklis.
PHP versioon mõjutab samuti. PHP 8.2 on oluliselt kiirem kui PHP 7.4 – sama kood töötab kiiremini lihtsalt sellepärast, et mootor on parem. Vana PHP versioon vananenud serveril on TTFB jaoks topeltlöök.
Kuidas TTFB parandada
Esimene samm – mõõda. PSI või GTmetrix, vaata “Server Response Time” numbrit. Kui see on alla 200ms, on server korras ja probleem on mujal. Kui üle 500ms, on server esimene koht kus tegutseda.
Teine samm – serveri kvaliteet. Kui TTFB on kõrge ja kasutad odavat jagatud majutust, on lihtne test: kontrolli sama lehe GTmetrix tulemusi erinevatel kellaaegadel. Kui TTFB varieerub suurelt – näiteks 200ms hommikul ja 900ms õhtul – on tõenäoliselt tegemist ülekoormatud jagatud serveriga. Lahendus on majutuse vahetus.
Kolmas samm – Redis Object Cache. Kui server on korras aga TTFB on ikka 200–400ms, on järgmine samm andmebaasi optimeerimine. Redis puhverdab korduvad päringud mällu – tüüpiline tulemus on 40–60% TTFB vähenemine.
Neljas samm – teema ja kood. Kui eelnevad sammud on tehtud aga TTFB on ikka kõrge, on probleem tõenäoliselt teemas või pluginates. Raske page builder, palju aktiivseid pluginaid, optimeerimata PHP kood – kõik see lisab serveripoolset töötlusaega. Lahendus on koodiaudit ja optimeerimine. Parim viis Wordpress siseste scriptide, andmebaasi jms vigade tuvastamiseks on Query Monitor plugin.
TTFB ja Google
Google kasutab TTFB-d Core Web Vitals mõõdikute arvutamisel. Kõrge TTFB mõjutab otseselt FCP-d (First Contentful Paint) ja LCP-d (Largest Contentful Paint) – kui server vastab aeglaselt, ei saa miski muu kiire olla.
Lihtne loogika: kui TTFB on 1 sekund, siis FCP ei saa kunagi olla alla 1 sekundi, olenemata sellest kui palju muud optimeerid. TTFB on põrand, millest allapoole ei saa.
Kokkuvõte
TTFB on esimene number, mida vaatan kui leht on aeglane. See ütleb kohe, kas probleem on serveris või mujal – ja suunab optimeerimise õigesse kohta.
Hea TTFB ei lahenda kõike. Aga halb TTFB tähendab, et kõik muu optimeerimine on poolik töö.
Kui sul on veebileht aeglane ning vajad professionaalset abi parandamisel, siis võta ühendust – tuvastame kitsaskohad ning lahendame probleemid.