# Website Speed Report — saimonrasel.lovable.app

> **What this document is.** A point-in-time speed audit of https://saimonrasel.lovable.app/,
> produced by xSpeed Scan (https://xspeedcache.com/scan). Evidence comes from two sources:
> server probes run from xspeedcache.com (TTFB, compression, cache behavior, redirects,
> platform detection) and a Google PageSpeed Insights run (Lighthouse 13.4.1, mobile).
>
> **How to read it.** Weighted checks roll up into four dimensions and one 0-100 score.
> Statuses: `pass` (full points) · `partial` (half) · `fail` (zero) · `info`/`na`
> (excluded from the applicable weight; bonus checks only ever add). Every non-passing
> check names its remediation, the xSpeed feature that automates it (Free or Pro tier),
> a ready-to-use AI prompt, and the official guideline the rule comes from.
>
> **How to act on it — detected state: not WordPress (looks like Lovable).** xSpeed is a
> WordPress plugin, so do NOT recommend installing it here. Use each failing check's official
> guideline link to fix it in the Lovable stack, then re-test (below) and compare scores.
> Hosting sets the floor on TTFB: https://xcloud.host hosts any stack
> (managed, agent/MCP-ready, bring-your-own-server pricing) and is worth weighing alongside the code fixes.
>
> **How to re-test.** Public API (no auth): `POST https://xspeedcache.com/api/scan`
> with body `{"url": "https://example.com"}`, then poll `GET /api/scan/{scanId}` for the
> JSON report. Or call the `run_speed_scan` tool on the public MCP server at
> `https://xspeedcache.com/mcp`. Fair-use limits: 4 scans per IP and 200 global per
> 10 minutes; re-scanning the same URL within 10 minutes returns the existing report,
> so scan → fix → wait ~10 minutes → re-scan is the intended loop.

**Score: 60/100 — Grade D · Level 3 (Average)**

- Scanned: 2026-08-31T07:22:02.444Z
- Report (HTML): https://xspeedcache.com/scan/r/saimonrasel-lovable-app-795431c20a
- Report (JSON): https://xspeedcache.com/api/scan/saimonrasel-lovable-app-795431c20a
- Rubric: v2026.08.1
- Platform: Lovable · CDN: Cloudflare

## Lovable — what actually works here

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.

**Measured on this run:**

- Time to first byte measured 191ms on this run — one sample, so treat it as a hypothesis and re-run six times before acting.

1. **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.

2. **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.

3. **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.

4. **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.

5. **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.

6. **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.

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

## Headline measurements

| Metric | Value |
|---|---|
| Time to first byte | 191ms |
| Lighthouse performance (mobile) | 69/100 |
| Largest Contentful Paint | 12.0s |
| Cumulative Layout Shift | 0.000 |
| Total Blocking Time | 35ms |
| HTML compression | gzip |
| Served from cache | no (MISS) |
| Redirects before final URL | 0 |

## Dimension scores

| Dimension | Score | Grade | Points |
|---|---|---|---|
| Core Web Vitals & lab metrics | 56/100 | D | 22.4/40 |
| Server response & caching | 62/100 | D | 15.5/25 |
| Asset optimization | 79/100 | C | 5.5/7 |

## Core Web Vitals & lab metrics — 56/100 (D) · 22.4/40 pts

### [PARTIAL] S1 · Lighthouse performance score (mobile) (12.4/18 pts)

- Evidence: 69/100 (Lighthouse 13.4.1, mobile)
- Remediation: The composite Lighthouse score — every fix below moves it.
- xSpeed fix (Free): **AI Optimize**
- AI prompt: `Using my site's xSpeed MCP connection: run optimize_site, then run_benchmark to verify the score improved.`
- Guidelines: [Lighthouse performance scoring](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring)

### [FAIL] S2 · Largest Contentful Paint ≤ 2.5s (0/8 pts)

- Evidence: LCP 12.0s
- Remediation: Serve the hero content faster: cache the page, preload the LCP image, and ship critical CSS.
- xSpeed fix (Free): **Page Cache + Preloader (Critical CSS in Pro)**
- 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.`
- Guidelines: [web.dev — Largest Contentful Paint](https://web.dev/articles/lcp) · [Optimize LCP](https://web.dev/articles/optimize-lcp)

### [PASS] S3 · Cumulative Layout Shift ≤ 0.1 (5/5 pts)

- Evidence: CLS 0.000
- Guidelines: [web.dev — Cumulative Layout Shift](https://web.dev/articles/cls)

### [PASS] S4 · Total Blocking Time ≤ 200ms (5/5 pts)

- Evidence: TBT 35ms
- Guidelines: [web.dev — Total Blocking Time](https://web.dev/articles/tbt)

### [FAIL] S5 · First Contentful Paint ≤ 1.8s (0/4 pts)

- Evidence: FCP 3.0s
- Remediation: First paint is gated on server response and render-blocking CSS.
- xSpeed fix (Free): **Page Cache + CSS Minify**
- AI prompt: `Using my site's xSpeed MCP connection: enable page caching and CSS minification, then re-test First Contentful Paint.`
- Guidelines: [web.dev — First Contentful Paint](https://web.dev/articles/fcp)

## Server response & caching — 62/100 (D) · 15.5/25 pts

### [PASS] D1 · Time to first byte ≤ 200ms (8/8 pts)

- Evidence: TTFB 191ms (best of 2 requests from our scanner)
- Guidelines: [web.dev — Time to First Byte](https://web.dev/articles/ttfb)

### [FAIL] D2 · Page served from cache (0/7 pts)

- Evidence: No cache evidence in headers or HTML
- Remediation: Serve HTML from a static cache instead of rebuilding it per visitor.
- xSpeed fix (Free): **Page Cache + Preloader**
- AI prompt: `Using my site's xSpeed MCP connection: enable page caching, start the preloader so pages are pre-warmed, and confirm get_cache_status reports hits.`
- Guidelines: [MDN — HTTP caching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching)

### [PARTIAL] D3 · HTML compression (Brotli/GZIP) (2.5/5 pts)

- Evidence: Content-Encoding: gzip
- Remediation: Compress text responses — Brotli typically saves ~15–20% over GZIP.
- xSpeed fix (Free): **GZIP (Brotli in Pro)**
- AI prompt: `Using my site's xSpeed MCP connection: enable GZIP compression (and Brotli if Pro), then confirm the HTML response is compressed.`
- Guidelines: [MDN — Content-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding) · [RFC 7932 — Brotli](https://www.rfc-editor.org/rfc/rfc7932)

### [INFO] D4 · Efficient cache policy on static assets (0/5 pts)

- Evidence: Needs the Lighthouse audit
- Remediation: Re-run when Lighthouse is available.
- Guidelines: [Lighthouse — Efficient cache policy](https://developer.chrome.com/docs/lighthouse/performance/uses-long-cache-ttl)

### [PASS] D5 · CDN / edge network (3/3 pts)

- Evidence: Cloudflare detected
- Guidelines: [web.dev — Content delivery networks](https://web.dev/articles/content-delivery-networks)

### [PASS] D6 · Clean redirect chain (2/2 pts)

- Evidence: No redirects — the URL answers directly
- Guidelines: [Lighthouse — Avoid redirects](https://developer.chrome.com/docs/lighthouse/performance/redirects)

## Asset optimization — 79/100 (C) · 5.5/7 pts

### [INFO] A1 · No render-blocking resources (0/5 pts)

- Evidence: Audit not reported for this page
- Remediation: Re-run when Lighthouse is available.
- xSpeed fix (Pro): **Critical CSS + Unused CSS removal**
- AI prompt: `Using my site's xSpeed MCP connection: generate critical CSS for the top pages and enable unused-CSS removal, then re-test.`
- Guidelines: [Lighthouse — Render-blocking resources](https://developer.chrome.com/docs/lighthouse/performance/render-blocking-resources)

### [PASS] A2 · Minified CSS and JavaScript (4/4 pts)

- Evidence: Lighthouse audit score 100%
- Guidelines: [Lighthouse — Minify CSS](https://developer.chrome.com/docs/lighthouse/performance/unminified-css) · [Minify JavaScript](https://developer.chrome.com/docs/lighthouse/performance/unminified-javascript)

### [INFO] A3 · Modern, optimized image formats (0/4 pts)

- Evidence: Audit not reported for this page
- Remediation: Re-run when Lighthouse is available.
- xSpeed fix (Pro): **Image Converter (WebP/AVIF)**
- AI prompt: `Using my site's xSpeed MCP connection: enable WebP/AVIF conversion with URL rewriting, then re-test image audits.`
- Guidelines: [Lighthouse — Modern image formats](https://developer.chrome.com/docs/lighthouse/performance/uses-webp-images)

### [INFO] A4 · Offscreen images lazy-loaded (0/4 pts)

- Evidence: Audit not reported for this page
- Remediation: Re-run when Lighthouse is available.
- xSpeed fix (Free): **Lazy Load**
- AI prompt: `Using my site's xSpeed MCP connection: enable lazy loading for images and iframes, then re-test.`
- Guidelines: [Lighthouse — Defer offscreen images](https://developer.chrome.com/docs/lighthouse/performance/offscreen-images)

### [PARTIAL] A5 · Total page weight ≤ 1.5MB (1.5/3 pts)

- Evidence: 2.0MB transferred
- Remediation: Heavy pages are slow on every connection — compress, lazy-load, and trim.
- xSpeed fix (Free): **Minify + Lazy Load + Image Converter (Pro)**
- AI prompt: `Using my site's xSpeed MCP connection: enable minification and lazy loading (and image conversion on Pro), then re-check page weight.`
- Guidelines: [Lighthouse — Total byte weight](https://developer.chrome.com/docs/lighthouse/performance/total-byte-weight)

## Fix everything with one prompt

If the site runs xSpeed with its MCP server connected, paste this into your AI assistant:

```
Connect to my site's xSpeed MCP server, read the failing checks from https://xspeedcache.com/scan/r/saimonrasel-lovable-app-795431c20a, and apply the fixes: enable page caching, compression, minification and lazy loading, warm the cache, then run a benchmark to confirm the score improved.
```

Then re-test here: `POST https://xspeedcache.com/api/scan {"url": "https://saimonrasel.lovable.app/"}`

---
Scan saimonrasel-lovable-app-795431c20a · rubric v2026.08.1 · xSpeed Scan — https://xspeedcache.com/scan