xSpeed Scan: Free Website Speed Test

xSpeed Scan is the free public speed test at xspeedcache.com/scan. One URL in, a graded report out: no signup, works on any website, and every report keeps its link so you can share it or come back after a fix and prove the difference.

What a scan measures

Every scan combines two evidence sources:

1. Server probes, run from xspeedcache.com: time to first byte (best of two live requests), the redirect chain, HTML compression, cache behavior read off the response headers, and platform detection.
2. Google PageSpeed Insights (Lighthouse), desktop and mobile. Core Web Vitals lab metrics (LCP, CLS, TBT), the performance score, and asset audits, from two parallel runs. The headline grade is the desktop run — the one you can reproduce in your own browser, and every report links the same run on Google’s PageSpeed Insights so you can. The mobile run is graded on the same rubric and shown by the Desktop / Mobile toggle at the top of the report; Google ranks on mobile, so check both. If Google’s API is briefly down, the scan still completes on probe evidence and says so.

The checks roll up into four dimensions: Lab performance (Lighthouse), Server response & caching, Asset optimization, and Platform readiness, each weighted into one 0–100 score with a letter grade (A+ to F) and a level name.

Lab data and real visitors

The grade is lab data: one Lighthouse run per device. Google ranks on something else, the Core Web Vitals real Chrome users recorded over the last 28 days (the Chrome UX Report). Every report shows both. Under the lab tiles, a Real visitors strip gives the 75th-percentile LCP, INP and CLS for that device, says whether they pass Core Web Vitals, and says whether the numbers are for the page itself or for the whole site (a page with little traffic of its own falls back to its site). When the lab run passes LCP and real visitors do not, the report says so in one line. A site with too little Chrome traffic has no field data, and the report says that too.

The field data does not change the grade. It is shown beside it so a green lab score is never read as a Core Web Vitals pass.

How “served from cache” is judged

The cache check grades an outcome, not a product: was this HTML rendered for this request, or was it ready before the visitor arrived? The same rule applies to every stack, so scores stay comparable:

• Pass — a cache hit in the response headers (any host’s own header, Cloudflare, LiteSpeed, xSpeed, Vercel’s x-vercel-cache, the standard Cache-Status that Netlify sends, or a non-zero Age), or the HTML served as a file by the web server. A pre-built page (Astro, Hugo, Jekyll, a Vite single-page app) and a WordPress page cache that nginx answers directly both count: nothing was rendered, which is exactly what a cache hit proves. The file evidence is the web server’s own — Last-Modified plus the ETag a file server builds from the file’s date and size — and is not credited when a session cookie or a PHP header shows a process ran.
• Partial — a caching plugin is installed but this request missed it.
• Fail — the page was rendered for this request with nothing in front of it. A WordPress site with no page cache and a Next.js or Nuxt route rendering on the server both land here.
• Not graded — a page correctly marked Cache-Control: private or no-store (a cart, an account page) must not be shared-cached, so the check leaves the score’s denominator instead of penalising it.

A static site on a slow or distant host still loses points on time to first byte: this rule only stops charging it for a cache it has nothing to put in.

How compression is judged

The scan fetches the HTML twice more, once asking for gzip and once for Brotli, and compares the bytes that actually cross the wire. gzip and Brotli both pass. A page loses half the points only when the encoding it serves is more than 10% (and more than 1.4KB) bigger than the one its own server can produce, which is the same line Lighthouse draws. The common cause is Brotli compressed on the fly at a low level: on some sites it comes out bigger than their gzip. An uncompressed page fails.

How the CDN check is judged

A CDN earns its bonus points when its edge answered the page, read from the edge’s own header (cf-cache-status: HIT on Cloudflare, x-cache: HIT on Fastly, and so on). A CDN that passes every page through to your server (cf-cache-status: DYNAMIC) is named in the report with the fix, but earns nothing, because only your images, CSS and JavaScript are being served from the edge. The check is a bonus and never lowers a score; a serving edge also shows up as a faster first byte and a cache hit.

How page weight is judged

Full marks go to pages up to 350KB. From there the credit steps down: two thirds up to 1MB, one third up to 1.5MB, none above. The line comes from our own reports: across 1,119 WordPress pages, 15.5% of those under 250KB failed mobile LCP, against 68% at 250–350KB and 83–87% from 350KB to 1MB. The old single line at 1.5MB passed pages that failed mobile LCP 78% of the time.

Every failing check names its fix

This is the part other speed tests skip. A failing check doesn’t just say what’s wrong. It names the exact xSpeed feature that automates the fix (Free or Pro), links the official guideline the rule comes from, and includes a ready-to-paste AI prompt. The “Top fixes” list ranks them by points recovered, so you always know what to do first.

Each fix is either Free or Pro, never both. Where Pro adds something on top of a Free fix (Critical CSS for a slow LCP, image conversion for a heavy page), the report shows it as a second, separate Pro line with the points it could recover. The JSON shape is in Scan MCP.

The report knows what your site runs

Reports walk a detection ladder and tailor their instructions to where your site already is:

• WordPress → detected from the page itself.
• xSpeed Cache → detected from the cache signature (with version and Pro edition) or the plugin’s public signals route.
• MCP server → whether the site’s own xSpeed MCP endpoint answers, so your AI assistant can apply fixes directly.
• xSpeed Hub → whether the site is attached to xSpeed Hub for fleet-wide AI management.

A WordPress site without xSpeed gets install-first instructions. A site with xSpeed but no MCP connection gets the connect step. A site with MCP live gets a one-prompt fix plan. And a non-WordPress site. Astro, Next.js, Lovable, Shopify, and more are detected: gets a fix plan for its own stack, never a WordPress plugin pitch.

Reports also consider hosting: a slow origin (high TTFB) triggers a hosting recommendation, because a cache is only as fast as the server behind a MISS.

Screenshots, history, and sharing

• Two graded views: the Desktop / Mobile toggle re-grades the whole report — score, dimensions, top fixes and every check — on that device’s run, with both letters shown up front.
• Screenshots of the page as Lighthouse saw it, desktop and mobile, with click-to-enlarge.
• Past scans of this domain: every report lists the domain’s earlier reports with date, score, grade and links, so trends are visible at a glance.
• Share tools: a copy link, social buttons, and a downloadable score card image.
• All public scans lists every site’s latest report.

The scan page shows three shelves. Featured is a curated set, recomputed from each site’s latest scan and held to B or better on the same rubric everyone else gets, a site that slips below B leaves the shelf on its next scan. Improved after scanning is real re-scans of any site that measurably got faster, compared only where both dates used the same rubric. Recently scanned is the newest public report per site.

When we can’t reach your site

Some sites sit behind a bot-protection interstitial. When our scanner hits one, what gets measured is Cloudflare’s “Just a moment…” page, about 5KB of challenge script and none of your content. That page scores well, because an almost-empty document loads fast, so the result looks plausible and is completely meaningless.

Those scans now say so at the top of the report and are not published to the public directory, on the same principle as a run that lost Lighthouse: we do not publish a number we cannot stand behind. Allow the scanner through. Its requests come from xspeedcache.com and identify themselves, and scan again.

Platform playbooks

Generic speed advice is wrong on some stacks, so where we detect one we know well, the report carries guidance written for it instead.

Astro (10 sites), Nuxt (9) and Shopify (5) each get one too. The Astro and Nuxt playbooks lead with the thing that decides most of the time on those stacks: how eagerly islands hydrate, and which routes are prerendered rather than rendered per visit. The Shopify one says plainly that TTFB is Shopify’s number and not worth chasing, and points at the apps instead.

Next.js, 83 of the sites scanned so far. Most of what makes a Next.js site slow is decided at build time, so the playbook leads with the rendering mode per route and what ends up in the client bundle. It reads x-nextjs-cache off your response and tells you whether that page was served from the render cache or built for that request: the single most useful fact about a Next.js site’s speed, and it costs nothing to look up.

Lovable. Lovable apps run as dynamically-loaded Cloudflare Workers, and the platform rewrites Cache-Control after your code returns, so the usual “set caching headers” advice is not merely unhelpful, it cannot work. The playbook says that plainly and points at the fixes that do work, which live inside the application and differ between Lovable’s two stacks.

Two things in it are measured on your actual scan rather than assumed:

• Which edge fingerprint your site shows: served from the platform edge with no-cache, or a Cloudflare zone answering DYNAMIC.
• How much text a crawler really reads from your HTML, with <script> and <style> contents stripped first. That matters: strip tags alone and inline JSON-LD and analytics config get counted as readable copy, which can more than double the number and make a blank page look full.

What the playbook deliberately does not do is guess which of Lovable’s two stacks you are on. Response headers are identical across both, so that needs the repo, the playbook tells you how to check rather than pretending to know.

Paste the report’s .md URL into your AI builder’s chat and it can work straight from these measurements.

If a scan is interrupted

Scans run on a bounded queue: a few measure at a time, the rest wait their turn, and the page tells you which. A scan is recorded the moment it is accepted, not when it finishes, so a deploy or a restart in the middle of your scan does not lose it: it is picked up again afterwards under the same report URL, and the link you already have keeps working.

If PageSpeed Insights itself fails, the result is not published, a score measured on a partial rubric is not a score we will stand behind. The scan is queued for another attempt instead, backing off over the next half hour, and the report page says what happened in the meantime.

For AI agents: the machine-readable twin

Every report has a Markdown twin at /scan/r/{id}.md (or request the report URL with Accept: text/markdown). It carries the full check list with evidence, remediations, prompts and guideline links, plus state-aware instructions for acting on the report. An AI assistant can read it and go to work.

You can also run scans programmatically:

• REST: POST https://xspeedcache.com/api/scan with {"url": "https://example.com"}, then poll GET /api/scan/{scanId}.
• MCP: the run_speed_scan and get_speed_scan tools on https://xspeedcache.com/scan/mcp: free, no API key. Connect it in one line with claude mcp add --transport http xspeed-scan https://xspeedcache.com/scan/mcp. Full setup, arguments, response shape and limits: xSpeed Scan MCP.
• From the Hub: sites attached to xSpeed Hub can run and view scans from the Hub dashboard or its MCP tools.

What we will not scan

Some targets are refused before a scan starts: anything that is not a resolvable public website (a typo, a private address, an ephemeral tunnel URL), and adult sites. Scans of hosts that are not real public websites: tunnels, raw IP addresses, reserved names like example.com. Still run if you ask, but never join the public directory, the sitemap, or Google.

Removing a report

Reports are public, which is what makes a shared link useful. They are kept out of search engine results. If you own a site and would rather its report were not public, email support@wpdeveloper.com. The address is on every report, and we will remove it. The report stops resolving and the site leaves the directory, the sitemap and the AI-readable index. We do not need to verify anything first; asking is enough.

Fair use

Scans are rate-limited (4 per IP per 10 minutes, plus a global ceiling), and re-scanning the same URL within 10 minutes returns the existing report. The intended loop is: scan → apply fixes → wait a few minutes → re-scan → compare. Failed scans are never listed publicly.