What a slow first byte costs you

Open the network tab on a page that "feels slow" and the first thing worth looking at is rarely the
JavaScript bundle or the image sizes. It's the gap between the request going out and the first byte
of the response coming back. On a healthy server that gap is a few dozen milliseconds. On a lot of
sites it sits well past a full second, and everything downstream, rendering, hydration, paint,
inherits that delay before a single pixel has been drawn. Time to first byte gets treated as a
footnote in most performance audits. It shouldn't be. It's the one number that a crawler pays for
directly, out of a budget that isn't unlimited.

Crawl budget is a time budget, not a page count

Googlebot allocates a finite amount of time to a site per crawl session, not a finite number of
URLs. That distinction matters more than most technical SEO checklists let on. A site with fast
responses gets more pages crawled per session simply because each fetch finishes quickly and the
crawler moves to the next URL. A site with a slow origin burns the same time budget on fewer pages,
because every request sits there waiting on TTFB before the crawler has read a single tag of HTML.

This shows up clearly in server logs once you cross-reference Googlebot's user agent against
response times. Pages behind slow endpoints get crawled less often, and new pages behind a slow
section of the site take longer to get picked up at all, not because they're unimportant, but
because the crawler ran out of time budget before it reached them. A publishing site adding
category or tag pages behind a database-driven archive view will often see exactly this pattern:
the new URLs exist, they're linked internally, and they still take weeks to show up in the index,
because every fetch into that section of the site costs the crawler more time than a fetch anywhere
else.

TTFB is upstream of Largest Contentful Paint

Largest Contentful Paint measures when the biggest visible element finishes rendering, and it feeds
directly into Core Web Vitals, which sits inside the ranking systems Google has described as using
page experience signals. TTFB is not LCP, but it's the floor LCP is built on: nothing the browser
does to render content can start until the first byte of the document arrives. A page with a
lightweight hero image and clean CSS can still post a bad LCP score if the server takes 1.8 seconds
to respond, because that 1.8 seconds happens before the browser has anything to paint at all. Teams
that spend weeks compressing images and deferring scripts while ignoring a slow origin are
optimizing the smaller half of the number.

Where the time actually goes

Profiling a slow origin usually turns up one of three patterns, and none of them involve caching.

An unindexed query is the most common. A page that joins a few tables to build a listing runs fine
in development against a few hundred rows and turns into a multi-second query in production against
a few hundred thousand. EXPLAIN on the query usually shows a full table scan where an index would
have turned it into a lookup. Nobody notices until the table grows.

A synchronous third-party call is the second. A page fetching stock levels, shipping rates, or a
loyalty balance from an external API on every request is only as fast as that API's slowest
response, and that response happens inline, before the server can send anything back. When the
third party has a bad day, so does every page that calls it.

The third is a CMS or framework doing work on every request that belongs at build time. Rendering a
page from a template and a set of content blocks on each hit, recomputing the same navigation tree
or the same related-posts query for every visitor, is expensive in a way that never shows up in a
local dev environment where traffic is one person clicking around. Under real load, that per-request
computation is what an SEO audit built around server response time
tends to surface first, well before it gets anywhere near meta tags or heading structure.

What this looks like from a waterfall

A slow TTFB rarely arrives with a label attached. It shows up as a long blank bar at the start of a
waterfall, before any of the labeled phases begin. The instinct is to look at what comes after that
bar, because that's where the named metrics live. The more useful instinct is to ask what the server
was doing during it: which query ran, which API got called, which computation happened that
shouldn't have needed to happen at all. That's a database and application question before it's a
frontend one, and treating it as one is usually what gets the number down.

Written by the team at Nooralto, a web and SEO studio based in Agadir and Paris.