Core Web Vitals: Why site speed matters to your business

Start with measurement, not assumptions

Many performance conversations begin the same way: someone runs Lighthouse once, sees a red score, and immediately wants a list of fixes.

That test can be useful, but Google's Core Web Vitals assessments are based on field data from real users, devices, and network conditions. Lab and field results often differ, especially on marketing sites with large hero images, third-party scripts, or visual page builders.

Before changing hosting, removing plugins, or rebuilding the homepage, answer three questions:

1. What do your actual visitors experience at the 75th percentile?
2. Which area is causing problems: loading, interaction, or visual stability?
3. Is the issue site-wide or limited to particular pages and templates?

Tools I regularly use to establish that baseline include:

• Google Search Console: Core Web Vitals reports based on Chrome UX Report (CrUX) field data
• PageSpeed Insights: CrUX field data and Lighthouse lab data for individual URLs
• Chrome DevTools: Performance analysis for reproducing slow LCP elements, long main-thread tasks, and delayed interactions

If a URL does not receive enough traffic for page-level field data, origin-level data and lab tests can provide a useful starting point. Treat those results as a hypothesis until you can validate the effect of your changes with real-user data.

What Core Web Vitals measure

The Core Web Vitals are three metrics covering different parts of the user experience:

Google evaluates each metric at the 75th percentile of page views, separated by mobile and desktop. In practical terms, at least 75% of visits need to meet the “good” threshold. A page must have good results for all three metrics to pass the overall Core Web Vitals assessment.

LCP thresholds

• Good: 2.5 seconds or less
• Needs improvement: over 2.5 seconds and up to 4.0 seconds
• Poor: over 4.0 seconds

The LCP element is often a hero image, video poster, heading, or large text block near the top of the page.

Common causes of poor LCP include:

• slow server response time (TTFB)
• oversized or incorrectly sized images
• render-blocking CSS or JavaScript
• images and fonts discovered too late in the loading process
• applying lazy loading to the LCP image

INP thresholds

• Good: 200 milliseconds or less
• Needs improvement: over 200 milliseconds and up to 500 milliseconds
• Poor: over 500 milliseconds

INP evaluates the latency of clicks, taps, and keyboard interactions throughout a visit. It replaced FID (First Input Delay) as a Core Web Vital and gives a more complete picture of how responsive a page feels.

Common causes of poor INP include:

• excessive JavaScript
• long main-thread tasks
• large or poorly split bundles
• expensive event handlers
• third-party scripts, chat widgets, and tag managers
• components that perform unnecessary work on every interaction

A page can have a good LCP score and still feel sluggish when menus, filters, or forms respond slowly.

CLS thresholds

• Good: 0.1 or less
• Needs improvement: over 0.1 and up to 0.25
• Poor: over 0.25

CLS increases when visible elements unexpectedly change position. Common causes include:

• images and videos without defined dimensions
• banners or advertisements injected after the initial render
• embeds without reserved space
• web fonts that change the width or height of text
• dynamic content inserted above existing elements

Layout instability is more than a visual annoyance. Users can click the wrong button or link when an element moves during an interaction.

What this means for SEO, and what it does not

Google confirms that its ranking systems use Core Web Vitals. However, its official guidance on page experience in Google Search also makes clear that there is no single page-experience signal that determines rankings on its own.

In practice:

• Good Core Web Vitals can contribute to a stronger overall page experience and better search visibility.
• A completely green report does not guarantee higher rankings.
• Technical performance cannot compensate for irrelevant content or an unclear offer.
• A site can rank with “needs improvement” scores when its other signals are strong.
• Persistently poor scores on important pages remain an avoidable technical weakness.

Treat Core Web Vitals as measurable evidence of technical UX quality, not as a shortcut to better rankings.

Business impact: relevant, but not guaranteed

Speed, stability, and responsiveness often correlate with engagement and conversions. However, there is no universal “one second faster equals X% more revenue” rule that applies to every website.

Traffic source, audience, offer clarity, and sales cycle can matter more than any single technical metric.

On marketing and lead-generation sites, I often see:

• High mobile LCP accompanying higher bounce rates on landing pages, particularly with paid traffic.
• Poor INP making navigation and forms feel broken even when the design looks polished.
• High CLS causing accidental clicks and unnecessary frustration on content-heavy pages.

During one marketing-site performance pass, the GTmetrix grade improved from B to A, with approximately 91 Performance, 96 Structure, a 1.2-second LCP, 6-millisecond TBT, and zero CLS after disciplined work on images, fonts, and scripts.

TBT is a lab metric, not a replacement for INP field data. Results like these still demonstrate how much the technical foundation can improve when media, loading priorities, and JavaScript are handled carefully. The eventual business outcome continues to depend on the offer, content, and traffic quality.

A practical order for improvements

Once field data identifies a bottleneck, I usually work in the following order.

1. Start with the pages and templates that matter

Search Console groups URLs with similar issues. Prioritize templates that generate substantial traffic or important conversions.

Optimizing a low-traffic About page while the homepage or key landing pages remain slow is rarely the best use of time or budget.

2. Improve mobile LCP

• Compress hero images and serve them at the dimensions in which they are displayed
• Use modern image formats where they make sense for the stack
• Reduce TTFB through caching, hosting improvements, or a suitable CDN
• Ensure the browser discovers the LCP resource early in the HTML
• Do not lazy-load the LCP image
• Use fetchpriority="high" or preloading selectively when appropriate
• Avoid unnecessary autoplay video above the fold

3. Improve INP and JavaScript execution

• Defer non-critical scripts
• Break long tasks into smaller units of work
• Reduce unnecessary processing inside event handlers
• Remove unused libraries and page-specific code where it is not needed
• Audit tag managers, analytics scripts, and chat widgets
• Test real interactions on a mid-range Android device, not only in desktop Chrome

4. Prevent layout shifts

• Define dimensions or an aspect ratio for images, videos, and embeds
• Reserve space for advertisements, cookie notices, and dynamic content
• Avoid inserting banners above existing content without allocating space
• Use fallback fonts with metrics that closely match the final web font
• Consider CSS properties such as size-adjust, ascent-override, descent-override, and line-gap-override
• Choose font-display deliberately; swap alone does not automatically prevent layout shifts

Google's guide to optimizing CLS provides more detail on diagnosing and preventing these shifts.

5. Recheck field data after deployment

CrUX data updates over a rolling period. A green Lighthouse run on your computer does not immediately tell you what real visitors are experiencing.

Give the changes time, then review:

• the 75th percentile
• mobile and desktop results
• affected URL groups
• changes in conversions and user behaviour

Performance is ongoing maintenance

Every new plugin, A/B testing snippet, analytics tag, chat widget, or campaign block can cause Core Web Vitals to regress. That is normal on an evolving website.

Serious websites treat performance in the same way they treat security and content: as an ongoing responsibility, not a one-time optimization project after launch.

If you are planning a redesign or migration, include performance in the acceptance criteria:

1. Define the important pages and templates
2. Document field data before making changes
3. Set targets for LCP, INP, and CLS
4. Run lab tests before release
5. Review field data after launch
6. Continue monitoring for regressions

The practical decision is to treat Core Web Vitals as baseline technical UX indicators. Measure real-user experiences, fix the problems confirmed by field data, and continue monitoring as the website evolves.

Want to check your website's performance?

Contact me. We can review your field data, identify pages and templates with LCP, INP, or CLS problems, and prioritize improvements by expected effort and impact instead of following a generic checklist.