Core Web Vitals
How Coframe interacts with LCP, CLS, and INP — and how to keep them healthy
Copy this guide and your current settings as a prompt for your AI agent.
Preview agent promptSee the guide, code and settings included when you copy.
Core Web Vitals are the set of real-user experience metrics that Google uses to measure page quality. There are three: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). Each has a published “good” threshold. Understanding how Coframe’s installation pattern interacts with each metric helps you maintain healthy scores as you roll out experiments and personalization.
| Metric | Measures | “Good” threshold |
|---|---|---|
| LCP | Loading performance — time until the largest visible content element is painted | < 2.5 s |
| CLS | Visual stability — total unexpected layout shift during the page’s lifetime | < 0.1 |
| INP | Responsiveness — delay from user interaction to next visual update | < 200 ms |
Thresholds are from the web.dev Core Web Vitals definition. These are published web standards, not Coframe measurements — Coframe does not set or guarantee targets for these metrics.
On this page
01LCP
LCP marks when the browser has painted the largest text or image element in the viewport. For most content-rich pages this is a hero image, a large heading, or an above-the-fold block.
The anti-flicker snippet hides <body> via a CSS opacity rule immediately on
page load, then reveals it once the SDK has applied its changes or timeoutMs
has elapsed — whichever comes first. The default timeoutMs in the generated
install script is 1000 ms. Because LCP is measured from when content becomes
visible, any element inside <body> that is the LCP candidate while hidden will
not register as painted until after the reveal. The anti-flicker window is
therefore a direct input to LCP on pages where Coframe is active.
The reveal is fail-open: show() is always called, even if the SDK fails to
load, so the page is never permanently hidden. Keeping timeoutMs as short as
your variant-load latency allows is the primary LCP lever available to you.
For tooling to measure and monitor LCP before and after rollout, see LCP Monitoring.
02CLS
CLS measures unexpected layout shifts: elements that move, change size, or push other content during the page’s lifetime. The most common causes are images without reserved dimensions, banners injected late into the DOM, or content that reflows after the initial paint.
Coframe’s anti-flicker mechanism addresses this at the reveal boundary. Rather
than swapping content after the page is already visible to the user — which would
cause a measurable layout shift — the snippet keeps the page hidden via a CSS
opacity rule and reveals it through a short opacity transition
(transition: opacity 0.2s ease). Content replacement happens while the page is
still hidden, so from the user’s perspective the layout is stable by the time
anything becomes visible.
This is not a guarantee of zero CLS. If a Coframe variant changes element dimensions significantly, and the browser has recorded a layout baseline before those elements were hidden, a layout shift event is still possible. The opacity-based reveal reduces the most common source of variant-driven layout shift, but it does not eliminate every possible cause.
For the full anti-flicker mechanism and its installation requirements, see Anti-Flicker.
03INP
INP measures the delay between a user interaction — click, tap, keyboard press — and the next visual update. High INP is usually caused by long tasks blocking the main thread.
The Coframe SDK script is loaded with the async attribute (script.async = true
in the install snippet). An async script does not block the HTML parser or hold up
the main thread during initial page load. The SDK’s work — fetching project data,
selecting variants, applying changes — happens after the initial parse completes
and does not execute synchronously on the critical path.
The synchronous part of the Coframe installation is only the anti-flicker snippet itself, which is a small inline IIFE. It is intentionally synchronous so it can hide the body before first paint, but its execution time is negligible compared to a full script load.
No Coframe-specific INP targets or overhead numbers are published. If you observe
elevated INP on a page where Coframe is active, the
Testing and Validation checklist
describes how to isolate Coframe’s contribution by loading the page with
?cf_disabled.
04Validating Impact
Comparing measurements with and without Coframe active is the reliable way to
quantify its contribution to any Core Web Vital. Load your page with ?cf_disabled
appended to the URL to disable Coframe for that request, then measure using the
browser’s Performance panel or Lighthouse. Compare those results against
measurements taken on a normal page load.
For a step-by-step validation checklist, including how to measure LCP impact, see Testing and Validation. For ongoing monitoring guidance, see Performance Validation.
# Core Web Vitals How Coframe interacts with LCP, CLS, and INP — and how to keep them healthy Core Web Vitals are the set of real-user experience metrics that Google uses to measure page quality. There are three: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). Each has a published “good” threshold. Understanding how Coframe’s installation pattern interacts with each metric helps you maintain healthy scores as you roll out experiments and personalization. Metric | Measures | “Good” threshold | LCP | Loading performance — time until the largest visible content element is painted | < 2.5 s | CLS | Visual stability — total unexpected layout shift during the page’s lifetime | < 0.1 | INP | Responsiveness — delay from user interaction to next visual update | < 200 ms | Thresholds are from the [web.dev Core Web Vitals](https://web.dev/articles/vitals) definition. These are published web standards, not Coframe measurements — Coframe does not set or guarantee targets for these metrics. ## LCP LCP marks when the browser has painted the largest text or image element in the viewport. For most content-rich pages this is a hero image, a large heading, or an above-the-fold block. The anti-flicker snippet hides `<body>` via a CSS opacity rule immediately on page load, then reveals it once the SDK has applied its changes or `timeoutMs` has elapsed — whichever comes first. The default `timeoutMs` in the generated install script is 1000 ms. Because LCP is measured from when content becomes visible, any element inside `<body>` that is the LCP candidate while hidden will not register as painted until after the reveal. The anti-flicker window is therefore a direct input to LCP on pages where Coframe is active. The reveal is fail-open: `show()` is always called, even if the SDK fails to load, so the page is never permanently hidden. Keeping `timeoutMs` as short as your variant-load latency allows is the primary LCP lever available to you. For tooling to measure and monitor LCP before and after rollout, see [LCP Monitoring](../docs/lcp-monitoring.html). ## CLS CLS measures unexpected layout shifts: elements that move, change size, or push other content during the page’s lifetime. The most common causes are images without reserved dimensions, banners injected late into the DOM, or content that reflows after the initial paint. Coframe’s anti-flicker mechanism addresses this at the reveal boundary. Rather than swapping content after the page is already visible to the user — which would cause a measurable layout shift — the snippet keeps the page hidden via a CSS `opacity` rule and reveals it through a short opacity transition (`transition: opacity 0.2s ease`). Content replacement happens while the page is still hidden, so from the user’s perspective the layout is stable by the time anything becomes visible. This is not a guarantee of zero CLS. If a Coframe variant changes element dimensions significantly, and the browser has recorded a layout baseline before those elements were hidden, a layout shift event is still possible. The opacity-based reveal reduces the most common source of variant-driven layout shift, but it does not eliminate every possible cause. For the full anti-flicker mechanism and its installation requirements, see [Anti-Flicker](../docs/anti-flicker.html). ## INP INP measures the delay between a user interaction — click, tap, keyboard press — and the next visual update. High INP is usually caused by long tasks blocking the main thread. The Coframe SDK script is loaded with the `async` attribute (`script.async = true` in the install snippet). An async script does not block the HTML parser or hold up the main thread during initial page load. The SDK’s work — fetching project data, selecting variants, applying changes — happens after the initial parse completes and does not execute synchronously on the critical path. The synchronous part of the Coframe installation is only the anti-flicker snippet itself, which is a small inline IIFE. It is intentionally synchronous so it can hide the body before first paint, but its execution time is negligible compared to a full script load. No Coframe-specific INP targets or overhead numbers are published. If you observe elevated INP on a page where Coframe is active, the [Testing and Validation](../docs/testing-and-validation.html) checklist describes how to isolate Coframe’s contribution by loading the page with `?cf_disabled`. ## Validating Impact Comparing measurements with and without Coframe active is the reliable way to quantify its contribution to any Core Web Vital. Load your page with `?cf_disabled` appended to the URL to disable Coframe for that request, then measure using the browser’s Performance panel or Lighthouse. Compare those results against measurements taken on a normal page load. For a step-by-step validation checklist, including how to measure LCP impact, see [Testing and Validation](../docs/testing-and-validation.html). For ongoing monitoring guidance, see [Performance Validation](../docs/performance-validation.html). ## Related - [Anti-Flicker](../docs/anti-flicker.html) — how the snippet works and why it must be installed synchronously - [LCP Monitoring](../docs/lcp-monitoring.html) — tooling for measuring LCP before and after rollout - [Performance Validation](../docs/performance-validation.html) — ongoing performance monitoring guidance - [Testing and Validation](../docs/testing-and-validation.html) — step-by-step verification checklist - [SDK Delivery and Versioning](../docs/delivery-and-versioning.html) — how the script tag and edge worker deliver the SDK