Time to first byte: the delay every other metric inherits

TTFB is the time from the start of the request to the first byte of the response. It is the whole trip before content renders.

• Redirects: every 301 or 302 adds a round trip before the real page.
• DNS lookup: the browser asks where your host lives.
• TCP and TLS handshakes: connections and encryption are set up.
• Server time: your app or CMS renders the HTML or fetches it from cache.

If TTFB is slow, Largest Contentful Paint is late even with perfect images and CSS. You feel it as a blank page before anything happens.

Use these reference points as of 2026, from web.dev. Good TTFB is up to 0.8 s. Poor is above 1.8 s. In between needs work.

Core Web Vitals do not include TTFB, but TTFB delays LCP. LCP is good up to 2.5 s and poor above 4 s. Lower TTFB and you raise your chance to pass the field assessment.

Field data is what matters for Search. It uses the Chrome User Experience Report over 28 days at the 75th percentile. It is per URL when there is enough traffic, else per origin.

• PageSpeed Insights: paste a URL, read the Mobile tab first. The top section is field data. It shows pass or fail on Core Web Vitals and distributions for metrics.
• Search Console Core Web Vitals report: group URLs by status and issue. It reads the same field data. Mobile-first indexing means the mobile data is the primary view.
• Expect gaps: low traffic URLs fall back to origin-level data or show nothing. Chrome on iOS is not in the dataset.

TTFB is shown in PageSpeed Insights field distributions when available. If it is high, your LCP will likely sit on the wrong side of 2.5 s for mobile users on real networks.

Lab runs tell you what to fix. Lighthouse is one simulated load on a mid-range phone over throttled 4G. Scores vary between runs.

• Run Lighthouse in PageSpeed Insights. Scroll to the audits. The Performance score weights Total Blocking Time 30%, LCP 25%, CLS 25%, First Contentful Paint 10% and Speed Index 10%.
• Compare TTFB across repeated runs and against your origin location. A large spread hints at cold caches or variable server time.
• Use your browser’s DevTools Network panel. Reload with the Disable cache option. Inspect the first request’s Waiting for server timing. That is TTFB.
• Test both Mobile and Desktop tabs. The mobile profile penalises slow backends over slower networks more clearly.

Pick one page that matters and one that is slow. For example, "/pricing" for a logged-out user and "/guides/getting-started" with a long article. Test both on Mobile and Desktop in PageSpeed Insights. Then replicate in DevTools with Disable cache and a hard reload.

1. 1

   Check for redirects

   Paste the bare domain and the final canonicals. If http to https and www to apex chain, fix to a single hop. "http://yourproduct.com/pricing" should 301 once to "https://www.yourproduct.com/pricing" or your chosen root, not twice.

2. 2

   Look at DNS and connection setup

   In DevTools waterfall, expand the first request. If DNS and connection take a long share, you are missing preconnects, or your origin is far from users.

3. 3

   Read server timing

   If Waiting is most of TTFB, the server is slow to render or to fetch data. That is your HTML generation path.

4. 4

   Repeat with a warm cache

   Reload without Disable cache. If TTFB drops a lot, HTML caching works when warm but you are missing a reliable cache layer for first visitors.

5. 5

   Test country distance

   Use a VPN or ask a team mate abroad to run PSI. If Europe is fast and US is slow, your origin or cache is not close to US users.

• Server-rendered pages without caching: every visit hits the database and templates, even for "/", "/pricing" and "/blog/*".
• A distant origin: a single region in Europe serving US or APAC users. Latency and TLS round trips add up before your HTML starts.
• Redirect chains: http to www to https to slash adds two or three round trips before any HTML.
• Slow database calls on every request: unindexed queries, N+1 fetches for navigation, settings or AB flags.
• Cold starts and build-time work on request: loading a large framework or compiling templates on each request.
• Heavy edge logic on cache misses: auth or geolocation decisions without fast paths for public pages.

You see it as a blank white page before the header appears. Your LCP then loses the race to 2.5 s on mobile. The Lighthouse run shows high TTFB and a weak LCP score with no obvious render-blockers.

Cache the HTML for public pages. Do it at the edge when you can, at the app when you must. Logged-out pages should almost never be rendered on every request.

1. 1

   Choose what to cache

   Cache "/", "/pricing", "/features/*", "/blog/*" for at least a few minutes. Vary on minimal cookies. Do not cache dashboards or personal data.

2. 2

   Set surrogate keys and purge on change

   When you publish a post, purge the home and category pages by key. Avoid global purges that empty the whole cache.

3. 3

   Add stale-while-revalidate

   Serve a cached page immediately, revalidate in the background. First byte leaves the server fast, and users get fresh content soon after.

4. 4

   Pre-render static routes at build time

   If your framework supports it, ship prebuilt HTML for marketing pages. The server then only serves files from storage or a CDN.

5. 5

   Return 103 Early Hints for critical assets

   If your server or CDN supports it, send preload hints for the hero image and CSS before the final response. The browser starts work early.

A fixed page looks like "/pricing" returning the first byte in about 200 ms from a nearby edge, with the hero image already preloading in the waterfall.

Put a CDN in front of your origin. Cache the HTML and assets, not just images. Enable HTTP/2 or HTTP/3 and persistent connections to cut repeated handshakes.

• Serve from the closest edge: configure your CDN to cache HTML for public pages with a short TTL, and revalidate on content change.
• Enable HTTP/2 or HTTP/3: multiplex requests on one connection. This reduces the connection overhead inside TTFB and speeds up subsequent resources.
• Keep-alive on: allow reuse of TCP connections. New requests avoid a fresh handshake, which lowers TTFB for in-page navigations and assets.
• Preconnect where you must call third parties: add <link rel="preconnect"> to critical origins you cannot avoid, such as your own CDN host.

If your audience is global, use multi-region origins or a CDN with good PoP coverage. A distant single-region server turns even small backend work into a slow TTFB for far users.

Every hop before your HTML adds to TTFB. Remove chains and extra lookups. Make the first request land on the final URL over HTTPS.

1. 1

   Flatten redirects

   Pick one canonical host and scheme. For example, always serve https and no www. Make http and www 301 directly to https://yourproduct.com/ not via a second hop.

2. 2

   Upgrade links at source

   Fix old internal links to point to https and the final path. Do not rely on redirects for your own navigation or sitemaps.

3. 3

   Set HSTS after you are stable

   When you are confident, send Strict-Transport-Security so repeat visits skip the http hop.

4. 4

   Use a fast DNS host

   Pick a reputable DNS provider. Long DNS lookups are rare but real on budget hosts. Keep CNAME chains short for your apex and www.

5. 5

   Tune TLS

   Enable HTTP/2 or HTTP/3 on your CDN or server. Use modern TLS. Reuse connections so the handshake is paid once per origin.

A fixed request goes from "http://yourproduct.com" to "https://yourproduct.com" in one 301, then serves HTML from cache. No extra www hop, no path redirects, no country redirects for public pages.

When you must render, make the work small and predictable. The code that runs on every request should do very little before it can stream HTML.

• Index database queries used on "/" and "/pricing". Avoid N+1 requests for menus, categories and settings. Cache those fragments.
• Warm caches on deploy: prefetch the top routes after release so the first real user does not pay the cold miss.
• Stream early: flush the HTML head and above-the-fold shell as soon as you can. The browser can request CSS and the hero image while the server finishes.
• Avoid per-request builds: no template compilation or schema introspection on first hit. Do that at startup.
• Make AB tests and flags cheap: resolve them at the edge or cache the evaluated variant for public pages.

If the server’s share of TTFB drops from hundreds of milliseconds to tens, you will see FCP move earlier and LCP follow. You also gain headroom for traffic spikes.

TTFB sets the earliest time anything can paint. First Contentful Paint is good up to 1.8 s and poor above 3 s. LCP measures the largest element in view and is good up to 2.5 s. If TTFB is one second, you have little time left for CSS, images and scripts to load before you miss those targets.

• Render-blocking resources: unblock CSS and defer scripts so the browser can render right after the first byte arrives.
• Images: never lazy-load the hero image. Use fetchpriority=high and, if it is a CSS background, a preload.
• Third-party scripts: cut or delay them. They do not affect TTFB, but they push LCP and INP later.
• Fonts: preload one above-the-fold face and use font-display to avoid a blank swap. Self-host to skip third-party handshakes.

A page with fast TTFB but slow render still fails users. Fix the backend and the render path together. Test on mobile. The field assessment reads real mobile users first.