What's a good TTFB target?

Under 200ms is considered good for most sites, 200-500ms needs improvement, and anything over 500ms is a genuine problem. Unlike LCP or CLS it isn't an official Core Web Vital, but it's a hard floor underneath all three - nothing downstream can start until the first byte arrives.

Does a CDN fix TTFB even for dynamic pages?

Only partially. A CDN speeds up static assets and can cache full HTML responses for pages that don't change per-request, but a genuinely dynamic page (personalized content, live data) still has to hit your origin - for that, the fix is server-side (query speed, function cold starts, region placement), not caching.

Why is TTFB slow on my very first request after a deploy but fast after that?

That's almost always a cold start on serverless infrastructure - the function has to initialize before it can handle the request. Subsequent requests hit a warm instance. If your traffic pattern is bursty, cold starts can matter more than your average TTFB suggests.

Does Scanverra measure TTFB separately from LCP?

Yes. It's a distinct metric captured in the same Lighthouse pass used for LCP and CLS, so you can tell whether a slow LCP is actually a slow-server problem in disguise or a genuinely separate rendering issue.

How to Fix Slow Time to First Byte (TTFB)

Why Your Server Is Slow to Respond

TTFB is almost entirely a backend and network problem, not a frontend one. Common causes:

Cold starts. Serverless functions that have to spin up an execution environment before handling the first request in a while.
Uncached dynamic rendering. Every request re-running database queries and server-side rendering that could have been cached or computed once.
Slow database queries. A single unindexed query or an N+1 pattern can add hundreds of milliseconds before the server can even start writing a response.
Long physical distance to origin. A visitor in Singapore hitting a server in Virginia pays for that round trip on every request, regardless of how fast the server itself responds.
Redirect chains. Each hop (http → https → www → final URL) is a full round trip before the real response even starts.

How to Identify What's Actually Slow

Scanverra's performance checks capture TTFB as part of the same Lighthouse run used for LCP and CLS, against your live URL - so you get the real server-response-time number, not a proxy for it. That matters because a slow LCP with a fast TTFB points you toward image/render fixes, while a slow LCP with a slow TTFB means fixing the server has to come first.

To narrow down where the time is actually going, check your hosting or APM provider's server-side timing breakdown (most platforms report time spent in function init, database calls, and response serialization separately) rather than guessing from the outside.

How to Fix It

1. Cache what doesn't need to be regenerated per-request

Anything that's the same for every visitor - or every visitor in a given segment - is a caching candidate. Set an explicit cache lifetime at the CDN edge instead of letting every request hit your origin:

Cache at the edge, but revalidate in the background so content doesn't go staletypescript

1Cache-Control: public, max-age=60, stale-while-revalidate=300

2. Put your origin (or at least a cache layer) close to your users

Deploy to a region near your actual traffic, or front a distant origin with an edge cache/CDN so most requests never make the long round trip at all.

3. Fix the slow query, not the symptom

If your APM shows database time dominating TTFB, that's usually a missing index, an N+1 query pattern, or a query doing more work than the page actually needs - profile the specific query before reaching for caching as a workaround.

4. Reduce cold-start frequency on serverless functions

Keep functions warm for latency-sensitive routes, minimize the code and dependencies that have to initialize before the handler runs, and consider a persistent server for traffic patterns where cold starts happen constantly.

5. Collapse redirect chains

Every hop between the URL a user requests and the URL that actually serves content is a full round trip added to TTFB before rendering can start - point links and canonical URLs directly at the final destination.

How Scanverra Detects TTFB Issues

TTFB is captured directly from the same real Lighthouse pass Scanverra runs for every performance check - on both a desktop profile and a 375px mobile viewport - so it's measured against your actual live server response, not simulated.