# Website Speed Report, replit.com

> **What this document is.** A point-in-time speed audit of https://replit.com/,
> 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, desktop).
> **Two graded runs.** The score below is graded on the **desktop** run — the one a reader can reproduce
> in their own browser. The mobile run is graded on the same rubric further down (42/100,
> grade F). Google ranks on mobile, so when the two differ, report both and act on the mobile failures too.
>
> **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 Next.js).** 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 Next.js 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/scan/mcp`. Fair-use limits: 4 scans per caller 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.
>
> **Connect this scanner as an MCP server (free, no API key).**
> Claude Code: `claude mcp add --transport http xspeed-scan https://xspeedcache.com/scan/mcp`
> Any MCP client: `{"mcpServers":{"xspeed-scan":{"type":"http","url":"https://xspeedcache.com/scan/mcp"}}}`
> Tools: `run_speed_scan` (url, fresh?, strategy?) and `get_speed_scan` (scanId). `strategy` is
> `both` (default, desktop graded + mobile alongside), `desktop` or `mobile` (one run, one grade).
> Docs: https://xspeedcache.com/docs/scan-mcp/

**Score: 63/100. Grade D · Level 3 (Average) — graded on the desktop run**

- Scanned: 2026-09-20T09:58:26.867Z
- Report (HTML): https://xspeedcache.com/scan/r/replit-com-3ad52900b7
- Report (JSON): https://xspeedcache.com/api/scan/replit-com-3ad52900b7
- Rubric: v2026.09.5
- Platform: Next.js · CDN: Cloudflare

## Next.js: what actually works here

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.

**Measured on this run:**

- No Next.js cache header on this response, so either the HTML is rendered per request or it is served by something in front that strips the header — worth confirming before you tune anything.
- A crawler reads about 9,354 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 300ms on this run — one sample, so re-run it a few times before treating it as the number.

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

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

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

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

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

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

## Headline measurements

| Metric | Value |
|---|---|
| Time to first byte | 300ms |
| Lighthouse performance (desktop) — graded | 57/100 |
| Lighthouse performance (mobile) | 32/100 |
| Reproduce the desktop run | https://pagespeed.web.dev/analysis?url=https%3A%2F%2Freplit.com%2F&form_factor=desktop |
| Largest Contentful Paint | 2.2s |
| Cumulative Layout Shift | 0.000 |
| Total Blocking Time | 1.3s |
| HTML compression | br |
| Served from cache | no (MISS) |
| Redirects before final URL | 0 |

## Dimension scores

| Dimension | Score | Grade | Points |
|---|---|---|---|
| Core Web Vitals & lab metrics | 68/100 | D | 27.3/40 |
| Server response & caching | 72/100 | C | 16.5/23 |
| Asset optimization | 38/100 | F | 6/16 |

## Core Web Vitals & lab metrics: 68/100 (D) · 27.3/40 pts

### [PARTIAL] S1 · Lighthouse performance score (desktop) (10.3/18 pts)

- Evidence: 57/100 (Lighthouse 13.4.1, desktop)
- 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)

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

- Evidence: LCP 2.2s
- 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)

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

- Evidence: TBT 1.3s
- Remediation: Less JavaScript on the main thread: defer scripts and drop unused bundles.
- xSpeed fix (Free): **JS Minify + Defer**
- AI prompt: `Using my site's xSpeed MCP connection: enable JS minification and deferred loading, then re-test Total Blocking Time.`
- Guidelines: [web.dev — Total Blocking Time](https://web.dev/articles/tbt)

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

- Evidence: FCP 661ms
- Guidelines: [web.dev — First Contentful Paint](https://web.dev/articles/fcp)

## Server response & caching: 72/100 (C) · 16.5/23 pts

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

- Evidence: TTFB 300ms measured from Vilnius, Lithuania (EU) (best of 2 requests). This includes the network round trips between us and your origin, not just server time. Google measured your server responding in 32ms from its own network — the gap between the two numbers is distance, not your server.
- Remediation: The server rebuilds the page on every request. A page cache answers in 5–15ms.
- xSpeed fix (Free): **Page Cache**
- AI prompt: `Using my site's xSpeed MCP connection: enable page caching and warm this page with the preloader, then re-check TTFB.`
- Guidelines: [web.dev — Time to First Byte](https://web.dev/articles/ttfb)

### [NA] D2 · Page served from cache (not graded)

- Evidence: Correctly per-visitor — this response is marked `no-store`, so it must not be held in a shared cache.
- Remediation: Nothing to fix. If parts of this page are the same for everyone, they can still be cached separately — but the page as a whole is right to opt out.
- Guidelines: [MDN — HTTP caching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching)

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

- Evidence: Content-Encoding: br
- 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)

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

- Evidence: Lighthouse cache-policy audit score 50% — 8 files: frame-art-poster-7204-preview.jpg, frame-jazz-night-poster-7301-preview.jpg, frame-dinner-party-poster-7303-preview.jpg…
- Remediation: Give your CSS/JS/images long Cache-Control lifetimes. One of these is served by another host, so that part will not clear.
- xSpeed fix (Free): **Browser Cache**
- AI prompt: `Using my site's xSpeed MCP connection: enable browser-cache headers for static assets, then re-run the audit.`
- 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: 38/100 (F) · 6/16 pts

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

- Evidence: Fails the Lighthouse audit — 8 files: 2tm5eg2-0_vvl.css, 2w5u-hyoll1np.css, 3ur2niygb1dxo.css… · ~350ms of first paint
- Remediation: CSS/JS in <head> blocks first paint. Inline the critical CSS and defer the rest.
- 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: Passes the Lighthouse audit
- Guidelines: [Lighthouse — Minify CSS](https://developer.chrome.com/docs/lighthouse/performance/unminified-css) · [Minify JavaScript](https://developer.chrome.com/docs/lighthouse/performance/unminified-javascript)

### [PARTIAL] A3 · Modern, optimized image formats (2/4 pts)

- Evidence: Lighthouse audit score 50% — 5 files: frame-art-poster-7204-preview.jpg, frame-jazz-night-poster-7301-preview.jpg, frame-dinner-party-poster-7303-preview.jpg…
- Remediation: Serve WebP/AVIF at the right compression — usually the single largest byte saving.
- 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] A6 · LCP image discoverable early (not graded)

- Evidence: Audit not reported for this page
- Remediation: Re-run when Lighthouse is available.
- xSpeed fix (Free): **Resource Hints (preload) + Lazy Load exclusions**
- 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.`
- Guidelines: [web.dev — Optimize LCP](https://web.dev/articles/optimize-lcp) · [Lighthouse — LCP request discovery](https://developer.chrome.com/docs/lighthouse/performance/prioritize-lcp-image)

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

- Evidence: 5.2MB 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)

## The mobile run: 42/100 (F) · Level 2 (Slow)

Same rubric, graded on the mobile Lighthouse run (performance 32/100). Reproduce it: https://pagespeed.web.dev/analysis?url=https%3A%2F%2Freplit.com%2F&form_factor=mobile

| Dimension | Score | Grade | Points |
|---|---|---|---|
| Core Web Vitals & lab metrics | 27/100 | F | 10.8/40 |
| Server response & caching | 72/100 | C | 16.5/23 |
| Asset optimization | 38/100 | F | 6/16 |

### Checks that differ from the desktop run

- [FAIL] S1 · Lighthouse performance score (mobile) (5.8/18 pts) — 32/100 (Lighthouse 13.4.1, mobile) (desktop: PARTIAL)
- [FAIL] S2 · Largest Contentful Paint ≤ 2.5s (0/8 pts) — LCP 24.9s (desktop: PASS)
- [FAIL] S4 · Total Blocking Time ≤ 200ms (0/5 pts) — TBT 1.5s (desktop: FAIL)
- [FAIL] S5 · First Contentful Paint ≤ 1.8s (0/4 pts) — FCP 4.1s (desktop: PASS)
- [PARTIAL] D1 · Time to first byte ≤ 200ms (4/8 pts) — TTFB 300ms measured from Vilnius, Lithuania (EU) (best of 2 requests). This includes the network round trips between us and your origin, not just server time. Google measured your server responding in 47ms from its own network — the gap between the two numbers is distance, not your server. (desktop: PARTIAL)
- [PARTIAL] D4 · Efficient cache policy on static assets (2.5/5 pts) — Lighthouse cache-policy audit score 50% — 3 files: frame-art-poster-7204-preview.jpg, frame-bento-dashboard-7306-preview.jpg, telemetry.js (elements.stytch.com) (desktop: PARTIAL)
- [FAIL] A1 · No render-blocking resources (0/5 pts) — Fails the Lighthouse audit — 8 files: 2tm5eg2-0_vvl.css, 0j_tske4s1i4i.css, 3z0vmpyix3h18.css… · ~1.9s of first paint (desktop: FAIL)
- [PARTIAL] A3 · Modern, optimized image formats (2/4 pts) — Lighthouse audit score 50% — 3 files: design-freely-chromatica.webp, design-freely-exhibition.webp, frame-art-poster-7204-preview.jpg (desktop: PARTIAL)

## 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/replit-com-3ad52900b7, 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://replit.com/"}`

## Scan any site yourself (free MCP)

Free, no API key. Scan any public site and get the same graded report as this one, with the fix for every failing check. These are the same tools that produced this report.

```
claude mcp add --transport http xspeed-scan https://xspeedcache.com/scan/mcp
```

Or in any MCP client:

```json
{
  "mcpServers": {
    "xspeed-scan": {
      "type": "http",
      "url": "https://xspeedcache.com/scan/mcp"
    }
  }
}
```

Tools: `run_speed_scan` · `get_speed_scan` · Docs: https://xspeedcache.com/docs/scan-mcp/

No MCP client? The same scan runs from Telegram: https://t.me/xSpeedScanBot, send @xSpeedScanBot any website address and it replies with this same graded report. Free, no signup.

---
Scan replit-com-3ad52900b7 · rubric v2026.09.5 · xSpeed Scan, https://xspeedcache.com/scan