Time To First Byte: Beyond Server Response Time<\/h1>\nMatt Zeunert<\/address>\n 2025-02-12T17:00:00+00:00
\n 2025-03-19T18:34:17+00:00
\n <\/header>\n
This article is sponsored by DebugBear<\/b><\/p>\n
Loading your website HTML quickly has a big impact on visitor experience. After all, no page content can be displayed until after the first chunk of the HTML has been loaded. That\u2019s why the Time to First Byte<\/a> (TTFB) metric is important: it measures how soon after navigation the browser starts receiving the HTML response.<\/p>\nGenerating the HTML document quickly plays a big part in minimizing TTFB delays. But actually, there\u2019s a lot more to optimizing this metric. In this article, we\u2019ll take a look at what else can cause poor TTFB and what you can do to fix it.<\/p>\n
What Components Make Up The Time To First Byte Metric?<\/h2>\n
TTFB stands for Time to<\/em> First Byte. But where does it measure from<\/em>?<\/p>\nDifferent tools handle this differently. Some only count the time spent sending the HTTP request and getting a response, ignoring everything else that needs to happen first before the resource can be loaded. However, when looking at Google\u2019s Core Web Vitals<\/a>, TTFB starts from the time when the users start navigating to a new page<\/a>. That means TTFB includes:<\/p>\n\n- Cross-origin redirects,<\/li>\n
- Time spent connecting to the server,<\/li>\n
- Same-origin redirects, and<\/li>\n
- The actual request for the HTML document.<\/li>\n<\/ul>\n
We can see an example of this in this request waterfall visualization<\/a>.<\/p>\n<\/p>\n <\/p>\n
<\/p>\n
<\/a>\n (Large preview<\/a>)
\n <\/figcaption><\/figure>\nThe server response time<\/a> here is only 183 milliseconds, or about 12% of the overall TTFB metric. Half of the time is instead spent on a cross-origin redirect — a separate HTTP request that returns a redirect response before we can even make the request that returns the website\u2019s HTML code. And when we make that request, most of the time is spent on establishing the server connection.<\/p>\nConnecting to a server on the web typically takes three round trips on the network:<\/p>\n
\n- DNS:<\/strong> Looking up the server IP address.<\/li>\n
- TCP:<\/strong> Establishing a reliable connection to the server.<\/li>\n
- TLS:<\/strong> Creating a secure encrypted connection.<\/li>\n<\/ol>\n
What Network Latency Means For Time To First Byte<\/h2>\n
Let\u2019s add up all the network round trips in the example above:<\/p>\n
\n- 2 server connections: 6 round trips.<\/li>\n
- 2 HTTP requests: 2 round trips.<\/li>\n<\/ul>\n
That means that before we even get the first response byte for our page we actually have to send data back and forth between the browser and a server eight times!<\/strong><\/p>\nThat\u2019s where network latency comes in, or network round trip time<\/a> (RTT) if we look at the time it takes to send data to a server and receive a response in the browser. On a high-latency connection with a 150 millisecond RTT, making those eight round trips will take 1.2 seconds. So, even if the server always responds instantly, we can\u2019t get a TTFB lower than that number.<\/p>\nNetwork latency depends a lot on the geographic distances between the visitor\u2019s device and the server the browser is connecting to. You can see the impact of that in practice by running a global TTFB test<\/a> on a website. Here, I\u2019ve tested a website that\u2019s hosted in Brazil. We get good TTFB scores when testing from Brazil and the US East Coast. However, visitors from Europe, Asia, or Australia wait a while for the website to load.<\/p>\n<\/p>\n <\/p>\n
<\/p>\n
<\/a>\n (Large preview<\/a>)
\n <\/figcaption><\/figure>\nWhat Content Delivery Networks Mean for Time to First Byte<\/h2>\n
One way to speed up your website is by using a Content Delivery Network<\/a> (CDN). These services provide a network of globally distributed server locations. Instead of each round trip going all the way to where your web application is hosted, browsers instead connect to a nearby CDN server (called an edge node). That greatly reduces the time spent on establishing the server connection, improving your overall TTFB metric.<\/p>\nBy default, the actual HTML request still has to be sent to your web app. However, if your content isn\u2019t dynamic, you can also cache responses at the CDN edge node<\/a>. That way, the request can be served entirely through the CDN instead of data traveling all across the world.<\/p>\nIf we run a TTFB test on a website that uses a CDN, we can see that each server response comes from a regional data center close to where the request was made. In many cases, we get a TTFB of under 200 milliseconds, thanks to the response already being cached at the edge node.<\/p>\n<\/p>\n <\/p>\n
<\/p>\n
<\/a>\n (Large preview<\/a>)
\n <\/figcaption><\/figure>\nHow To Improve Time To First Byte<\/h2>\n
What you need to do to improve your website\u2019s TTFB score depends on what its biggest contributing component is.<\/p>\n
\n- A lot of time is spent establishing the connection: Use a global CDN.<\/strong><\/li>\n
- The server response is slow: Optimize your application code<\/strong> or cache the response<\/strong><\/li>\n
- Redirects delay TTFB: Avoid chaining redirects<\/strong><\/a> and optimize the server<\/strong> returning the redirect response.<\/li>\n<\/ul>\n
<\/p>\n <\/p>\n
<\/p>\n
<\/a>\n (Large preview<\/a>)
\n <\/figcaption><\/figure>\nKeep in mind that TTFB depends on how visitors are accessing your website. For example, if they are logged into your application, the page content probably can\u2019t be served from the cache. You may also see a spike in TTFB when running an ad campaign, as visitors are redirected through a click-tracking server.<\/p>\n
Monitor Real User Time To First Byte<\/h2>\n
If you want to get a breakdown of what TTFB looks like for different visitors on your website, you need real user monitoring<\/a>. That way, you can break down how visitor location, login status, or the referrer domain impact real user experience.<\/p>\nDebugBear<\/a> can help you collect real user metrics for Time to First Byte, Google Core Web Vitals, and other page speed metrics. You can track individual TTFB components like TCP duration or redirect time and break down website performance by country, ad campaign, and more.<\/p>\n<\/p>\n
\n 2025-03-19T18:34:17+00:00
\n <\/header>\n
Generating the HTML document quickly plays a big part in minimizing TTFB delays. But actually, there\u2019s a lot more to optimizing this metric. In this article, we\u2019ll take a look at what else can cause poor TTFB and what you can do to fix it.<\/p>\n
What Components Make Up The Time To First Byte Metric?<\/h2>\n
TTFB stands for Time to<\/em> First Byte. But where does it measure from<\/em>?<\/p>\n Different tools handle this differently. Some only count the time spent sending the HTTP request and getting a response, ignoring everything else that needs to happen first before the resource can be loaded. However, when looking at Google\u2019s Core Web Vitals<\/a>, TTFB starts from the time when the users start navigating to a new page<\/a>. That means TTFB includes:<\/p>\n We can see an example of this in this request waterfall visualization<\/a>.<\/p>\n <\/p>\n <\/a> The server response time<\/a> here is only 183 milliseconds, or about 12% of the overall TTFB metric. Half of the time is instead spent on a cross-origin redirect — a separate HTTP request that returns a redirect response before we can even make the request that returns the website\u2019s HTML code. And when we make that request, most of the time is spent on establishing the server connection.<\/p>\n Connecting to a server on the web typically takes three round trips on the network:<\/p>\n Let\u2019s add up all the network round trips in the example above:<\/p>\n That means that before we even get the first response byte for our page we actually have to send data back and forth between the browser and a server eight times!<\/strong><\/p>\n That\u2019s where network latency comes in, or network round trip time<\/a> (RTT) if we look at the time it takes to send data to a server and receive a response in the browser. On a high-latency connection with a 150 millisecond RTT, making those eight round trips will take 1.2 seconds. So, even if the server always responds instantly, we can\u2019t get a TTFB lower than that number.<\/p>\n Network latency depends a lot on the geographic distances between the visitor\u2019s device and the server the browser is connecting to. You can see the impact of that in practice by running a global TTFB test<\/a> on a website. Here, I\u2019ve tested a website that\u2019s hosted in Brazil. We get good TTFB scores when testing from Brazil and the US East Coast. However, visitors from Europe, Asia, or Australia wait a while for the website to load.<\/p>\n <\/p>\n <\/a> One way to speed up your website is by using a Content Delivery Network<\/a> (CDN). These services provide a network of globally distributed server locations. Instead of each round trip going all the way to where your web application is hosted, browsers instead connect to a nearby CDN server (called an edge node). That greatly reduces the time spent on establishing the server connection, improving your overall TTFB metric.<\/p>\n By default, the actual HTML request still has to be sent to your web app. However, if your content isn\u2019t dynamic, you can also cache responses at the CDN edge node<\/a>. That way, the request can be served entirely through the CDN instead of data traveling all across the world.<\/p>\n If we run a TTFB test on a website that uses a CDN, we can see that each server response comes from a regional data center close to where the request was made. In many cases, we get a TTFB of under 200 milliseconds, thanks to the response already being cached at the edge node.<\/p>\n <\/p>\n <\/a> What you need to do to improve your website\u2019s TTFB score depends on what its biggest contributing component is.<\/p>\n <\/p>\n <\/a> Keep in mind that TTFB depends on how visitors are accessing your website. For example, if they are logged into your application, the page content probably can\u2019t be served from the cache. You may also see a spike in TTFB when running an ad campaign, as visitors are redirected through a click-tracking server.<\/p>\n If you want to get a breakdown of what TTFB looks like for different visitors on your website, you need real user monitoring<\/a>. That way, you can break down how visitor location, login status, or the referrer domain impact real user experience.<\/p>\n DebugBear<\/a> can help you collect real user metrics for Time to First Byte, Google Core Web Vitals, and other page speed metrics. You can track individual TTFB components like TCP duration or redirect time and break down website performance by country, ad campaign, and more.<\/p>\n\n
<\/p>\n
\n <\/figcaption><\/figure>\n\n
What Network Latency Means For Time To First Byte<\/h2>\n
\n
<\/p>\n
\n <\/figcaption><\/figure>\nWhat Content Delivery Networks Mean for Time to First Byte<\/h2>\n
<\/p>\n
\n <\/figcaption><\/figure>\nHow To Improve Time To First Byte<\/h2>\n
\n
<\/p>\n
\n <\/figcaption><\/figure>\nMonitor Real User Time To First Byte<\/h2>\n