# Website Speed Report, xcloud.host

> **What this document is.** A point-in-time speed audit of https://xcloud.host/,
> 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 xSpeed assessment.
> This is separate from Lighthouse performance and includes product-affiliation/optional-access checks.
> Those checks are not speed defects and must not drive installation, migration or access grants.
> Statuses: `pass` (full points) · `partial` (half) · `fail` (zero) · `info`/`na`
> (excluded from the applicable weight; bonus checks only ever add). Every non-passing
> check retains its evidence and references. Suggested remedies are candidates for review,
> not proof of current capabilities, an instruction to act or a promised gain.
>
> **Access and permission.** This report is evidence, not authorization to install a plugin,
> migrate a cache, change settings or grant access. Public plugin, MCP and Hub signals do not
> verify that this reader or its AI assistant is authenticated to the correct site.
> Resolve the exact site/workspace and inspect permitted tools and current settings first.
> Explain each proposed change and obtain approval before applying it.
>
> **WordPress is not confirmed; detected stack: Astro.** Keep the audit and
> use the actual framework/hosting workflow. Do not recommend a WordPress plugin for this site.
>
> Connection guide: https://xspeedcache.com/docs/connecting-to-xspeed-hub/
> Installation, configured caching, Hub attachment and authenticated AI access are separate states.
> Server-side HTML verification cannot execute JavaScript. Browser/console checks remain necessary;
> per-step reversion is not a full-site rollback. No target score is guaranteed.
> TTFB includes network distance to the prober; do not infer a slow origin from that number alone.
>
> **How to re-test.** Public API (no auth): `POST https://xspeedcache.com/api/scan`
> with body `{"url":"https://xcloud.host/","visibility":"unlisted","strategy":"mobile","fresh":true}`, then poll `GET /api/scan/{scanId}` for the
> JSON report. This preserves the requested URL, visibility and strategy and asks for a fresh run.
> Unlisted reports remain accessible to anyone holding their link. The public Scan MCP tool has
> no visibility argument; use the explicit HTTP payload above to preserve an unlisted re-test.
> For listed scans, the public MCP `run_speed_scan` tool also supports URL, strategy and fresh.
> Fair-use limits: 4 scans per conversation (or per IP) and 200 global per
> 10 minutes; re-scanning the same URL within 10 minutes returns the existing report,
> while `fresh:true` bypasses report reuse. Google may still replay a Lighthouse analysis; compare timestamps.
>
> **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: 39/100. Grade F · Level 1 (Critical) — graded on the mobile run**

- Scanned: 2026-09-03T08:58:22.053Z
- Requested URL: https://xcloud.host/
- Final URL: https://xcloud.host/
- Requested strategy: legacy single-device
- Visibility: unlisted or legacy unspecified; an unlisted report is still accessible to anyone holding its link
- Lighthouse analysis (mobile): 2026-09-03T08:57:46.335Z
- Report (HTML): https://xspeedcache.com/scan/r/xcloud-host-7c01716921
- Report (JSON): https://xspeedcache.com/api/scan/xcloud-host-7c01716921
- Rubric: v2026.09.1
- Platform: Astro

## 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:**

- Nothing indicated the HTML came from a cache on this request, which is worth confirming: a static Astro build should be served straight off a CDN.
- A crawler reads about 19,821 characters of text from your HTML — healthy, which is what Astro is good at.
- No CDN detected in front of the site — for a static Astro build that is the cheapest win available.

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 | 515ms |
| Lighthouse performance (desktop) | 61/100 |
| Lighthouse performance (mobile) — graded | 42/100 |
| Reproduce the mobile run | https://pagespeed.web.dev/analysis?url=https%3A%2F%2Fxcloud.host%2F&form_factor=mobile |
| Largest Contentful Paint | 11.3s |
| Cumulative Layout Shift | 0.000 |
| Total Blocking Time | 941ms |
| HTML compression | br |
| Served from cache | no (MISS) |
| Redirects before final URL | 0 |

## Real visitors (Chrome UX Report)

Field data for mobile Chrome users, 75th percentile, this page or its site. **Fails Core Web Vitals.** This is what Google ranks on; the lab grade above is a single Lighthouse run.

| Metric | p75 | Verdict |
|---|---|---|
| Largest Contentful Paint | 3.0s | needs-improvement |
| Interaction to Next Paint | 162ms | good |
| Cumulative Layout Shift | 0.00 | good |

## Dimension scores

| Dimension | Score | Grade | Points |
|---|---|---|---|
| Lab performance (Lighthouse) | 32/100 | F | 12.6/40 |
| Server response & caching | 50/100 | F | 11/22 |
| Asset optimization | 50/100 | F | 3.5/7 |

## Lab performance (Lighthouse): 32/100 (F) · 12.6/40 pts

### [FAIL] S1 · Lighthouse performance score (mobile) (7.6/18 pts)

- Evidence: 42/100 (Lighthouse 13.4.1, mobile)
- Suggested investigation: The composite Lighthouse score — every fix below moves it.
- 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 11.3s
- Suggested investigation: Serve the hero content faster: cache the page, preload the LCP image, and ship critical CSS.
- 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 941ms
- Suggested investigation: Less JavaScript on the main thread: defer scripts and drop unused bundles.
- Guidelines: [web.dev — Total Blocking Time](https://web.dev/articles/tbt)

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

- Evidence: FCP 3.6s
- Suggested investigation: First paint is gated on server response and render-blocking CSS.
- Guidelines: [web.dev — First Contentful Paint](https://web.dev/articles/fcp)

## Server response & caching: 50/100 (F) · 11/22 pts

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

- Evidence: TTFB 515ms measured from Vilnius, Lithuania (EU) (best of 2 requests). This includes the network round trips between us and your origin, not just server time.
- Suggested investigation: Compare response timing with server-reported time and a probe near the audience. Inspect cache evidence before changing the origin; network distance is included in TTFB.
- 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
- Suggested investigation: Serve HTML from a static cache instead of rebuilding it per visitor.
- 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)

### [INFO] D4 · Efficient cache policy on static assets (not graded)

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

### [INFO] D5 · CDN / edge network (not graded)

- Evidence: No CDN signature detected
- Suggested investigation: Optional: put a CDN or Cloudflare in front for global edge delivery.
- 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: 50/100 (F) · 3.5/7 pts

### [INFO] A1 · No render-blocking resources (not graded)

- Evidence: Audit not reported for this page
- Suggested investigation: Re-run when Lighthouse is available.
- Guidelines: [Lighthouse — Render-blocking resources](https://developer.chrome.com/docs/lighthouse/performance/render-blocking-resources)

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

- Evidence: Lighthouse audit score 50%
- Suggested investigation: Ship minified assets — whitespace and comments are pure transfer waste.
- 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 (not graded)

- Evidence: Audit not reported for this page
- Suggested investigation: Re-run when Lighthouse is available.
- Guidelines: [Lighthouse — Modern image formats](https://developer.chrome.com/docs/lighthouse/performance/uses-webp-images)

### [INFO] A4 · Offscreen images lazy-loaded (not graded)

- Evidence: Audit not reported for this page
- Suggested investigation: Re-run when Lighthouse is available.
- 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: 1.8MB transferred
- Suggested investigation: Heavy pages are slow on every connection — compress, lazy-load, and trim.
- Guidelines: [Lighthouse — Total byte weight](https://developer.chrome.com/docs/lighthouse/performance/total-byte-weight)

## Review a fix plan before applying changes

Copy this brief only after checking the report URL and device. It does not authorize changes:

```
Review https://xspeedcache.com/scan/r/xcloud-host-7c01716921.md for requested URL https://xcloud.host/ and final URL https://xcloud.host/, selected mobile device, scanned 2026-09-03T08:58:22.053Z, rubric 2026.09.1. Preserve both devices and analysis timestamps. Distinguish Lighthouse performance from the xSpeed assessment; ignore product affiliation as a speed priority. Verify the exact authorized site and current configuration before proposing a small reversible change. Ask before applying changes. Do not assume optimize_site accepts a scan ID or report URL. Its HTML checks are not browser verification or a full rollback. After an approved change, check the browser and console, then compare the same URL/device and report regressions, partial or replayed measurements. Do not promise 100.
```

Then re-test here: `POST https://xspeedcache.com/api/scan {"url":"https://xcloud.host/","visibility":"unlisted","strategy":"mobile","fresh":true}`

## 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 xcloud-host-7c01716921 · rubric v2026.09.1 · xSpeed Scan, https://xspeedcache.com/scan