Klõpsasid lingil ja brauser lihtsalt seisab. Ei mingit lehe laadimist, ei mingit edenemisnäidikut, ainult valge ekraan ja ootamine. See ei ole sinu internetikiirus ega aeglane JavaScript. See on TTFB: aeg, mis kulub serveril kõige esimesele päringule vastamiseks.

TTFB määrab, millal kasutajad üldse midagi oma ekraanil näevad. Aeglase TTFB korral lahkuvad külastajad enne, kui su sait üldse renderduma hakkab. Ja alates 2025. aastast arvestab Google oma paremusjärjestuse signaalides Core Web Vitals raames ka serveri reageerimisvõimet.

Altpoolt leiad, mis TTFB tegelikult on, millisest neljast komponendist see koosneb ja kuidas viia see tasemele, kus su sait toimetab esimese baidi kohale kiiremini, kui kasutaja jõuab silma pilgutada.

💡 Kiirülevaade:

• Mõista, mis on TTFB ja miks iga selle viivituse sekund korrutub iga külastaja tegevusega.
• Jaluta läbi nelja teguri ahel: DNS, server, WordPressi pluginad ja HTML-i puhverdamine.
• Võrdle nelja stsenaariumi reaalsete Pingdomi mõõtmistega, alates 150 ms kuni katastroofilise 4,2 sekundini.
• Luba HTML-i puhverdamine ja vaata, kuidas üksainus plugin vähendab TTFB-d dramaatiliselt ilma hosti vahetamata.

Mis on TTFB ja miks see mõjutab kõike

Formaalne definitsioon Vikipeediast: TTFB on aeg HTTP-päringu saatmisest kuni vastuse esimese baidi kättesaamiseni kliendi brauseris. See hõlmab socket-ühenduse latentsust, päringu edastamise aega ja serveri töötlusaega.

Lihtsamalt öeldes: TTFB on paus „lingil klõpsamise" ja „saidil hakkab midagi toimuma" vahel. Mängurikeeles on see latentsus, ping, viivitus enne esimest vastust. Kasutajad ei näe päist, menüüd ega laadimisanimatsiooni, ainult tühja kaarti. Mida pikem see paus, seda suurem on tõenäosus, et nad sulgevad kaardi.

Oluline nüanss: TTFB ei mõjuta ainult esmast lehe laadimist. Iga sisemine navigeerimine, iga klikk menüülingil, iga klikk postituses oleval pildil on eraldi HTTP-päring omaenda TTFB-ga. Kehv tulemus korrutub iga lugeja tegevusega.

Neli tegurit, millest TTFB koosneb

TTFB ei ole üksik mõõdik, vaid viivituste summa ahela „kasutaja → sait" igas etapis. Kõik neli lüli töötavad järjestikku: kui üks aeglustub, aeglustub ka lõpptulemus. Vaatame igaühte lähemalt.

DNS: esimene kontrollpunkt

Brauser ei tea, kus su server füüsiliselt asub, enne kui DNS teisendab domeeni IP-aadressiks. Head, hajutatud sõlmede võrguga DNS-serverid teevad seda millisekunditega, samas kui kehvad lisavad igale lehe laadimisele kümneid või sadu millisekundeid.

Praktiline miinimum: kasuta Cloudflare'i või sarnast globaalse DNS-i puhverdamisega teenust. Pärast esimest päringut jääb aadress puhvrisse ja DNS-i latentsus kaob järgmiste päringute puhul täielikult.

Server ja PHP: mis toimub hostis

Iga päring puhverdamata WordPressi lehele käivitab PHP interpretaatori. Server laeb tuuma, teema ja aktiivsed pluginad, käivitab nende koodi ja alles seejärel edastab HTML-i. Kaasaegsed PHP versioonid käsitlevad seda tsüklit palju kiiremini kui kümnendi tagused väljalasked, rääkimata täiesti iganenud harudest.

Kaks hostingu parameetrit määravad kiiruse: PHP versioon ja sinu paketile eraldatud protsessori aeg. Odav jagatud hostimine, kus ühel serveril on kümneid saite ja aegunud PHP, on garanteeritud tee TTFB > 1 sekund. Spetsialiseeritud WordPressi hostimine PHP 8.2+ ja sisseehitatud serveritaseme puhverdamisega annab põhimõtteliselt teistsuguseid numbreid.

WordPressi pluginad ja teema

WordPress koostab lehti kümnetest PHP-failidest ja iga aktiivne plugin lisab sellesse protsessi oma koodi. Kümme kvaliteetset pluginat tunnustatud arendajatelt võivad TTFB-d vaevu mõjutada. Üks kehvasti kirjutatud plugin, mis teeb igal päringul kolm täiendavat andmebaasipäringut, võib kogu saidi kiiruse põhja lasta.

Siin on näide mõistlikust pluginakomplektist, kõik vajalik, mitte midagi üleliigset:

Ja see on juba potentsiaalselt problemaatiline konfiguratsioon. Mitukümmend aktiivset pluginat ja server peab lehe genereerimisel igaühte neist töötlema:

Praktikas tähendab üle 30 aktiivse plugina peaaegu garanteeritult kõrget TTFB-d, isegi hea hostingu korral. Reegel on lihtne: iga plugin peaks täitma konkreetset ülesannet, mida ei saa muul viisil lahendada. Kõik, mis on seal „igaks juhuks", tuleks eemaldada.

HTML-i puhverdamine: peamine hoob

Kõige võimsam tegur üldse. Vahemäluplugin nagu Cache Enabler salvestab lehtedest valmis HTML-koopiad serveri kettale. Kui päring saabub, edastab veebiserver staatilise faili, jättes kogu PHP ja WordPressi virna vahele.

Tulemus: server ei pea enam iga külastaja jaoks tuuma, teemat ja pluginaid laadima. Ainult veebiserver ise (nginx või Apache) edastab sisu otse. Seepärast annabki vahemällu salvestamine kõige märkimisväärsema TTFB vähenemise, mõõdetuna kordades, mitte protsentides. Miks nginx on selle ülesande jaoks tõhusam kui Apache, käsitlesime eraldi artiklis.

TTFB praktikas: neli stsenaariumi

Liigume edasi reaalsete mõõtmiste juurde. Allpool on Pingdom Toolsi abil saadud testitulemused erinevate saitide ja serverite kombinatsioonide kohta. Iga stsenaarium näitab TTFB-d nii vahemällu salvestamata kui ka salvestatud versiooni puhul.

Aeglane sait aeglasel serveril

Halvim võimalik kombinatsioon: sait kümnete pluginatega ja ilma vahemäluta vanal jagatud hostingu serveril, kus töötab PHP 5.4.

Vaatame lähemalt esimese päringu üksikasju, kus on näha serveri igavesti kestev mõtlemisaeg:

TTFB on 4,2 sekundit. Neli sekundit, mil kasutaja vaatab tühja ekraani, enne kui brauser üldse andmeid vastu võtab. Lisage sellele lehe renderdamise aeg ja kogu ooteaeg enne saidi valmimist küünib kergesti seitsme sekundini. Ees olev Cloudflare siin ei aita: probleem on sügavamal, hostingu ja saidi koodi tasandil.

Kiire sait keskmisel serveril

Muudetud tingimused: minimaalsete pluginatega sait, server Apache’l standardse PHP versiooniga, vahemälu puudub.

Tulemus: 521 ms. Juba 8 korda parem kui esimeses stsenaariumis. Pool sekundit esimese baidini, enamiku saitide jaoks vastuvõetav. Nüüd lubame vahemälu:

TTFB langeb 152 millisekundini. Isegi keskmine hosting koos korralikult seadistatud vahemäluga annab suurepäraseid tulemusi.

Aeglane sait kiirel serveril

Vastupidine olukord: optimeeritud server Pleskis koos nginxiga ja standardse PHP versiooniga, kuid pluginatega üle koormatud sait.

Ilma vahemäluta kulutab kiire server raske saidi töötlemisele ikkagi 1,29 sekundit. Hea hosting leevendab, kuid ei lahenda halvasti optimeeritud WordPressi probleemi.

Lubage vahemälu ja TTFB langeb 400 millisekundini. Rohkem kui kolmekordne erinevus.

Kiire sait kiirel serveril

Optimaalne stsenaarium: kerge sait heal hostingul.

Ilma vahemäluta edastab server esimese baidi alla 500 millisekundiga. Lisage vahemälu:

Tulemus: alla 150 ms. Praktiliselt kohene vastus.

Tulemuste kokkuvõte

Kõik neli stsenaariumi ühel graafikul:

Nende mõõtmiste järeldus on selge: majutus loeb, kuid see, mida sa saidi endaga teed, mõjutab TTFB-d rohkem. Kiire server koos vahemäluga suudab isegi probleemse saidi vastuvõetava 400 ms peale tõmmata, samas kui aeglane server ilma vahemäluta uputab isegi kerge WordPressi saidi.

Kuidas TTFB-d parandada: samm-sammuline plaan

Optimeerimine liigub lihtsast keerukani, alates sellest, mis võtab viis minutit ja annab maksimaalse mõju, kuni peenemate seadistusteni.

1. samm: luba HTML-i vahemälu. Paigalda tasuta Cache Enabler või mõni sarnane vahemäluplugin. See üksainus tegevus vähendab TTFB-d dramaatiliselt igal majutusel. Liialdamata võib öelda, et see on suurima tulususega minut kogu WordPressi optimeerimises.

2. samm: kontrolli oma PHP versiooni. Leia oma majutuse halduspaneelilt või cPanelist PHP versiooni seade. Kui saadaval on uuem versioon (8.2 või uuem), lülita sellele ümber. Vananenud harult kaasaegsele üleminek kiirendab märgatavalt iga päringu töötlemist. Enne ümberlülitamist veendu, et sinu teema ja kõik pluginad oleksid valitud versiooniga ühilduvad.

3. samm: auditeeri oma pluginaid. Keela kõik, mis ei ole praegu aktiivses kasutuses. Jäta alles ainult pluginad, mis lahendavad konkreetset ülesannet. Kõik muu tuleks kustutada, mitte lihtsalt deaktiveerida. Pluginad, mida hoitakse „edaspidiseks kasutuseks" või „võib-olla läheb vaja", lisavad koodi igale päringule, olenemata sellest, kas sa neid kasutad või mitte.

4. samm: vali kiire teema. Teema määrab, kui palju PHP koodi iga lehe laadimisel käivitatakse. Rasked teemad koos visuaalsete leheehitajatega tekitavad oluliselt rohkem serveritööd kui minimalistlikud lahendused. Kui TTFB test puhtal WordPressi installatsioonil (ilma pluginateta, vaiketeema) näitab head tulemust, kuid skoor langeb järsult pärast sinu teema aktiveerimist, on probleem teemas endas.

5. samm: hinda oma majutust. Kui TTFB ületab pärast esimest nelja sammu endiselt 500-800 ms, on piirang majutuse poolel. Spetsialiseeritud WordPressi majutus koos nginx-i, PHP 8.2+ ja serveripoolse vahemäluga pakub põhimõtteliselt teistsugust reageerimiskiirust. Valides otsi sisseehitatud objektivahemälu (Redis või Memcached), mis on järgmine tase pärast HTML-i vahemälu.

Video: TTFB teooriast tulemusteni

Vaata visuaalset TTFB lahtiseletust koos reaalajas mõõtmistega enne ja pärast optimeerimist:

⁉️🤔 Korduma kippuvad küsimused

Millist TTFB-d peetakse WordPressi jaoks heaks?

Kasuta juhisena Google Core Web Vitalsi sihtväärtusi: kuni 800 ms on vastuvõetav, kuni 500 ms on hea, kuni 200 ms on suurepärane. Praktikas on vahemäluga WordPressi saidi puhul saavutatav vahemik 100-400 ms. Ilma vahemäluta langeb isegi kiire sait harva alla 400-500 ms.

Kas TTFB parandamiseks on majutuse vahetamine kohustuslik?

Mitte alati. HTML-i vahemälu vähendab TTFB-d dramaatiliselt isegi keskmisel majutusel. Enne kolimist luba vahemälu, uuenda PHP uuemale versioonile ja korista pluginad ära. Kui TTFB on pärast seda endiselt üle 800 ms, siis on tõesti aeg majutust vahetada.

Miks TTFB mõõtmiste lõikes kõigub?

TTFB-d mõjutavad serveri protsessori koormus mõõtmise hetkel, võrgu latentsus ja testserveri geograafiline asukoht. Tee seeria 5-7 mõõtmisest ja kasuta mediaani, mitte esimest juhuslikku väärtust. Testi mitmest asukohast: Euroopas asuv server võib näidata suurepärast TTFB-d Frankfurtist, kuid kehva Tokyost.

Kas TTFB mõjutab Google'i edetabeleid?

Jah, alates 2025. aastast on serveri reageerimisvõime osa Core Web Vitalsist kui edetabelisignaal. Otsene mõju on mõõdukas, kuid kaudne mõju on märkimisväärne: kõrge TTFB suurendab põrkemäära ja kõrge põrkemäär kahjustab otseselt edetabeleid.

Kas ma saan TTFB-d tasuta mõõta?

Jah. Kasuta Pingdom Tools, GTmetrix, PageSpeed Insights või WebPageTest. Oluline nüanss: mõõda konkreetselt TTFB-d (time to first byte), mitte kogu lehe laadimisaega. Pingdomis pead selleks laiendama saidi esimese päringu üksikasju.

Mida TTFB-ga kohe ette võtta

Peamine järeldus ülaltoodud mõõtmistest: HTML-i vahemälu on kõige võimsam ja lihtsam hoob. Üksainus plugin vähendab TTFB-d dramaatiliselt igal majutusel ja see võtab täpselt viis minutit.

Tegevuste järjekord on järgmine:

• Kui TTFB > 1 sekund, alusta vahemälust ja PHP uuendamisest. Need kaks sammu annavad suurema osa võimalikust paranemisest.
• Kui TTFB on vahemikus 400 kuni 800 ms, kõrvaldab pluginapõhine ja teema audit tavaliselt ülejäänud viivituse.
• Kui TTFB on püsivalt alla 200 ms, oled optimaalses tsoonis; hoia praegust taset.

Alusta tasuta vahemälupluginaga: paigalda, aktiveeri ja tee test läbi Pingdom Tools. Näed erinevust kohe. Milline on sinu praegune TTFB? Jaga oma numbreid kommentaarides.