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?
- Is TTFB Important?
- How to Measure Your TTFB
- 4 Ways to Reduce TTFB on Your WordPress 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 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 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 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
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 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 35 Google Cloud Platform locations available, so it is important to strategically place your WordPress 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.
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.
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 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. 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 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
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 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.
Save time, costs and maximize site performance with:
- Instant help from WordPress hosting experts, 24/7.
- Cloudflare Enterprise integration.
- Global audience reach with 35 data centers worldwide.
- Optimization with our built-in Application Performance Monitoring.