What does TTFB – Time To First Byte mean

What is the TTFB?

Time To First Byte (TTFB) is a value used to measure the responsiveness of a web server or other network resource. This measurement is critical for all websites and related CMS, whether your website is based on WordPress, Prestashop, Magento or any other system. Be careful not to confuse TTFB with TTLB – Time To Last Byte .

The TTFB indicates how fast a server is to initiate a data transmission with a client, which is usually the user’s browser or the spider of a search engine. In other words, the TTFB is the time that the browser must wait before receiving the data.

Technically, the TTFB is measured by counting the time elapsed from the client’s HTTP request to receiving the first byte of the page.

This time consists of:

• the connection time
• the time it takes to send the HTTP request
• the time it takes to get the first byte of the page

The TTFB calculation always includes network latency in measuring the time it takes to start loading a resource.

In many cases, a fast TTFB time is a well-configured web server signal, even if an important impact is given by the presence of a caching system. Most commonly, a very low TTFB is observed with statically served web pages, while a higher TTFB is often due to numerous requests to a database.

How to measure the Time To First Bite – TTFB

TTFB can be measured with various online tools such as WebPageTest or even with Google Chrome Developer Tools . In the following image I tested the TTFB simulating a GPRS network, notoriously very slow. The result, despite a penalizing throttling, remains satisfactory: 0.63 seconds. With the commercial network I get a TTFB of 25 μs (microseconds), 25 thousandths of a second.

Google Analytics also has the function to measure loading times but you have to pay attention to the approximation level and above all the sampling level (which you can change) .

How to evaluate the Time To First Bite – TTFB

• 1 – 0.2 seconds:excellent
• 3 – 0.5 seconds:good
• 6 – 0.9 seconds:average
• 1 – 1.5 seconds:above average
• 6 seconds or slower:very bad

A good tool for measuring TTFB is WebPageTest . Enter your website and launch the analysis.

Time To First Bite Analysis – TTFB with WebPageTest

How to optimize the Time To First Bite – TTFB

Below I summarize the effective optimizations to improve TTFB.

• Use a CDN
• Optimize the application code
• Optimize database queries
• Reduce http calls
• Ensure fast server response
• Use a caching method respond first, process later RFPL

Use a Content Delivery Network – CDN

Why use a CDN? A CDN works by providing alternative servers for users to download assets (usually static content, such as images and JavaScript). These nodes scattered around the world, being geographically closer to users, ensure faster response and download times due to reduced latency.

While CDNs are an adequate solution for most websites looking for speed improvements, not every site needs them. It is important to understand how CDNs work and ultimately whether the benefits are worth the cost of adding one.

A CDN is essentially a network of geographically distributed servers. Each CDN node (also called Edge Server) caches the static content of a site such as images, CSS / JS files, and other structural components. Most of an end user’s page load time is spent on fetching this content, and therefore it makes sense to deliver these “building blocks” of a site to as many servers as possible, spread across the globe. When a user requests yours, the closest node in their proximity will deliver the static content, ensuring data transmission over the shortest distance (reduced latency), thus providing the fastest site experience.

CDNs ensure that users download data from servers that are closest, in geographic proximity. CDNs not only ensure a faster experience for users, but they also help prevent site crashes in the event of traffic spikes – CDNs help distribute bandwidth across multiple servers instead of loading all the work on only one server. There are CDNs like Cloudflare that also protect against DDOS attacks and are born more oriented towards security.

Insights:

• Why use a Content Delivery Network (CDN)?

Optimize the application code

• Accelerate and secure applications with a Reverse Proxy Server
• Use a Load Balancerif necessary
• Cache static and dynamic content
• Compress data with gzip
• Optimize the SSL / TLS protocol
• Implements HTTP / 2, SPDY has been deprecated
• Update the softwareinstalled on the web server
• Optimize Linuxfor Performance
• Optimize the web serverfor performance
• Monitor live activity for bottlenecks

Insights:

• 10 Tips for 10x Application Performance

Optimize database queries

• Learn how to properly create an index
• Request only the strictly necessary data
• Avoid WHERE functions, avoid having to read the entire database to answer a query
• Avoid correlated subquerieswhenever possible . Related subqueries depend on other queries.
• Whenever possible, avoid using Wildcard characterswithin a query with LIKE

Insights:

• 5 Tips to Optimize Your SQL Queries

Reduce HTTP calls

• Check how many HTTP callsyour site makes
• Remove unnecessary images
• Reduce the sizeof the remaining images
• Analyzeother factors that impact upload speed
• Invoke JavaScript asynchronously
• CombineCSS files together

Insights:

• How to Reduce Your Website’s HTTP Requests

Ensure fast server response

• Combine External CSS: Many themes use separate CSS in many files.
• Combine external JavaScript: Just like the CSS file, JavaScript files can also be combined to reduce HTTP calls
• Use lazyloading to defer image loading: deferring image loading helps save bandwidth and reduce page load times
• Inline small CSS and JavaScript: it is often better to insert small strings of CSS or JavaScript directly into the HTML rather than importing an external file
• Use keep-alive: Make sure your web server is set to use keep-alive to optimize handling of HTTP requests

Insights:

• Server response time

Use a Respond First, Process Later – RFPL caching method

• Server (application) receives a request and sends the previously cached response
• Server (application) continues to process the current request
• Server (application) saves the result of the process in cache

To comply with the RFPL method, certain conditions must be met:

• Cache only GET requests
• Always supply from cache first if it exists
• Close the connection and send the content lengthbefore the server has finished processing the request in the background
• Update the cache only if its age is greater than TTL (TTL expired): in this way you will avoid regenerating the same content more than necessary, saving CPU and RAM

To send the content first you need two headers:

• Content-Length: {n}
• Connection: close

These two headers tell the browser to close the connection and when to stop downloading content (of a given length) from the server without having to wait for the process to finish on the server. In case your browser supports Gzip compression.

Insights:

• Reducing the response time to first byte using cache first – process later method