The fix, in one snippet
curl -s -o /dev/null -w 'ttfb %{time_starttransfer}s\n' https://example.com/Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
We record the time from request to complete response for every crawled page and report those over 800 ms, along with the median across the crawl. The figure includes DNS, connection, TLS and the server's own processing, measured from our network rather than from a browser.
Treat it as a sample from one location, not a benchmark. What it is good for is comparison: one page far slower than the median points at something specific.
Why it matters
Server response time is the floor under every other performance metric. Nothing can render before the HTML arrives, so a slow Time to First Byte pushes Largest Contentful Paint out by the same amount no matter how well the front end is built.
It also governs crawl rate. Google adjusts how fast it crawls based on how fast the server answers and whether errors appear under load; a slow site is crawled more slowly, which delays indexing of everything new.
Most of the time the cause is a small number of pathological pages rather than the platform: an unindexed query on a listing page, an N+1 in a template, an external API called synchronously during render.
How to fix it
Start with the slowest pages in the evidence rather than with the average. Measure server-side to separate application time from network time:
curl -s -o /dev/null -w 'dns %{time_namelookup}s connect %{time_connect}s ttfb %{time_starttransfer}s\n' \
https://example.com/slow-pageThen look for the usual causes in order: missing database indexes, queries inside a loop, uncached external calls, and template work repeated per item. Cache the expensive fragments rather than the whole page where personalisation prevents full-page caching, and put a CDN in front of anything that is the same for everyone.
Where this fits
Slow server response is check 4 of 7 that the seo & site health audit runs under technical seo and speed, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Render-blocking scripts in the head (medium), where synchronous scripts in the head stop the parser. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Slow server response closes one route in. Immediately below it: http:// references on HTTPS pages, where links from an HTTPS page to http:// URLs cost a redirect on every click and expose the first request; Language attribute missing, where the lang attribute on <html> tells screen readers which pronunciation to use and search engines which language to file the page under; No cache policy on HTML, where hTML with no cache policy is re-downloaded in full on every visit, including every back-button navigation.
Found in the same scan
The seo & site health audit reports this alongside checks from other categories that are at least as serious, including Broken internal links, where an internal link that returns an error is a dead end for the reader and a wasted request for the crawler, and Crawl errors (4xx / 5xx), where uRLs reached during the crawl that returned a client or server error. A single run of seo & site health audit answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Slow server response (medium severity)
Scanner check id: seo-response-timeThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.