According to Wikipedia, Time To First Byte “measures the duration from the user or client making an HTTP request to the first byte of the page being received by the client's browser. This time is made up of the socket connection time, the time taken to send the HTTP request, and the time taken to get the first byte of the page.”
In short, it is a commonly used performance measurement of how long it takes for the web server to start sending data. It's often misused as a general performance metric: for example, more aggressive gzip compression might worsen your TTFB, but improve your overall page load time. It's useful as a diagnostic indicator though, and this page will go through some common reasons your TTFB might be very high.
Some useful tools to test your TTFB are http://www.bytecheck.com and https://performance.sucuri.net. Remember, you want to try to achieve a sensible TTFB value, not necessarily the best possible TTFB value.
One common reason for high TTFB is high resource usage on your server. All CPU cores might be busy, or your server might be swapping if it's running low on RAM. Some things to check for:
top: how's your CPU usage and RAM looking? Alternatively, for RAM, you can also use free -mdf -h: are any partitions out of disk space?iotop: is there an excessive amount of disk IO happening?nload to check, and your provider will likely have bandwidth graphs too.Your TTFB may be high if your website makes very many database queries, or consists of very unoptimized application code (such as PHP). A common example of this is WordPress websites that use dozens of plugins. If possible, look into reducing the workload for your application by disabling plugins or unnecessary features.
Caching is a good idea for almost all database-driven applications: serving a cached version of a dynamic page will lead to a vastly reduced workload, and improved TTFB. This is especially beneficial if your website has many database queries that can't be avoided or reduced.
LiteSpeed offers one of the most effective caching plugins for many popular CMSes: LiteSpeed Cache.
For database-driven websites, a high TTFB can be caused by a slow database. There can be several reasons for this: most commonly, either very old versions of MySQL, or lack of configuration tuning. Occasionally, it also happens when the latency on remote database servers is too high. It's strongly recommended to use the newest version of MySQL available to you, as each release brings major performance improvements, and to consider optimizing your configuration using such tools as http://mysqltuner.pl
Sometimes, having a large number of ModSecurity rules, or very complex ones, can lead to a significant rise in TTFB. This is particularly true with the SecRequestBodyAccess On directive, and rulesets that use RBL DNS lookups for requests. When diagnosing high TTFB issues, you may want to temporarily disable ModSecurity, to rule this possibility out.
Rarely, a slow DNS server may be responsible for a high TTFB, especially in artificial benchmarks, where DNS is not cached. Several websites are available to test the speed of your site's DNS response, such as https://www.dnsperf.com/dns-speed-benchmark
This is especially common in VPSes, where some providers severely oversell, or use old setups. You may also encounter this if your server uses very old, very slow hardware, such as underpowered processors, or processors that do not support hardware AES acceleration. If this is the case, you will likely benefit from migrating to another provider.