It is a proven fact that the speed of the site is an important metric. TTFB or Time to First Byte is one part of the overall speed metric.
Having a fast-loading site is crucial, so it is wise to look for all the ways to improve the speed.
One of the ways of improving speed is to improve the TTFB.
In this article, I will tell you all about the Time to First Byte, covering all the aspects of the topic.
- What is TTFB?
- Factors of TTFB
- How to Measure TTFB?
- Does TTFB Matter?
- Ways to Reduce TTFB
- How does better hosting help in reducing TTFB?
What is TTFB?
TTFB is an abbreviation for ‘time to first byte.’ This is a measurement of time a browser (user) has to wait to receive the first byte of data from the server-side. The longer the server takes to process the request and responds accordingly, the longer will be TTFB.
You click a link, and the web pages open up. But it takes time to display the content. That waiting time includes running of various scripts and execution of commands.
TTFB is the time a browser has to wait to receive the first amount of data.
TTFB under 100ms is quite good, however Google suggest keeping it under 200ms.
To understand it clearly, you have to know how the Internet works.
Or, more precisely, how the data transfer from the storage (server) to your browser.
How does Data transfer?
The process happens in three steps:
- The time it takes in sending the request to open up a page
- Time in the processing of the request by the webserver
- The time it takes in responding with the first byte of data
#1 Sending the Request
When you put a URL in the browser, the browser sends the HTTP request to the server.
It contains instructions to fetch the data the URL is pointing to.
The browser cannot send data directly to the server, so it used proxies (browser, medium, lan, WiFi) to create a connection.
As you can see, the HTTP request has information regarding the content user wants.
The time between the sending of the request by the browser and request received by the server depends on various factors:
After receiving the request, the server processes the request.
#2 Processing of the Request
The server has to read the message to generate a correct response for the request. It finds the files the browser has requested and prepares it to send it to the browser.
The time takes in this process is determined by:
The server begins sending the data/webpages to the browser.
#3 Responding with the Data
The server responds with the requested data, and the browser displays it as a webpage.
The time taken by the first byte of the data from the server to the client is TTFB. Similarly, the time taken by the last byte of the data from the server to the client is TTLB.
This duration of time depends on:
Explaining all the Factors
#1 DNS Lookup:
When a visitor visits a site, he uses the domain name. Or URL.
But the domain name is only a collection of alphabets that points to a specific IP address. The web browser needs to know the IP address.
The DNS provider provides the IP address, and also configures it to point to the domain name. It translates human-readable information (the domain name, website, and any other internet resources) into the addressing protocols (IP addresses) used by computers to navigate and locate information online.
Most of the domain name sellers offer free DNS, and they work great.
But there are DNS providers that can improve the DNS lookup to a great extent.
The DNS lookup time is a part of the TTFB time.
So, if the DNS is of poor quality, it will inevitably affect the duration of sending the request.
Premium DNS offers better speed, security, reports, authentication, performance, redundancy, queries, customer service than the free DNS providers.
#2 User’s Internet Speed
The internet speed of the user is a significant factor while sending the request.
The request sent by the browser operating at 5G would be faster than the browser operating at 2G.
Not only the speed of the browser, but the speed of proxies also plays a role.
#3 Geographical Distance
The physical distance between the server and the browser does have an impact on the overall TTFB.
Undoubtedly, the speed of the delivery of digital content via the Internet is super fast, but still, when you look into the core, the bytes or data is traveling some sort of distance.
Example: There are two cases:
Case A: The user is in London, and the server is in Beijing
Case B: The user is in London, and the server is in London
When you run the experiment, while controlling all other factors, you will find that data takes less time in traveling the shorter distance with comparison to the longer distance.
You can use CDNs to reduce this time, but more about it later.
#4 Database Calls
The request asks for the particular content that the server has to find in the storage. For that, he has to make database calls to fetch the content. The faster database management tool performs the function at a better speed.
Most of the hosting providers already have DBMS installed on their web servers. The most popular DBMS are MariaDB, MongoDB, and MySQL.
#5 Running Scripts
From Google:
Third-party JavaScript often refers to scripts that can be embedded into any site directly from a third-party vendor. These scripts can include ads, analytics, widgets, and other scripts that make the web more dynamic and interactive.
Third-party scripts could be:
- Ads
- Social Sharing Buttons
- A/B testing tools
- Embed content
Due to the third-party scripts, the server has to collect the data from the external application by making the API calls.
Which, as a result, affects the TTFB.
#6 Ineffective Server Resources
The problem could be from the server-side too.
The stack could be outdated, or the hardware could be old. The majority of the servers are running on the HDD server, while many hosting companies are offering SSD servers.
Getting hosting that offers a better stack would surely improve the TTFB.
#7 Not Caching the First Response
The HTTP connection is always new.
Both the server and the client-side erase the connection history after sending the message. For every new transfer, the connection has to be made from the beginning. This is how HTTP connects.
Many webmasters use caching to serve the already saved pages from the browser cache or the server cache. But when there is no caching assigned, the process has to be done from one end to another end.
So the response begins after the complete process instead of from the cache memory.
#8 The Network Speed of the Server
The speed of the WebServer network also determines how quickly it will send the response. The hosting server is like the powerhouse of the entire site.
It does not matter if you optimize your site correctly; if the speed of the hosting server is not right, TTFB will be slow.
You can check the webserver speed from here.
#9 The Network Speed of the User
I already talked about the Internet speed of the user.
How fast the user’s browser parses the data it receives from the web server depends on the Internet.
That’s why massive games or pages open better on WiFi than on the mobile network.
How to Measure TTFB?
There are several tools that you can use to measure the TTFB.
Here, I am mentioning the few tools that you can use to measure the time of the first byte of your site.
But don’t worry if they all show different results. Or any single one shows mixed results when you use it multiple times.
Minor discrepancies happen.
#1 Measure TTFB with WebPageTest
WebPage Test is a resourceful site that gives you a lot of tools for site testing. You can check the speed from mobile, desktop, and various browsers from multiple locations.
It then displays a lot of information regarding site speed.
The WebPage also has a pool of resources that can help you to optimize your site for the best performance.
#2 Measure TTFB with Geekflare’s Tool
Geekflare is an excellent site that provides many tools for free. You can use these tools to discover various information about your website.
One of the tools is the TTFB test. Check here.
Just enter your site, and test TTFB. It will display the result after performing the test.
#3 Measure TTFB with Pingdom
Pingdom calls it waiting time instead of TTFB. But it has the same meaning.
Pingdom tools offer a lot of information and break the content into various files. It shows the time taken to fetch each of the components of the page individually. You can check which script or the element of the page is taking time to load.
#4 Measure TTFB with GTmetrix
Similar to Pingdom, GTMetrix calls it waiting time, not Ttfb.
Put the URL in the box and let the GMetrix do its work. You will get a detailed report about your site showing you how the data of your website is reaching to the visitor.
#5 Measure TTFB with Google Chrome DevTools
You can also use Chrome Dev Tools to measure TTFB. But it has a drawback. If you are testing TTFB using this tool from your computer, the results can be affected by network latency and your internet connection. So try to use a third-party tool that tests from a data center.
Steps to check the TTFB using Chrome Dev Tools are:-
- Go to Chrome Menu
- Select More Tools > Developer Tools
- Right-click on a page element
- Choose Inspect
- You can also use the keyboard shortcuts Ctrl+Shift+I (Windows) or Cmd+Opt+I (Mac)
- Open the network window
- Check your website’s performance
#6 Measure TTFB with Tool from KeyCDN
KeyCDN offers complete web pages test from multiple locations. The list displays the TTFB exclusively and also gives other information.
The acceptable TTFB (less than 300ms) turns green.
#7 Measure TTFB with DotCom tools
Another site where you can check the TTFB of your website is dotcom-tools.
They call it FIrstByteTime. You have to check the waterfall model to find the TTFB.
You know the TTFB of your site. Pagespeed Insights recommends having TTFB under 200ms, but Google does not call it TTFB. They use the ‘server response time.’
TTFB: Does it Matter or Not?
There is a long debate over whether TTFB matters or not.
Is it just a trending term popularised by the SEOs to look smart, or is there a positive relationship between the TTFB and the site performance.
Cloudflare has a detailed article about why they don’t cater to the TTFB, and why you should not worry about it at all.
The Cloudflare ran an experiment.
In the experiment, they sent instructions to the server to send the letter ‘H’ as a first response and then wait for ten seconds before sending anything else. They got the reply ‘H.’ Later the browser received the rest of the content after ten seconds.
This means that TTFB does not look for the first byte of the content, but it is the first byte of the response.
Gomez has replicated the experiment, and the results are matching.
On the other hand, Moz has also done relevant research.
Moz has tested 100,000 URLs and found out that the pages that are ranking well on Google have lower TTFB than the others.
Correlation does not mean Causation. However, Moz defends their side by saying that the correlations across 100k of results do give something to think about. It is indeed a good observation, but one cannot forget that the site ranking well has better SEO optimization.
The post by Littlebizzy offers an excellent insight into the topic.
Though TTFB might have something on the speed of the site, it is meaningless for the end-user.
When we see the complete process of data transfer (request-process-response), we find that the Internet connection of the user, the device, and the location do play a role in TTFB. This means that TTFB is different for every user and every reload.
It is a metric that depends on the environment, and every user has a unique setting.
The debate around the TTFB is intense, and it matters, or it does not matter for the user is not clear. Google used the term Server Response Time in its documentation, not TTFB.
At the end of the day, if your server is responding late, it will affect the speed of the site.
So, if there is a way to improve it, you should do it. But you do not need to worry about it.
How to Reduce the TTFB for the site?
TTFB is the sum time of three processes, as I mentioned above. These processes depend on various factors.
I have mentioned the most common factor.
Some of the factors could be changed from the front end, while some require the server end solutions.
We will see both of them:
#1 What a Site Owner can do:
Geographical Distance:
The physical distance between the server and the user does affect the TTFB. This is called the latency rate. So to reduce the latency rate, you have to bring the server near to the visitor.
You can do that with CDN.
CDN means Content Delivery Network. A content delivery network (CDN) is a system of distributed servers (network) that deliver content to the visitor, based on the geographic locations of the user, the origin of the webpage and the content delivery server.
Best CDN available:
- StackPath
- Sucuri
- Cloudflare
- KeyCDN
- CacheFly
Not caching the response:
If you are not configuring the caching properly, you are adding extra load on your site. The same content has to travel the same distance whenever there is a call.
You should enable the browser caching so the browser could fetch the file from memory itself instead of raising a request to the server. Leveraging the browser cache optimizes the speed of the whole site.
You can enable caching on WordPress with these plugins.
- WP Rocket
- W3 Total Cache
- WP Super Cache
- Sucuri Firewall
- WP Fastest Cache
- Comet Cache
Running Scripts
If there is no need, do not install the third-party script on your site.
The server has to send different requests to all the third parties to fetch the information so it can send the response to the request.
Keep the essential scripts on your site.
DNS Lookup Time
The Free DNS provider takes more time to resolve the query than the premium DNS provider. Buy a DNS hosting to improve the DNS lookup time, which in result will reduce the TTFB for your site.
Best DNS provider:
- Cloudflare
- Rackspace
- FreeDNS
- CloudDNS
- GeoScaling
- Namecheap
These are the few things you can do from your side to reduce the server response time.
#2 Server Side Solution
Your hosting is as responsible for the TTFB as you are. If you are doing everything correctly, then maybe the problem could be from the server hosting side.
Ineffective Resources
It is vital for the fast loading of your site that your hosting has an effective stack of tech to support your website.
Also, they should be appropriately configured.
Database Calls:
The server needs to make database calls to fetch the information from the storage. There are various DBMS that do this job.
Most of the DBMS do a pretty good job, but if the DBMS is not updated for a long time, it started working slowly. A regularly updated and maintained DBMS enhances the speed of database calls.
Network Speed of the Server:
The server could be running on a slow network connection. The server needs to be live with a high bandwidth Internet connection so that it can receive, process, and respond to the high number of requests being made at the same time.
Storage:
The capacity to read and write the data on the server depends on the Hard drives. SSD drives are the latest technology and store data more efficiently with more speed than the HDD.
Get a Better Hosting
The hosting has a direct impact on the Time to First Byte of your site.
How Web Hosting provider Reduce TTFB:
- Using the latest software and hardware to improve the efficiency of the process
- Regular maintenance of the programs so they work effectively consistently
- Resolve DNS queries with more speed
- Use Art of the State CDNs and Caching Tools
You could see the changes in the TTFB immediately after moving on to our WordPress hosting.
Conclusion
TTFB depends on many other things like PHP setting, MySQL setting, RAM, Cache profiling, TLS, User’s network connection, Browsers, location….
That does not mean you can do nothing, or you should do nothing.
The best solution is to have better hosting. With better hosting comes the better configuration of servers, and better optimization of resources.
Which, as a result, improves the Time to First Byte.
