Time to First Byte (TTFB): Measure It and Fix a Slow Server

Time to first byte, usually shortened to TTFB, is how long a visitor waits before the first piece of your page starts to arrive. Everything else on the page, including the main image or headline that Largest Contentful Paint measures, has to wait for it. If your server takes a long time to answer, no amount of image tuning can fully hide that delay.

TTFB is not one thing, and that is why it is often misdiagnosed. It includes redirects, the DNS lookup, the connection and security handshake, and the time your server spends building the response. Two sites can show the same slow number for completely different reasons, and the fix for one does nothing for the other.

This guide is for site owners and developers who have seen a slow server response warning in a speed test. You will measure TTFB properly, find out which part is slow, and apply the fix that matches. It makes no promise about a specific speed-up: results depend on your hosting, your software and where your visitors are.

Before you begin

You need a browser with Developer Tools, a terminal with curl (included on macOS and Linux, and available for Windows), and the address of two or three representative pages: your home page, a typical content page and a page that depends on a database such as a search or product page.

You will also want access to wherever the site is hosted, either a control panel or server configuration, if you plan to change caching. Reading and measuring changes nothing. Changes to caching, redirects or hosting can affect what visitors see, so make a note of the current settings or take a backup first, and test in a staging copy if you have one.

Plan an hour for measurement. Fixes vary from a five-minute setting to a hosting move.

What TTFB includes

web.dev defines TTFB as the time between starting navigation to a page and the moment the first byte of the response begins to arrive. That covers:

time spent on redirects;
service worker startup, if the site uses one;
the DNS lookup;
the connection and TLS negotiation;
the request itself, up to the first byte of the response.

So a visitor who types http://example.com, gets redirected to https://example.com and then to https://www.example.com pays for two redirects before the real request even starts.

web.dev gives a rough guide: a TTFB of 0.8 seconds (800 milliseconds) or less is good, and more than 1.8 seconds is poor. TTFB is not itself a Core Web Vital, but a slow one makes it harder to reach good Largest Contentful Paint results, since the page cannot paint until its first bytes arrive. A server-rendered page may tolerate a higher TTFB if its first and largest paints are still good, while a page that renders its content in the browser relies more heavily on a fast first response. For the metric background, see Core Web Vitals explained.

Lighthouse reports a related audit called server response time. It flags a main document that takes more than 600 milliseconds to start responding. That number is stricter than 800 ms because the audit leaves out DNS and redirect time. As of Lighthouse 13 it appears inside the Document request latency insight. Crawvix has a check called "Server response time is acceptable" that reads this Lighthouse audit and judges the result against 800 ms.

Step-by-step instructions

Step 1: Take a baseline with field data and a lab test

Start with real-visitor data if it exists. PageSpeed Insights shows Chrome User Experience Report data for pages with enough traffic, and your own real-user monitoring can show more. Then run a lab test: Chrome DevTools, Lighthouse or a tool such as WebPageTest.

In DevTools, open the Network panel, tick "Disable cache" to imitate a first visit, reload, click the first request (your page) and open the Timing tab. The "Waiting (TTFB)" row is the time spent waiting for the first byte, which includes one network round trip plus the time your server needed to prepare the response.

Run the test at least three times and note the median, because single runs vary.

What success looks like: You have a field number if available, a lab number for each of your sample pages, and the date.

Step 2: Split TTFB into its parts with curl

Use curl to see where the time goes. The write-out variables below are documented in curl's manual:

curl -s -o /dev/null -L \
  -w "redirects: %{num_redirects}\nredirect time: %{time_redirect}\ndns: %{time_namelookup}\ntcp: %{time_connect}\ntls: %{time_appconnect}\nfirst byte: %{time_starttransfer}\ntotal: %{time_total}\n" \
  https://example.com/

Read the output as cumulative times in seconds from the start of the request. time_namelookup is when DNS finishes, time_connect is when the connection is established, time_appconnect is when the TLS handshake finishes, and time_starttransfer is when the first byte arrives. Subtract one from the next to find how long each stage took. The gap between time_appconnect and time_starttransfer is mostly your server's work (plus one round trip).

time_redirect shows the time spent on redirects before the final request started. If it is more than zero, you have found a cost that you can often remove entirely.

What success looks like: You can say whether the largest share is redirects, connection setup or server processing.

Step 3: Remove avoidable redirects

web.dev lists redirects among the common causes of high TTFB, such as a missing https:// scheme in links or inconsistent trailing slashes, and redirects from link shorteners and tracking services. Check your internal links, canonical tags, sitemap and social profiles, and update them to point to the final address, so visitors and crawlers land directly. Pick one canonical host (see www vs non-www), and keep one redirect from the other versions rather than a chain (see redirect chains and loops).

For the first HTTP to HTTPS hop, web.dev suggests using HSTS, and optionally HSTS preload, so returning visitors skip that step. HSTS has its own risks if misconfigured, so read the HSTS guide before changing it.

What success looks like: num_redirects in the curl test is 0 for the URL you actually link to.

Step 4: Cache what can be cached

If your server builds every page from scratch on each request, caching is usually the largest win. web.dev names uncached content as a major cause: pages that cannot be cached force costly database lookups, and old or rarely visited pages are often uncached.

Practical options, from simplest:

Full-page caching in your CMS or host, so common pages are stored and sent without running the application each time.
A CDN in front of the site, so responses are served from a location nearer to the visitor. See CDN setup.
Cache-Control headers that tell caches how long a response may be reused. Even short lifetimes help busy sites, web.dev notes, but keep personalized pages (logged-in pages, carts, accounts) out of shared caches by marking them private.

Also watch for unique query strings added by analytics or ads. web.dev points out that they can bypass the cache.

What success looks like: A second request for the same page is faster than the first, and a response header or log entry shows it was served from a cache.

Step 5: Find slow back-end work

If caching does not apply or the uncached page is still slow, measure the server's own steps. The Server-Timing response header lets your application report durations that DevTools then displays in the request's timing section. Here is a header with one entry:

Server-Timing: db;desc="Database";dur=121.3, render;dur=48.7

Add entries around your slowest stages, such as database queries, calls to other services and template rendering. web.dev lists slow back-end work, synchronous server-side rendering, under-resourced hosting and heavy plugins or themes (for example on WordPress) among the causes. Typical remedies include reducing or indexing slow queries, removing plugins you do not need, and moving from an overloaded shared plan to resources that match your traffic. Lighthouse's own guidance for this audit suggests optimizing application logic, optimizing database queries, upgrading server hardware and using a CDN if the document can be cached at edge servers.

What success looks like: You can point to the slowest stage by name and number.

Step 6: Consider streaming and Early Hints

Two techniques help when back-end work is unavoidable. Streaming sends the start of the page (the <head>) while the rest is still being built, so the browser can begin fetching styles earlier. A 103 Early Hints response lets the server tell the browser about important files before the final response is ready. web.dev notes both are most helpful when the server has substantial work to do. Not every framework or host supports them, and a changed behavior can confuse measurement: with Early Hints the browser may count the first bytes of the early response, which is why PerformanceNavigationTiming offers finalResponseHeadersStart to measure the final response.

What success looks like: You only try these after Steps 3 to 5, and the final-response timing improves.

Step 7: Retest the same way and compare

Repeat the exact tests from Steps 1 and 2. If your field TTFB looks much worse than your lab number, web.dev's advice is to check caching, redirects and network differences, and to test uncached URLs with a cache-busting parameter. Field data takes time to reflect changes, as it covers real visits over a rolling period.

What success looks like: The lab numbers improve and, over the following weeks, the field data follows.

Final verification checklist

You know your TTFB for at least three representative pages, with the date.
You split the time into redirect, DNS, connection and server parts.
Internal links, canonical tags and the sitemap point straight to the final URL.
Common pages are cached, and personalized pages are not served from shared caches.
You can name the slowest back-end step, using Server-Timing or another profiler.
The curl test shows zero unnecessary redirects.
You retested after each change and kept the before and after numbers.

Common mistakes to avoid

Testing with the cache warm. A repeat request is often fast. Disable the cache or use an uncached URL to see what a first-time visitor or crawler gets.

Blaming the server when the redirects are slow. Check time_redirect before spending money on hosting.

Caching logged-in pages in a shared cache. This can show one person's page to another. Mark personalized responses private and exclude them from page caches.

Optimizing images to fix a slow first byte. Images load after the document. They matter for LCP, but they do not change TTFB.

Changing five things at once. You cannot tell what helped. Change one thing, retest and record it.

Trusting one measurement. Run several tests and compare medians.

Expecting a CDN to fix a slow application. A CDN helps when responses can be cached or when distance is the problem. An uncached page that is slow to build is still slow on a cache miss.

Frequently asked questions

What is a good TTFB?

web.dev's rough guide is 0.8 seconds or less for good, and more than 1.8 seconds as poor. It describes this as a guide for most sites rather than a pass or fail rule.

Is TTFB a ranking factor?

TTFB is not a Core Web Vital. It affects how soon content can appear, and so influences metrics such as LCP. This guide cannot say how it affects any ranking.

Why is my TTFB different in PageSpeed Insights and Lighthouse?

Field TTFB comes from real visits, which include real networks, redirects and cache states. A lab run is a single simulated load. Lighthouse's server response time audit also excludes DNS and redirect time.

Does a CDN always lower TTFB?

Not always. It can lower latency for visitors far from your server and reduce the work your server does, but only cacheable responses benefit fully. A CDN setup that bypasses its cache for your pages will not help much.

How do I measure TTFB for crawlers?

Your server logs record response times for every request, including from search engine crawlers. Google says it lowers its crawl rate when a share of URLs return server errors, so a struggling server matters to crawlers too. See HTTP 500 errors and SEO.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.