# Website Speed Report, speed.press

> **What this document is.** A point-in-time speed audit of https://speed.press/,
> 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 (97/100,
> grade A+). 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 Astro).** 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 Astro 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: 97/100. Grade A+ · Level 5 (Instant) — graded on the desktop run**

- Scanned: 2026-09-20T10:22:36.056Z
- Report (HTML): https://xspeedcache.com/scan/r/speed-press-3eec6fb61e
- Report (JSON): https://xspeedcache.com/api/scan/speed-press-3eec6fb61e
- Rubric: v2026.09.5
- Platform: Astro · CDN: Cloudflare

## Astro: what actually works here

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.

**Measured on this run:**

- The HTML came back from a cache — the build is not being repeated per visit, so look at what the page ships rather than at the server.
- A crawler reads about 5,703 characters of text from your HTML — healthy, which is what Astro is good at.
- Served through Cloudflare.

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

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

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

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

## Headline measurements

| Metric | Value |
|---|---|
| Time to first byte | 130ms |
| Lighthouse performance (desktop) — graded | 100/100 |
| Lighthouse performance (mobile) | 100/100 |
| Reproduce the desktop run | https://pagespeed.web.dev/analysis?url=https%3A%2F%2Fspeed.press%2F&form_factor=desktop |
| Largest Contentful Paint | 239ms |
| Cumulative Layout Shift | 0.001 |
| Total Blocking Time | 7ms |
| HTML compression | br |
| Served from cache | yes (HIT) |
| Redirects before final URL | 0 |

## Dimension scores

| Dimension | Score | Grade | Points |
|---|---|---|---|
| Core Web Vitals & lab metrics | 100/100 | A+ | 40/40 |
| Server response & caching | 92/100 | A | 27.5/30 |
| Asset optimization | 100/100 | A+ | 16/16 |

## Core Web Vitals & lab metrics: 100/100 (A+) · 40/40 pts

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

- Evidence: 100/100 (Lighthouse 13.4.1, desktop)
- 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 239ms
- 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.001
- Guidelines: [web.dev — Cumulative Layout Shift](https://web.dev/articles/cls)

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

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

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

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

## Server response & caching: 92/100 (A) · 27.5/30 pts

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

- Evidence: TTFB 130ms 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 2ms from its own network — the gap between the two numbers is distance, not your server.
- Guidelines: [web.dev — Time to First Byte](https://web.dev/articles/ttfb)

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

- Evidence: Cache HIT evidence in response headers
- 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% — 1 file: logo.svg
- Remediation: Give CSS/JS/images long Cache-Control lifetimes so repeat views are free.
- 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: 100/100 (A+) · 16/16 pts

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

- Evidence: Passes the Lighthouse audit
- 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)

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

- Evidence: Passes the Lighthouse audit
- 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)

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

- Evidence: 0.0MB transferred
- Guidelines: [Lighthouse — Total byte weight](https://developer.chrome.com/docs/lighthouse/performance/total-byte-weight)

## The mobile run: 97/100 (A+) · Level 5 (Instant)

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

| Dimension | Score | Grade | Points |
|---|---|---|---|
| Core Web Vitals & lab metrics | 100/100 | A+ | 40/40 |
| Server response & caching | 92/100 | A | 27.5/30 |
| Asset optimization | 100/100 | A+ | 16/16 |

### Checks that differ from the desktop run

- [PASS] S1 · Lighthouse performance score (mobile) (18/18 pts) — 100/100 (Lighthouse 13.4.1, mobile) (desktop: PASS)
- [PASS] S2 · Largest Contentful Paint ≤ 2.5s (8/8 pts) — LCP 787ms (desktop: PASS)
- [PASS] S3 · Cumulative Layout Shift ≤ 0.1 (5/5 pts) — CLS 0.000 (desktop: PASS)
- [PASS] S4 · Total Blocking Time ≤ 200ms (5/5 pts) — TBT 0ms (desktop: PASS)
- [PASS] S5 · First Contentful Paint ≤ 1.8s (4/4 pts) — FCP 787ms (desktop: PASS)

## 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/speed-press-3eec6fb61e, 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://speed.press/"}`

## 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 speed-press-3eec6fb61e · rubric v2026.09.5 · xSpeed Scan, https://xspeedcache.com/scan