When it comes to the overall speed of your site, a lot of times we focus on front-end performance and optimizations to improve page load speeds.
However, sometimes it is good to look at it from the server-side, where your website originally starts loading.
Today we are going to dive into how TTFB (time to first byte) affects you and discuss some easy ways on how to reduce it. TTFB is commonly an overlooked performance factor, but it should be taken into consideration when testing the speed of your site.
What is TTFB?
TTFB stands for time to first byte. To put it simply, this is a measurement of how long the browser has to wait before receiving its first byte of data from the server. The longer it takes to get that data, the longer it takes to display your page. A common misconception is that this is calculated after DNS lookup times, however, the original calculation of TTFB in networking always includes network latency. This involves a 3 step process and delays and latency can occur anywhere in between, adding up to your total TTFB.
1. Request to Server
When someone visits your website, the first thing that happens is an HTTP request is sent from the client (browser) to the server. In this step, there are a variety of factors that can introduce delays. Slow DNS lookup times could contribute to increased time for the request. If the server is located geographically far away, this can introduce latency in the distance the data has to travel. Also, if you have complex firewall rules this could increase routing time. And don’t forget the client’s internet speed.
2. Server Processing
After the request has been sent, the server now has to process it and generate a response. This could introduce a number of different delays such as slow database calls, too many 3rd party scripts, not caching your first response, badly optimized code or theme, and inefficient server resources such as disk I/O or memory.
3. Response to Client
After the server processes the request, it then has to send it back to the client (or rather send back the first byte). This is heavily affected by both the network speed of the server and the client. If the client has slow internet from a Wi-Fi hotspot, it is going to reflect in the TTFB.
Is TTFB Important?
It is important to understand that TTFB (time to first byte) is not the same as website speed. This is really a measurement of responsiveness. There are a lot of discussions around the web on whether or not TTFB is important. Some say it is meaningless (Cloudflare, LittleBizzy), and others say it is important (Ilya Grigorik, Web Performance Engineer at Google). Both sides bring up some valid points on why or why it isn’t important and also some questions about how it is actually calculated.
Moz even did an in-depth study on the correlation between search rankings and time to first byte. However, it is hard to know if this was the cause or if the sites with lower TTFB were also simply faster in general, which in turn could be affected by Google’s page speed ranking factor.
However, rather than spending time harping over if it matters or not, we would rather focus on optimizations you can do to improve this metric. Everything you do can contribute to the overall speed of your site, and this will, in turn, affect your TTFB. In our tests sites with much greater TTFB simply load and feel slower.
Generally, anything under 100 ms is great and good TTFB. Google PageSpeed Insights recommends under 200 ms for server response time. If you are in the 300-500 ms range, this is pretty standard. And if you are over 600 ms, you might have something misconfigured on your server or it might be time to upgrade to a better web stack. Or follow our recommendations below on how to reduce your TTFB. And remember that SSL/TLS negotiation can also be a factor.
How to Measure Your TTFB
There is a multitude of different ways you can test your TTFB. We will explore a couple below. But remember, every tool will give slightly different results so it is important to simply use one and stick with it for a baseline.
Measure TTFB with Google Chrome DevTools
You can measure TTFB in Google Chrome by launching DevTools. Remember though, if you are testing from your computer that TTFB is affected by network latency and your internet connection. So it is probably more effective to use 3rd party tool (as seen further below) which is testing from a data center.
- Select More Tools > Developer Tools from the Chrome Menu.
- Right-click on a page element and select Inspect
- Use the keyboard shortcuts Ctrl+Shift+I (Windows) or Cmd+Opt+I (Mac)
You can launch the network window and see the performance of your site.
Measure TTFB with Geekflare’s Tool
Geekflare has an awesome collection of free tools you can use to test and troubleshoot things on your website. Geekflare’s TTFB tool is simple, quick, and lets you see how fast (low) your time to first byte is from three locations around the globe.
Measure TTFB with WebPageTest
You can also measure your TTFB with WebPageTest. According to their glossary, the target time is the time needed for the DNS, socket and SSL negotiations + 100ms. A single letter grade will be deducted for every 100ms beyond the target. As you can see in our test below, this site measured in at 0.256s or 256 ms TTFB.
Measure TTFB with Pingdom
Chrome and WebPageTest refer to it as TTFB. However, if you are using Pingdom it is actually referred to as “Wait” time. Make sure to also check out our in-depth guide on how to use Pingdom.
Measure TTFB with GTmetrix
In GTmetrix, just like with Pingdom, TTFB is referred to as wait time. Make sure to also check out our in-depth guide on how to use GTmetrix.
Measure TTFB with Tool from KeyCDN
KeyCDN has a great web performance test tool in which you can measure your TTFB from 14 different locations simultaneously. As you can see below in our test, the TTFB is low in the United States and much higher overseas. This is because our server is physically located in the United States. This is proof right here that latency and distance play into TTFB.
There are also some other various tools to measure TTFB, such as the Sucuri Performance Tool and ByteCheck. Did you know? Even Google Analytics has a section to see your average response time. Simply click into “Behavior > Site Speed > Overview.”
4 Ways to Reduce TTFB on Your Site
Now let’s dive into some ways on how to reduce the TTFB on your site.
1. Utilize a Fast Host
The first way to reduce TTFB is to ensure you are using a fast host. We compared a 3rd party shared host’s TTFB (located in Phoenix, AZ) and Kinsta’s TTFB (located in Council Bluffs, Iowa). We utilized the exact same setup with the default Twenty Seventeen theme running. Remember that Kinsta now has all 37 Google Cloud Platform locations available, so it is important to strategically place your site closer to your visitors.
Kinsta also includes Google Cloud Platform’s premium tier network on all hosting plans. A lot of other hosting providers use Google Cloud’s standard tier network, which results in slower speeds.
Shared Host TTFB
Across all regions, the average TTFB was 520 ms. Across the United States and Canada, the average TTFB was 240 ms.
Kinsta TTFB
Across all regions, the average TTFB was 412 ms. Across the United States and Canada, the average TTFB was 164 ms. If you host with Kinsta, you can also choose to host your site in Europe or Asia. See the list of Google Cloud Data Center Locations.
So simply by using a faster host, we saw a 20% decrease in TTFB globally. And a 32% decrease in TTFB across the United States and Canada.
Having a good application, database, and managed WordPress host (like Kinsta), with a carefully thought out architecture, is crucial to lowering your TTFB.
This also makes a good case for carefully choosing a place physically located in a region where your customers are. If most of your customers are in the United States, don’t host your server in Europe (although a CDN can help negate some of that).
2. Implement a CDN
Another easy way to decrease TTFB is to utilize a Content Delivery Network (CDN). If you have a website that is serving visitors in different parts of the country, or around the globe, this can drastically decrease your TTFB. As we saw above, location is very important. We ran a little test to show the difference with KeyCDN as our CDN provider. Each test was run 5 times and the average was taken.
TTFB Without CDN
We first ran a test with our CDN disabled and as you can see our total load time was 1.45 s and our average TTFB on an asset was around 136 ms.
TTFB With CDN
We then enabled our CDN and ran the test again. As you can see our total load times dropped down to 788 ms and our average TTFB is now 37 ms! What a difference a CDN can make. Another important thing to note is that we chose the Stockholm location to perform this test. Why? Because we wanted to show you the real improvement that can be had by decreasing the physical distance. There is a CDN POP located in Stockholm, so our content is being served from Stockholm.
Note: If you are utilizing Cloudflare, you might have a slightly higher TTFB. This is most likely due to the additional overhead and complexity of having the fully proxy service running. Remember that Cloudflare has additional firewalls and other features that some CDN providers don’t have. So you would need to make up your own mind which might benefit you more. If your entire site is not properly optimized, taking the hit on the slightly higher TTFB might be worth the trade-off.
However, you might also want to check out WP Bullet’s guide on using Cloudflare page caching to lower TTFB. This could require some additional setup and testing. Make sure to run your own tests as each environment is different.
Suggested reading: How to Set up Cloudflare APO for WordPress.
3. Use Caching on Your Site
A third way and probably one of the easiest ways to decrease your TTFB is to utilize caching on your site. Many only think that caching can help decrease your load times, but in fact, it also helps decrease TTFB as it helps reduce the server processing time. We ran some tests again with and without caching running. Each test was run 5 times and the average was taken.
Without Cache Running
We ran the site through Pingdom, and without cache running, our site scored a 1.17 s load time and a 560 ms TTFB.
With Caching Enabled
We then enabled caching and ran the site through Pingdom again. This time our site scored a 643 ms load time and a 57 ms TTFB.
So by enabling caching, we were able to reduce our TTFB by a whopping 90%! You can read more about Kinsta’s caching. We do this at a server-level which means no caching plugins are required. If you aren’t using a managed WordPress host, we recommend using a free caching plugin like the Cache Enabler.
4. Use a Premium DNS Provider
And last but not least, DNS plays a part in TTFB as well. It is hard to exactly calculate how much it is affected, but you can still see overall DNS lookup times and see that there are faster and slower providers out there. We ran a couple of tests with the SolveDNS speed test tool. Here is an example of a domain using NameCheap’s free DNS and the response times.
Free NameCheap DNS
And below is an example using Amazon Route 53’s premium DNS. As you can see in general, DNS lookup times are much faster with Amazon. Typically premium DNS providers will have better speeds. Cloudflare is a free one that also has great performance.
Amazon Route 53 DNS
Make sure to check out our post on why you should be using a premium DNS provider. We partnered with Amazon Route 53 here at Kinsta and it is available to all customers free of charge.
Summary
There is a multitude of other things you could optimize or fix to reduce TTFB, such as database caching, Disk IO, Swap usage, RAM, PHP settings, MySQL settings, network settings, TLS overhead, etc. But the ones mentioned above are fairly easy to implement and will give you the fastest performance boost. So the next time someone asks you how to reduce your TTFB, remember that a fast host, CDN, caching, and DNS all play a huge part. Fixing or improving those bottlenecks will do the trick.
What has been your experience with TTFB? We would love to hear about it below.
Brian has a huge passion for WordPress, has been using it for over a decade, and even develops a couple of premium plugins. Brian enjoys blogging, movies, and hiking. Connect with Brian on Twitter.
My absolute favorite way to reduce TTFB is by utilizing Cloudflare page caching which I outlined https://guides.wp-bullet.com/cloudflare-cache-wordpress-posts-and-pages-guide/ which is working quite well. For a worldwide audience this is tough to beat given the amount of datacenter locations Cloudflare has.
P.S. typo, should be its: ‘how long the browser has to wait before receiving it’s first byte of data from the server’
Great post! We have updated our post above with a mention. And thanks for heads up on typo :)
Thanks Brian, my pleasure. Keep the great content coming and I’ll be sure to link to these valuable articles
Thanks for sharing that post Mike.
Really solid post on TTFB, thanks for sharing Brian.
Thanks Luke!
I wanted to share another follow up here Brian for Adwords users. Google adds a query string which busts the cache of any page caching plugins. I showed how to remove it in nginx https://guides.wp-bullet.com/remove-google-adwords-gclid-query-string-for-nginx/ which should be useful for Kinsta users and in Apache https://guides.wp-bullet.com/remove-google-adwords-gclid-query-string-htaccess/
Great article Brian, but I’m still stumped about what I can do about a severely slow site I’m dealing with now. Rarely do we get it under 8 seconds, but OFTEN it jumps up to 15 seconds and sometimes up 30 seconds or more. When I run the test, it appears to always be in the first two steps to connect to first the non-secure domain name and then the https. You can see it here https://gtmetrix.com/reports/www.animalreikisource.com/SdHPE71Y Of course there are individual things that can be optimized more, but we’ve already done a ton and what’s left CONSISTENTLY is the TTFB which brought me to your site. But at this point, I don’t know what to do. I will be reading the other articles you link to but would appreciated advice if you have any. Thanks.
Hey Kathy! Just a quick look through on your site and there are probably 20+ things on your homepage which shouldn’t be loading. This is common as a lot of plugins, scripts, and themes load things everywhere. I recommend checking out these posts in which you could better optimize your homepage: https://kinsta.com/blog/disable-wordpress-plugins-loading/ + https://kinsta.com/blog/wordpress-performance-plugins/
Also, whenever I see a TTFB as high as yours… it is commonly one of two things. Your caching is not setup correctly, or your WordPress host simply can’t cut it, in which case I recommend upgrade/migrating to a better one.
On testing without and then with caching: why do you have the performance grade better (98) without caching and with longer loading time, then with caching and shorter loading time (97)?
I just noticed that if I disabled Cloudflare, I get TTFB grade of A at webpagetest.org. Now looking for a better CDN alternative. :D
Yes, you need to utilize full page caching to fix the TTFB issue as Cloudflare is a fully proxy service. This requires setting up some page rules. Or you could go with a CDN provider like KeyCDN. Your TTFB would be a lot lower without any configuration.
Brian,
Excellent consolidation of information regarding this
important subject, TTFB… As a matter of fact I’ve referenced this
article within my blog on this very same subject matter to further
inform our readers of the additional discoveries you have provided.
All The Best and Thanks!
Michael Lofton
I wasn’t aware of Premium DNS Providers!
That seems like a solution for us. Since CDN hasn’t solved it, in my case!
Solid article!
Thank for you article, very solid. I’m trying to speed up “beta . develer . com” 2sec. waiting TTFB. Any suggestion?
Hey Pietro,
A TTFB that high is almost always a caching problem on your server or WAF. Make sure you are using a caching plugin, server-level cache (like we have here at Kinsta), or if you’re using a WAF that caching is configured correctly. I’m assuming your server is fairly close to where you are speed testing from? Physical distance also makes a difference.
I have been practicing with CloudFlare for a while now, and essentially the goal was to improve my sites performance. The extra security is an extended bonus for me. About my opinion, it helps me a lot. I am fortunate that I chose to use their settings and now that they have added more free tools, it delivers it all high.
I have discovered though that there are several matters as far as analytics and SEO are concerned. For better SEO, I have not observed any difference, but for statistics, it made some positive changes from improving the bounce rate to getting more subscribers. I am not so that much able to calculate those figures are especially with the integration of Google Analytics. Something I am still looking very carefully. I will see and update you.
Though it’s been great, and I’m happy to be using CloudFlare for my writing blog. The page loading speed improvements solely are worth it, but the technique to prevent threats and the awareness that my blog will always be online are also valuable.
Wow, Excellent post. This article is really very interesting and effective. I think its must be helpful for us. Thanks for sharing your informative.
This is such an awesome guide to decrease TTFB. Hats off.
I have activated the LiteSpeed cache plugin that run on my website. Currently just purchased WP Rocket plugin, wondering can i use together with LiteSpeed cache plugin? If so, what should i take note of, so as not being interfere with each other?
Thanks!
Hey MiTGroup!
That is a good question. We recommend reaching out to the developers of the plugins to ask. In most cases, it’s not recommended or needed to run two caching plugins (unless you’re only using specific features from each and have caching disabled in one). We have automatic server-level caching here at Kinsta so no caching plugin is needed.
If you want to take this a step further, consider enabling DNS prefetching on your site. This technique lets you tell the browser to perform DNS lookups on a page in the background while the user is browsing. For more on this, check out Preload, Prefetch, Preconnect: How to Speed Up Your Site With Browser Resource Hints . There are loads of other advanced techniques you could implement on your site to improve your TTFB, such as Disk IO, TLS overhead, reducing autoloaded data, and more. But the methods we’ve covered in this article are relatively easy to implement and will give you the biggest bang for your buck.