If you manage websites for clients, you have probably heard some version of this question: "Is the site fast?" Usually the answer comes from a quick test run on one laptop, a screenshot of a score, or a gut feeling. That approach breaks down quickly. Scores fluctuate, lab tests don't match what real visitors experience, and a single good result says little about the pages that matter most to a business. Setting up proper Core Web Vitals monitoring replaces guesswork with measured data, so you can see which pages struggle, on which devices, and whether your changes actually helped. This guide walks through how to do that for a client website, from choosing the right metrics to building a monitoring routine that holds up over time.

What Core Web Vitals Actually Measure

Core Web Vitals are a set of three user-experience metrics that Google uses as part of its page experience signals. They focus on loading, interactivity, and visual stability. Each one captures a different thing a visitor notices.

• Largest Contentful Paint (LCP) measures how long it takes for the largest visible content element, usually a hero image, a banner, or a main text block, to render. Google's guidance treats 2.5 seconds or less as good at the 75th percentile of page loads.
• Interaction to Next Paint (INP) replaced First Input Delay as the responsiveness metric in March 2024. It measures the delay between a user interaction, such as a click, tap, or key press, and the next visual update. A good INP is 200 milliseconds or less.
• Cumulative Layout Shift (CLS) measures unexpected movement of visible elements while the page loads. A score of 0.1 or less is considered good.

The thresholds are evaluated at the 75th percentile, meaning three out of four page views should meet the target. This detail matters for monitoring, because averages can hide a lot. A site with a fast average can still have a painful experience for a meaningful share of visitors, especially on slower mobile connections.

For the current definitions and thresholds, the official reference is maintained at web.dev's Core Web Vitals documentation. Check it periodically, since metric definitions have changed before.

Lab Data and Field Data: Why You Need Both

Most guesswork comes from confusing two kinds of data. Understanding the difference is the foundation of any reliable monitoring setup.

Lab data is collected in a controlled environment. A tool loads your page with a simulated device and network connection, then records the metrics. Lighthouse, WebPageTest, and the PageSpeed Insights lab section all produce lab data. Lab data is excellent for debugging because it is repeatable. If you change an image and rerun the test, you can see the effect directly.

Field data, sometimes called Real User Monitoring (RUM), comes from actual visitors using real devices on real networks. The Chrome User Experience Report (CrUX) is the main public source for field data on Core Web Vitals. It aggregates anonymised data from Chrome users who have opted in to usage statistics, and it is only published for origins and pages with enough traffic to meet privacy thresholds.

The practical implication is simple. Lab data tells you what could be wrong and helps you fix it. Field data tells you what real users are experiencing. A page can score 95 in a lab test and still show poor INP in field data because real visitors are on mid-range Android phones doing things your test script never does, like opening menus or typing into a search box. Good monitoring uses lab data for diagnosis and field data for judging success.

Step 1: Set Up a Baseline Before Changing Anything

Before you optimise anything, record where the site stands. Without a baseline, you cannot prove that a change helped, and clients will eventually ask.

1. Identify the key page templates. Most websites are built from a handful of templates: homepage, product or service pages, category pages, blog posts, and checkout or contact pages. Monitor each template, not just the homepage. A site often looks fine on the homepage and fails on its product template.
2. Check whether field data exists. Enter the client's domain or specific URLs into PageSpeed Insights and look at the "Discover what your real users are experiencing" section. If you see a notice that there is not enough data, the site may be too low-traffic for CrUX to report on it. In that case, you will need your own RUM tooling, covered below.
3. Record the 75th percentile values for LCP, INP, and CLS on mobile and desktop separately. Mobile usually performs worse and deserves its own tracking, since many sites receive most of their traffic from phones.
4. Save the date and the scope. Note which URLs were tested, which device type, and the date. CrUX data is a rolling window, typically covering the previous 28 days, so the date matters when you compare results later.

Step 2: Use the Right Tools for Each Job

You do not need a dozen tools. A small, well-chosen stack covers most client work.

For most client sites, the combination of Search Console for trend-level monitoring, PageSpeed Insights for per-URL checks, and Lighthouse or WebPageTest for debugging covers the essentials. If the client's traffic is too low for CrUX, or if they need detailed segmentation, the web