Core Web Vitals in Practice: When Speed Matters—and When It Isn't the Main Problem

Core Web Vitals describe three important parts of a page experience: loading the main content, responding to interaction and maintaining visual stability. They are useful diagnostic signals, but they are not a complete measure of website quality. A fast page can still have an unclear offer, reach the wrong audience or send enquiries into a broken process.

The objective is not a perfect score in one test. It is to identify which metric affects real users, on which templates and for what technical reason.

What the three metrics measure

Largest Contentful Paint

Largest Contentful Paint measures how long it takes to render the largest visible content element in the initial viewport. This is often a hero image, prominent heading block or large section of text.

The recommended “good” threshold is an LCP of 2.5 seconds or less at the 75th percentile of page visits, assessed separately for mobile and desktop users.

A slow LCP can result from server response time, an oversized image, render-blocking styles, delayed font loading or a primary element inserted late by JavaScript.

Interaction to Next Paint

Interaction to Next Paint measures how quickly a page presents visual feedback after clicks, taps and keyboard interactions. It evaluates interactions throughout the visit rather than only the first one.

The recommended good threshold is 200 milliseconds or less at the 75th percentile.

Common causes of poor INP include long tasks on the browser’s main thread, expensive rendering, heavy event handlers and third-party scripts competing with the interface.

Cumulative Layout Shift

Cumulative Layout Shift measures unexpected movement of visible elements. A familiar example is a button moving immediately before a person clicks because an image or banner loads above it.

A CLS score of 0.1 or less is considered good.

Images without reserved dimensions, late-inserted content, poorly handled font swaps and layout-changing animations can all contribute to instability.

Field and laboratory data answer different questions

Laboratory tools load a page under controlled conditions. They are useful for repeatable tests, debugging and comparing a specific change. They cannot represent every device, network and browsing pattern.

Field data comes from real visits. It shows the range of actual experiences but requires sufficient traffic and does not update immediately after deployment.

Use the sources together:

• field data establishes whether real visitors experience the problem;
• laboratory tests reproduce it;
• browser profiling identifies the implementation cause.

One fast run on a developer laptop does not prove the site is fast for its audience. One poor synthetic result also does not reveal which users or journeys are affected.

Diagnose templates rather than isolated URLs

Pages sharing a template often share the same performance problem. If every service page uses the same hero, scripts and content structure, fixing one URL without addressing the component achieves little.

A useful sequence is:

1. identify the failing metric;
2. group affected pages by template;
3. reproduce the issue on a representative page;
4. isolate the technical cause;
5. make one controlled change;
6. check for functional and accessibility regressions;
7. monitor later field data.

This keeps optimization tied to the system rather than a screenshot of one score.

Review the usual sources of performance cost

Images

A primary image can delay LCP when it is too large, delivered in an unsuitable format, missing responsive variants or discovered late.

Reserve image dimensions to reduce layout shifts. Prioritize assets required for the initial viewport, but do not give every image equal loading priority.

Fonts

Multiple families, unnecessary weights and late downloads can delay text or cause visible movement. Use only the required files, preload genuinely critical assets and choose fallback fonts with compatible proportions.

Third-party scripts

Analytics, chat, video, maps, advertising and embedded forms compete for network and processing time.

For each script, ask whether it has a clear purpose, whether it must load immediately and whether it belongs on every page. A convenient installation snippet still has a runtime cost.

Animation

Animation is not inherently slow. Problems arise when it repeatedly changes layout, performs excessive work or competes with an active interaction.

Prefer properties that avoid layout recalculation, test on less capable devices and respect reduced-motion preferences.

Prioritize by user and business impact

Performance work deserves high priority when:

• main content appears noticeably late;
• controls respond with visible delay;
• movement causes mistaken interactions;
• an essential journey fails on weaker devices or networks;
• technical weight obstructs accessibility or routine use.

Core Web Vitals do not reveal whether the proposition is understandable, whether visitors are suitable or whether the company follows up on enquiries.

If a fast page cannot explain what the company offers, positioning and content deserve attention. If campaigns attract the wrong audience, reducing load time will not change that audience’s intent. If enquiry handling has no owner, faster submission does not repair the process.

Technical, editorial and operational problems should therefore be ranked together. The most visible metric is not automatically the most important constraint.

A developer-led technical SEO audit provides the wider context around rendering, indexing and internal structure. Performance requirements can also affect custom website scope and cost.

For diagnosis and implementation, see SEO and performance optimisation or share the affected pages through the contact section.

← Back to the blog