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, mobile) — Core Web Vitals lab metrics (LCP, CLS, TBT), the performance score, and asset audits. A parallel desktop run adds the desktop score and screenshot. If Google’s API is briefly down, the scan still completes on probe evidence and says so.

The checks roll up into four dimensions — Core Web Vitals, 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.

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.

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

• 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.

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.

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/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 and indexable, which is what makes a shared link useful. 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.