ar.bd
Lab data: Lighthouse 13.4.1 mobile run, graded above · Reproduce this run on PageSpeed Insights ↗
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. This report predates the desktop-graded headline: only the mobile run was graded. 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).
Lovable what actually works on this platform
Lovable apps run as Cloudflare Workers, and the platform rewrites Cache-Control after your code returns. The usual caching advice does not apply — these are the fixes that do.
- A crawler reads about 14,924 characters of text from your HTML.
- Time to first byte measured 122ms on this run — one sample, so treat it as a hypothesis and re-run six times before acting.
- Measure first, six runs, take the median. A cold worker isolate inflates the first request on almost every Lovable site — often 4-5x the median. One request, or an average that includes run 1, invents a problem that is not there.
- Do not try to fix this with Cache-Control headers. Lovable runs apps as dynamically-loaded Cloudflare Workers. The hosting layer rewrites Cache-Control after your worker returns, and the Cache API throws. Any header-level fix is discarded — the win has to come from inside the application.
- Find out which stack the project is. TanStack Start (server-rendered, has src/routes/) and Vite React SPA (client-rendered, has src/App.tsx) have different problems and different fixes. This cannot be told from the outside — the response headers are byte-identical — so check the repo before changing anything.
- If TanStack Start: cache the render in two tiers. An in-isolate LRU alone hits about 1 request in 6, because traffic spreads across isolates that do not share memory. Put a shared store (KV, or a table keyed on URL) behind it and the hit rate goes to roughly 7-8 in 8. Emit an x-app-cache: HIT-MEMORY|HIT-SHARED|MISS header while you measure — a HIT that is still slow proves the cost is cold start, not the cache.
- If Vite SPA: the bundle is the cost, not the server. TTFB is usually fine; what feels slow is downloading, parsing and executing JavaScript before anything appears. Split routes with lazy imports, prefetch the chunk on hover, and measure the JS transferred before first paint rather than TTFB.
- Never cache an authenticated route. Serving one visitor a page rendered for another is far worse than a slow site. Keep /admin, /profile and anything carrying credentials off the cache, and verify a logged-out fetch renders the signed-out view before you enable public caching.
- Press Publish. Lovable syncs code to git automatically but does NOT deploy. Production keeps serving the previous build until someone presses Publish — this is the most common reason a real fix looks like it did nothing.
The full instruction set, and a machine-readable copy of this report, live at ar.bd.md — paste that URL into your AI builder's chat and it can work straight from these measurements.
This is a Lovable site — act on the report with your AI assistant
- ✓Platform detectedLovable — 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 Lovable 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 (1 checks name a concrete remediation):
Read the speed report at https://xspeedcache.com/scan/r/ar-bd-d53378ef7f.md — it lists every failing check with evidence and the official guideline for the fix. Produce a prioritized fix plan for my Lovable site, apply what you can, then re-test by POSTing {"url":"https://ar.bd/"} 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.8/40 pts earnedServer response & caching
6/6 checks passed · 30/30 pts earnedAsset optimization
4/5 checks passed · 16/16 pts earnedAI 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.Past scans of ar.bd newest first · every report keeps its link
| Scanned | Score | Grade | Graded on | TTFB | Lighthouse | |
|---|---|---|---|---|---|---|
| 2026-10-01 11:03 UTC | 97 | A+ | desktop | 124ms | 100 | View report → |
| 2026-09-23 13:14 UTC | 97 | A+ | desktop | 136ms | 99 | View report → |
| 2026-09-23 02:38 UTC | 97 | A+ | desktop | 117ms | 100 | View report → |
| 2026-09-20 10:58 UTC | 100 | A+ | desktop | 136ms | 100 | View report → |
| 2026-09-20 06:48 UTC | 97 | A+ | desktop | 104ms | 100 | View report → |
| 2026-09-19 08:02 UTC | 99 | A+ | desktop | 138ms | 94 | View report → |
| 2026-09-15 11:31 UTC | 85 | B | mobile | 123ms | 68 | View report → |
| 2026-09-15 07:30 UTC | 93 | A | mobile | 130ms | 91 | View report → |
| 2026-09-14 14:29 UTC | 100 | A+ | mobile | 124ms | 99 | View report → |
| 2026-09-14 14:27 UTC this report | 100 | A+ | mobile | 122ms | 99 |
Reports graded on different runs are not a trend: mobile-graded rows are the older rubric's headline, desktop-graded rows the current one. Compare like with like.