Troubleshoot High Time to First Byte (TTFB)
When investigating slow performance on your site, you may discover that your site has a high TTFB or Time to First Byte. TTFB refers to the time it took for your browser to receive the first byte of data for your site to load. Each time a new user visits the site, their browser must first download your web page.
There are two main methods to testing TTFB; browser and speed test. Pages in the wp-admin cannot be scanned by speed test tools, so you if you wish to test these you will need to use the browser method.
Test TTFB in Chrome
- Right or ctrl click on the web page you’d like to test
- Select Inspect
- Click on the Network tab
- Hard refresh the page:
- Mac – Hold down ⌘ Cmd then press R
- PC – Hold down Ctrl then press R
- Click on the line listing the URL of the page requested
- Click Timing
- You will see TTFB and a value in milliseconds (ms) on its own line
NOTE: If you are testing a wp-admin page or testing any page while logged in as an admin, this is uncached on the server. It will have a naturally higher TTFB than pages on the front end, which can be served from server cache.
- A TTFB below 200ms is considered great.
- A TTFB in the 200ms to 500ms range is considered normal and okay.
- A TTFB consistently higher than 600ms will be a need to be investigated.
Test TTFB with Online Tools
There are also many online page speed tests available that will show the TTFB. The TTFB is typically located within the waterfall area of a speed test on its own line. Some common speed test websites are:
Always take into account the location of the page speed test, as a closer test will give faster results due to network latency. If you cannot change the location of the test, it may be wise to find a different tool which will allow you to test from a location closer to your primary user base.
Troubleshoot High TTFB
- Test the TTFB on a few different pages of your website.
- If it’s just a few pages that are slow, it’s likely an element that is being used in common across the pages. Try disabling any element that may impact all slow pages.
- Test a static HTML file instead of a dynamic WordPress page. For example, upload a file with SFTP called
test.htmlthat contains just some simple test wording.
- If TTFB is high on a static page, then there may be a load issue on the server. Contact Support for assistance.
- If TTFB is low on a static page, then some content on your site is likely causing the issue.
- Activate a different theme, preferably a default theme without modifications.
- If TTFB is lower, your theme is likely causing the issue. Check for an update or reach out to the theme developer.
- If TTFB is still high, try disabling plugins.
- Deactivate all plugins.
WordPress and Dynamic Content
The most common culprit for high TTFB is dynamic content generation. This refers to the time it takes PHP and database queries to generate your webpages. The primary contributing factors to slow dynamic content generation are large files, excess or slow database queries, and autoload data.
If your web page is loading large files, or too many files, this content can also take a long time for the browser to download on the user’s end.
WP Engine’s caching system helps offset many of the resources needed to serve dynamic pages by storing each generated page as a static file in cache. This cached version can then be served to all subsequent visitors much more quickly. Page cache is purged automatically every ten minutes. Since page caching helps offset much of the time and resources required to generate the requested page, it’s definitely best to do what you can to Improve Page Cacheability so that even more requests are served from cache. This helps ensure your site is fast and scalable. We also recommend using our Object Caching layer, which caches the results of queries sent to the database, up to 1MB. This means when your page does have to be generated uncached, the queries can be served faster from cache.
Another big factor that can contribute to TTFB are the queries to your database. Too many queries, queries that run too long, or queries that don’t complete will all directly impact the page’s ability to load efficiently.
Installing a diagnostic plugin like Query Monitor can help you find which plugins, themes, or settings are impacting load time.
A more robust tool, called New Relic, can also allow digging in at a code-level to find any queries causing trouble.
Reduce Autoloaded Data
Autoloaded data is information in your database that is told by WordPress to load on every page. This is useful for things like URL, active theme and plugins, but this becomes a problem when too much data is told to autoload. Too much autoloaded data can quickly result in adding millions of bytes of excess data to each page load.
We recommend having no more than 800,000 bytes of autoloaded data (about 0.8MB) for optimal performance.
This limit is particularly important when Object Cache is enabled, as it only has a 1MB buffer size. High autoloaded data combined with Object Caching can result in instant 502 errors.
Autoloaded data is always stored in the wp_options table. In this table there is a column called “autoload” with a value set to yes or no for each corresponding row.
Setting a row to yes will enable autoload for that value.
Setting a row to no will disable autoload for that value.
NOTE: Before making any changes to your database be sure to make a checkpoint.
Run Clean-up Queries
Calculate the total autoload data:
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes';
Find your largest autoload rows:
SELECT LENGTH(option_value),option_name FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 20;
If you find that you have a large amount of data, review our guide for further steps to help reduce autoloaded data.
Update Plugins and Themes
As simple as it may seem, plugin and theme authors often add optimizations in their updates. This means updating your plugins can optimize your sites by using new, more efficient plugin queries and PHP code.
Not only is it important to stay on top of these updates to make sure your site stays secure, but to ensure your site remains fast.
NOTE: Some Premium themes and plugins do not list their updates on the plugins page within your wp-admin. Check within the plugin itself or with the plugin author periodically.
When a page is dynamically generated, the Apache web server is handling the PHP code to do this. Apache has a configuration file labeled .htaccess that defines the web server configuration for your specific site. This file has to be loaded with every uncached request to your site, so optimizing this file will lower your site’s TTFB. Whenever possible, keep your .htaccess file as short and clean as you can.
Add all redirects to the User Portal and remove them from the .htaccess file and redirect plugins.
When redirects are placed in the User Portal, they are handled before they have to be loaded by Apache, making them far less resource-intensive up front.
Limit Other Directives
There may be some PHP directives you want to include in your .htaccess file. However, many of them (like caching directives, gzip directives, and more) are already configured higher up on the server and do not need to be set in this file.
Use Standard WordPress Rules
We advise against customizing the default .htaccess rules. The default WordPress rules should always exist.
Network Latency refers to how long it takes for a single bit of data to travel from one location to another. When you request a website, the request leaves your browser and has to make several hops to get to the server through your Internet Service Provider (ISP). If any of these “hops” are experiencing issues or are down, it could interrupt your connection to the site.
You can use a traceroute to help determine whether one of the hops from your local connection is experiencing latency.
- Network Latency is largely not something that cannot be controlled.
- CDN can help by distributing your assets to global servers and reducing the distance larger assets travel.
- In some cases we can also look into migrating your site to a server that is closer to your primary user base. Contact Support for assistance migrating your website to a new region.
The amount of traffic your site receives is largely outside of your control. You do, however, have control over how that traffic interacts with the server resources. This is referred to as the scalability of your site, and centers around overall cacheability.
Having a high cacheability means a larger number of requests are being served from cache, and the more requests your site can serve at once. High cacheability sites are also highly scalable as more traffic is added.
Having a low cacheability site means the site is returning a larger amount of uncached requests. Excess uncached requests will increase CPU load, slow response times and ultimately increase TTFB. Low cacheability sites are also poorly scalable as more traffic is added and will experience performance issues.
NOTE: If you’re anticipating a spike in traffic, ensure your site is able to scale.
NEXT STEP: Bracing for a traffic surge