What is TTFB (aka Server response time)?
- It is the amount of time a browser waits to receive the first piece of information from a web server after requesting it
- TTFB stands for “Time To First Byte”
- Can cause noticeable delay in web page rendering
- Represents a combination of network and server-side page speed issues
Delays can occur between the time the browser makes a request and when the browser receives a response.
These delays can add up and “time to first byte” (TTFB) is the measurement we can use to determine the severity of these collective delays.
What causes slow TTFBs (Server response times)?
In general there are four main reasons for long TTFB times…
- Network issues
- Dynamic content creation
- Web server configuration
- Amount of traffic
How to make TTFB faster?
Don’t be confused!
Making TTFB faster and reducing server response time both are one and same thing.
The first step is to optimize what you can easily control. The things you control are…
- Dynamic content creation
- Web server configuration
The things you have less control over are..
- Network issues
- Amount of traffic
The good news is that if you take care of the things you can control, the way your web server responds (and its TTFB) is improved in those situations that you don’t control.
Dynamic content creation
The most common reason for long TTFB times is the creation of dynamic content.
When a web server provides dynamic content (like a WordPress page) several things have to happen between the time it receives a request and when it provides a response.
The best way to illustrate this is to compare the difference between static files and dynamic content.
- When a browser asks for a static file, the server can just immediately respond with the file.
- When a browser asks for a dynamic file, the server must build the file before responding back to the browser.
WordPress pages are dynamic. This means they must be built by getting php files and interacting with a database.
This can means hundreds and even thousands of interactions just to build one page. This happens every time the page is called by a browser, even if the page content has not changed.
It is this process that adds to your TTFB, making it slow (sometimes the process takes a second or more).
WordPress specific slow TTFB
The main way to fix this for WordPress powered sites is to provide cached versions of your pages.
Caching static versions of your WordPress pages
The “building” part we looked at above happens everytime a page is called by the browser.
What if we didn’t wait for the browser to call it? What if we prebuild the page and have the HTML ready for the browser whenever it wants it?
Install a caching plugin
Try W3 Total Cache or WP Super Cache or just search Google for “wp caching plugins”. WordPress caching plugins can require a learning curve and have several configuration options but once you get them running right they can be very effective.
Use a WordPress host that provides caching
Use of quality WordPress hosting can solve this by just switching to them. Try to use a good one like WP Engine that provide caching automatically and protect you from future configuration mistakes and other things us curious webmasters tend to do (like installing plugins that kill your pagespeed time).
Web server configuration
The next area you have control over is your choice of webserver and how it is configured.
When I say web server, I do not mean a computer or host, I mean the software it is using (Apache, NGINX, IIS, Litespeed, etc.).
I will only cover one example of web server configuration, but it is the most common issue…
Apache .htaccess file
On Apache servers the main reason for poor TTFB is the .htaccess file.
The .htaccess file is a convenient way to make configurations to the server. It is so convenient in fact that it is often used where it should not be.
The .htaccess file is an actual web file that if present, can be used to give instructions to the server on how to act. This file is often used for creating redirects, mod rewrites, adding headers, etc.
The problem is .htaccess causes major performance issues
The official Apache documentation 1 tells you…
However, in general, use of .htaccess files should be avoided when possible. Any configuration that you would consider putting in a .htaccess file, can just as effectively be made in a <Directory> section in your main server configuration file.
Apache goes on to point out the various performance issues the use of .htaccess causes…
– “httpd will look in every directory for .htaccess files. Thus, permitting .htaccess files causes a performance hit, whether or not you actually even use them! Also, the .htaccess file is loaded every time a document is requested.
– “In the case of RewriteRule directives, in .htaccess context these regular expressions must be re-compiled with every request to the directory, whereas in main server configuration context they are compiled once and cached. Additionally, the rules themselves are more complicated, as one must work around the restrictions that come with per-directory context and mod_rewrite.”
The above two issues alone can cause major TTFB delays
Also if we consider the large role that mod rewrite can play in a typical WordPress site, we can imagine how bad things can get.
Use latest version of webserver
Whatever webserver you use, make sure it is the latest version, and that you are following the best practices.
Often just updating your software will help your TTFB.
PHP
With php, it is especially important to update to the latest version because each of the last few updates have included important performance enhancements.
The same script will run slower on an older version of php than it does on a newer version.
Now to the things we didn’t have control over…
At the beginning of this article I mentioned four things that affected TTFB.
The things you can easily control are…
- Dynamic content creation
- Web server configuration
The things you have less control over are..
- Amount of traffic
- Network issues
If you have reduced your TTFB, you actually end up having some “control” of traffic issues as well.
Traffic
If your TTFB and over all server processing was slow, this affected how much traffic your server could handle.
By improving the way your server handle dynamic content creation and server configurations, you will be able to handle more traffic better than before using the exact same hardware.
What is the average TTFB?
It is hard to give an exact number for this beacause there are many different scenarios, but generally speaking for a modern website and assuming you are testing a page from the same general geographical region as where the page is hosted…
- Less than 100 milliseconds is superb
- 200 milliseconds is ideal
- 500 milliseconds is not ideal
- 1 second is bad
- 2 seconds or more is very bad
The further away you test from the longer the TTFB will be due to latency.
As a reference, Google.com has a ~100 millisecond TTFB, The page you are reading now has a ~150 millisecond TTFB. Google has stated 2 that web servers should have a server response time of 200 milliseconds or less.