Hosting & uptime

What your host is responsible for, and what your site is

A slow website has two possible causes, and from the outside they feel identical. One is fixed by changing your hosting; the other is not, and a bigger server will not touch it.

Two problems that feel identical

Your pages take too long, some visitors leave before anything appears, and nothing in your inbox tells you who. There are two separate reasons that happens. Either your server is slow to answer at all, or it answers quickly and the page then asks the browser to fetch a great deal more. The first is your host's. The second follows you to any host you move to.

Buyers usually pay for the wrong one. A hosting upgrade is easy to sell and easy to buy, and it does nothing for a homepage carrying two megabytes of uncompressed photographs. The reverse happens too: a week spent trimming JavaScript on a server that needs four seconds to send the first byte. The audit keeps the two apart by measuring them apart.

What the server itself is measured on

The first measurement is how long your server takes to answer one plain request. Over 0.5 seconds is noted, over 2 seconds is raised as a warning, over 5 seconds as critical. The hosting section adds its own line at 1,500 ms, with the two fixes the code actually names: work on the backend, or put a CDN in front. Both of those are your host's territory.

The clock starts before the request and stops when the whole HTML document has arrived, redirects included, so it is a larger figure than a pure time-to-first-byte, and a redirect chain shows up inside it. Google's 800 ms threshold describes something else again: the time-to-first-byte real Chrome users recorded, which the audit reads from Google's field data rather than from our own request. Compression and caching headers come from that same response, and both are settings on the server rather than changes to your website.

Ten requests at once

Idle latency flatters a cheap server, so the hosting check sends ten requests at the same moment and records how many came back, the average time under that load, and the slow tail at the 95th percentile. Fewer than ten successes is a warning about capacity. Ten successes with an average over 2,000 ms is recorded as informational: everyone was answered, slowly.

Ten simultaneous requests is not a stress test and is not described as one. It is the smallest number that separates quick when nobody is looking from quick when two people arrive together. The comparison is the useful part. A single request back in 300 ms and a concurrent average of 3,000 ms is a server running out of room, not a heavy page. The test counts any reply below a 500 status as a success, because it is asking whether the server answered, not whether the page was correct.

Uptime, and what three requests can honestly say

The availability figure in the report comes from three requests taken a fifth of a second apart. It raises no finding in either direction; it is recorded and shown. Three requests in one moment cannot tell you whether your site was down at four on Sunday morning. Uptime is a claim that only continuous monitoring earns, and this engine does not monitor, so it does not make the claim.

Five hosting questions that matter cannot be answered from outside: whether backups run and have ever been restored, whether deploys go through a pipeline, whether staging is separate from production, whether anything logs and alerts, and whether the bill is watched. They are printed as a checklist under not assessed remotely. They used to be raised as findings on every audit, which meant faultless infrastructure could never score 100, and five items nobody had looked at padded the issue count on the front of the report.

DNS, and the lookup that did not happen

Every visit begins with a DNS lookup, and the audit makes about fifteen of its own. Each is asked over ordinary DNS first, with a six-second limit, then over DNS-over-HTTPS if that fails — because plenty of consumer connections quietly intercept or drop port 53, including the one this tool was written on, where google.com's TXT record times out over UDP and resolves instantly over HTTPS.

When both transports fail, the record is reported as unmeasured with that reason, never as missing. That rule runs through the whole engine, and it was learned here: an unanswered lookup used to produce four confident findings telling a stranger their email authentication was broken, when it was our connection that had failed. The DNS finding this page owns is DNSSEC, raised as informational when no DNSKEY record exists. Without signed answers a poisoned resolver can send your visitors to someone else's server, and the padlock still appears, because the certificate belongs to whatever answered.

What the engine checks here

Each of these is a rule in the code, not a category heading.

Time to answer, measured from outside your networkOver 0.5 seconds is noted, over 2 seconds is a warning, over 5 seconds is critical. The hosting section applies a separate warning above 1,500 ms, recommending backend work or a CDN. The clock covers the whole HTML document and any redirects, so it is a larger number than time-to-first-byte alone.
Ten concurrent requestsTen requests fired at the same moment, each with a 15-second timeout. Successes, the average and the 95th percentile under load are all recorded. Fewer than ten successes is a warning about capacity; ten successes averaging over 2,000 ms is informational. Any reply below a 500 status counts as an answer, because this measures whether the server coped, not whether the page was right.
Compression on the HTMLContent-Encoding read from the response: gzip, Brotli or deflate. Nothing there is a warning. It is a server setting, so it is fixed where your site is hosted rather than in the site itself.
Caching instructions and a validatorCache-Control and Expires: neither present is a warning, and a policy of no-cache or no-store is a warning in its own right. ETag and Last-Modified are checked separately; neither present is informational, because without one a returning visitor cannot be sent a 304 Not Modified and downloads the whole page again.
Who is answering on your behalfThe provider is read from response headers alone — cf-ray for Cloudflare, x-vercel, cloudfront, x-amz, fastly, akamai, netlify, github.io — along with the Server and X-Powered-By values. A CDN is only recorded as present for Cloudflare, CloudFront, Fastly, Akamai, Vercel or Netlify. Nginx and Apache are named too, but they are web servers, not CDNs, and are not counted as one.
Whether static files come from a CDNA separate question, answered from the addresses your page loads rather than from your headers, so a site behind Cloudflare can still show no CDN for its assets. None found is informational, the lightest severity. It is a string match on the URL, so a self-hosted file named jquery.min.js can satisfy it — one reason this finding is never raised above informational.
Cookie weight and connection reuseThe Set-Cookie header is measured: over 4,096 bytes is a warning, over 1,024 bytes informational, because the browser sends cookies back with every subsequent request. Connection: close is recorded as informational, since it makes the browser open a fresh connection for each file.
DNS resolution and DNSSECRecords are asked for over ordinary DNS with a six-second limit, then over DNS-over-HTTPS if that fails; once the resolver has proved unresponsive the remaining lookups go straight to HTTPS instead of each waiting out its own timeout. A record neither transport could reach is reported as unmeasured with the reason, not as absent. No DNSKEY record is raised as informational.

Questions

My developer says it is the host and my host says it is the site. Which is it?

The report gives you the numbers that settle it: how long a single request took, how long ten concurrent requests took on average, and how much the page weighs. A quick single request with a slow concurrent average points at capacity on the server. A single request that stays quick under load, on a large page with a long list of render-blocking files, points at the website. Both can be true at once, and when they are, both are listed.

Will a more expensive hosting plan make my site faster?

Sometimes, and the measurements say when. If the server is slow to answer one plain request, or fails when ten arrive together, that is exactly what a better plan buys. If it answers in a couple of hundred milliseconds and the page is still slow, a bigger plan changes nothing, because the wait is in what the page asks the browser to fetch afterwards. Compression and caching headers sit in between: server settings, usually free to switch on, and often the cheapest improvement in the whole report.

Can you tell me my uptime percentage?

No, and the report does not pretend to. The availability figure comes from three requests taken moments apart during the audit, and it raises no finding either way. A real uptime figure needs something checking your site continuously for weeks, which is monitoring rather than an audit. If you want that, it is separate work, and we would rather say so than hand you a number we did not measure.

Sources

Public and checkable. Nothing here rests on a number we cannot point at.

This is one of fifteen categories. You can read a real report this engine produced on this very site — including the findings it raised against us — or ask for an audit of yours.