Measure in production: Core Web Vitals audit for developers and marketers

Measure It in Production: A Core Web Vitals Audit for Developers and Marketers

Core Web Vitals are three measurable metrics: LCP, INP, and CLS. The target at the 75th percentile is LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. You get field data from the Chrome User Experience Report and Google Search Console, and lab diagnostics from PageSpeed Insights and Lighthouse.

In short:

• For accurate diagnosis, analyzing field data from the Chrome User Experience Report and Search Console is essential, since it reflects real user experience.
• Suggested fixes include optimizing images, breaking up JavaScript tasks, and setting element dimensions, all of which directly improve LCP, INP, and CLS.
• When tackling issues, it's important to focus on INP, the most demanding of the three, since it only shows up during actual user interaction.
• By tracking data through the web-vitals library and segmenting by device, you can precisely identify which pages need optimization most.
• A comprehensive approach — review, diagnosis, action, and ongoing monitoring — delivers lasting improvements in user experience and SEO results.

Table of Contents

• What LCP, INP, and CLS Actually Measure
• Why Core Web Vitals Matter for Experience and SEO
• How to Measure Core Web Vitals: Field vs. Lab Data
• How to Fix Issues: Concrete Fixes for LCP, INP, and CLS
• How to Run a Core Web Vitals Audit in Practice
• Which Tools to Use and Where to Start Measuring
• How Moxy-web Approaches Improving Core Web Vitals
• What I Think Developers Most Often Get Wrong About Core Web Vitals
• How Moxy-web Helps Fix Core Web Vitals Issues
• Sources
• Frequently Asked Questions

What LCP, INP, and CLS Actually Measure

LCP (largest contentful paint) measures when the largest visible element loads within the viewport. Most often, that's a hero image, a video, or a block of headline text. INP (interaction to next paint) succeeded the FID metric and doesn't just measure the first click — it measures responsiveness across the entire visit session. It captures every interaction (click, tap, keypress) and estimates how much time passes before the browser next paints the screen.

CLS (cumulative layout shift) is a somewhat different animal. It's calculated as the sum of layout shifts within session windows, with each shift weighted by the size of the moved element and the distance it moved. Typical culprits behind poor CLS:

• images and ads without defined dimensions (width/height or aspect-ratio),
• custom fonts that load late and shift the text (FOIT/FOUT),
• dynamically inserted content (banners, cookie notices) without reserved space.

Understanding these three mechanics is a prerequisite for real diagnosis, not just superficially patching symptoms.

Why Core Web Vitals Matter for Experience and SEO

Google uses Core Web Vitals as part of its page experience assessment for ranking. That doesn't mean a fast site will automatically outrank content-wise better competition, since content quality remains decisive. But between two otherwise comparable pages, they act as a tiebreaker.

The business impact is even more tangible on the user experience side. Slow loading and an unstable layout can significantly affect whether a visitor stays on the page or closes the tab before ever seeing the offer.

Expert tip: Don't expect an immediate response in Search Console. The report is based on a 28-day rolling window of CrUX data, so improvements in field data only show up after about a month, and visible shifts in search results often only appear after two to three months.

How to Measure Core Web Vitals: Field vs. Lab Data

When deciding which tool to trust, a simple priority rule applies. Field data from the Chrome User Experience Report and Search Console shows what real visitors on real devices are actually experiencing, which is why it's decisive for SEO assessments. Lab data from PageSpeed Insights, Lighthouse, or Chrome DevTools is a simulation on one device at one connection speed, so it's excellent for diagnostics and testing fixes, but it doesn't reflect the spread of real traffic.

For your own production monitoring, it's worth installing the web-vitals library. It collects all three metrics in the visitor's browser and sends them to an analytics tool or your own database, forming the basis of so-called RUM (real user monitoring):

• install the library via npm or a CDN and listen for the onLCP, onINP, onCLS events,
• send the data along with information about the device, connection, and visitor path,
• segment the 75th percentile separately for mobile and desktop devices, since results often differ significantly between them.

Without this segmentation, a good average value can hide a serious mobile problem.

How to Fix Issues: Concrete Fixes for LCP, INP, and CLS

Fixes vary by metric, and priority should follow this logic:

1. LCP. Preload the key image or font with <link rel="preload">, compress and properly size images (WebP or AVIF), extract critical CSS for above-the-fold content, and reduce TTFB with a CDN or faster hosting.
2. INP. Break up long JavaScript tasks into smaller chunks (splitting "long tasks"), defer non-critical scripts with defer or async, and use web workers for intensive calculations so they don't block the main thread.
3. CLS. Always specify width and height or aspect-ratio for images and videos, reserve space for banners and ads before they load, and avoid animations that shift elements within the layout (use transform instead of top/left).

Some fixes are quick wins, like adding dimensions to images or switching to a CDN. Others, especially lowering INP on complex, highly interactive pages, often require architectural changes, such as splitting large JavaScript bundles or switching to a lighter framework. You can find concrete examples of these measures in this overview of the most common mistakes in web development.

Expert tip: INP is the toughest nut to crack for many sites, since it only shows up during actual user interaction. Field data is therefore practically essential for proper INP diagnosis, since a lab test only simulates interaction in a very limited way.

How to Run a Core Web Vitals Audit in Practice

A repeatable audit is a sequence of five steps: first, a field review in Search Console, where you identify URL groups flagged as Needs Improvement or Poor. Then you pick priority pages based on traffic and business value (for example, product pages or campaign landing pages). This is followed by lab analysis in Lighthouse or PageSpeed Insights for precise root-cause diagnosis. Then you implement fixes, and finally track the impact through RUM data and a repeat CrUX review.

Priority criteria should include:

• traffic volume for a given URL group,
• direct impact on revenue or conversions,
• the share of visitors actually affected by the metric.

Track results regularly, since the Search Console report updates with a delay, and a single good lab result doesn't mean the issue is fixed for every visitor. You can also find a detailed overview of page speed measures in this website optimization guide.

Which Tools to Use and Where to Start Measuring

Every tool has its own role. Search Console shows aggregated field data by URL group, PageSpeed Insights combines field and lab views for a single page, Lighthouse and Chrome DevTools allow for in-depth lab diagnostics with a "waterfall" loading view, and WebPageTest adds testing from multiple locations and devices. For your own field data, use the CrUX API or the web-vitals library, which you build directly into your site's code and send data from to your own analytics tool.

• Search Console: field data, URL groups, Good/Needs Improvement/Poor labels.
• PageSpeed Insights: a combination of field and lab data for a single page.
• Lighthouse/DevTools: a detailed lab waterfall for diagnosing individual causes.
• web-vitals library: RUM measurements directly from real visitors.

How Moxy-web Approaches Improving Core Web Vitals

The author of this guide, Žiga from the Moxy-web team, checks field data first on every project, then lab results. During the initial review, the client gets a concrete, prioritized list, not a general report. The focus is on actions that can be measured in the next CrUX cycle.

What I Think Developers Most Often Get Wrong About Core Web Vitals

The biggest mistake I see when working with teams isn't a lack of knowledge about the metrics — it's relying on a single Lighthouse test as a final verdict. A lab number from one device on one connection only tells you how a page performs under ideal conditions, not how a real visitor on an older phone with a slow network actually experiences it.

Another underrated issue is INP. Many teams still focus mainly on optimizing LCP, since it's the most visible and easiest to understand, and leave INP aside until a drop in Search Console alerts them. This is a misplaced priority, since INP is often the first metric to fall out of threshold on highly interactive pages, like filters, carts, or forms.

A third thing I recommend to every developer: don't fix things based on guesswork. Install the web-vitals library, see which page group is actually struggling, and only then touch the code. Speed without data is just a feeling, not a strategy.

— Ziga

How Moxy-web Helps Fix Core Web Vitals Issues

Instead of coordinating field data, lab tests, and code fixes yourself, you can hand the entire process over to a team that does it every day. Moxy-web reviews a business's current state, prepares a prioritized list of concrete fixes, and implements them too, without lengthy back-and-forth between a developer and an ad agency. The process is simple: first, a review of the existing site, then a proposal with clear steps, and finally implementation together with hosting and ongoing maintenance, so results don't degrade with the next upgrade. For online stores that also need to sort out payment acceptance alongside speed, it's also worth looking at solutions for POS terminals connected to an online store. If you'd like a concrete assessment of your site's current state and a proposed set of fixes, check out the offering at Moxy-web and request a review today.

Sources

• Understanding Core Web Vitals and Google search results
• Core Web Vitals
• Core Web Vitals report - Search Console Help

Frequently Asked Questions

What are Core Web Vitals?

Core Web Vitals are three Google user experience metrics: LCP for loading speed, INP for responsiveness, and CLS for a page's visual stability.

What are CLS and LCP?

LCP measures when the largest visible element on a page loads, while CLS measures how much elements unexpectedly shift around the screen while the page is loading.

Are Core Web Vitals still relevant in 2026?

Yes, Google continues to use them as part of its page experience assessment, and since its introduction, INP has become one of the hardest metrics to hit on interactive pages.

What counts as a good Core Web Vitals score?

A good score at the 75th percentile means LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1, while significantly higher values are typically rated as poor under the standards.

How quickly do Core Web Vitals improvements show up in field data?

Because the Chrome User Experience Report uses a 28-day rolling window, improvements in field data only show up after about a month, and any SEO effects typically appear after two to three months.

Recommended

• Page Load Speed: A Business Guide for Decision-Makers
• Why Testing Web Solutions Matters for Business Success
• A Website Development Checklist: A 2026 Guide
• The Role of Fast Page Loading for Business Owners in 2026