Core Web Vitals

Core Web Vitals are a set of metrics used to describe important parts of website performance. They focus on how quickly major content appears, how promptly the page responds to interaction and how stable the layout remains.

The current metrics are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, usually called LCP, INP and CLS. They provide a shared language for investigating performance, but they do not describe every aspect of a useful website.

What is Largest Contentful Paint?

Largest Contentful Paint measures when the largest eligible content element in the viewport is rendered. It provides a signal about when the main visible content has appeared.

A good LCP is 2.5 seconds or less. The important element might be a prominent image or a substantial block of text, depending on the page.

When investigating a slow result, establish which element is being measured. Optimising an unrelated image may have little effect if the delay concerns the main content or the resources needed to display it.

What is Interaction to Next Paint?

Interaction to Next Paint assesses responsiveness to user interactions across the visit. It concerns the delay between an interaction and the next visual update, with the metric designed to reflect slower interaction experiences.

A good INP is 200 milliseconds or less. The result is particularly relevant when a page appears loaded but menus, buttons or other controls feel slow to respond.

A page can therefore have acceptable loading performance and still provide a frustrating interaction. Investigate the behaviour people experience rather than assuming that a fast initial appearance means the task works well.

What is Cumulative Layout Shift?

Cumulative Layout Shift measures unexpected visual movement in the layout. A good CLS score is 0.1 or less.

Unexpected shifts can make reading and interaction difficult. Someone may be about to select a control when late-arriving content moves it. The performance problem then becomes a practical usability problem.

Investigations should identify which elements move and why. Images without reserved space, late-inserted content and changing layouts are examples of conditions worth examining, depending on the actual evidence.

How are the thresholds assessed?

Core Web Vitals assessments use the 75th percentile of measured experiences, with mobile and desktop considered separately. This focuses attention on how a substantial majority of visits perform.

A single fast test does not prove that real visitors consistently receive the same result. Devices, network conditions, content and interaction patterns can vary.

The thresholds are a useful diagnostic framework. They should be read alongside the amount, source and scope of the data rather than treated as a complete verdict on the website.

Field data versus laboratory tests

Field data describes measured experiences from real use. Laboratory testing examines a page under controlled conditions. Both are useful, but they answer different questions.

A laboratory run can help reproduce and investigate a problem. Field data helps establish how the page behaves across actual visits. Differences between them are a reason to investigate the conditions.

A new or low-traffic page may not have enough eligible field data for a public assessment. That absence does not automatically mean it performs well or poorly.

What should you investigate first?

Begin with important pages and tasks. A slow product page or an unresponsive enquiry journey may deserve attention before a minor issue on an obsolete article.

Use the available evidence to identify a cause. Large assets, resource loading, script activity and layout behaviour can contribute in different ways. A general instruction to “improve speed” gives a developer less direction than a specific measured problem.

After making a change, test the relevant behaviour again. The fix should address the observed issue without breaking the content or interaction.

Do Core Web Vitals affect SEO?

Google recommends good Core Web Vitals as part of a strong page experience. Passing the thresholds does not guarantee high rankings, and a useful answer still needs to be relevant to the search.

A page with excellent performance can contain weak information. A detailed page can also need technical improvement. Treat content and performance as connected responsibilities rather than substitutes.

See technical SEO for the broader foundation and search intent for the relationship between a query and its answer.

Why a perfect score is not the whole objective

Performance tools can encourage teams to chase a single visible number. That can be useful for identifying work, but the score should not replace the experience the website needs to deliver.

Removing essential functionality may improve a test while making the service less useful. Conversely, a heavy decorative feature may add little value relative to its cost.

Make those trade-offs explicitly. Ask what a feature contributes, how often it is needed and whether there is a lighter way to achieve the same purpose.

How should performance be maintained?

Check representative templates and important journeys after meaningful changes. New imagery, scripts, integrations and content can alter performance after the original build.

Assign responsibility for monitoring and response. A problem becomes easier to manage when the team knows what is being measured and who investigates a material regression.

For definitions and thresholds, see web.dev's Web Vitals guidance and its threshold explanation. Explore Linford websites for the relationship between performance and the wider experience.