Tempo até o primeiro 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 TTFB 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. » (Tradução) (Síntese localizada do trecho três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## What TTFB is » (Tradução) (Síntese localizada do trecho quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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. » (Tradução) (Síntese localizada do trecho cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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 redirect, 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.

» (Tradução) (Síntese localizada do trecho seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## What counts as good » (Tradução) (Síntese localizada do trecho sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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.

» (Tradução) (Síntese localizada do trecho oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Why it matters even though it isn’t a “core” metric » (Tradução) (Síntese localizada do trecho nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«You’ll hear a lot about Core Web Vitals — LCP, INP, and CLS. TTFB is not one of them. But it sits underneath the ones about loading: both First Contentful Paint 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. » (Tradução) (Síntese localizada do trecho dez, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«The practical takeaway: TTFB doesn’t get you ranked by itself, but a bad one quietly holds back the metrics that do. » (Tradução) (Síntese localizada do trecho onze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## The usual fixes, in plain terms » (Tradução) (Síntese localizada do trecho doze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- 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. » (Tradução) (Síntese localizada do trecho treze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Want the full version — the exact thresholds, the LCP relationship, the Lighthouse-vs-CrUX threshold confusion, Early Hints, and how to measure it? Switch to the Avançado tab. » (Tradução) (Síntese localizada do trecho catorze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«> TL;DR — TTFB is the time from the start of the request to when the first byte

of the response arrives — the sum of redirect 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 FCP and LCP. web.dev: good is ≤0.8 s, poor is >1.8 s (75th percentile). It’s both a field and a lab metric. Lighthouse’s “Reduce server response times” audit is narrower — it flags server time over ~600 ms, not full TTFB, and as of Lighthouse 13 it lives inside the “Document request latency” insight. Fix it with a CDN, edge/HTML caching, faster hosting, fewer redirects, 103 Early Hints, and efficient TLS. And a high TTFB doesn’t always mean a slow site. » (Tradução) (Síntese localizada do trecho dezessete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## What TTFB actually measures » (Tradução) (Síntese localizada do trecho dezoito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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: » (Tradução) (Síntese localizada do trecho dezenove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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 » (Tradução) (Síntese localizada do trecho vinte, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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).

» (Tradução) (Síntese localizada do trecho vinte e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## It is not a Core Web Vital » (Tradução) (Síntese localizada do trecho vinte e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«I’ll say it plainly because it’s the single most common misconception: TTFB is not a Core Web Vital. The three Core Web Vitals are LCP (loading), INP (interactivity), and CLS (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.” » (Tradução) (Síntese localizada do trecho vinte e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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. » (Tradução) (Síntese localizada do trecho vinte e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## How it caps FCP and LCP » (Tradução) (Síntese localizada do trecho vinte e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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. » (Tradução) (Síntese localizada do trecho vinte e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«This is also where the real-world data gets pointed. The HTTP Archive’s Web Almanac found 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. » (Tradução) (Síntese localizada do trecho vinte e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«So the ranking story is indirect but real: TTFB is not a Google ranking signal (the ranking signals are LCP, INP, and CLS — 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. » (Tradução) (Síntese localizada do trecho vinte e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Thresholds: good, needs improvement, poor » (Tradução) (Síntese localizada do trecho vinte e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«web.dev’s guidance, measured at the 75th percentile of real-user loads: » (Tradução) (Síntese localizada do trecho trinta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- Good: ≤ 0.8 s

• Poor: > 1.8 s

» (Tradução) (Síntese localizada do trecho trinta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«“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. » (Tradução) (Síntese localizada do trecho trinta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## The 600 ms vs 800 ms confusion » (Tradução) (Síntese localizada do trecho trinta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«This trips up a lot of people, so it’s worth being precise. There are two different numbers floating around: » (Tradução) (Síntese localizada do trecho trinta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- CrUX / 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. » (Tradução) (Síntese localizada do trecho trinta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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. » (Tradução) (Síntese localizada do trecho trinta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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. » (Tradução) (Síntese localizada do trecho trinta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Field and lab — both » (Tradução) (Síntese localizada do trecho trinta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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 Insights and Search Console. 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 WebPageTest 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. » (Tradução) (Síntese localizada do trecho trinta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## A high TTFB doesn’t always mean a slow site » (Tradução) (Síntese localizada do trecho quarenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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 FCP 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.” » (Tradução) (Síntese localizada do trecho quarenta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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. » (Tradução) (Síntese localizada do trecho quarenta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## How to improve TTFB » (Tradução) (Síntese localizada do trecho quarenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Roughly in priority order: » (Tradução) (Síntese localizada do trecho quarenta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- 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 » (Tradução) (Síntese localizada do trecho quarenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.) « 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. » (Tradução) (Síntese localizada do trecho quarenta e cinco, parte dois: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Where sites actually stand » (Tradução) (Síntese localizada do trecho quarenta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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. » (Tradução) (Síntese localizada do trecho quarenta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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. » (Tradução) (Síntese localizada do trecho quarenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## AI summary » (Tradução) (Síntese localizada do trecho cinquenta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«A condensed take on the Advanced version: » (Tradução) (Síntese localizada do trecho cinquenta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- TTFB = 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 redirect 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 Vitals are LCP, INP, and CLS. TTFB is a foundational, diagnostic metric.
• It caps FCP and LCP. 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: Lighthouse’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 Lighthouse 13 this audit lives inside the “Document request latency” insight.
• Field and lab: CrUX/PSI/Search Console (field); DevTools “Waiting (TTFB)”, WebPageTest, Lighthouse (lab).
• High TTFB ≠ slow site: an SSR page can have a higher TTFB but better FCP/LCP than a client-rendered one, because the first byte is complete HTML.
• Fixes (priority): hosting first, then CDN, HTML caching, fewer redirects, » (Tradução) (Síntese localizada do trecho cinquenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.) « 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. » (Tradução) (Síntese localizada do trecho cinquenta e três, parte dois: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Official documentation » (Tradução) (Síntese localizada do trecho cinquenta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Primary-source documentation from Google’s Chrome and web.dev teams. » (Tradução) (Síntese localizada do trecho cinquenta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- 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 FCP and LCP.

• Optimize TTFB — the optimization guide: hosting first, then CDN, caching, redirects, streaming, 103 Early Hints, and service workers.
• Reduce server response times — the Lighthouse audit (~600 ms server-time threshold) and how it differs from full TTFB. As of Lighthouse 13 it’s folded into the “Document request latency” insight.
• Web Vitals — where TTFB sits in the metric taxonomy: a supplementary/diagnostic metric, with LCP, INP, and CLS as the Core Web Vitals.
• Largest Contentful Paint (LCP) — confirms LCP includes TTFB delays.
• First Contentful Paint (FCP) — confirms FCP includes TTFB, and lists “reduce server response times (TTFB)” as a fix.
• Core Web Vitals (Google Search Central) — the ranking-signal docs name LCP, INP, and CLS only; TTFB is not listed.
• 103 Early Hints — the early response code, browser/server support, and real-world results. » (Tradução) (Síntese localizada do trecho cinquenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Quotes from the source » (Tradução) (Síntese localizada do trecho sessenta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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. » (Tradução) (Síntese localizada do trecho sessenta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«web.dev — what TTFB is » (Tradução) (Síntese localizada do trecho sessenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- “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 » (Tradução) (Síntese localizada do trecho sessenta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«web.dev — thresholds » (Tradução) (Síntese localizada do trecho sessenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- “Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds.” Jump to quote » (Tradução) (Síntese localizada do trecho sessenta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«web.dev — not a Core Web Vital » (Tradução) (Síntese localizada do trecho sessenta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- “Because TTFB isn’t a Core Web Vitals 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 » (Tradução) (Síntese localizada do trecho sessenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«web.dev — relationship to FCP and LCP » (Tradução) (Síntese localizada do trecho sessenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- “Because TTFB precedes user-centric metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP)…” 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”) » (Tradução) (Síntese localizada do trecho setenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Lighthouse — server response time vs full TTFB » (Tradução) (Síntese localizada do trecho setenta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- “Server response time is only part of the full Time to First Byte (TTFB).” (Lighthouse, “Reduce server response times.”) » (Tradução) (Síntese localizada do trecho setenta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Patrick Stox — on TTFB’s status (from my Ahrefs Core Web Vitals guide) » (Tradução) (Síntese localizada do trecho setenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- “There are additional Web Vitals 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 » (Tradução) (Síntese localizada do trecho setenta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Note: web.dev and the Lighthouse docs are JavaScript-rendered in places, and only the quotes carrying a #:~:text= deep link above were verified against the live page during this brief. The server-rendered-site line and the Lighthouse “server response time is only part of the full TTFB” line are reproduced from the source brief and should be confirmed against the live pages before being treated as final. » (Tradução) (Síntese localizada do trecho setenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## TTFB triage checklist » (Tradução) (Síntese localizada do trecho setenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«When PageSpeed Insights, Search Console, or Lighthouse flags a slow server response, work down this list: » (Tradução) (Síntese localizada do trecho setenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- [ ] Confirm what you’re looking at — full field TTFB (≤0.8 s good) or the Lighthouse “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 CrUX via PageSpeed Insights or the Search Console Core Web Vitals report, at the 75th percentile.
• Look at whether TTFB is the thing capping your LCP — if LCP is poor and the page content is optimized, TTFB is the first suspect.
• Count your redirects — eliminate any redirect chains under your control on key entry URLs.
• Confirm a CDN is serving your users (edge PoPs close to your audience), and that HTML/edge caching 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. » (Tradução) (Síntese localizada do trecho oitenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## TTFB cheat sheet » (Tradução) (Síntese localizada do trecho oitenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«What TTFB is the sum of

1. Redirect 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 » (Tradução) (Síntese localizada do trecho oitenta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Thresholds (75th percentile of real-user loads) » (Tradução) (Síntese localizada do trecho oitenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«| Band | Full TTFB (CrUX / web.dev) | | --- | --- | | Good | ≤ 0.8 s | | Needs improvement | 0.8 s – 1.8 s | | Poor | > 1.8 s | » (Tradução) (Síntese localizada do trecho oitenta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Two thresholds, two scopes » (Tradução) (Síntese localizada do trecho oitenta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«| Tool | Threshold | Measures | | --- | --- | --- | | CrUX / web.dev (field) | 0.8 s “good” | Full TTFB (DNS + conn + TLS + redirects + server) | | Lighthouse audit (lab) | ~600 ms flag | Server response time only | » (Tradução) (Síntese localizada do trecho oitenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Fast facts

• TTFB is not a Core Web Vital. The Core Web Vitals are LCP, INP, CLS.
• It’s both a field and a lab metric.
• Both FCP and LCP 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. » (Tradução) (Síntese localizada do trecho oitenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Fix priority: hosting → CDN → HTML/edge caching → cut redirects → stream markup → 103 Early Hints → efficient TLS → service worker startup. » (Tradução) (Síntese localizada do trecho noventa, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Tools for measuring TTFB » (Tradução) (Síntese localizada do trecho noventa e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- PageSpeed Insights — the easiest field read: shows your CrUX TTFB (real Chrome users) alongside a lab run, for a URL or origin.

• Search Console — Core Web Vitals report — field data grouped by URL pattern; the place to spot TTFB problems at scale.
• CrUX (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.
• Lighthouse — runs the “Reduce server response times” audit (~600 ms server-time flag); built into DevTools and PageSpeed Insights. As of Lighthouse 13, this check surfaces inside the “Document request latency” insight.
• WebPageTest — 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. » (Tradução) (Síntese localizada do trecho noventa e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## TTFB mistakes that lead to the wrong fix » (Tradução) (Síntese localizada do trecho noventa e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### Calling every delay a server problem » (Tradução) (Síntese localizada do trecho noventa e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«TTFB includes redirects, DNS, connection setup, TLS, service-worker startup, and server processing. Break the request into phases before changing application code or hosting. » (Tradução) (Síntese localizada do trecho noventa e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### Comparing Lighthouse’s 600 ms audit with the 800 ms field threshold » (Tradução) (Síntese localizada do trecho cem, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«The Lighthouse audit is a narrower lab diagnostic, while the 0.8-second guidance describes full TTFB. Label the source and scope when reporting either number. » (Tradução) (Síntese localizada do trecho cento e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### Testing only from a location near the origin » (Tradução) (Síntese localizada do trecho cento e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«A nearby lab can hide geographic latency. Compare regions or use real-user data before assuming the same experience applies to the whole audience. » (Tradução) (Síntese localizada do trecho cento e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### Chasing TTFB while the page is already fast » (Tradução) (Síntese localizada do trecho cento e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«A high TTFB can be compatible with a fast streamed or cached experience. Check whether it actually constrains FCP or LCP before prioritizing it over a larger bottleneck. » (Tradução) (Síntese localizada do trecho cento e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Diagnose a slow TTFB by symptom » (Tradução) (Síntese localizada do trecho cento e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### The first request is slow but repeat requests are fast » (Tradução) (Síntese localizada do trecho cento e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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. » (Tradução) (Síntese localizada do trecho cento e dez, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### TTFB is slow only in distant regions » (Tradução) (Síntese localizada do trecho cento e onze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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. » (Tradução) (Síntese localizada do trecho cento e doze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### A URL has much worse TTFB than its template peers » (Tradução) (Síntese localizada do trecho cento e treze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Likely cause: redirects, an uncached route, or expensive page-specific backend work. Fix: compare the redirect chain, cache status, and server timing with a healthy peer. Confirm: the outlier’s document request moves back toward the template baseline. » (Tradução) (Síntese localizada do trecho cento e catorze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### DevTools and CrUX disagree » (Tradução) (Síntese localizada do trecho cento e quinze, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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 data to judge prevalence. Confirm: your RUM distribution explains which segment produces the slower aggregate. » (Tradução) (Síntese localizada do trecho cento e dezesseis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Measure TTFB from the command line » (Tradução) (Síntese localizada do trecho cento e dezenove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Use curl’s timing variables to separate the first byte from DNS, connection, and TLS setup. » (Tradução) (Síntese localizada do trecho cento e vinte, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

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 TTFB-style measurement. Run several cold and warm requests from more than one relevant region; a single local sample is not a field benchmark. » (Tradução) (Síntese localizada do trecho cento e vinte e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Read Navigation Timing in the browser » (Tradução) (Síntese localizada do trecho cento e vinte e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

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 » (Tradução) (Síntese localizada do trecho cento e vinte e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### Edge-cache test » (Tradução) (Síntese localizada do trecho cento e vinte e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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. » (Tradução) (Síntese localizada do trecho cento e vinte e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### Redirect-removal test » (Tradução) (Síntese localizada do trecho cento e trinta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Test to run: use curl -sS -I on the final public URL and inspect the redirect chain 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-HTTPS or hostname normalization. » (Tradução) (Síntese localizada do trecho cento e trinta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### Field TTFB test » (Tradução) (Síntese localizada do trecho cento e trinta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Test to run: compare post-release Navigation Timing or web-vitals TTFB 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; CrUX over its rolling window. Rollback trigger: error rate, cache correctness, or user-visible latency worsens. » (Tradução) (Síntese localizada do trecho cento e trinta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## TTFB metrics worth tracking » (Tradução) (Síntese localizada do trecho cento e trinta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### Real-user TTFB at p75 » (Tradução) (Síntese localizada do trecho cento e trinta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Metric: the 75th-percentile TTFB by template, region, and device class. What it tells you: how long the document request delays most real visits before rendering can begin. How to pull it: Navigation Timing, the web-vitals library, CrUX, or PageSpeed Insights. 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. » (Tradução) (Síntese localizada do trecho cento e trinta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### Cache-hit TTFB versus cache-miss TTFB » (Tradução) (Síntese localizada do trecho cento e trinta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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. » (Tradução) (Síntese localizada do trecho cento e quarenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«### TTFB share of LCP » (Tradução) (Síntese localizada do trecho cento e quarenta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Metric: TTFB divided by the LCP 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 LCP 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. » (Tradução) (Síntese localizada do trecho cento e quarenta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Resources worth your time » (Tradução) (Síntese localizada do trecho cento e quarenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«My related writing

• Core Web Vitals: A Beginner’s Guide — where TTFB 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. » (Tradução) (Síntese localizada do trecho cento e quarenta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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. » (Tradução) (Síntese localizada do trecho cento e quarenta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Data

• The HTTP Archive Web Almanac — Performance chapter — the long-run TTFB and LCP field data for the whole web. » (Tradução) (Síntese localizada do trecho cento e quarenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«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 Vitals) 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. » (Tradução) (Síntese localizada do trecho cento e quarenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Stats worth citing » (Tradução) (Síntese localizada do trecho cento e cinquenta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- ~42% of mobile sites have a “good” TTFB — 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-LCP sites, TTFB alone consumed ~2.27 seconds — nearly the entire 2.5-second “good LCP” 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 » (Tradução) (Síntese localizada do trecho cento e cinquenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Test yourself: Time to First Byte » (Tradução) (Síntese localizada do trecho cento e cinquenta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Five quick questions on what TTFB measures and how to improve it. Pick an answer for each, then check. » (Tradução) (Síntese localizada do trecho cento e cinquenta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Registro de alterações