# Page experience and Core Web Vitals

Core Web Vitals are three field metrics: **LCP**, how long until the largest piece of content appears; **INP**, how long the page takes to respond to interactions; and **CLS**, how much the layout moves under the reader. They are measured from real visits at the 75th percentile, so a fast test on your own machine says almost nothing about them.

- **Status:** Reference
- **Audience:** both, developer
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/technology/core-web-vitals/

## The three metrics, and what actually causes each

| Metric | Good at p75 | Dominant causes |
|---|---|---|
| LCP — Largest Contentful Paint | 2.5 s or less | Slow first byte; render-blocking CSS and fonts; the hero image discovered late or not preloaded |
| INP — Interaction to Next Paint | 200 ms or less | Long JavaScript tasks blocking the main thread; heavy event handlers; layout thrash on input |
| CLS — Cumulative Layout Shift | 0.1 or less | Images and embeds without dimensions; fonts swapping to a different metric; content injected above what is being read |

INP replaced First Input Delay because delay was the wrong thing to measure: it timed how long before the handler started, not how long before the reader saw a result. A page could score perfectly and still feel unresponsive. INP measures the whole interaction through to the next paint, which is what a person experiences.

All three are collected from real visits, on real devices and networks. That is why the 75th percentile matters: it is a promise about the slower quarter of your readers, not about a laptop on office broadband.

## What a documentation site should fix first

The metric profile of a text-heavy reference site is unusual, and the generic advice — reduce JavaScript, defer scripts, code-split — is mostly aimed at problems it does not have.

1. **Time to first byte.** LCP cannot be better than the moment the HTML arrives. On static pages this is the whole game.
2. **Fonts.** A web font that blocks rendering delays LCP; one that swaps late causes CLS. Subset it, self-host it, and give it a fallback with similar metrics.
3. **Dimensions on every image and embed.** The cheapest CLS fix there is: reserve the space before the asset loads.
4. **Stylesheet weight and order.** CSS is render-blocking by definition. A large ordered set of layers is fine if it is one request; it is not fine as fifty.
5. **Nothing injected above the fold after load.** A banner that appears a second in pushes the paragraph the reader had started down the page.

INP rarely needs attention on a page with no script, because there is no main-thread work to block an interaction. That is worth knowing before spending a week on it.

## Does Connect use Core Web Vitals as a target?

**Educational, with two design decisions that address the metrics directly.** No published Core Web Vitals figures exist for this site and none are invented here — a number quoted without a measurement behind it would be exactly the kind of claim this corpus refuses to make. What can be stated is what the delivery does.

- **The documentation pages carry no JavaScript.** There is no script to parse, no hydration step and no main-thread work between the HTML arriving and the page being usable. The whole INP category is structurally absent rather than optimised away.
- **Static assets are served `no-cache, must-revalidate`.** This is a correctness choice, not a speed one, and it is an honest trade: a revalidation round trip per asset is spent to guarantee a browser cannot mix modules from two releases. Conditional requests keep the cost to a 304 rather than a re-download.

The application at `/app` is a different kind of artefact and is not compared with the documentation here. It is an interactive workspace, excluded from search indexing by a `noindex` tag, and page-experience metrics designed for indexed landing pages are not the right instrument for it.

## Measuring honestly

**Lab is not field** — A synthetic run measures one device on one network. It is excellent for finding a regression and cannot tell you what your readers experience.
**The 75th percentile moves for reasons you did not cause** — A change in the mix of devices or countries visiting shifts the number without any change to the site.
**Averages hide the problem** — The metric is defined at p75 precisely because the mean is dominated by the fast majority.
**Attribution beats a score** — Knowing that LCP is 3.1 s is not actionable. Knowing that the LCP element is a font-swapped heading is.

> **Careful** Do not tune for a score. The metrics are proxies for how a page feels; a page can be made to score well and read worse — deferring the text that is the reason the reader arrived is the classic example.

## Questions

### Do Core Web Vitals affect search rankings?

They are part of a page-experience signal, and they are much weaker than relevance. A slow page that answers the question outranks a fast one that does not. Treat them as a reason to fix a genuinely poor experience rather than as a lever to pull for position.

### Why does my page score well in a lab test and badly in the field?

Because the two measure different things. Lab tools run one page load on a chosen device and network; field data comes from real visits at the 75th percentile, including slow phones, poor connections and cold caches. A large gap between them usually points at a first-byte or a font problem that a warm local run never sees.

### Is a JavaScript-free page automatically fast?

It removes the largest cause of poor INP and a common cause of poor LCP, which is a considerable head start. It does nothing about a slow server, an oversized image or a font that blocks rendering — those are the three that remain, and on a static site they are usually the only three.

## Related

- [HTTP caching and revalidation](https://connectbyjbrh.com/docs/technology/http-caching/)
- [Content Security Policy](https://connectbyjbrh.com/docs/technology/csp/)
- [Web accessibility](https://connectbyjbrh.com/docs/technology/accessibility/)
- [HTTPS and TLS](https://connectbyjbrh.com/docs/technology/https/)
- [Virtualised rendering](https://connectbyjbrh.com/docs/technology/virtualised-rendering/)

## What this page is based on

- web.dev — Core Web Vitals definitions and thresholds, https://web.dev/articles/vitals
- web.dev — Interaction to Next Paint, https://web.dev/articles/inp
- Connect application delivery — documentation pages carry no JavaScript; static assets are served `no-cache, must-revalidate`
- Connect capability registry (docs-source/facts.py) — public_docs; no measured page-experience figures are recorded