Slow server response: how to fix TTFB

What it means

Slow server response means the server takes too long to return the initial HTML document after receiving a request. Google calls this server response time — the gap between when the browser sends a request and when it receives the first byte of the response.

Why it matters

A slow server response pushes back Largest Contentful Paint, which is one of Google's Core Web Vitals and a direct ranking input. It also slows Googlebot's crawl rate, meaning new or updated pages get discovered and indexed less frequently. For AI agents that parse HTML directly, a delayed response wastes budget and can cause timeouts on pages with many resources.

How to fix it

1. Enable compression (gzip or brotli) and verify Content-Encoding headers are set.
2. Move rendering to the edge or CDN so the first byte travels a shorter distance.
3. Pre-render or cache pages server-side (SSR/SSG) instead of computing HTML on every request.
4. Audit third-party scripts that block the main thread during initial render and defer or lazy-load them.

Example

GET /product/123
Time to first byte: 4,200 ms   # server does 6 uncached DB queries per request

GET /product/123
Time to first byte: 240 ms     # response cached at the edge / query results memoized

TTFB is server think-time plus network. Cache rendered pages or query results, add DB indexes, and put a CDN in front so repeat requests skip the origin.

When it's not a problem

Slow server response is less concerning if the page content is already cached and the HTML is small enough that the delay doesn't push LCP past 2.5 seconds. If the crawl budget is large relative to page count, a slightly slower server won't materially affect indexing frequency.

How Crawlinx detects it

We record the elapsed time to receive the response for each crawled URL. When it exceeds 3000 ms the page is flagged as a slow server response; the finding shows the measured milliseconds.

How common is it?

3026 audited sites in our corpus currently show this issue. The breakdowns below show which platforms, gatekeepers, verticals and countries are most exposed.

FAQ

What's a good TTFB?

Aim under 800 ms, ideally under 200 ms for cached pages. Google treats server response time as a Core Web Vitals input because it front-loads every other metric.

Is a slow response a page bug or a server bug?

Almost always server-side: uncached database work, N+1 queries, slow upstream APIs, or cold serverless starts. The HTML itself rarely causes high TTFB.

Why is only one page slow?

Usually that route does uncached, per-request work others don't — a heavy search, a personalized query, or an external API call. Cache or precompute that specific response.

Related guides

• Core Web Vitals: LCP, INP and CLS Explained (2026)
• Core Web Vitals in a Crawler: What Lab Data Shows
• Crawl Budget: What It Is and How to Manage It
• WordPress SEO: The Technical Defaults That Cost You