Lab data: Lighthouse 13.4.1 desktop run, graded above · Reproduce this run on PageSpeed Insights ↗ · Mobile: 63 (D) —
Why is this different from the score in my browser?
The graded score is the desktop run. Lighthouse 13.4.1 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. On this page the mobile run scored 63 (D) against 76 (C) here — to see every check graded on that run.
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).
Lab data: Lighthouse 13.4.1 mobile run, graded above · Reproduce this run on PageSpeed Insights ↗ · Desktop: 76 (C) —
Why is this different from the score in my browser?
This view grades the mobile run. Lighthouse 13.4.1 runs at Google through the PageSpeed Insights API on an emulated mid-range Android with a 4× CPU slowdown and a throttled connection. Chrome DevTools on your own machine, on the Desktop preset, applies almost none of that, and the same page routinely scores 30–50 points higher there. Neither number is wrong — they are different tests.
Mobile is what Google ranks on, so this is the number that affects your
search performance. On this page the desktop run scored 76 (C) against
63 (D) here —
to see every check graded on that run. To reproduce it, open the same run on PageSpeed Insights,
or pass strategy=mobile to the PageSpeed API — it defaults to desktop.
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, mobile). Server probes (TTFB, compression, cache, headers) are measured separately from Vilnius, Lithuania (EU).
Next.js what actually works on this platform
Most of what makes a Next.js site slow is decided at build time — which routes are static, what ends up in the client bundle, and where the server boundary sits. These are the levers, in the order worth pulling them.
- Your HTML came back HIT from the Next.js render cache — the render is already being reused, so look at the client bundle next.
- A crawler reads about 3,099 characters of text from your HTML.
- No next/image URLs in the HTML — images look like they are being served raw, which is usually the largest remaining win.
- Time to first byte measured 101ms on this run — one sample, so re-run it a few times before treating it as the number.
- Decide the rendering mode per route, not per app. Next.js will statically generate, revalidate on a schedule (ISR) or render per request, and the choice is made route by route. A public marketing or content page rendered per request pays a server round trip on every visit for output that could have been reused. Start with the routes that get the most traffic and the least personalisation.
- Read the cache header before changing anything. x-nextjs-cache (or x-vercel-cache) reports HIT, STALE, MISS, BYPASS or PRERENDER for the HTML. MISS or BYPASS on a page with no per-visitor content is the clearest signal you have something to gain; a HIT means the render is already free and your time is better spent on the client bundle.
- Check First Load JS per route. next build prints it. That number, not TTFB, is what a visitor waits through before the page becomes interactive. A shared component pulled into the root layout is charged to every route, so look for one heavy import inflating the whole app rather than a single slow page.
- Keep server-only work behind the server boundary. A dependency imported in a Client Component ships to the browser. Date libraries, SDKs and icon sets pulled across a "use client" boundary are a common way an otherwise small app grows a large bundle — audit what crosses it.
- Use next/image and next/font rather than raw tags. next/image serves modern formats at the right size and reserves space so the layout does not shift; next/font self-hosts the font files and removes the render-blocking request to a font host. Both are small changes with visible effects on Core Web Vitals.
- Load third-party scripts through next/script. Analytics, chat widgets and tag managers loaded as plain script tags block the main thread during hydration. next/script with an afterInteractive or lazyOnload strategy moves them out of the critical path without removing them.
The full instruction set, and a machine-readable copy of this report, live at v0.app.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
Top fixes ranked by points recovered · mobile
This is a Next.js site — act on the report with your AI assistant
- ✓Platform detectedNext.js — 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 Next.js 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 (6 checks name a concrete remediation):
Read the speed report at https://xspeedcache.com/scan/r/v0-app-4bac9633f7.md — it lists every failing check with evidence and the official guideline for the fix. Produce a prioritized fix plan for my Next.js site, apply what you can, then re-test by POSTing {"url":"https://v0.app/pricing"} 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.
Core Web Vitals & lab metrics
3/5 checks passed · 29.8/40 pts earnedAI prompt
Using my site's xSpeed MCP connection: run optimize_site, then run_benchmark to verify the score improved.AI prompt
Using my site's xSpeed MCP connection: enable JS minification and deferred loading, then re-test Total Blocking Time.Server response & caching
5/6 checks passed · 27.5/30 pts earnedAI prompt
Using my site's xSpeed MCP connection: enable browser-cache headers for static assets, then re-run the audit.Asset optimization
2/5 checks passed · 8/16 pts earnedAI prompt
Using my site's xSpeed MCP connection: generate critical CSS for the top pages and enable unused-CSS removal, then 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.Core Web Vitals & lab metrics
2/5 checks passed · 18.7/40 pts earnedAI prompt
Using my site's xSpeed MCP connection: run optimize_site, then run_benchmark to verify the score improved.AI prompt
Using my site's xSpeed MCP connection: enable page caching, start the preloader, and (on Pro) generate critical CSS for this page; then re-test LCP.AI prompt
Using my site's xSpeed MCP connection: enable JS minification and deferred loading, then re-test Total Blocking Time.Server response & caching
5/6 checks passed · 27.5/30 pts earnedAI prompt
Using my site's xSpeed MCP connection: enable browser-cache headers for static assets, then re-run the audit.Asset optimization
2/5 checks passed · 8/16 pts earnedAI prompt
Using my site's xSpeed MCP connection: generate critical CSS for the top pages and enable unused-CSS removal, then 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.Past scans of v0.app newest first · every report keeps its link
| Scanned | Score | Grade | Graded on | TTFB | Lighthouse | |
|---|---|---|---|---|---|---|
| 2026-09-20 11:06 UTC this report | 76 | C | desktop | 101ms | 71 | |
| 2026-09-20 10:51 UTC | 56 | D | desktop | 101ms | 42 | View report → |
| 2026-09-20 10:41 UTC | 55 | D | desktop | 97ms | 39 | View report → |