Core Web Vitals: a business guide to loading, interaction and stability
A performance score is useful only when you understand the experience behind it. Learn what to measure and how to prioritise a fix.
Samin Panah · Updated October 19, 2026
Three metrics, three different problems
Largest Contentful Paint, or LCP, measures when the largest visible content element is rendered. Interaction to Next Paint, or INP, describes responsiveness to user interactions. Cumulative Layout Shift, or CLS, measures unexpected visual movement. Together they cover important parts of the experience, but they do not describe every aspect of usability or accessibility.
web.dev's good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1. Assessment uses the 75th percentile of visits, separated by device type. These are experience thresholds, not guarantees that a visitor will buy or that a page will rank above a competitor.
Use lab tests to diagnose, field data to understand visits
A lab test runs under a controlled environment and can expose heavy media, blocking work or unstable layout. Its result depends on the simulated conditions. Real-user data reflects actual visits across devices and connections. A fast development laptop can hide problems experienced by someone on a slower phone.
When field data is missing or sparse, say so. Do not label the site healthy simply because one test looks good. Use available lab evidence to prioritise investigation and collect appropriate real-user signals when possible. Compare like-for-like page types and devices rather than combining unrelated experiences into one flattering average.
Find what delays the first useful screen
Inspect which element is the largest content and how it is delivered. A large image, delayed font or video-heavy introduction can affect loading. Make sure important content does not depend on an unnecessary chain of requests. Use correctly sized media and prioritise what the first screen actually needs.
Avoid applying a blanket rule that every asset should load immediately. Content lower on the page can often wait, while the main image needs a different priority. Test changes with the actual design and source media. Compressing an asset so aggressively that a product or portfolio example becomes unreadable is not a successful optimisation.
Keep interactions responsive and layout predictable
Long tasks can make a button or form feel unresponsive even after the page appears loaded. Investigate expensive event handlers, excessive updates and third-party scripts. Show clear progress during a genuine wait, but do not use a spinner to conceal avoidable blocking work. The control should respond to the action the user took.
Reserve space for images, embedded content and dynamic messages. A form should not jump away from a user's pointer when validation appears. Test the page after media loads, after a language change and during slower network conditions. Layout stability matters throughout the visit, not only in an empty screenshot.
Connect performance work to the site's purpose
Prioritise important conversion paths and repeated experience problems. Monitor completed tasks alongside performance, and distinguish correlation from a controlled result. A published company's conversion lift can show that performance matters in that context; it cannot predict the effect of your own change.
My product and web service joins performance work to conversion-focused design and analytics. Bring the pages that matter commercially and any available field evidence. The right plan identifies the experienced bottleneck, fixes it and checks the result rather than optimising for a score without a clear user benefit.
Is a perfect performance score the right launch requirement?
Not necessarily. A score can help compare controlled tests, but a launch decision also needs functional checks, accessible interactions, clear content and dependable submission paths. Decide which experience requirements are essential for the site's actual audience. Do not trade away readable product media or necessary functionality simply to improve a single synthetic number.
When a metric remains poor, identify its concrete cause and affected visits. A known loading problem on an important page deserves a plan; a missing field-data sample deserves a limitation statement. Review the whole experience after the repair, including whether a user can still inspect the work and complete the intended task. Performance should support the product rather than replace its purpose.