Wanneer het aankomt op de snelheid van jouw website dan ligt de focus voornamelijk op de front-end prestatie en optimalisatie om de laadtijden van pagina’s te verbeteren.
Soms is het ook goed om naar de server-kant te kijken, de plek waar jouw website begint met laden.
Vandaag duiken we in het onderwerp TTFB (Time to first byte), hoe het jouw website beïnvloedt en we bespreken gemakkelijke manieren om de tijd te verkorten. TTFB is vaak een overgeslagen prestatie factor, maar het zou zeker in overweging moeten worden genomen wanneer de snelheid van een website wordt getest.
Wat is TTFB?
TTFB staat voor time to first byte. Simpel gezegd: de tijd hoe lang het duurt voor de browser de eerste byte data ontvangt van de webserver. Hoe langer het duurt om de data te ontvangen, hoe langer het duurt voor de browser om jouw pagina te weergeven. Een veel voorkomend misverstand is dat het wordt berekend na de DNS look-up, maar in de originele berekening van TTFB is netwerk latency inclusief. Dit bestaat uit een 3 stappen proces en vertragingen en latency kan overal optreden wat bijdraagt aan het totaal TTFB.
1. Verzoek naar de Server
Wanneer iemand jouw website bezoekt dan is het eerste wat gebeurt een HTTP verzoek verstuurd van de browser naar de server. In deze stap zijn er een aantal factoren die vertragingen kunnen veroorzaken. Langzame DNS look-up tijden kunnen bijdragen aan de verhoogde tijd voor het verzoek. Indien de server geografisch gezien ver gelokaliseerd is dan kan dit latency in de afstand die de data moet afleggen veroorzaken. Ook kunnen ingewikkelde firewall regels de routing tijd verlengen. En vergeet de internetsnelheid van de cliënt niet.
2. Server verwerking
Nadat het verzoek is verstuurd moet de server het verwerken en een reactie genereren. Dit kan weer voor een aantal vertragingen zorgen zoals bijvoorbeeld trage database calls, te veel externe scripts, het niet cachen van de eerste reactie, slecht geoptimaliseerde code of thema en inefficiënte server resources zoals disk I/O of geheugen.
3. Reactie naar de cliënt
Als de server het verzoek heeft verwerkt dan moet de reactie terug worden gestuurd naar de cliënt (of eigenlijk, de eerste byte terugsturen). Dit wordt ernstig beïnvloedt door zowel de netwerksnelheid van de server als de netwerksnelheid van de cliënt. Als de cliënt langzaam internet heeft van een Wi-Fi hotspot, dan wordt dat zichtbaar in de TTFB.
Is TTFB belangrijk?
Het is belangrijk om te begrijpen dat TTFB (Time to first byte) niet hetzelfde is als de snelheid van de website. Het is meer een maatstaf voor reactiviteit. Er zijn veel discussie op het internet of TTFB wel of niet belangrijk is. Een aantal zeggen dat het betekenisloos is (Cloudflare, LittleBizzy) en andere zeggen dat het juist wel belangrijk is (Ilya Grigorik, Web Performance Engineer bij Google). Beide kanten hebben goede punten waarom het wel of waarom het niet belangrijk is en vragen over hoe het nu daadwerkelijk berekend wordt.
Moz heeft zelfs een diepteonderzoek gedaan naar de correlatie tussen search rankings en time to first byte. Hoewel het lastig is om te weten of dit de oorzaak was of dat websites met lagere TTFB over het algemeen snellere websites waren, wat weer invloed kan hebben op Google’s page speed ranking factor.
Echter, in plaats tijd te besteden aan de discussie of het wel of niet belangrijk is, besteden wij liever tijd aan het focussen op het maken van optimalisaties. Alles wat je doet kan bijdragen aan de algemene snelheid van jouw website, en dat heeft dan weer invloed op jouw TTFB. Op onze test sites voelen de websites met lange TTFB veel langzamer aan.
Over het algemeen genomen: alles onder de 100ms is fantastisch en een goede TTFB. Google PageSpeed Insights raadt onder de 200ms voor server reactietijd aan. Zit je in het 300 tot 500ms gebied, dan is dat redelijk standaard. Zit je over de 600ms dan is er misschien iets incorrect geconfigureerd of wordt het tijd om over te stappen op een betere web stack. Je kunt ook onze aanbevelingen hieronder opvolgen om de TTFB te verminderen. Onthoud ook dat SSL/TLS onderhandeling ook een factor is.
Hoe meet je jouw TTFB
Er is een massa verschillende manieren waarop je jouw TTFB kunt meten. We zullen er een paar hieronder benoemen. Onthoud wel dat elke tool een net iets andere uitkomst geeft dus het is belangrijk op er 1 te kiezen en daarbij te blijven voor de nulmeting.
TTFB meten met Google Chrome DevTools
Je kunt TTFB meten in Google Chrome door gebruik te maken van de DevTools. Bedenk wel, als je test vanaf jouw computer dat TTFB wordt beïnvloedt door netwerk latency en jouw internetverbinding. Het is waarschijnlijk dus effectiever om gebruik te maken van een externe tool (besproken hieronder in dit artikel) die test vanuit een data centrum.
- Selecteer Meer hulpmiddelen > Ontwikkelaar hulpmiddelen van het Chrome menu
- Klik met de rechtermuisknop op een element in de pagina en selecteer inspecteer
- Gebruik de shortcuts op je keyboard Ctrl + Shift + I (Windows) of Cmd + Opt + I (Mac)
Je kunt het netwerkscherm openen en de prestaties van jouw website bekijken.
TTFB meten met de tool van Geekflare
Geekflare heeft een mooie verzameling gratis tools die je kan gebruiken om je site te testen en problemen op je site op te lossen. De TTFB-tool van Geekflare is simpel, snel en laat zien hoe lang het duurt voordat de eerste byte arriveert, vanuit drie verschillende locaties verspreid over de hele wereld.
TTFB meten met WebPageTest
Je kunt TTFB ook meten met WebPageTest. Volgens hun is de doeltijd de tijd die nodig is voor de DNS, socket en SSL onderhandelingen + 100ms. Voor elke 100ms langzamer dan de doeltijd wordt er een lagere letter waardering toegekend. Zoals je hieronder kunt zien, deze website is gemeten in 0.256s of 256ms TTFB.
TTFB meten met Pingdom
Chrome en WebPageTest refereren het als TTFB maar Pingdom refereert het als “Wacht” tijd. Lees ook onze uitgebreide handleiding hoe je Pingdom moet gebruiken.
TTFB meten met GTmetrix
In GTmetrix is, net als bij Pingdom, TTFB benoemd als wachttijd. Lees ook onze uitgebreide handleiding hoe je GTmetrix moet gebruiken.
TTFB meten met een hulpmiddel van KeyCDN
KeyCDN heeft een goede web prestatie test tool waarmee je jouw TTFB voor 14 verschillende locaties tegelijkertijd kan meten. Zoals je kunt zien in de test hieronder is de TTFB laag in de Verenigde Staten en overzees veel hoger. Dit wordt veroorzaakt door het feit dat de server fysiek geplaatst is in de Verenigde Staten. Dit is tevens ook bewijs dat latency en afstand invloed hebben op TTFB.
Er zijn nog veel meer tools om jouw TTFB te meten, zoals Sucuri Performance Tool en ByteCheck. Wist je dat Google Analytics een sectie heeft waarin je de gemiddelde reactietijd van jouw website kunt zien? Klik op “Gedrag > Site snelheid > Overzicht”.
4 manieren om de TTFB op jouw site te verminderen
Laten we eens kijken naar manieren om de TTFB op jouw website te verminderen.
1. Maak gebruik van een snelle host
De eerste manier om je TTFB te verlagen is er zeker van te zijn dat je gebruik maakt van een snelle hosting provider. We hebben de TTFB van een externe shared hosting provider (Phoenix, AZ) vergeleken met de TTFD van Kinsta (Council Bluffs, Iowa). We hebben gebruik gemaakt van exact dezelfde setup met het standaard thema Twenty Seventeen. Hou in gedachten dat Kinsta alle 37 Google Cloud Platform locaties beschikbaar heeft, het is dus belangrijk om jouw website strategisch dichtbij jouw bezoekers te plaatsen.
Bij Kinsta krijg je ook toegang tot het Premium Tier netwerk van Google Cloud Platform bij alle hostingpakketten. Veel andere hostingproviders gebruiken het standaardnetwerk van Google Cloud, wat resulteert in lagere snelheden.
Shared host TTFB
Voor alle regio’s was de gemiddelde TTFB 520ms. Over heel de Verenigde Staten en Canada was de gemiddelde TTFB 240ms.
Kinsta TTFB
Voor alle regio’s was de gemiddelde TTFB 412 ms. Over heel de Verenigde Staten en Canada was de gemiddelde TTFB 164 ms. Wanneer je host bij Kinsta dan heb je de mogelijkheid om jouw site in Europa of Azië te plaatsen. Bekijk de lijst met Google Cloud Data Center Locaties.
Door simpelweg een snellere hosting provider te gebruiken zagen we een vermindering van 20% van de TTFB wereldwijd. Zelfs een vermindering van 32% van de TTFB voor de Verenigde Staten en Canada.
Het hebben van een goede applicatiehost, databasehost en managed WordPress host (zoals Kinsta), met een goed doordachte architectuur, is cruciaal om je TTFB te verlagen.
Deze test hierboven laat ook zien dat het belangrijk is om weloverwogen een fysieke locatie te kiezen in de buurt van jouw klanten. Als de meeste klanten uit de Verenigde Staten komen, host dan je server niet in Europa (Al kan een CDN een deel hiervan oplossen).
2. Implementeer een CDN
Een andere makkelijke manier om jouw TTFB te verminderen is het gebruik maken van een Content Delivery Netwerk (CDN). Als jij een website hebt die bezoekers uit verschillende delen van het land, of over de hele wereld, bedient dan kan dit jouw TTFB drastisch verminderen. Wat we hierboven zagen was dat de locatie een belangrijke factor is. Wij deden een kleine test met KeyCDN als onze CDN-provider. Elke test duurde 5 minuten en we hebben het gemiddelde genomen.
TTFB zonder CDN
Eerst hebben we getest met onze CDN uitgeschakeld en zoals je kunt zien was de totale laadtijd 1.45s en ons gemiddelde TTFB op een asset was rond de 136ms.
TTFB met CDN
Daarna hebben wij de test nogmaals uitgevoerd maar dan met de CDN ingeschakeld. Zoals je kunt zien is onze totale laadtijd gezakt naar 788ms en onze gemiddelde TTFB is nu maar 37ms! Wat kan een CDN voor verschil maken. Een belangrijke notitie is dat wij Stockholm als locatie hebben gekozen om deze test uit te voeren. Waarom? We wilden laten zien wat voor verbetering het kan zijn als je de fysieke afstand verkleint. Er is een CDN POP in Stockholm, dus de content werd ook geserveerd vanuit Stockholm.
Let op: indien je gebruik maakt van Cloudflare, dan heb je misschien een iets hogere TTFB. Dit komt waarschijnlijk door de extra overhead en complexiteit van het hebben van een complete proxy-service. Onthoud dat Cloudflare extra firewalls en features heeft die andere CDN-providers mogelijk niet hebben. Je moet dus de keuze maken wat voor jou de beste keuze is. Als jouw complete website niet goed is geoptimaliseerd, dan is het hebben van een iets hogere TTFB het misschien waard.
Het is misschien goed om de handleiding van WP Bullet over Cloudflare pagina caching om TTFB te verminderen te lezen. Dit kan mogelijk wat extra setup en testen vereisen. Wees er zeker van dat je jouw eigen testen uitvoert aangezien elke omgeving anders is.
Leessuggestie: Zo stel je Cloudflare APO in voor WordPress
3. Caching gebruiken op je site
De derde optie, en waarschijnlijk de gemakkelijkste optie om je TTFB te verminderen is het gebruik maken van caching op jouw website. Velen denk dat caching alleen helpt om de laadtijden te verminderen, maar het helpt ook om de TTFB te verminderen aangezien het de server verwerkingstijd verminderd. Wij hebben wat testen uitgevoerd met en zonder caching. Elke test is 5 keer uitgevoerd en daarvan hebben wij het gemiddelde genomen.
Zonder Cache ingeschakeld
We hebben de website met Pingdom getest, zonder de cache ingeschakeld te hebben, en onze website scoorde een 1.17s laadtijd met een 560ms TTFB.
Met caching ingeschakeld
Na het inschakelen van caching hebben we weer met Pingdom getest. Deze keer scoorde de website een 643ms laadtijd en een 57ms TTFB.
Door het inschakelen van caching konden wij onze TTFB reduceren met een verbazingwekkende 90%! Je kunt meer lezen over Kinsta’s caching. Wij doen dit op server-niveau wat betekend dat er geen caching plugins nodig zijn. Als je geen gebruik maakt van een beheerde WordPress host dan raden wij de gratis Cache Enabler plugin aan.
4. Maak gebruik van een premium DNS provider
Als laatste, maar zeker niet de slechtste, speelt DNS ook een rol bij TTFB. Het is moeilijk om exact te berekenen hoeveel invloed het heeft, maar je kunt aan DNS loop-up tijden zien dat er snelle en langzame providers zijn. We hebben een aantal testen gedaan met de SolveDNS speed test tool. Hieronder staat een voorbeeld van een domein dat gebruik maakt van NameCheap’s gratis DNS en de reactietijden.
Gratis NameCheap DNS
Hieronder staat een voorbeeld waarbij gebruik gemaakt wordt van Amazon Route 53 premium DNS. Zoals je kunt zien zijn de DNS look-up tijden over het algemeen veel sneller bij Amazon. Typisch gezien hebben de premium DNS providers betere snelheden. Cloudflare is een gratis aanbieder met uitstekende prestaties.
Amazon Route 53 DNS
Lees ook onze post waarom je gebruik zou moeten maken van een premium DNS provider. Wij zijn partners met Amazon Route 53 en is gratis beschikbaar voor al onze klanten.
Samenvatting
Er zijn massa’s mogelijkheden van dingen die je kan optimaliseren of repareren om jouw TTFB te verminderen. Denk aan database caching, Disk IO, Swap gebruik, RAM, PHP-instellingen, MySQL instellingen, netwerkinstelling, TLS-overhead en meer. De methodes die hierboven zijn beschreven zijn relatief gemakkelijk om te implementeren en geven het snelste een prestatie boost. Onthoud dus voor de volgende keer als iemand je vraagt hoe ze de TTFB kunnen verminderen dat een snelle host, CDN, caching en DNS een grote rol spelen. Repareren of verbeteren van deze knelpunten zal een hoop oplossen.
Wat is jouw ervaring met TTFB? We horen er graag over in de reacties hieronder.
Brian heeft een enorme passie voor WordPress, gebruikt het al meer dan tien jaar en heeft zelfs al aantal premium plugins ontwikkeld. Brian houdt van bloggen, films en hikes. Kom in contact met Brian op Twitter.
Over het algemeen wordt een trage TTFB veroorzaakt door netwerkproblemen, webserverconfiguratie, dynamische content of bijvoorbeeld het websiteverkeer. Dynamische content en serverconfiguratie zijn de twee aspecten waar je invloed op kunt hebben. In tegenstelling tot statische pagina s moet een server een dynamisch bestand bouwen voordat hij reageert. Bij een WordPress site zijn de desbetreffende pagina s waarschijnlijk dynamisch. Dit betekent dat ze moeten communiceren met een database om te worden gebouwd met PHP voordat ze worden afgeleverd.