Lab data: Lighthouse 13.5.0 desktop run, graded above · Reproduce this run on PageSpeed Insights ↗
Why is this different from the score in my browser?
The graded score is the desktop run. Lighthouse 13.5.0 runs at Google through the PageSpeed Insights API on a desktop profile with no CPU or network throttling — close to what Chrome DevTools on a laptop, GTmetrix's default test and the PageSpeed API (which defaults to desktop) all measure, so this is the number you should be able to reproduce: run it yourself on PageSpeed Insights.
Google ranks on mobile. That run happens too, on an emulated mid-range Android with a 4× CPU slowdown and a throttled connection, and the same page routinely scores 30–50 points lower there. Neither number is wrong — they are different tests.
Lighthouse also varies a few points run to run on the same URL. Treat a trend across several scans as the signal, never a single digit.
Lab data: Google PageSpeed Insights (Lighthouse, desktop). Server probes (TTFB, compression, cache, headers) are measured separately from Vilnius, Lithuania (EU).
Lighthouse was unavailable for the mobile run · Desktop: 92 (A) —
Astro what actually works on this platform
Astro ships no JavaScript unless you ask for it, so a slow Astro site is almost always one of two things: islands hydrating when they do not need to, or the HTML being built per request when it could have been built once.
- The HTML is served as a pre-built file straight off the web server — nothing is built per visit, so look at what the page ships rather than at the server.
- A crawler reads about 19,476 characters of text from your HTML — healthy, which is what Astro is good at.
- No CDN detected in front of the site — for a static Astro build that is the cheapest win available.
- Check your client: directives before anything else. client:load hydrates an island immediately and costs the visitor JavaScript on first paint. client:visible defers it until the component scrolls into view and client:idle until the browser is free; most islands want one of those. A page full of client:load is the usual reason an Astro site feels heavy.
- Know whether each route is static or server-rendered. Astro can output a static file, render per request, or mix the two per route. A page with no per-visitor content that is rendered per request pays for it on every visit. Prerender the ones that can be, and let the CDN serve them.
- Use astro:assets for images. It emits modern formats at the sizes actually used and reserves the space so the layout does not shift. Raw <img> tags are usually the largest remaining payload on an otherwise lean Astro site.
- Watch what a shared layout pulls in. An import in a layout is charged to every page that uses it. One heavy component or icon set there outweighs anything you will save on an individual route.
The full instruction set, and a machine-readable copy of this report, live at xspeedcache.com.md — paste that URL into your AI builder's chat and it can work straight from these measurements.
Top fixes ranked by points recovered · desktop
This is an Astro site — act on the report with your AI assistant
- ✓Platform detectedAstro — every check below links the official guideline for the fix in this stack.
- →Act on it with your AIThe machine-readable twin of this report gives an agent every failing check with its evidence, remediation and guideline link.
- →Check the originHosting sets the floor on TTFB. xCloud hosts any stack — agent/MCP access built in, bring-your-own-server pricing.
xSpeed is a WordPress plugin, so it can't automate Astro fixes — and that's fine. Every check below links its official guideline, and the machine-readable twin of this report gives an AI everything it needs to plan the work (5 checks name a concrete remediation):
Read the speed report at https://xspeedcache.com/scan/r/xspeedcache-com-d76b28655b.md — it lists every failing check with evidence and the official guideline for the fix. Produce a prioritized fix plan for my Astro site, apply what you can, then re-test by POSTing {"url":"https://xspeedcache.com/"} to https://xspeedcache.com/api/scan and compare the scores.Run this scan without the form
Plug xSpeed Scan into your agent stack, or test any site from a chat.
Connect this scanner to your AI assistant
Free. No API key, no sign-up. Scan any public site and get the same graded report as this one, with the fix for every failing check.
Endpoint
https://xspeedcache.com/scan/mcpClaude Code — one command
claude mcp add --transport http xspeed-scan https://xspeedcache.com/scan/mcpClaude Desktop, Cursor, or any MCP client — add to your config
{
"mcpServers": {
"xspeed-scan": {
"type": "http",
"url": "https://xspeedcache.com/scan/mcp"
}
}
}run_speed_scanScan any public URL and return this whole graded report.get_speed_scanRead a scan already run, by its id.
Lab performance (Lighthouse)
5/5 checks passed · 39.6/40 pts earnedServer response & caching
4/6 checks passed · 24.5/27 pts earnedAI prompt
Using my site's xSpeed MCP connection: enable browser-cache headers for static assets, then re-run the audit.AI prompt
Using my site's xSpeed MCP connection: connect Cloudflare (or configure the CDN rewriter) and purge, then re-scan.Asset optimization
2/5 checks passed · 12/16 pts earnedAI prompt
Using my site's xSpeed MCP connection: enable HTML, CSS and JS minification, purge the cache, and re-test.AI prompt
Using my site's xSpeed MCP connection: preload the LCP image for this page and exclude it from lazy loading, then re-test LCP.AI prompt
Using my site's xSpeed MCP connection: enable minification and lazy loading (and image conversion on Pro), then re-check page weight.Server response & caching
4/6 checks passed · 22/22 pts earnedAI prompt
Using my site's xSpeed MCP connection: connect Cloudflare (or configure the CDN rewriter) and purge, then re-scan.Past scans of xspeedcache.com newest first · every report keeps its link
| Scanned | Score | Grade | Graded on | TTFB | Lighthouse | |
|---|---|---|---|---|---|---|
| 2026-10-14 15:53 UTC | 92 | A | desktop | 6ms | 100 | View report → |
| 2026-10-13 02:35 UTC | 92 | A | desktop | 6ms | 97 | View report → |
| 2026-10-12 08:02 UTC this report | 92 | A | desktop | 20ms | 98 | |
| 2026-10-10 19:39 UTC | 92 | A | desktop | 8ms | 98 | View report → |
| 2026-10-05 10:49 UTC | 92 | A | desktop | 8ms | 98 | View report → |
| 2026-10-05 09:11 UTC | 92 | A | desktop | 12ms | 100 | View report → |
| 2026-10-04 08:25 UTC | 92 | A | desktop | 10ms | 100 | View report → |
| 2026-10-04 07:47 UTC | 92 | A | desktop | 8ms | 98 | View report → |
| 2026-10-02 09:15 UTC | 92 | A | desktop | 7ms | 99 | View report → |
| 2026-10-01 21:55 UTC | 92 | A | desktop | 7ms | 100 | View report → |