Slow first response

Why the first response matters

Everything else on a page waits for the HTML. The browser cannot discover the stylesheet, the images or the scripts until the document has started to arrive, so a slow server delays the entire page, and on a phone connection the delay is larger. Slow servers can also reduce how often a crawler is willing to visit.

Slowness at launch often comes from something that was fine during building. A page that runs database queries on every request, a hosting plan that sleeps idle sites, a heavy theme with many plugins, or a server far from your visitors all show up here. A cold start on a serverless host can add a second on its own, which is why a single measurement can be misleading.

How Skewcheck detects it

Skewcheck times its own single request for the page, from sending the request to having received the whole HTML document, including any redirects it followed. If that takes 1500 milliseconds or less, the check passes. If it takes longer, the check warns with medium severity and removes 6 points from the score. It is a warning, not a failure, because one measurement from one place is only a hint.

Be clear about what this number is not. It is one request made from Skewcheck's servers, not a field measurement of real visitors, and it does not include images, scripts, fonts or rendering, so it is not a Core Web Vitals score. Run the check again if the result looks off, since a slow first hit on a cold host is often followed by a fast second. A consistently slow result across several runs is a real signal.

for i in 1 2 3; do curl -s -o /dev/null -w '%{time_total}s\n' https://example.com/; done

Bringing it under the budget

The biggest win is usually caching the HTML so it does not have to be built for every request. Static and statically generated pages served from a CDN typically answer in a fraction of the time. On a platform like WordPress, a page-caching plugin or the host's built-in cache does this. On Next.js, prefer static rendering for pages that do not change per visitor. On Webflow and Framer, pages are served from the platform's CDN, so a slow result usually points at something in front of the site, such as a proxy or a redirect chain, rather than the site itself.

If the page must be generated per request, look at what it waits for: slow database queries, calls to other services made one after another, or a server in a distant region. Remove redirect hops, since each one costs a full round trip. After the change, compare several measurements from before and after rather than a single run.

Before and after

The document took 2840 ms to arrive, over the 1500 ms budget.

The document arrived in 210 ms.