# Website Speed Report, montagemotion.com

> **What this document is.** A point-in-time speed audit of https://montagemotion.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.5.0, 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 (72/100,
> grade C). 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 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: Next.js.** 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://montagemotion.com/","visibility":"listed","strategy":"both","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: 88/100. Grade B · Level 4 (Fast) — graded on the desktop run**

- Scanned: 2026-09-22T15:34:19.693Z
- Requested URL: https://montagemotion.com/
- Final URL: https://montagemotion.com/
- Requested strategy: both
- Visibility: listed; an unlisted report is still accessible to anyone holding its link
- Lighthouse analysis (desktop): 2026-09-22T15:34:00.550Z
- Report (HTML): https://xspeedcache.com/scan/r/montagemotion-com-be40ca2a92
- Report (JSON): https://xspeedcache.com/api/scan/montagemotion-com-be40ca2a92
- 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:**

- Your HTML came back HIT from the Next.js render cache — the render is already being reused, so look at the client bundle next.
- A crawler reads about 9,886 characters of text from your HTML.
- Time to first byte measured 145ms 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 | 145ms |
| Lighthouse performance (desktop) — graded | 97/100 |
| Lighthouse performance (mobile) | 76/100 |
| Reproduce the desktop run | https://pagespeed.web.dev/analysis?url=https%3A%2F%2Fmontagemotion.com%2F&form_factor=desktop |
| Largest Contentful Paint | 1.1s |
| Cumulative Layout Shift | 0.000 |
| Total Blocking Time | 0ms |
| HTML compression | br |
| Served from cache | yes (HIT) |
| Redirects before final URL | 0 |

## Real visitors (Chrome UX Report)

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

| Metric | p75 | Verdict |
|---|---|---|
| Largest Contentful Paint | 1.8s | good |
| Interaction to Next Paint | 79ms | good |
| Cumulative Layout Shift | 0.04 | good |

## Dimension scores

| Dimension | Score | Grade | Points |
|---|---|---|---|
| Lab performance (Lighthouse) | 99/100 | A+ | 39.5/40 |
| Server response & caching | 92/100 | A | 27.5/30 |
| Asset optimization | 56/100 | D | 9/16 |

## Lab performance (Lighthouse): 99/100 (A+) · 39.5/40 pts

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

- Evidence: 97/100 (Lighthouse 13.5.0, 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 1.1s
- 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 0ms
- Guidelines: [web.dev — Total Blocking Time](https://web.dev/articles/tbt)

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

- Evidence: FCP 281ms
- 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 145ms 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 4ms 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: email-decode.min.js
- Suggested investigation: Give CSS/JS/images long Cache-Control lifetimes so repeat views are free.
- 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: 56/100 (D) · 9/16 pts

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

- Evidence: Fails the Lighthouse audit — 3 files: 40bt0c4lfq3gz.css, 2jhph4akbviz9.css, 2e0nv2zfx9m-q.css · ~200ms of first paint
- Suggested investigation: CSS/JS in <head> blocks first paint. Inline the critical CSS and defer the rest.
- 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% — 1 file: image
- Suggested investigation: Serve WebP/AVIF at the right compression — usually the single largest byte saving.
- 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
- Suggested investigation: Re-run when Lighthouse is available.
- 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.9MB transferred
- Guidelines: [Lighthouse — Total byte weight](https://developer.chrome.com/docs/lighthouse/performance/total-byte-weight)

## The mobile run: 72/100 (C) · Level 3 (Average)

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

Lighthouse analysis: 2026-09-22T15:34:00.681Z; replayed: no.

| Dimension | Score | Grade | Points |
|---|---|---|---|
| Lab performance (Lighthouse) | 64/100 | D | 25.7/40 |
| Server response & caching | 92/100 | A | 27.5/30 |
| Asset optimization | 56/100 | D | 9/16 |

### Checks that differ from the desktop run

- [PARTIAL] S1 · Lighthouse performance score (mobile) (13.7/18 pts) — 76/100 (Lighthouse 13.5.0, mobile) (desktop: PASS)
- [FAIL] S2 · Largest Contentful Paint ≤ 2.5s (0/8 pts) — LCP 4.9s (desktop: PASS)
- [PASS] S4 · Total Blocking Time ≤ 200ms (5/5 pts) — TBT 14ms (desktop: PASS)
- [PARTIAL] S5 · First Contentful Paint ≤ 1.8s (2/4 pts) — FCP 1.8s (desktop: PASS)
- [PASS] D1 · Time to first byte ≤ 200ms (8/8 pts) — TTFB 145ms 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 5ms from its own network — the gap between the two numbers is distance, not your server. (desktop: PASS)
- [FAIL] A1 · No render-blocking resources (0/5 pts) — Fails the Lighthouse audit — 3 files: 2jhph4akbviz9.css, 2e0nv2zfx9m-q.css, 40bt0c4lfq3gz.css · ~350ms of first paint (desktop: FAIL)
- [PARTIAL] A3 · Modern, optimized image formats (2/4 pts) — Lighthouse audit score 50% — 4 files: _next/image, _next/image, _next/image… (desktop: PARTIAL)
- [PASS] A5 · Total page weight ≤ 1.5MB (3/3 pts) — 0.8MB transferred (desktop: PASS)

## 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/montagemotion-com-be40ca2a92.md for requested URL https://montagemotion.com/ and final URL https://montagemotion.com/, selected desktop device, scanned 2026-09-22T15:34:19.693Z, rubric 2026.09.5. 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://montagemotion.com/","visibility":"listed","strategy":"both","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 montagemotion-com-be40ca2a92 · rubric v2026.09.5 · xSpeed Scan, https://xspeedcache.com/scan