Core Web Vitals

Last updated 28 October 2026

Quick answer

Core Web Vitals are Google's field metrics for loading, responsiveness, and visual stability. The three current metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). In A/B testing, it helps teams protect page speed and user experience while variants, scripts, and tracking are running.

Key takeaways

The current trio is Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift.
A client-side variant can delay the largest element, slow the next interaction, or move the layout. That can masquerade as a losing test.
Mida's own notes focus on applying changes early and on keeping anti-flicker in the head with a timeout.

Definition

Core Web Vitals are Google's field metrics for loading, responsiveness, and visual stability. The three current metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). An A/B test can move all three, so they belong in the experiment as guardrails.

What Core Web Vitals means in A/B testing

LCP is the render time of the largest image, video, or text block in the viewport. A good field LCP is 2.5 seconds or less. INP, which replaced First Input Delay on 12 March 2024, measures how quickly the page responds to taps, clicks, and key presses across the visit. A good INP is 200 milliseconds or less. CLS scores unexpected layout movement. A good CLS is 0.1 or less. Google evaluates them at the 75th percentile of real visits, separately for mobile and desktop. Lab tools such as Lighthouse approximate the same ideas. They are not the field score.

Why Core Web Vitals matters

A variant that loads a heavier hero, injects a late banner, or waits on a testing script can lose the test because the page got worse, not because the copy was worse. LCP is the usual victim of a late hero or a render-blocking script. CLS is the usual victim of flicker: the control paints, then the variant swaps it. INP suffers when variant code does a lot of work on the click that was supposed to be the conversion. Search uses the field scores as a ranking signal, so a permanent rollout of a slow winner can also cost traffic. Mida's LCP and Largest Contentful Paint entries are the same metric, spelled two ways.

Example of Core Web Vitals

Control product pages have a field LCP of 2.2 seconds and a CLS of 0.05. Variant B replaces the hero with a larger image and a client-side badge. In the lab, LCP moves to 3.4 seconds and CLS to 0.22 because the badge pops in after the title. Add-to-cart rate is up 3% after a week. The primary metric says continue. The vitals say the lift may be the badge's novelty sitting on a worse page. The team compresses the hero and reserves space for the badge, then restarts, instead of shipping the slow version.

How to use Core Web Vitals

Record the field LCP, INP, and CLS for the template before the test, on mobile and desktop. Preview the variant and look for a flash of the control, a hero that arrives late, and a click that feels stuck. If any vital crosses from good into poor only on the variant, treat that as a failed QA check even if the conversion rate is ahead. After launch, watch the same template so the rollout does not quietly move the 75th percentile.

Common mistake

A common mistake is quoting one Lighthouse score as the Core Web Vitals result. The ranking signal is the 75th percentile of Chrome field data. Another is hiding flicker with an anti-flicker snippet that has no timeout: the page stays blank, LCP gets worse, and the test measures the blank screen. The anti-flicker script needs a short maximum wait so the control can paint if the variant never arrives.

How Mida works with Core Web Vitals

Mida does not replace a vitals report. The product notes that apply here are about when the variant is applied. The lightweight testing page says the loader identifies the visitor, assigns the experiment, checks targeting, and applies the variation, and that extra tools load only when needed, specifically to limit damage to LCP. The visual-editor notes say the script is meant to apply the change before the visitor sees the control. The anti-flicker article says a snippet without a timeout can block rendering and hurt Largest Contentful Paint, and that a timeout in the one-to-three-second range lets the page paint anyway.

The QA checklist puts that snippet in the head, before the main script, once, and not via a tag manager. Flickering and STTV are the glossary entries for the flash and for the time until the variant is visible. There is no /integration/ page for Core Web Vitals, because they are metrics, not a tag you connect.

Related A/B testing terms

FAQ

Which thresholds count as good?

Google's published good ranges are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less. The needs-improvement bands run up to 4 seconds, 500 milliseconds, and 0.25. Above those, the score is poor. Field data, not a single lab run, is what Search uses.

Did First Input Delay stay a Core Web Vital?

No. Interaction to Next Paint replaced First Input Delay as the responsiveness vital on 12 March 2024. A write-up that still lists FID as one of the three current vitals is out of date. FID can still appear in older reports.

Should a slower variant be shipped if the conversion rate is higher?

Only with your eyes open. The conversion rate during the test already includes visitors who tolerated the delay. After the test, the same delay hits everyone, including people who would have bounced before converting. Treat LCP, INP, and CLS as guardrails next to the primary metric, and do not ship a win that clearly worsens them unless you have accepted that cost.