← Back to SEO LearnNOTABIS SEO / LEARN

Performance · 9 September 2026

Slow Server Responses: How to Investigate Response Time

A slow response finding means the measured request took more than two seconds in that audit. Investigate server work, database calls, caching, network path, and load before choosing a fix.

Quick answer

A slow response is a clue that the server or delivery path took too long to return the requested response. NOTABIS flags a measured response above two seconds, but one crawl measurement is not a complete performance profile. Reproduce the issue, separate server time from network and browser work, and investigate the slowest shared path first.

What the issue means

Response time includes several stages: connection setup, TLS, queueing, server processing, database or API work, and transfer. An audit commonly measures the time from making the HTTP request until the response is available to the crawler. It does not equal a browser’s Largest Contentful Paint or total page load time.

Why it matters for SEO

Slow responses can make crawling and user access less efficient, especially when they affect many URLs or occur during peak load. They can also delay the delivery of the HTML needed for rendering. The finding is not a direct ranking penalty and should be interpreted with real user and server data.

How NOTABIS detects it

The slow-response-review rule records an issue when the measured response time exceeds 2,000 milliseconds. The report includes the audit measurement. Results can vary with origin load, cache state, geography, network conditions, and crawler timing.

How to check it yourself

Measure the same URL repeatedly and inspect timing breakdowns in browser developer tools or a trusted monitoring system. Use server access logs and application traces to find database queries, upstream calls, queueing, or cold-start work. Compare cached and uncached responses where safe.

How to fix it

Start with the shared cause: optimise expensive queries, remove unnecessary upstream calls, cache safe repeat requests, and reduce application work before response generation. Check connection pooling, CDN configuration, and origin capacity. Avoid hiding a slow origin by increasing timeouts; that can make failures harder to see.

Verify with repeated measurements from representative locations and under realistic load. Recheck correctness, cache invalidation, and authenticated or personalised routes separately.

When it is intentional or does not need fixing

A one-off slow response may be transient. Reports, exports, search pages, and deliberately expensive operations may have different budgets from normal landing pages. Private routes should not be made publicly cacheable just to improve a crawler measurement.

Related issues

Compare HTTP compression, large HTML responses, and cache policy.

Run a NOTABIS audit

NOTABIS helps surface slow responses across crawled URLs so you can look for shared infrastructure or template patterns rather than treating one measurement as a diagnosis.

Measure before you change

See which issues affect your site.
Run a NOTABIS audit ↗