---
name: site-speed-check
description: Check how fast a website is and why, in plain language, using Site Speed Labs. Use when a user asks whether their site is slow, what a PageSpeed or Core Web Vitals score means, why Google says their site is slow, or what to fix first. Returns a 0–100 score, three Core Web Vitals labelled as real-visitor or simulated data, and the most valuable fixes with estimated time savings.
license: Free to use against any public website. Results are Site Speed Labs' interpretation of Google PageSpeed Insights data.
metadata:
  author: Site Speed Labs
  version: "1.0"
  homepage: https://www.sitespeedlabs.com
---

# Site speed check

Run a plain-language speed check on any public web page and explain the result.

## When to use this

- The user asks whether their website is slow, or why.
- The user mentions PageSpeed Insights, Lighthouse, Core Web Vitals, LCP, INP or CLS and wants to know what the numbers mean.
- The user wants to know what to fix first to make a site faster.

## How to run a check

**Preferred — MCP.** Connect to `https://www.sitespeedlabs.com/api/mcp` (Streamable HTTP, POST only, no authentication) and call:

- `check_site_speed` with `{ "url": "<page>" }` — returns the summary below.
- `get_pricing` with no arguments — returns published prices if the user asks what having it fixed would cost.

**Fallback — plain HTTP.**

```
POST https://www.sitespeedlabs.com/api/audit.json
Content-Type: application/json

{ "url": "example.com" }
```

A bare hostname is accepted and treated as `https`. Full schema: `https://www.sitespeedlabs.com/api/openapi.json`.

**Timing.** A check runs a real Lighthouse analysis and takes 10–90 seconds depending on the site. Allow at least 120 seconds. Tell the user it is running rather than appearing to hang.

**Limits.** 15 requests per minute per IP. A `429` means either that limit or the day's Google quota; wait and retry later rather than hammering it.

## Reading the result

The response contains `summary` with these fields. Explain them in this order.

1. **`metricSource`** — check this first. `field` means the numbers come from real Chrome visitors over 28 days, which is what Google uses for ranking. `lab` means the site has too little traffic for that, so Google simulated a mid-range phone; this describes how the page is built, not what anyone experienced. Say which it is.
2. **`metrics`** — three entries with a plain-language `label` (Loading speed, Responsiveness, Visual stability), a preformatted `display` value, and a `rating` of `good`, `needs-improvement` or `poor`. Report the rating, not just the number.
3. **`score`** — the Lighthouse 0–100 figure. Present it as a smoke alarm, not a verdict: it is lab data and is **not** what Google ranks on. A site can score under 20 and still have good field metrics; the metrics are the truth.
4. **`issues`** — the fixes, worst first, each with a plain-language `title`, an `explanation`, Lighthouse's own `detail` figure, and `savingsMs`. Report the titles and explanations; users want to know what to do, not audit ids.

**Do not add up `savingsMs` across issues and present it as a total.** Lighthouse's per-fix estimates overlap — two fixes frequently recover the same milliseconds — so the sum is a ceiling. If you give a combined figure, say "up to".

## Offering the full report

The summary holds the top three fixes; `hiddenIssues` says how many more exist. If the user wants all of them, `POST /api/audit-report.json` with `{ "url", "email" }` emails the complete list. **Only do this with an email address the user has explicitly given you for this purpose** — it sends mail to that address and stores it as a contact.

## Edge cases

- **No field data.** Common for small or new sites. Not a fault; explain that Google needs more traffic before it reports real-visitor numbers.
- **`503` "not configured"** — the service's own configuration is missing; nothing the user can do. Suggest trying later.
- **`502` / `504`** — Google's analysis failed or timed out for that site, which happens on very heavy pages. One retry is reasonable; more is not.
- **A perfect 100** — genuine but rare for a real business site. Say so, and note that field data (if present) matters more.