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.
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.
- Time to first byte. LCP cannot be better than the moment the HTML arrives. On static pages this is the whole game.
- 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.
- Dimensions on every image and embed. The cheapest CLS fix there is: reserve the space before the asset loads.
- 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.
- 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.
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.