As a site owner, a tech SEO or a developer, you’re probably all too familiar with the struggle to achieve optimal site performance in a digital world where every millisecond counts. One critical metric that often gets overlooked, but can have a huge impact on user experience and page speed, is the Time to First Byte (TTFB).
Understanding and optimizing this crucial element can be very useful in your quest for better performance and greater user satisfaction.
As such, through this article, we want to examine TTFB in greater detail, explain its significance, and provide practical tips to help you reduce your website’s TTFB score.
Let’s dive in!
What is Time to First Byte?
Time to First Byte is a performance metric that measures the time elapsed between an HTTP request sent from a client to a server and the first byte of the requested page’s data returned to the client browser as a response. Essentially, it indicates the responsiveness of a web server and serves as an indicator of the initial loading speed of a website.
The calculation process consists primarily of the socket connection time, the time taken to send the HTTP request, and the time taken to receive the first byte of the page.
If the time taken for the first byte to be returned in response to a client request is above what we consider to be optimal, the page load time will automatically increase.
Basically, if the server hosting the documents for a website struggles to respond quickly to incoming requests, it will have a negative impact on performance, user experience and crawlability.
What is the ideal TTFB result?
To answer that question, we can look directly to Google which recommends values of 200 ms or less for the TTFB metric.
It is difficult to determine a clear average for global websites, depending on the target country and server structure. However, according to the leading study in the field that highlights the relationship between TTFB and the higher ranked sites in the SERPs, we can safely conclude that for many of them, the metric is below 500 ms, generally landing somewhere around 350 ms.
In TTFB tests, results varied depending on a number of variables such as the server performance of different hosting providers, the time of the test, and the distance between the server and the client sending the request.
In tests performed on Google’s Lighthouse and PageSpeed test tools, TTFB scores of 600 ms or higher are marked as unsuccessful by Google.
Why is TTFB important for SEO?
Cutting straight to the chase, the main reason TTFB is so important for the online world, and more specifically our SEO efforts, is that it directly and concretely affects page load times and user experience.
Among the many metrics Google uses to determine its search results (the ones we definitely know about and the ones we can only guess) the importance of page load times as well as user experience has increased.
The trend has only grown since 2014 when Google announced that it would evaluate page speed as a ranking metric for the first time and subsequently when it announced the Mobile-First Indexing algorithm update.
Although there are many factors that can impact page load times, TTFB is critical for measuring the adequacy of server configurations and the general ability of the server to handle incoming traffic.
Despite the significant improvements in the client-side and website configurations (coding, visual optimization, etc.) that affect page load times, poorly implemented server configurations and the server’s response capacity have a very direct impact on page load times.
As we move towards mobile-focused search engines, it has become increasingly important to optimize websites for mobile devices that have weaker device limits – as compared to computers – in terms of RAM, processor configurations, and connection speed.
While it is difficult, for us as SEOs, to optimize for mobile devices on the client side, there are things we can do on the server side to optimize response capacity. We will examine that in more detail below.
TTFB and crawl budget
In addition to the effects TTFB can have on page load times and UX, a high TTFB score will also affect your site’s crawl frequency. When Google bots send a crawl request to any site, they also regulate the crawl frequency by taking into account the server’s response times to prevent the server from crashing due to overload.
For example, for a server with a TTFB score of 200 ms, the number of crawl requests that Google bot will send to the server will be different from that of a server clocking in at 650 ms, 1000 ms, or even 2000 ms metrics. Such scores clearly indicate that we are operating with much slower servers and Google will adjust accordingly.
A website with a server that has optimized its TTFB and responds to requests in an optimal way will see an increase in crawl requests and crawl frequency. Consequently, such a site will also have to deal less with issues such as delayed indexing or delayed crawls.
However, it’s important to keep in mind that getting your content indexed and ranked is closely related to other metrics such as the technical quality and content quality of your site.
TTFB is not a decisive factor in whether a content is indexed after crawling, but a good score can’t hurt as the number of crawl requests to your site will increase in proportion to your TTFB score
“Server response is not the only metric that affects crawlability and crawl budget. The content quality, technical structure, and overall site health can also significantly affect crawlability.” – Oskay Günaçar
What causes TTFB scores?
Measuring your TTFB, as we mentioned earlier, consists of three basic stages:
- Socket connection time: the time it takes for the request to pass through the network and reach the web server.
- Processing the received request and preparing the response.
- The time it takes for the response (network resources) generated in response to the request to reach the client.
All of the above mentioned conditions should ideally be optimal for a good TTFB score. For those websites with a poor TTFB score, the problem could be a result of any or all of the three stages on the server and user side.
Socket connection time (sending the request to the server)
The measurement of the TTFB metric begins with the HTTP request sent from the client to the server. The time it takes for the HTTP request sent from the client to reach the server after the socket connection can vary depending on DNS lookup time, the user’s network speed, the user distance to the server, and any interruptions in the connection. Website owners cannot directly intervene in these connection times where the request sent by the client is sent to the server.
Processing the received request and preparing the response
The server receives the HTTP request from the client after the socket connection and starts processing it. In this process, relevant information, or data, for the request is called in the database.
Files in the request are then processed and edited by communicating with scripts and network resources on the server side. After this process, a response specific to the request from the client is generated and sent. This is the process where website management can intervene and make optimizations.
Some of the strategies and applications applied on the server side to optimize the processing of the request include using a high-quality server, using cache, optimizing the database and optimizing the resources called on the network.
Sending the prepared response from the server
When the server creates a response for the client side request in the previous two steps, it must send it back to the client. This step depends on both the website’s server connection speed and the client’s connection speed.
TTFB is determined when the client receives the first byte, i.e., when the client starts receiving the response. Like the time it takes to acquire the request initially, the distance between the client sending the request and the server also affects the time it takes to send the prepared response.
To avoid such situations, it would be helpful to have servers specific to the countries where your users are located or to take advantage of CDN services.
Factors and metrics that affect TTFB scores generally include:
- High traffic which can cause a server slowdown for websites that do not have enough server resources.
- Network problems.
- The use of too much dynamic content which increases server density.
- The failure to use applications such as server cache or client cache.
- Insufficient server resources including RAM, CPU, disk and network connection speed.
- The database is not optimized.
- General server settings, like the firewall, are not optimized.
- The use of a shared server and hosting service.
How to optimize your score
When it comes to optimizing your TTFB score, there are certain SEO steps that can be taken on both the client side and the server side.
1. Using a CDN
Content delivery network (CDN) technology is one of the important improvement methods for websites with poor TTFB values. CDN services are highly effective in preventing delays caused by distance between the client and the server, which is a major factor in determining TTFB scores.
CDN services are particularly useful for websites with a user base in one or a few countries, where distance-related delays can be eliminated.
By sending your site’s static resources through a CDN, you can reduce the load on your main server and reduce the number of resource requests sent over the network from your server. Static resources hosted on CDN servers are delivered much faster to users than on traditional servers, so your TTFB metric will improve significantly.
In addition, many CDNs also provide support for image optimization, bulk image reduction, minifying CSS & JS resources, HTTP2 push and Brotli compression.
2. Server configuration
Another step you can implement is ensuring that your server is optimally configured. Depending on the type of server on which you are hosting your website, you should implement server-side optimizations and ensure that HTTP requests are processed quickly on the backend.
If you are using PHP, it is especially important to ensure that your PHP version is up-to-date.
On the server, you should implement optimizations such as HTTP/2 and even HTTP 3, Brotli compression (if possible), server-side caching, and database caching (Redis).
Below are some of the configurations and practices you can use on almost any server type to optimize TTFB scores.
By activating the use of the latest version of the HTTP “protocol”, HTTP/2, on your server, you can ensure that requested resources are delivered to the client much faster over the network.
HTTP/3 is even better and the latest version of HTTP which can solve the head-of-line blocking problem present in TCP (HTTP/2). Thanks to the UDP protocol, web servers that use HTTP/3 can communicate with clients easily and faster.
On your server and CDN, don’t forget to use the newest TLS protocol to maintain fast communication speed. With TLS 1.3, you can keep TLS negotiation as short as possible.
Brotli provides 30% more compression compared to Gzip, allowing resources sent from the server to the client to be further compressed and thus minimizing the resources requested.
Redis is an open-source NoSQL database written in the C language. Unlike traditional databases, it stores data in memory rather than writing it to a disk, allowing for faster data communication on the server side.
By implementing server-side caching, you’ll enable your servers to read data quickly, subsequently reducing the burden on the CPU and RAM and preventing static resources hosted on the server from being processed repeatedly.
Implement load balancing
Distribute incoming requests among multiple server instances to ensure optimal resource usage and minimize request processing time.
3. Reducing dynamic content
To avoid such situations, use dynamic content sparingly and caching should be implemented on both user and/or server-side. If caching is not applied on the server side, static resources on web pages can be cached on the browser or user side, allowing the resources to be stored on the user’s computer and loaded much faster, thereby optimizing TTFB scores.
4. Server hardware upgrades
Upgrading your server hardware is important even if you have great server configurations, great infrastructure and great web site architecture. Regardless of all those things, you can still have bad TTFB scores due to lack of hardware resources on the server side.
RAM, internet connection speed, CPU and disk quality and capacity are all factors that determine a server’s TTFB scores and directly have an impact on its responsiveness.
If you are using a UI panel like cPanel, Webmin, or Plesk on your server and trying to process WordPress requests with 512MB or 1GB of RAM, you’re in for a total disaster. Everything you process on your server will slow down your server’s response speed.
In such situations you need to identify how many server sources are solicited by internal staff and you need to have a lot of extra sources which will be used to process upcoming potential traffic to the server.
Sharing hostings are generally slower versions of servers which can be a good fit for really small projects. However for the mid to big level projects it’s better to use separate servers with enough hardwares.
5. Database optimization
Similar to server optimization, it is possible to improve your TTFB score by focusing your optimization efforts on the database. If you have checked your TTFB on the server side and found that there is not much processing going on with any requests, but the wait time for database queries is increasing, then optimizing the database might be your best option.
Here are some steps you can take to do that:
- Indexing: Use appropriate indexes on your database tables to speed up data retrieval. Analyze the most common queries, and add indexes to the columns that are frequently used in WHERE clauses or JOIN operations. Here is a good guide about indexing: https://dataschool.com/sql-optimization/how-indexing-works/
- Query optimization: Review and optimize your SQL queries. Remove unnecessary JOINs, reduce nested queries, and use LIMIT clauses to return only the required data. Use tools like EXPLAIN or EXPLAIN ANALYZE to understand the execution plan and optimize accordingly.
- Caching: Implement caching mechanisms to store the results of frequently accessed queries. This can be done at the application level or by using tools like Redis or Memcached.
- Connection pooling: Use connection pooling to manage and reuse database connections efficiently. Connection pooling can minimize the overhead of opening and closing connections for each query, improving overall performance.
- Database normalization: Normalize your database schema to eliminate redundancy and ensure data consistency. This can help reduce the complexity of queries and improve query performance.
- Denormalization: In some cases, denormalizing the database schema can prove beneficial by reducing the number of JOIN operations. Use this approach with caution, as it can increase data redundancy and maintenance complexity.
- Use materialized views: Materialized views are precomputed query results that are stored and can be updated periodically. Using materialized views can help improve query performance for complex and time-consuming queries.
- Split read and write operations: Distribute the load on your database by separating read and write operations. Use read replicas to handle read-heavy workloads and leave the primary database for write operations.
- Monitor and analyze: Continuously monitor your database performance to identify bottlenecks and performance issues. Use database profiling tools and logs to understand query performance, slow queries, and other potential issues.
6. Optimizing server application code
Very much like database optimization, there are steps you can take that will play a part in ultimately improving your TTFB.
- Use efficient algorithms and data structures: Choose the right algorithms and data structures for your application based on time and space complexity. Optimize the most critical and frequently used parts of your code.
- Minimize blocking operations: Blocking operations can cause delays in processing requests. Use asynchronous or non-blocking operations whenever possible, especially for I/O-bound tasks.
- Optimize middleware and plugins: Review and optimize the middleware and plugins used in your application. Remove unnecessary middleware or replace it with more efficient alternatives.
- Use code profiling tools: Use profiling tools to identify performance bottlenecks and optimize the slow parts of your code. Profiling can help you pinpoint CPU, memory, or I/O-bound issues in your application.
- Optimize server-side rendering (SSR): If your application uses server-side rendering, optimize the rendering process to minimize the time taken to generate the HTML response. Use techniques like lazy loading, code splitting, or partial rendering to improve performance.
7. Service Workers
Service Workers is a useful tool that allows you to intercept and control network requests, manage caching, and provide offline support, among other features. Service Workers is used to serve cached content faster and reduce the load on your server.
It acts as a proxy server between client and your server and can serve cached files before the client request reaches your main server. By using the tool, you can cache your big byte files and can decrease server’s overload.
In conclusion, TTFB is a crucial metric for SEO as it holds significant weight when it comes to the SERPs. Not only is it important for SEO, but a faster TTFB contributes to a better user experience and subsequently enhances user engagement, reduces bounce rates, and improves overall website performance.
Keep an eye out for part two where we will take a more hands-on approach to measuring your TTFB score.