Klikkasit linkkiä, ja selain vain istuu paikallaan. Ei sivun latautumista, ei edistymispalkkia, vain valkoinen ruutu ja odottelua. Kyse ei ole nettiyhteydestäsi eikä hitaasta JavaScriptistä. Kyse on TTFB:stä eli ajasta, joka palvelimelta kestää vastata aivan ensimmäiseen pyyntöön.

TTFB määrittää, milloin käyttäjät ylipäätään näkevät ruudullaan mitään. Hitaalla TTFB:llä vierailijat lähtevät jo ennen kuin sivustosi ehtii alkaa renderöityä. Ja vuodesta 2025 alkaen Google sisällyttää palvelimen vasteajan sijoitussignaaleihinsa Core Web Vitals.

Alta löydät, mitä TTFB todella on, mistä neljästä osatekijästä se koostuu ja miten saat sen painettua tasolle, jolla sivustosi toimittaa ensimmäisen tavun nopeammin kuin käyttäjä ehtii räpäyttää silmäänsä.

💡 Nopea yleiskatsaus:

• Ymmärrä, mitä TTFB on ja miksi jokainen tämän viiveen sekunti kertaantuu jokaisessa kävijän toiminnossa.
• Käy läpi neljän tekijän ketju: DNS, palvelin, WordPress-lisäosat ja HTML-välimuistitus.
• Vertaile neljää skenaariota oikeilla Pingdom-mittauksilla, 150 millisekunnista katastrofaaliseen 4,2 sekuntiin.
• Ota käyttöön HTML-välimuistitus ja näe, miten yksi ainoa lisäosa pudottaa TTFB:tä dramaattisesti ilman palveluntarjoajan vaihtoa.

Mitä TTFB on ja miksi se vaikuttaa kaikkeen

Muodollinen määritelmä Wikipediasta: TTFB on aika HTTP-pyynnön lähettämisestä vastauksen ensimmäisen tavun vastaanottamiseen asiakasselaimessa. Se sisältää socket-yhteyden viiveen, pyynnön lähetysajan ja palvelimen käsittelyajan.

Yksinkertaisemmin sanottuna: TTFB on tauko "linkin klikkaamisen" ja "sivustolla alkaa tapahtua jotain" välillä. Pelitermeillä se on latenssi, pingi, viive ennen ensimmäistä vastausta. Käyttäjät eivät näe ylätunnistetta, valikkoa eivätkä latausanimaatiota, vain tyhjän välilehden. Mitä pidempi tämä tauko on, sitä suuremmalla todennäköisyydellä he sulkevat välilehden.

Tärkeä vivahde: TTFB vaikuttaa muuhunkin kuin vain sivun ensimmäiseen lataukseen. Jokainen sisäinen navigointi, jokainen valikkolinkin klikkaus, jokainen artikkelin sisällä olevan kuvan klikkaus on erillinen HTTP-pyyntö, jolla on oma TTFB:nsä. Huono tulos kertaantuu jokaisessa lukijan toiminnossa.

Neljä tekijää, joista TTFB muodostuu

TTFB ei ole yksi ainoa mittari, vaan viiveiden summa "käyttäjä → sivusto" -ketjun jokaisessa vaiheessa. Kaikki neljä lenkkiä toimivat peräkkäin: jos yksi hidastuu, lopputuloskin hidastuu. Tarkastellaan kutakin erikseen.

DNS: ensimmäinen tarkistuspiste

Selain ei tiedä, missä palvelimesi fyysisesti sijaitsee, ennen kuin DNS muuntaa verkkotunnuksen IP-osoitteeksi. Hyvät DNS-palvelimet, joissa on hajautettu solmuverkko, tekevät tämän millisekunneissa, kun taas huonot lisäävät kymmeniä tai satoja millisekunteja jokaiseen sivulataukseen.

Käytännön minimi: käytä Cloudflarea tai vastaavaa palvelua, jossa on maailmanlaajuinen DNS-välimuistitus. Ensimmäisen pyynnön jälkeen osoite pysyy välimuistissa, ja DNS-viive katoaa kokonaan seuraavilta pyynnöiltä.

Palvelin ja PHP: mitä palveluntarjoajan päässä tapahtuu

Jokainen pyyntö välimuistittamattomalle WordPress-sivulle käynnistää PHP-tulkin. Palvelin lataa ytimen, teeman ja aktiiviset lisäosat, suorittaa niiden koodin ja vasta sitten toimittaa HTML:n. Nykyaikaiset PHP-versiot käsittelevät tämän syklin paljon nopeammin kuin vuosikymmenen takaiset julkaisut, puhumattakaan täysin vanhentuneista haaroista.

Kaksi palvelinparametria määrittää nopeuden: PHP-versio ja palvelupaketillesi varattu suoritinaika. Halpa jaettu hosting, jossa on kymmeniä sivustoja yhdellä palvelimella ja vanhentunut PHP, on varma tie yli sekunnin TTFB:hen. Erikoistunut WordPress-hosting, jossa on PHP 8.2+ ja sisäänrakennettu palvelintason välimuistitus, tuottaa täysin erilaisia lukemia.

WordPress-lisäosat ja teema

WordPress kokoaa sivut kymmenistä PHP-tiedostoista, ja jokainen aktiivinen lisäosa lisää oman koodinsa tähän prosessiin. Kymmenen laadukasta lisäosaa hyvämaineisilta kehittäjiltä tuskin vaikuttaa TTFB:hen. Yksi huonosti kirjoitettu lisäosa, joka tekee kolme ylimääräistä tietokantakyselyä jokaisella pyynnöllä, voi romuttaa koko sivustosi nopeuden.

Tässä esimerkki järkevästä lisäosakokoonpanosta, kaikki tarpeellinen, ei mitään ylimääräistä:

Ja tämä on jo mahdollisesti ongelmallinen kokoonpano. Useita kymmeniä aktiivisia lisäosia, ja palvelimen on käsiteltävä jokainen niistä sivua muodostaessaan:

Käytännössä yli 30 aktiivista lisäosaa lähes takaa korkean TTFB:n, jopa hyvällä hostingilla. Sääntö on yksinkertainen: jokaisella lisäosalla tulee olla tietty tehtävä, jota ei voi ratkaista muuten. Kaikki, mikä on siellä "varmuuden vuoksi", tulee poistaa.

HTML-välimuistitus: tärkein vipuvarsi

Kaikkein tehokkain tekijä. Välimuistilisäosa, kuten Cache Enabler, tallentaa valmiita HTML-kopioita sivuista palvelimen levylle. Kun pyyntö saapuu, verkkopalvelin toimittaa staattisen tiedoston ohittaen koko PHP- ja WordPress-pinon.

Lopputulos: palvelimen ei enää tarvitse ladata ydintä, teemaa ja lisäosia jokaiselle kävijälle. Vain itse verkkopalvelin (nginx tai Apache) palvelee sisältöä suoraan. Tästä syystä välimuistitus tarjoaa merkittävimmän TTFB:n pienenemisen, kertaluokissa eikä prosenteissa. Käsittelimme, miksi nginx on tähän tehtävään tehokkaampi kuin Apache, erillisessä artikkelissa.

TTFB käytännössä: neljä skenaariota

Siirrytään todellisiin mittauksiin. Alla on testituloksia erilaisille sivusto- ja palvelinyhdistelmille, jotka on saatu Pingdom Toolsin kautta. Jokainen skenaario näyttää TTFB:n sekä välimuistittamattomalle että välimuistitetulle versiolle.

Hidas sivusto hitaalla palvelimella

Huonoin mahdollinen yhdistelmä: kymmeniä lisäosia sisältävä sivusto ilman välimuistitusta vanhalla jaetulla hostingilla, jossa on PHP 5.4.

Laajennetaan ensimmäisen pyynnön tietoja, jossa näkyy palvelimen ikuisuudelta tuntuva miettimisaika:

TTFB on 4,2 sekuntia. Neljä sekuntia käyttäjä tuijottaa tyhjää ruutua, ennen kuin selain vastaanottaa mitään dataa. Lisää siihen sivun renderöintiaika, ja kokonaisodotusaika ennen kuin sivusto on valmis nousee helposti seitsemään sekuntiin. Cloudflare edessä ei auta tässä: ongelma on syvemmällä, hostingin ja sivuston koodin tasolla.

Nopea sivusto keskitasoisella palvelimella

Muuttuvat olosuhteet: sivusto, jossa on minimaalisesti lisäosia, palvelin Apachella ja vakio-PHP-versiolla, ei välimuistitusta.

Tulos: 521 ms. Jo 8 kertaa parempi kuin ensimmäinen skenaario. Puoli sekuntia ensimmäiseen tavuun, hyväksyttävää useimmille sivustoille. Otetaan nyt välimuistitus käyttöön:

TTFB putoaa 152 millisekuntiin. Jopa keskitasoinen hosting oikein määritetyllä välimuistituksella tuottaa erinomaisia tuloksia.

Hidas sivusto nopealla palvelimella

Käänteinen tilanne: optimoitu palvelin Pleskillä, jossa on nginx ja vakio-PHP-versio, mutta lisäosilla pullisteltu sivusto.

Ilman välimuistia nopea palvelin käyttää silti 1,29 sekuntia raskaan sivuston käsittelyyn. Hyvä hosting lieventää, mutta ei ratkaise huonosti optimoidun WordPressin ongelmaa.

Ota välimuistitus käyttöön, ja TTFB putoaa 400 millisekuntiin. Ero on yli kolminkertainen.

Nopea sivusto nopealla palvelimella

Optimaalinen skenaario: kevyt sivusto hyvällä hostingilla.

Ilman välimuistia palvelin toimittaa ensimmäisen tavun alle 500 millisekunnissa. Lisää välimuistitus:

Tulos: alle 150 ms. Käytännössä välitön vaste.

Tulosten yhteenveto

Kaikki neljä skenaariota yhdessä kaaviossa:

Näistä mittauksista voi vetää suoran johtopäätöksen: palvelinympäristöllä on väliä, mutta se, mitä itse sivustolle tehdään, vaikuttaa TTFB:hen enemmän. Nopea palvelin ja välimuistitus voivat nostaa ongelmallisenkin sivuston hyväksyttävään 400 millisekuntiin, kun taas hidas palvelin ilman välimuistia upottaa kevyenkin WordPress-sivuston.

Miten TTFB:tä parannetaan: vaiheittainen suunnitelma

Optimointi etenee yksinkertaisesta monimutkaiseen, viidessä minuutissa tehtävistä ja suurimman vaikutuksen tuovista toimista hienosäätöön.

Vaihe 1: ota HTML-välimuisti käyttöön. Asenna ilmainen Cache Enabler tai vastaava välimuistilisäosa. Tämä yksittäinen toimenpide pienentää TTFB:tä dramaattisesti millä tahansa palveluntarjoajalla. Liioittelematta: paras tuotto käytetylle minuutille koko WordPress-optimoinnissa.

Vaihe 2: tarkista PHP-versiosi. Etsi palveluntarjoajasi hallintapaneelista tai cPanelista PHP-version asetus. Jos nykyaikainen versio on saatavilla (8.2 tai uudempi), vaihda siihen. Vanhentuneesta haarasta moderniin siirtyminen nopeuttaa huomattavasti jokaisen pyynnön käsittelyä. Ennen vaihtoa varmista, että teemasi ja kaikki lisäosasi ovat yhteensopivia valitun version kanssa.

Vaihe 3: tarkasta lisäosasi. Poista käytöstä kaikki, mikä ei ole parhaillaan aktiivisessa käytössä. Pidä vain lisäosat, jotka ratkaisevat jonkin tietyn tehtävän. Kaikki muu tulee poistaa, ei pelkästään deaktivoida. Lisäosat, jotka on säästetty "tulevaa käyttöä varten" tai "jotka saattavat olla hyödyksi", lisäävät koodia jokaiseen pyyntöön, käytitpä niitä tai et.

Vaihe 4: valitse nopea teema. Teema määrittää, kuinka paljon PHP-koodia suoritetaan jokaisella sivulatauksella. Raskaat teemat, joissa on visuaalisia sivurakentajia, tuottavat merkittävästi enemmän palvelintyötä kuin minimalistiset ratkaisut. Jos TTFB-testi puhtaalla WordPress-asennuksella (ei lisäosia, oletusteema) näyttää hyvää tulosta, mutta tulos romahtaa teemasi aktivoinnin jälkeen, ongelma on itse teemassa.

Vaihe 5: arvioi palveluntarjoajasi. Jos TTFB on edelleen yli 500-800 ms neljän ensimmäisen vaiheen jälkeen, rajoitus on palvelinpäässä. Erikoistunut WordPress-palveluntarjoaja, jossa on nginx, PHP 8.2+ ja palvelinpuolen välimuisti, tarjoaa perustavanlaatuisesti erilaisen vasteaikatason. Valitessasi etsi sisäänrakennettua objektivälimuistia (Redis tai Memcached), joka on seuraava taso HTML-välimuistin jälkeen.

Video: TTFB teoriasta tuloksiin

Katso visuaalinen TTFB-erittely ja live-mittaukset ennen optimointia ja sen jälkeen:

⁉️🤔 Usein kysytyt kysymykset

Mikä TTFB on hyvä WordPressille?

Käytä ohjenuorana Googlen Core Web Vitals -tavoitenopeuksia: jopa 800 ms on hyväksyttävä, jopa 500 ms on hyvä, jopa 200 ms on erinomainen. Käytännössä WordPress-sivustolla, jossa on välimuisti, saavutettavissa oleva vaihteluväli on 100-400 ms. Ilman välimuistia nopeakaan sivusto harvoin alittaa 400-500 ms.

Onko palveluntarjoajan vaihto pakollista TTFB:n parantamiseksi?

Ei aina. HTML-välimuisti pienentää TTFB:tä dramaattisesti jopa keskinkertaisella palvelimella. Ennen siirtoa ota välimuisti käyttöön, päivitä PHP nykyaikaiseen versioon ja siivoa lisäosat. Jos TTFB on sen jälkeen edelleen yli 800 ms, silloin on todella aika vaihtaa palveluntarjoajaa.

Miksi TTFB vaihtelee mittauksesta toiseen?

TTFB:hen vaikuttavat palvelimen suorittimen kuormitus mittaushetkellä, verkon viive ja testipalvelimen sijainti. Ota 5-7 mittauksen sarja ja käytä mediaania, älä ensimmäistä satunnaista arvoa. Testaa useista sijainneista: palvelin Euroopassa voi näyttää erinomaista TTFB:tä Frankfurtista, mutta heikkoa Tokiosta.

Vaikuttaako TTFB Googlen sijoituksiin?

Kyllä, vuodesta 2025 alkaen palvelimen vasteaika on osa Core Web Vitals -signaaleja sijoitustekijänä. Suora vaikutus on kohtalainen, mutta epäsuora vaikutus on merkittävä: korkea TTFB kasvattaa välitöntä poistumisprosenttia, ja korkea poistumisprosentti heikentää sijoituksia suoraan.

Voinko mitata TTFB:n ilmaiseksi?

Kyllä. Käytä Pingdom Toolsia, GTmetrixiä, PageSpeed Insightsia tai WebPageTestiä. Tärkeä vivahde: mittaa nimenomaan TTFB (aika ensimmäiseen tavuun), ei sivun kokonaislatausaikaa. Pingdomissa sinun on laajennettava sivuston ensimmäisen pyynnön tiedot tätä varten.

Mitä TTFB:lle kannattaa tehdä juuri nyt

Yllä olevien mittausten tärkein johtopäätös: HTML-välimuisti on tehokkain ja yksinkertaisin vipuvarsi. Yksi ainoa lisäosa pienentää TTFB:tä dramaattisesti millä tahansa palveluntarjoajalla, ja siihen menee tasan viisi minuuttia.

Toimintajärjestys on seuraava:

• Jos TTFB > 1 sekunti, aloita välimuistista ja PHP:n päivittämisestä. Nämä kaksi vaihetta tuovat suurimman osan mahdollisesta parannuksesta.
• Jos TTFB on 400-800 ms, lisäosien ja teeman tarkastus yleensä poistaa jäljellä olevan viiveen.
• Jos TTFB on jatkuvasti alle 200 ms, olet optimaalisella alueella; pidä nykyinen taso yllä.

Aloita ilmaisella välimuistilisäosalla: asenna, aktivoi ja aja testi Pingdom Toolsilla. Näet eron välittömästi. Mikä on nykyinen TTFB:si? Jaa lukemasi kommenteissa.