Main area
Agency
technisches-seo

TTFB and the Critical Rendering Path — the Initial Load from Server to First Paint

Redaktion ·

TTFB and the Critical Rendering Path — the Initial Load from Server to First Paint

Between clicking a link and seeing the first visible pixel, two things happen in sequence. First, the server has to even start responding — that is what TTFB measures. Then the browser has to assemble an image from the incoming HTML, CSS and JavaScript — that is the critical rendering path. The two are directly connected: a slow server pushes everything after it back, and a blocked render path makes even a fast server feel sluggish. If you want to optimise load times seriously, you have to understand both halves — otherwise you pull the wrong lever.

TTFB — what exactly gets measured

TTFB stands for Time to First Byte: the time between the start of navigation to a page and the moment the first byte of the response arrives at the browser (source: web.dev, accessed 2026-06-06). The emphasis is on first byte — not the whole document, not the first pixel, just the very first chunk of response. So TTFB is not a load time in the everyday sense; it is the starting gun for everything that follows.

The value is made up of several phases the browser runs through before the server can even answer:

  • Redirect time — every 301/302 redirect costs a full extra round trip.
  • Service worker startup time — if a service worker intercepts the request.
  • DNS lookup — resolving the domain name into an IP address.
  • Connection setup and TLS handshake — the TCP handshake plus establishing the encrypted connection.
  • Request processing — the actual work on the server until the first byte goes out.

Only once this chain is complete does transfer begin. Each step is its own potential bottleneck, which is exactly why it matters to know which phase dominates for you — the browser devtools show this per request in the network tab.

The threshold — what counts as good

The web.dev guideline is clear: 0.8 seconds (800 milliseconds) or less counts as good, measured at the 75th percentile. Values above 1.8 seconds count as poor (source: web.dev, accessed 2026-06-06). Everything in between is the grey zone of “needs improvement”.

Those 800 ms are a rough orientation, not a hard ranking limit. TTFB itself is also not a standalone Core Web Vitals value — it does not appear directly in any of the three official metrics. It still matters, and the reason is mechanics, not marketing.

Why TTFB is the starting gun for LCP

TTFB precedes every other meaningful loading performance metric (source: web.dev, accessed 2026-06-06). First Contentful Paint cannot happen earlier than the arrival of the first byte. And Largest Contentful Paint — the Core Web Vitals value that measures the largest visible element — sits even further back in the chain.

The consequence is uncomfortably simple: a poor TTFB makes a good LCP impossible. If the server takes 1.5 seconds before the first byte arrives, LCP cannot land below those 1.5 seconds — no matter how lean your CSS is or how cleverly you load images. TTFB is the foundation; all frontend optimisation builds on top of it. It hits single-page apps with client-side rendering especially hard: there the user first waits for the first byte and then still waits for the JavaScript that assembles the page.

TTFB levers — where you actually gain time

The most effective levers sit at the server and connection layer:

Use a CDN. A content delivery network places edge servers geographically closer to the user, brings modern protocols (HTTP/2, HTTP/3) and speeds up DNS resolution and connection setup. For sites with an audience across multiple regions this is often the single biggest gain.

Configure caching. Correctly set Cache-Control headers let edge and server caches take effect. Even short cache durations help enormously on busy sites — only the first visitor in the window pays the full latency, everyone after gets the cached response. Important: invalidate deliberately on releases, and do not append pointless query parameters that turn every request into a cache miss.

Avoid redirects. Redirects are a common TTFB killer because each one costs a complete extra round trip (source: web.dev, accessed 2026-06-06). Check especially the same-origin redirects you control yourself. An HSTS header eliminates the HTTP-to-HTTPS redirect; with HSTS preload you save it even on the very first visit.

Reduce server work. Faster database queries, less synchronous backend work per request, streaming the markup instead of waiting for the finished document. And with 103 Early Hints the server can tell the browser, while the backend is still processing, which critical resources to download in parallel.

The critical rendering path — from byte to pixel

Once the first byte arrives, the browser takes over. The critical rendering path is the sequence of steps it runs to turn raw code into a visible image. The order is fixed:

  1. HTML → DOM. The browser parses the incoming HTML and builds the Document Object Model from it — the tree structure of all elements.
  2. CSS → CSSOM. In parallel it parses the CSS and builds the CSS Object Model — the tree structure of all style rules.
  3. Render tree. DOM and CSSOM are merged into a render tree that contains only the visible elements with their computed styles.
  4. Layout (also reflow). The browser calculates the exact position and size of every element on the page.
  5. Paint. The calculated pixels are actually painted to the screen.

Only after step 5 does the user see anything. The key point: this chain can stall at several places — reproducibly, because certain resources block the path.

What blocks the path — render-blocking CSS and JS

Two resource types hold up the render path:

Render-blocking CSS. CSS is render-blocking by default. The browser has to have built the entire CSSOM before it can form the render tree and paint anything at all — otherwise it would show an unstyled layout and then flash to the styled one. So every external stylesheet in the <head> delays the first paint until it is fully loaded and parsed. Large CSS files or many separate stylesheet requests are the typical bottleneck here. See also render-blocking resources.

Synchronous JavaScript. When the HTML parser hits a <script> without an async or defer attribute, it stops. It has to download, parse and execute the script before continuing with the HTML — because the script could modify the DOM. A single synchronous script high in the <head> can hold up DOM construction for hundreds of milliseconds.

Levers for the critical rendering path

The goal: as few resources as possible block the first paint, and the ones that are necessary arrive as early as possible.

Inline critical CSS. Embed the CSS needed for the visible area (above the fold) directly into the HTML. That way the browser does not have to wait for an external request to make the first paint. The rest of the CSS loads asynchronously.

Defer or async your JavaScript. defer loads the script in the background and runs it only once the HTML is fully parsed — the parser runs through without interruption. async also loads in parallel but executes as soon as the script is ready (order not guaranteed). For most scripts that are not needed immediately, defer is the safe choice.

Minimise critical resources. Fewer and smaller blocking files. Remove unused CSS, bundle stylesheets instead of loading twelve separately, preload fonts instead of discovering them late.

Prioritise resources. Use preload, preconnect and fetchpriority to tell the browser early what is important — so the LCP image or critical font does not sit in the queue behind unimportant requests.

How these levers play out in a concrete audit is shown by PageSpeed Insights — render-blocking resources appear there as an explicit recommendation.

How the two halves work together

TTFB and the critical rendering path are not separate worlds but two legs of the same run. TTFB decides when the browser can start working. The critical rendering path decides how fast it builds an image from the material. Optimise only one half and the other stays the bottleneck.

A practical image: TTFB is the time until the parcel rings the recipient’s doorbell. The critical rendering path is the time from the doorbell ringing until the parcel is unpacked and assembled. Together they make up what the user experiences as “the page is loading” — and together they decide the LCP that Google scores in the Core Web Vitals.

FAQ

Is TTFB itself a Core Web Vitals value?

No. The three Core Web Vitals are LCP, INP and CLS — TTFB is none of them. But TTFB is the precursor that caps LCP from below: a TTFB of 1.5 seconds makes an LCP under 1.5 seconds mathematically impossible. That is why TTFB shows up as a diagnostic value in every serious performance audit.

What TTFB value is good?

As a guideline, 0.8 seconds (800 ms) or less at the 75th percentile. Above 1.8 seconds counts as poor, in between as needing improvement (source: web.dev, accessed 2026-06-06). That is an orientation, not a hard limit — but the lower it is, the more headroom you have in the rest of the load.

What is the difference between async and defer on scripts?

Both load the script in parallel with HTML parsing and do not block the parser during download. The difference is execution: defer waits until the HTML is fully parsed and runs scripts in document order. async executes as soon as the script is loaded — regardless of how far the parser has got and without guaranteed order. For dependent scripts, defer is the safe choice.

Why does CSS block rendering even though it only affects appearance?

Because the browser does not want to show an unstyled layout and then flash to the styled one afterwards. It needs to know the complete CSSOM to build the render tree correctly — otherwise the first paint would be wrong and would have to be repainted. So it waits until the render-blocking CSS is fully there. The fix is not to remove CSS but to inline the critical CSS and load the rest asynchronously.

Does a CDN always improve TTFB?

Not necessarily. A CDN mainly helps with connection and DNS latency and with a geographically distributed audience. If your TTFB is instead dominated by slow server processing — say heavy database queries per request — a CDN will not solve that. So the rule is: first look in the network tab to see which phase dominates, then pick the matching lever.

Themenuebersicht

Technisches SEOCore Web VitalsPageSpeed & Performance