Time to First Byte (TTFB)

TL;DR — Time to First Byte is how long the browser waits, after it asks for a page, before the very first byte of the answer comes back. It’s a measure of server responsiveness. A good TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. is 0.8 seconds or less. It is not a Core Web Vital — but a slow one drags down the metrics that are, because nothing on the page can start until that first byte shows up.

What TTFB is

When you click a link, your browser sends a request to a server and then waits. Time to First Byte (TTFB) is the length of that wait — from the moment the request starts to the moment the first byte of the response begins to arrive.

It isn’t just “how fast the server thinks.” A lot happens before your browser even talks to the right machine: it may follow a redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., look up the domain in DNS, open a connection, and negotiate the secure (TLS) handshake. TTFB rolls all of that together, then adds the server’s own processing time, and stops the clock at the first byte back.

What counts as good

Google’s web.dev guidance is simple: aim for a TTFB of 0.8 seconds or less. Above 1.8 seconds is considered poor. Most sites should be able to hit the good mark — and many don’t, which is exactly why it’s worth checking.

Why it matters even though it isn’t a “core” metric

You’ll hear a lot about Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. — LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.. TTFB is not one of them. But it sits underneath the ones about loading: both First Contentful PaintFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. and Largest Contentful Paint include TTFB in their measurement. The browser can’t paint anything until the bytes start arriving. So a slow TTFB puts a ceiling on how fast your page can possibly feel.

The practical takeaway: TTFB doesn’t get you ranked by itself, but a bad one quietly holds back the metrics that do.

The usual fixes, in plain terms

• Use a CDN. It puts a copy of your site on servers physically closer to your visitors, so the round trip is shorter.
• Cache your pages. If the server can hand back a ready-made copy instead of rebuilding the page every time, the first byte comes much sooner.
• Get better hosting. A faster server and database is the most direct fix.
• Cut redirects. Every redirect is an extra round trip before the real page even starts loading.

Want the full version — the exact thresholds, the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. relationship, the LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.-vs-CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. threshold confusion, Early Hints, and how to measure it? Switch to the Advanced tab.

TL;DR — TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. is the time from the start of the request to when the first byte of the response arrives — the sum of redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. time, service worker startup, DNS lookup, connection + TLS negotiation, and the request itself, up to that first byte. It is not a Core Web Vital; it’s a foundational, diagnostic metric that feeds FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. and LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.. web.dev: good is ≤0.8 s, poor is >1.8 s (75th percentile). It’s both a field and a lab metric. LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.’s “Reduce server response times” audit is narrower — it flags server time over ~600 ms, not full TTFB, and as of LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 13 it lives inside the “Document request latency” insight. Fix it with a CDN, edge/HTML cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency., faster hosting, fewer redirects, 103 Early Hints, and efficient TLS. And a high TTFB doesn’t always mean a slow site.

What TTFB actually measures

TTFB measures the time between starting to navigate to a page and when the first byte of the response begins to arrive. The thing people get wrong is treating it as pure backend processing time. It isn’t. It’s the sum of everything that has to finish before that first byte can come back:

1. Redirect time
2. Service worker startup time (if one applies)
3. DNS lookup
4. Connection and TLS negotiation
5. The request — up until the point the first byte of the response has arrived

Server processing is in there, but so is the whole connection-setup tax. That distinction matters the moment you start reading tools, because they don’t all measure the same slice (more on that below).

It is not a Core Web Vital

I’ll say it plainly because it’s the single most common misconception: TTFB is not a Core Web Vital. The three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. are LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (loading), INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (interactivity), and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. (visual stability). TTFB is a foundational, diagnostic metric — Google’s own framing is that it’s “a foundational metric for measuring connection setup time and web server responsiveness in both the lab and the field.”

Google is also explicit that you don’t strictly have to hit the good TTFB threshold: because it isn’t a Core Web Vital, it’s “not absolutely necessary that sites meet the ‘good’ TTFB threshold, provided that it doesn’t impede their ability to score well on the metrics that matter.” That last clause is the catch — for most sites a bad TTFB absolutely does impede the metrics that matter.

How it caps FCP and LCP

TTFB precedes every user-centric loading metric. Both First Contentful Paint and Largest Contentful Paint include TTFB in their measurement — the clock for those metrics is already running while you wait for the first byte. web.dev breaks LCP into sub-parts and TTFB is the first of them, which is why you can’t have a fast LCP sitting on top of a slow TTFB.

This is also where the real-world data gets pointed. The HTTP Archive’s Web Almanac foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. that on sites with poor LCP, TTFB alone was eating roughly 2.27 seconds — nearly the entire 2.5-second “good LCP” budget — before any image or text even started to render. If your LCP is bad and your on-page content looks optimized, TTFB is the first place I’d look.

So the ranking story is indirect but real: TTFB is not a Google ranking signal (the ranking signals are LCP, INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. — TTFB isn’t named in that set). But it’s baked into LCP, which is a ranking signal. The path runs through LCP, not through TTFB directly.

Thresholds: good, needs improvement, poor

web.dev’s guidance, measured at the 75th percentile of real-user loads:

• Good: ≤ 0.8 s
• Poor: > 1.8 s

“Most sites should strive to have a TTFB of 0.8 seconds or less.” Worth knowing the history: Google moved the “good” line from 500 ms to 800 ms back in 2022, and older data was recalculated under the new standard — so don’t compare raw historical TTFB numbers without checking which threshold they used.

The 600 ms vs 800 ms confusion

This trips up a lot of people, so it’s worth being precise. There are two different numbers floating around:

• CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. / web.dev TTFB threshold: 800 ms. This is the field threshold for full TTFB (DNS + connection + TLS + redirects + server time).
• Lighthouse “Reduce server response times” audit: ~600 ms. This is a lab audit that flags when the browser waits more than about 600 ms for the server to respond to the main document request. Crucially, it measures server response time only — it does not include DNS, connection setup, or TLS.

So the Lighthouse number looks stricter, but it’s measuring a narrower slice. As the docs put it, “server response time is only part of the full Time to First Byte (TTFB).” Don’t treat a passing Lighthouse audit as proof of a good field TTFB, and don’t panic that 600 < 800 means the thresholds contradict each other — they measure different things.

One version note: as of Lighthouse 13, this audit no longer stands alone — it’s been folded into the broader “Document request latency” insight. The underlying ~600 ms server-response check is the same; it’s just surfaced differently depending on which Lighthouse version generated your report.

Field and lab — both

TTFB is one of the metrics you can read in both worlds. In the field, it comes from CrUX (real Chrome users), surfaced in PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. and Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.. In the lab, Chrome DevTools labels it “Waiting (TTFB)” in the Network panel waterfall (“the browser is waiting for the first byte of a response”), and tools like WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. and Lighthouse report it too. One field caveat: in CrUX, TTFB is still treated as somewhat experimental — it excludes some advanced navigation types like prerendered and back/forward-cache navigations, so field averages can read a touch pessimistic relative to what users actually feel.

A high TTFB doesn’t always mean a slow site

Here’s the nuance that the threshold numbers hide. A server-rendered page can post a higher TTFB than a client-rendered one and still deliver better FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. and LCP — because when that first byte finally arrives, it’s complete HTML the browser can paint immediately, rather than a thin shell that then has to fetch and run a JavaScript bundle before anything appears. Google says it directly: “a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience.”

The flip side: for a client-rendered single-page app, TTFB determines when the JavaScript bundle even starts loading, so a low TTFB matters more there, not less. Don’t optimize TTFB in a vacuum — optimize the whole loading chain, and judge TTFB by what it does to FCP and LCP.

How to improve TTFB

Roughly in priority order:

• Start with hosting. A slow backend or database query is a tax on every single request, and no amount of front-end work removes it. This is the first thing to consider.
• Use a CDN. A CDN solves the proximity problem — a distributed network of edge servers caches resources physically closer to your users, cutting the speed-of-light cost of the connection and TLS handshake. It’s the highest-ROI fix for most sites, because geographic distance from your origin is a structural tax nothing on the backend can erase. The caveat: for fully dynamic, personalized content that can’t be cached, a CDN adds a hop without a cache-hit payoff — there the answer is backend optimization, edge compute, or streaming.
• Cache your HTML, even briefly. Even a short cache time helps a busy site noticeably: only the first visitor in that window pays the full latency back to the origin; everyone else gets the cached copy.
• Eliminate redirects. Redirects are a common contributor to high TTFB — each one is a round trip before the real response starts. Cut the ones under your control.
• Stream markup to the browser. Browsers process markup efficiently when it’s streamed in chunks as it arrives. Many SSR frameworks support streaming but it’s left switched off; turning it on can drop TTFB on dynamic pages with no infrastructure change at all.
• Use 103 Early Hints. The 103 status code is a preliminary response the server can send while the backend is still preparing the markup, hinting to the browser to begin downloading render-critical resources early. It doesn’t lower TTFB itself — in fact a 103 can count as the “first byte” — but it shrinks the impact of a high TTFB. Shopify and Cloudflare have reported several hundred milliseconds of LCP improvement from it, in some cases close to a second.
• Negotiate TLS efficiently and optimize service worker startup. A service worker that hasn’t started yet adds its startup time to TTFB; once running, its cache (stale-while-revalidate, or an app-shell model for SPAs) can dramatically reduce TTFB.

Where sites actually stand

The reason this is worth your attention: it’s a stubborn problem across the web. The Web Almanac’s mobile good-TTFB rate has barely moved in five years — hovering around 41–42% — meaning a majority of mobile sites still don’t have a “good” TTFB. That stagnation is, frankly, an opportunity. For a server-heavy site failing LCP, TTFB is usually the highest-leverage fix on the board.

This page is part of the web-performance cluster, which sits under Core Web Vitals. For the metrics TTFB feeds into, see Largest Contentful Paint and First Contentful Paint; to measure it on real users and in the lab, see CrUX, PageSpeed Insights, and Lighthouse.

AI summary

A condensed take on the Advanced version:

• TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. = the wait for the first byte. Time from the start of the request to when the first byte of the response arrives — the sum of redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. time, service worker startup, DNS lookup, connection + TLS negotiation, and the request itself. Not just server processing.
• It is NOT a Core Web Vital. The Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. are LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.. TTFB is a foundational, diagnostic metric.
• It caps FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. and LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.. Both include TTFB, so a slow TTFB sets a ceiling on how fast a page can load. On poor-LCP sites, TTFB alone was ~2.27 s — nearly the whole 2.5 s good-LCP budget.
• Rankings: indirect. TTFB isn’t a Google ranking signal, but it’s baked into LCP, which is. The path runs through LCP.
• Thresholds (75th pct): good ≤ 0.8 s, poor > 1.8 s. The “good” line moved from 500 ms to 800 ms in 2022.
• 600 ms vs 800 ms: LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.’s “Reduce server response times” audit flags ~600 ms of server time only — narrower than the 800 ms full-TTFB field threshold. “Server response time is only part of the full TTFB.” As of LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 13 this audit lives inside the “Document request latency” insight.
• Field and lab: CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program./PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking./Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. (field); DevTools “Waiting (TTFB)”, WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input., Lighthouse (lab).
• High TTFB ≠ slow site: an SSR page can have a higher TTFB but better FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital./LCP than a client-rendered one, because the first byte is complete HTML.
• Fixes (priority): hosting first, then CDN, HTML caching, fewer redirects, streaming, 103 Early Hints, efficient TLS, service worker startup.
• State of the web: mobile good-TTFB has been flat at ~41–42% for five years — a real opportunity.

Official documentation

Primary-source documentation from Google’s Chrome and web.dev teams.

• Time to First Byte (TTFB) — the definition, the five components, the 0.8 s / 1.8 s thresholds, why it isn’t a Core Web Vital, and its relationship to FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. and LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good..
• Optimize TTFB — the optimization guide: hosting first, then CDN, cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency., redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., streaming, 103 Early Hints, and service workers.
• Reduce server response times — the Lighthouse auditLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. (~600 ms server-time threshold) and how it differs from full TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good.. As of LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 13 it’s folded into the “Document request latency” insight.
• Web Vitals — where TTFB sits in the metric taxonomy: a supplementary/diagnostic metric, with LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. as the Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors..
• Largest Contentful Paint (LCP) — confirms LCP includes TTFB delays.
• First Contentful Paint (FCP) — confirms FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. includes TTFB, and lists “reduce server response times (TTFB)” as a fix.
• Core Web Vitals (Google Search Central) — the ranking-signal docs name LCP, INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. only; TTFB is not listed.
• 103 Early Hints — the early response code, browser/server support, and real-world results.

Quotes from the source

On-the-record statements from Google’s web.dev and Chrome teams. Each link is a deep link that jumps to the quoted passage on the source page where one was verified.

web.dev — what TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. is

• “TTFB is a metric that measures the time between starting navigating to a page and when the first byte of a response begins to arrive.” Jump to quote
• “Time to First Byte (TTFB) is a foundational metric for measuring connection setup time and web server responsiveness in both the lab and the field.” Jump to quote

web.dev — thresholds

• “Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds.” Jump to quote

web.dev — not a Core Web Vital

• “Because TTFB isn’t a Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold, provided that it doesn’t impede their ability to score well on the metrics that matter.” Jump to quote

web.dev — relationship to FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. and LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.

• “Because TTFB precedes user-centric metrics such as First Contentful Paint (FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital.) and Largest Contentful Paint (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.)…” Jump to quote
• On a server-rendered site: “a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience.” (web.dev, “Time to First Byte”)

LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. — server response time vs full TTFB

• “Server response time is only part of the full Time to First Byte (TTFB).” (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal., “Reduce server response times.”)

Patrick Stox — on TTFB’s status (from my Ahrefs Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. guide)

• “There are additional Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. that serve as proxy measures or supplemental metrics but are not used in the ranking calculations. The Web Vitals metrics for visual load include Time to First Byte (TTFB) and First Contentful Paint (FCP).” Read the guide

TTFB triage checklist

When PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results., or LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. flags a slow server response, work down this list:

• Confirm what you’re looking at — full field TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. (≤0.8 s good) or the LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. “Reduce server response times” audit (~600 ms, server time only). They aren’t the same number.
• Check the field, not just the lab — pull TTFB from CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. via PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. or the Search Console Core Web VitalsThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. report, at the 75th percentile.
• Look at whether TTFB is the thing capping your LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. — if LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. is poor and the page content is optimized, TTFB is the first suspect.
• Count your redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. — eliminate any redirect chainsA → B → C instead of A → C. Each hop loses link equity and adds latency. under your control on key entry URLs.
• Confirm a CDN is serving your users (edge PoPs close to your audience), and that HTML/edge cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. is actually hitting, not just static assets.
• Profile the backend — slow database queries or heavy server-side work on the main document request.
• Verify TLS is efficient (modern protocol, session resumption) and DNS is fast.
• If the page is dynamic SSR, check whether streaming is enabled in your framework — it’s often off by default.
• Consider 103 Early Hints for render-critical resources if your server/CDN supports it.
• If you use a service worker, check its startup isn’t adding to TTFB on first load, and that its cache strategy helps repeat loads.

TTFB cheat sheet

What TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. is the sum of

1. RedirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. time
2. Service worker startup (if any)
3. DNS lookup
4. Connection + TLS negotiation
5. The request — up to the first byte of the response

Thresholds (75th percentile of real-user loads)

Two thresholds, two scopes

Fast facts

• TTFB is not a Core Web Vital. The Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. are LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good..
• It’s both a field and a lab metric.
• Both FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. and LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. include TTFB — it sets a ceiling on them.
• Ranking impact is indirect, via LCP — TTFB itself isn’t a ranking signal.
• DevTools labels it “Waiting (TTFB)” in the Network panel.
• The “good” line moved from 500 ms → 800 ms in 2022.

Fix priority: hosting → CDN → HTML/edge cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. → cut redirects → stream markup → 103 Early Hints → efficient TLS → service worker startup.

Tools for measuring TTFB

• PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. — the easiest field read: shows your CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. (real Chrome users) alongside a lab run, for a URL or origin.
• Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. — field dataPerformance metrics captured from real users, not lab tests. grouped by URL pattern; the place to spot TTFB problems at scale.
• CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. (Chrome User Experience Report) — the underlying field dataset; queryable directly via the CrUX API or BigQuery for historical trends.
• Chrome DevTools — Network panel — hover the main document request and read the “Waiting (TTFB)” timing for a precise lab breakdown of connection vs server time.
• LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. — runs the “Reduce server response times” audit (~600 ms server-time flag); built into DevTools and PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.. As of LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 13, this check surfaces inside the “Document request latency” insight.
• WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. — detailed waterfalls with TTFB broken out by connection phase, and multi-location/connection testing to isolate geographic latency.
• web-vitals JS library — collect TTFB (and the rest) from your own real users in the field and send it to your analytics.

TTFB mistakes that lead to the wrong fix

Calling every delay a server problem

TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. includes redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., DNS, connection setup, TLS, service-worker startup, and server processing. Break the request into phases before changing application code or hosting.

Comparing Lighthouse’s 600 ms audit with the 800 ms field threshold

The Lighthouse auditLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. is a narrower lab diagnostic, while the 0.8-second guidance describes full TTFB. Label the source and scope when reporting either number.

Testing only from a location near the origin

A nearby lab can hide geographic latency. Compare regions or use real-user data before assuming the same experience applies to the whole audience.

Chasing TTFB while the page is already fast

A high TTFB can be compatible with a fast streamed or cached experience. Check whether it actually constrains FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. or LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. before prioritizing it over a larger bottleneck.

Diagnose a slow TTFB by symptom

The first request is slow but repeat requests are fast

Likely cause: cold caches, connection setup, or application warm-up. Fix: inspect cache headers and separate cold from warm tests. Confirm: the waterfall shows which connection or server phase disappears on the repeat request.

TTFB is slow only in distant regions

Likely cause: physical distance to the origin or a CDN cache miss. Fix: serve cacheable HTML closer to users and verify edge cache behavior. Confirm: regional tests show a shorter wait without changing the response body.

A URL has much worse TTFB than its template peers

Likely cause: redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., an uncached route, or expensive page-specific backend work. Fix: compare the redirect chainA → B → C instead of A → C. Each hop loses link equity and adds latency., cache status, and server timing with a healthy peer. Confirm: the outlier’s document request moves back toward the template baseline.

DevTools and CrUX disagree

Likely cause: one lab request cannot represent the field’s devices, locations, cache states, and 75th percentile. Fix: use the lab request to diagnose and field dataPerformance metrics captured from real users, not lab tests. to judge prevalence. Confirm: your RUM distribution explains which segment produces the slower aggregate.

Measure TTFB from the command line

Use curl’s timing variables to separate the first byte from DNS, connection, and TLS setup.

curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s starttransfer=%{time_starttransfer}s total=%{time_total}s\n' \
  https://example.com/

time_starttransfer is the command’s TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good.-style measurement. Run several cold and warm requests from more than one relevant region; a single local sample is not a field benchmark.

Read Navigation Timing in the browser

const nav = performance.getEntriesByType('navigation')[0];
console.table({
  ttfb: Math.round(nav.responseStart - nav.requestStart),
  dns: Math.round(nav.domainLookupEnd - nav.domainLookupStart),
  connect: Math.round(nav.connectEnd - nav.connectStart),
});

Prove a TTFB change took effect

Edge-cache test

Test to run: request the same document twice with curl -sS -D - -o /dev/null, then inspect the CDN’s cache-status and age headers. Expected result: the repeat request is served from cache according to the CDN’s documented header. Failure interpretation: the route is bypassing or immediately expiring the cache. Monitoring window: immediate. Rollback trigger: personalized, authenticated, or stale HTML is served to the wrong request.

Redirect-removal test

Test to run: use curl -sS -I on the final public URL and inspect the redirect chainA → B → C instead of A → C. Each hop loses link equity and adds latency. separately. Expected result: the intended entry URL reaches the document without an avoidable hop. Failure interpretation: routing or canonical-host rules still add a round trip. Monitoring window: immediate. Rollback trigger: the change breaks required HTTP-to-HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' or hostname normalization.

Field TTFB test

Test to run: compare post-release Navigation Timing or web-vitals TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. by region and template with the pre-release baseline. Expected result: p75 improves in the affected segments without more errors. Failure interpretation: the lab gain did not reach real users or shifted work elsewhere. Monitoring window: as RUM traffic arrives; CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. over its rolling window. Rollback trigger: error rate, cache correctness, or user-visible latency worsens.

TTFB metrics worth tracking

Real-user TTFB at p75

Metric: the 75th-percentile TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. by template, region, and device class. What it tells you: how long the document request delays most real visits before renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. can begin. How to pull it: Navigation Timing, the web-vitals library, CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program., or PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.. Benchmark / realistic range: 0.8 seconds or less is the good target described in this article; interpret segments separately. Cadence: weekly in RUM and monthly for the rolling public field trend.

Cache-hit TTFB versus cache-miss TTFB

Metric: p75 TTFB split by the CDN’s cache outcome. What it tells you: whether origin work or edge delivery owns the delay. How to pull it: join response cache-status headers with RUM or CDN logs. Benchmark / realistic range: use the site’s own regional baseline because provider, route, and personalization differ. Cadence: weekly and after cache-rule changes.

TTFB share of LCP

Metric: TTFB divided by the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. duration for the same visit. What it tells you: whether server and connection time are the limiting part of the loading experience. How to pull it: collect TTFB and LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. together in RUM. Benchmark / realistic range: no universal percentage is honest; prioritize TTFB when it consistently consumes a large part of LCP. Cadence: monthly by template.

Resources worth your time

My related writing

• Core Web Vitals: A Beginner’s Guide — where TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. fits among the loading metrics, and why it’s a supplemental metric rather than a ranking signal.
• The Beginner’s Guide to Technical SEO — the bigger picture site performance sits inside.

Official

• web.dev’s TTFB and Optimize TTFB — the two definitive pages.
• The Chrome team’s 103 Early Hints write-up, with the Shopify/Cloudflare results.

Data

• The HTTP Archive Web Almanac — Performance chapter — the long-run TTFB and LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. field dataPerformance metrics captured from real users, not lab tests. for the whole web.

From around the industry

• Cloudflare blog: Early Hints — Cloudflare’s own write-up on shipping 103 Early Hints, including real-world results and CDN implementation details.
• web-vitals JS library (GitHub) — the canonical library for collecting TTFB (and all Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors.) from real users; use this to send field TTFB to your own analytics.
• HTTP Archive Web Almanac 2022 — Performance — historical baseline showing 40% mobile good-TTFB under the then-new 800 ms threshold; useful for multi-year trend context.
• Fastly — HTTP/2 Server Push vs Early Hints — CDN perspective on why Early Hints is replacing Server Push for reducing TTFB impact.

Stats worth citing

• ~42% of mobile sites have a “good” TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. — and it’s barely moved in five years. The Web Almanac’s mobile good-TTFB rate has hovered around 41–42% across five years of data: a stubborn, web-wide stagnation. Source
• On poor-LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. sites, TTFB alone consumed ~2.27 seconds — nearly the entire 2.5-second “good LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.” threshold, before any content rendered. TTFB is the largest sub-part of LCP for sites that fail it. Source
• 103 Early Hints delivered several hundred milliseconds of LCP improvement in Shopify and Cloudflare testing — in some cases close to a second faster. Source
• The “good” TTFB line moved from 500 ms to 800 ms in 2022, and historical data was recalculated under the new standard — worth knowing before comparing old TTFB numbers. Source

Test yourself: Time to First Byte

Five quick questions on what TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. measures and how to improve it. Pick an answer for each, then check.

TTFB

Time to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good.

Related: Core Web Vitals, LCP, FCP

TTFB

Time to First ByteTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. (TTFB) measures the time between starting to navigate to a page and the moment the first byte of the server’s response begins to arrive. It’s the cumulative cost of everything that has to happen before any content can come back: redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. time, service worker startup (if there is one), DNS lookup, connection and TLS negotiation, and the request itself — up until that first byte.

TTFB is not a Core Web Vital. The Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. are LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.; TTFB is a foundational, diagnostic metric. It matters because it precedes every user-centric loading metric — both First Contentful PaintFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. and Largest Contentful Paint include TTFB — so a slow TTFB sets a ceiling on how fast a page can ever appear to load. Its effect on rankings is therefore indirect, routed through LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. rather than measured directly.

web.dev’s thresholds, measured at the 75th percentile of real-user loads: good is 0.8 s or less, and poor is greater than 1.8 s. It’s both a field and a lab metric — you’ll see it in CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. and PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. from real users, and in Chrome DevTools’ “Waiting (TTFB)” timing in the lab. The usual fixes are a CDN, edge or HTML caching, faster hosting and backend, fewer redirects, efficient TLS, and 103 Early Hints. One caveat worth keeping in mind: a higher TTFB doesn’t always mean a slower site — a server-rendered page can post a higher TTFB yet still deliver faster FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. and LCP than a client-rendered one.

Related: Core Web Vitals, LCP, FCP

Changelog