Quantifiable metrics can be useful when troubleshooting and evaluating a product.
Despite ‘Time to First Byte’ having a half technical-sounding name, is not one of them and when viewed in isolation without context does not provide a reliable indicator of site performance, or server performance.
An example of using flawed metrics to solve a problem is an employee giving a Performance Bonus’s based on the time it takes them to get to work each day. While this might sound acceptable at first glance, the Metric of travel time does not take into account how far away each employee lives or what mode of transport they use, and is not a measure of ‘staff performance’ which it was intended for.
This is much the same as:
‘Time To First Byte’ (TTFB) is the delay between when the browser first makes the connection to the server, how soon the web browser starts receiving the data, measured in milliseconds or seconds. (lower being better)
Reasons why TTFB is not an accurate measure of site performance
Latency and distance is key
As TTFB is the measure of responsiveness between the web browser and web-server, if the test is being carried out on the other side of the world on a poor internet connection the results will not reflect real-life performance from your customers.
A site closer to your target audience will almost always load faster than one further away, this is physics.
This is evident within KeyCDN’s performance testing tool which show TTFB times as low as 89.84ms for Sydney Australia where the site is hosted, and 636.79ms in New York some 16,000km away.
Different testing tools will show different results, even between tests due to network conditions and testing methodologies.
KeyCDN Performance Tester: https://tools.keycdn.com/performance
Bytecheck: https://www.bytecheck.com/
HTTPS and SSL/TLS connections will significantly increase TTFB
Nonencrypted HTTP connections require a ‘TCP Handshake’ (blue) to be established with the server before data can be exchanged.
HTTPS connections not only require a ‘TCP Handshake’, but a second ‘TLS Handshake’ to negotiate the secure connection. This can significantly increase the TTFB scores, in some cases double it, particularly if the site needs to redirect from HTTP to HTTPS.
In practice, this connection time is often insignificant after the first connection to the server as the web-server will use ‘persistent connections’ (Keep-Alive) to reduce the need to perform this handshake for each connection or request to the server.
If chasing the lowest TTFB was your goal, you’d never use HTTPS on your site which is the opposite of how you should be building a website!
Redirects
If you type ‘cpanel-help.com’ into your browser, your browser will typically rewrite it and connect to the server with ‘http://cpanel-help.com’.
Once connected, the web-server will perform a 301 redirect to ‘https://cpanel-help.com’.
This is made worse if additional redirects are required, such as to ‘https://www.cpanel-help.com’.
While redirects are bad and where possible avoided, your browser will cache this new address and subsequent requests will go straight to the actual URL.
TTFB can be Manipulated and does not relate to how fast the page loads
As we know, TTFB is just the measure of the web browser getting something, anything!
Cloudflare proved this point with their TTFB Test Server which send’s the first ‘H’ in ‘HTTP/1.1 200 OK’ of the HTTP response, then waits 10 seconds before sending the rest of the page.
On Paper and in synthetic test which only focus on ‘TTFB’ this would be legendary tech and you’d assume the website would load fast. For actual visitors this site would be unusable.
In many cases a higher TTFB can result in a faster loading site.
Gzip compression will often lead to a higher TTFB due to additional processing, but as the data exchanged is less, the page may load faster.
Contrary to popular belief, TTFB is not a metric that is heavily scored on by search engines.
This is confirmed by John Mueller (Webmaster Trends Analyst at Google) on Twitter who advised against blindly focusing on it and it is not used for search ranking.
TTFB is related to the type of page being displayed and the code behind it
For dynamic PHP sites such as WordPress, the page must first be generated in full before it can be served to the web browser. Factors such as poor coding and an excessive number of plugins increase the time it takes for the server to execute the code.
An example of this is below, where a page with a 5-second sleep to simulate bad code or a long database query is tested.
Subsequently you can see it has a TTFB of 5.271s which is very bad.
To help determine if your server is just slow, or if a larger coding issue exists you can perform the same test against a static element of the site, such as a sitemap or html readme file.
In this case the page had a 0.118s TTFB
Conclusion
Measuring the performance of a site is tough, especially if you are fixated on one metric that is only showing only one part of a larger picture.
To properly diagnose poor site performance or validate the site is working correctly you should consider following the below steps
- Load and use the site on your own computer, is it slow, are you getting timeout issues?
- If possible, get feedback from your target audiance
- Verify your site is correctly being served from cache, this is often embedded in the source code.
4. Review server load in cPanel or your VPS, are you hitting CPU/IO/Memory limits or getting faults
5. Run benchmarks using local tools such as Google Chrome Developer to get data based on your own internet connection.
6. Do different types of pages or parts of the site load faster than others, if so why?
7. What suggestions and feedback do tools such as GTmetrix and Google PageSpeed Insights provide
8. What are my goals and expectations
How to you measure your site performance, leave your thoughts and feedback below