How to Reduce TTFB to Improve WordPress Page Load Times
Updated on January 22, 2018
When it comes to the overall speed of your WordPress 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 WordPress them, 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.
Does TTFB matter? It contributes to your overall speed, so what do you think? 😉
Click to Tweet
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 WordPress 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 mis-configured 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 are 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.
Google Chrome devtools TTFB
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 seen in our test below, this site measured in at 0.256s or 256 ms TTFB.
Webpagetest First Byte Time
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.
Wait time in Pingdom tools
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 in 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.
KeyCDN TTFB test
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.”
Google Analytics report for TTFB
4 Ways to Reduce TTFB on Your WordPress Site
Now let’s dive into some ways on how to reduce the TTFB on your WordPress site.
1. Utilize a Fast WordPress Host
The first way to reduce TTFB is to ensure you are using a fast WordPress 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 13 Google Cloud Platform locations available, so it is important to strategically place your WordPress site closer to your visitors.
Shared Host TTFB
Across all region, the average TTFB was 520 ms. Across the United States and Canada the average TTFB was 240 ms.
Shared hosting 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 WordPress site in Europe or Asia. See the list of Google Cloud Data Center Locations.
Managed WordPress hosting TTFB
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 WordPress host 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 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 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 before adding a CDN
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.
TTFB after adding a CDN
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.
3. WordPress Caching
A third way, and probably one of the easiest ways to decrease your TTFB is to utilize caching on your WordPress 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 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.
TTFB with WordPress caching enabled
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 the free Cache Enabler plugin.
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 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
Free DNS speed
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
Amazon premium DNS speed
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.
There are 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 WordPress 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 is the Chief Marketing Officer at Kinsta. He focuses on everything from developing new online growth strategies, content creation, technical SEO, and outreach within the community. He has a huge passion for WordPress, has been using it for 8+ years, and even develops a couple premium plugins. Brian enjoys blogging, movies, and hiking. Connect with Brian on Twitter.
Kinsta is a premium hosting platform optimized specifically for WordPress, created by WordPress professionals.
A cookie is a piece of information that a website stores on a visitor’s computer. We use this for some functionality on our website to work properly, and also to collect analytics to better understand our visitors and offer them a better experience. You can accept all cookies at once or fine-tune your preferences in the cookie settings.
Thanks, we've saved your settings, you can modify them any time on the cookie settings page
These cookies are needed for our website to function providing payment gateway security and ther essentials. Therefore they are always on but they do not contain personally identifiable information (PII).
If you've set preferences (which cookies you accept and which you don't) we store your preferences here to make sure we don't load anything that you didn't agree to.
WordPress sets a couple of cookies that track logged in users and store user preferences set in their WordPress user profile. These are set for members of the Kinsta website only - members of our staff.
Stripe is our payment provider and they may set some cookies to help them with fraud prevention and other issues. This is required for our payments to work.
This cookie contains information about the affiliate who refered a visitor. The cookie contains no information about the visitor whatsoever.
Analytics help us deliver better content to our audience. We have made sure no personally identifiable information (PII) is sent by anonymizing IPs.
Analytics cookies allow us to gather data to help us better understand our visitors and offer them a better experience.
Set and used by Hotjar. We use Hotjar to analyze user behavior without identifying the user.
Marketing cookies help us target our ads better. We mainly use them to target ads to users who have visited Kinsta.
Set and used by Twitter, used for targeting advertisements and promoting content to users who have visited kinsta.com.
Set and used by AdRoll for remarketing and targeting advertisements to users who have visited kinsta.com.
Set and used by Facebook, used for targeting advertisements and promoting content to users who have visited kinsta.com.
Set and used by Quora, used for targeting advertisements to users who have visited kinsta.com.