Is your website actually any good?

The SEO audit looks at how search engines see your page — titles, tags, structure and markup. This quality check looks at how the page actually performs for a human visitor: how quickly the server responds, how heavy the page is, whether compression and caching are enabled, whether HTTPS and the protective security headers are set, and whether it is genuinely usable on a phone. Most sites need both.

Under 400 ms to first byte is good, 400–900 ms is workable, and anything over 900 ms is a real problem. Slow first-byte times are almost always one of three things: the server is physically far from your visitors, database queries are slow, or there is no caching layer. Hosting in the same region as your customers usually fixes the first one outright.

They are instructions your server sends to the browser about how to protect your visitors. HSTS forces HTTPS on every future visit. Content-Security-Policy limits where scripts may load from, which is the strongest defence against injected code. The others prevent clickjacking, MIME-type confusion and referrer leakage. They cost nothing to add and most sites have none of them.

Yes, especially in India where a large share of traffic is on mobile data. Heavy HTML delays the first paint, and every extra hundred kilobytes is measurable in bounce rate. The usual culprits are inline styles, uncompressed markup, and scripts loaded in the head that block rendering.

Not directly, and we will not pretend otherwise. Core Web Vitals (LCP, INP, CLS) need a real browser rendering the page and, for field data, actual Chrome user measurements. What this tool measures is server response time, page weight, compression, caching and render-blocking scripts — the server-side inputs that largely determine those scores. For lab Core Web Vitals, run PageSpeed Insights alongside this.