Understanding Site Speed: The Time to First Byte (TTFB)
When troubleshooting a slow website, there are a few helpful metrics to determine the causes and solutions. One of those metrics is the Time To First Byte (TTFB), a measurement used by all site performance benchmarking tools. It’s an important metric to measure how fast your website starts loading in a specific location or with a particular combination of settings. Understanding TTFB can help you get a better grasp of how website speed works, what’s slowing down your site, and how to fix it.
What is Time To First Byte (TTFB)?
TTFB measures the time elapsed between the moment a web user makes an HTTP request, like loading a webpage, to the time the first byte is received by the client’s browser. Many use this reading as a rudimentary way to test server speed and while this works, it’s only half the story. If the website you’re trying to load uses a Content Management System (CMS) like WordPress, the server must do all the CMS computations required to produce content. The PHP service must load your MySQL database, get the content, calculate the appropriate HTML output, and return it to the website visitor.
If you have a slow CMS, all those steps can take time and you may receive bad TTFB results like 1-3 seconds or more. That doesn’t necessarily mean your hosting server is slow or experiencing issues. More often than not, it means you have too many plugins or extensions, you’re not using a caching system, or you’re using an old PHP version. Of course, it is a totally different story if you are measuring a static HTML page with a slow TTFB. Then, you may want to start your investigation from the server itself, as there are no other factors impacting the performance of your site.
How Does Dynamic Caching Affect TTFB?
Dynamic Caching is like having your local barista remember your order instead of having to repeat it every time. Because they already know your drink, they can start making it as soon as you walk in, serving it to you that much faster. Caching works in a similar way by storing the data required to serve a webpage for next time.
Our Dynamic Caching uses NGINX as a reverse proxy. This means that all the computing from your PHP and MySQL services are stored in the server’s RAM. When a visitor gets a cached response from us, it’s like they’re loading a static HTML page — only faster! It’s faster because the content is served from the memory and not from the server’s hard drive. Although SSDs are super fast, nothing compares to the server RAM when it comes to speed.
If you have the Dynamic Caching on and still have slow TTFB, there are two things to check:
- Are you measuring a cached result? The easiest way to check is to perform your test more than once. It is normal to get a slower first result and much faster consecutive ones. By performing multiple tests you can guarantee you’re measuring cached results.
- Are you measuring from a close geographical location? If you’re testing from a remote location, it is normal that you have high networking latency. If you want your site to be fast from a variety of locations, consider implementing a CDN.
Can All Pages be Cached?
Not all pages can be fully cached. Checkout pages, carts, and logged in users have special circumstances. That doesn’t mean the TTFB has to be slow. The first step is making sure you’re using PHP 7.1 or above. We have opcache enabled by default for it and WordPress and other CMS apps work dramatically faster. Next, you can use our Memcached service to improve the time your app takes to get data from the MySQL server. Last but not least, check the plugins you’re using. How many are you using, are they high-quality, and what load do they cause to your page rendering process?
Caching tends to camouflage poorly built websites by masking development problems. If your site loads quickly without cache, this means it has good code and is “healthy”. You shouldn’t rely solely on our Dynamic Caching or your own caching plugins to have a fast website.
How Does a Content Delivery Network (CDN) Affect the TTFB?
As mentioned above, TTFB is seriously affected by the networking speed between the server and your browser (or the tool you’re using to test your speed). Using a CDN can improve your site speed if it has endpoints near your geographic location. Note, however, that if you have a CDN like CloudFlare enabled, you’re measuring the TTFB between your browser and the particular CDN endpoint serving your request and not between you and the SiteGround server. If the CDN hasn’t cached your content yet, it has to call the SiteGround server first, get the data, distribute it and then serve it to you. That may cause further delay before the first byte is received.
To get around this, make sure you have caching enabled for your CDN and check whether it has an endpoint close to your geographic target. It’s worth experimenting with different CDN providers in case your visitors are in a part of the world that’s not covered by your current one.
Comments ( 17 )
Thanks! Your comment will be held for moderation and will be shortly published, if it is related to this blog article. Comments for support inquiries or issues will not be published, if you have such please report it through
Frank curious
Good article. Can you say something about using GZip compression on wordpress. I read about it but I am not sure if I should install some of the code I find on the internet. It is supposed to be written in the htaccess file. It should save a lot of traffic between servers. Google recommends it.
Hristo Pandjarov Siteground Team
Here's an article on how to enable it for most content extensions: https://www.siteground.com/kb/how_to_enable_gzip_compression_for_your_pages/
Sunny
Are there any tools to measure plugin performance on the server? P3 is no longer maintained and offers inaccurate results so that's out.
Hristo Pandjarov Siteground Team
P3 was nevr a good plugin to be honest. It's better to test from a remote location using something like Pingdom: https://tools.pingdom.com
Sladjan
You can use Query Monitor, it will give you an insight into what plugin is generating which queries. It has many more functions, you should check it.
Verbunt
Hi there, does the Dynamic Caching option from the SG super cacher work for Magento as well? I can remember SG once told me it wasn't.
Hristo Pandjarov Siteground Team
We don't support Magento for the Dynamic Caching option because there are too many ways to configure your site and it's very difficult to come up with an easy solution to handle cache purging.
Issac Ng
I always get a spike of high CPU and RAM usage (till maximum) for around 1-3 minutes. Is it because of the of Dynamic Caching?
Hristo Pandjarov Siteground Team
Most probably because the Dynamic Caching was cleared at that time :)
KRIS
Good article so far! Does WP Rocket also benefit dynamic caching same as in-house supercacher?
Hristo Pandjarov Siteground Team
It's a different approach towards caching and optimization but it should benefit TTFB in a similar way to a certain degree.
Donnie
Minify JavaScript Files appears in SG Optimizer, and there is Auto Minify (Web Optimization) in Cloudflare settings. They appear do be doing similar things. What are the differences? What happens if they are both turned on?
Hristo Pandjarov Siteground Team
One of them will do nothing. It's not a problem but generally if you have it enabled in CloudFlare - keep it off in the plugin.
Angelo
Hello Hristo and thank you for the article. We have almost all funtions activated with SG Optimizer plugin with PHP 7.1 and GrowGeek account, including about cache. Recently we also activated Cloudfare free account trough Siteground, and their caching tool seems already enabled. Here's what they explain, but is not clear if with Siteground should be the same, please is your recommendation the same as they do (standard caching)? *** You can set Cloudflare’s CDN to cache static content according to these levels: - No Query String: Only delivers files from cache when there is no query string. - Ignore Query String: Delivers the same resource to everyone independent of the query string. - Standard: Delivers a different resource each time the query string changes. We recommend using the Standard level. *** Thank you!
harris
my server response time is very hight, its almost 1.9s which is massive, i want to reduce that, i have cloudflare pro account, please suggest me what i do ???? as i am also using SG Optimizer with enabled Static, dynamic caching.
Hristo Pandjarov Siteground Team
If you're getting 1.9s it means that most probably your site is not properly cached and the SG Optimizer is not working due to some other plugin on your site. Please, contact our Help Desk in order to get further assistance on this matter.
James
Very good sir! Thank you.
Start discussion
Thanks! Your comment will be held for moderation and will be shortly published, if it is related to this blog article. Comments for support inquiries or issues will not be published, if you have such please report it through