Core Web Vitals Test 2026: The 12-Step Field Guide

By Marcus Vega 2026-06-22 19 min read

A complete core web vitals test in 2026 grades exactly three field metrics: Largest Contentful Paint (LCP) under 2.5 seconds, Interaction to Next Paint (INP) under 200 milliseconds, and Cumulative Layout Shift (CLS) at or below 0.1, all measured at the 75th percentile of real visitors. A page passes only if all three clear the "good" threshold at the same time. That last rule trips up most teams: a 98 Lighthouse performance score means nothing if your INP sits at 240ms in the field. This guide walks through 12 concrete steps to run, read, automate, and fix a real core web vitals test using free tools and your own data.

What a core web vitals test actually measures in 2026

Core Web Vitals are Google's field-based page-experience metrics for loading, interactivity, and visual stability. The phrase "field-based" is the entire point, and it is the single fact most marketers get wrong. A core web vitals test is not a synthetic stopwatch you run once on your laptop. It is a verdict computed from anonymized telemetry sent by real Chrome users as they actually use your pages. Google's own Search Central documentation frames these as real-world user experience signals, not lab simulations.

In 2026 the core trio is fixed: LCP for loading, INP for responsiveness, and CLS for visual stability. INP fully replaced First Input Delay (FID) in March 2024, and by 2026 FID is gone from every reporting surface. The replacement matters because FID only measured the delay before the first interaction was processed, while INP measures the full latency of every interaction across the page lifecycle and reports a near-worst-case value. A button that feels snappy on the first click but janks on the tenth will pass FID and fail INP. The web.dev Web Vitals overview documents this shift in detail.

The evaluation window also confuses people. Google does not grade your average user. It grades your 75th-percentile user, meaning the experience that 25% of your page loads are worse than. If your median LCP is a clean 1.8 seconds but your p75 is 2.9 seconds, you fail. This is deliberate. Google wants the metric to reflect a broad slice of real conditions, including mid-range Android phones on congested mobile networks, not just the fast experiences that flatter your dashboard. Mobile and desktop are scored separately, and a page can pass on one and fail on the other.

The data source is the Chrome User Experience Report (CrUX), a public dataset aggregating real-user measurements from opted-in Chrome users across millions of origins. This is why PageSpeed Insights, Search Console, and CrUX can disagree with a Lighthouse lab run: they read different data. Understanding which surface reads field data and which reads lab data is the foundation of every reliable core web vitals test, and we will separate them precisely later in this guide. If you want a structured program around these signals, our technical SEO services build monitoring like this into client engagements.

The three metrics and their 2026 thresholds

Before running a single test you need the thresholds memorized, because the tools color-code results against them and you will misread the colors otherwise. Each metric has three bands: good, needs improvement, and poor. "Good" is the only band that counts as passing. "Needs improvement" is a polite way of saying failing. The thresholds below have been stable across Google's guidance since 2024, which is unusual and useful: you can build dashboards against them without fear of a moving target. The one change in recent years was the responsiveness metric itself swapping from FID to INP, not a threshold revision.

The table below lists every current Core Web Vital, its 2026 good and poor cutoffs, what it physically measures, and the most common root cause when it fails. Use this as the reference card you keep open while diagnosing a report.

Read this table top to bottom and a pattern appears. The three named Core Web Vitals (LCP, INP, CLS) are the metrics Google ranks against. The next three (TTFB, FCP, TBT) are diagnostic vitals: they are not scored for ranking, but they tell you why a Core Web Vital is failing. TTFB is a component of LCP, so a slow server poisons your loading score before a single byte of image is decoded. TBT is the lab-measurable proxy for INP, since you cannot measure real interactions in a synthetic test. When you optimize, you fix the diagnostic vitals and the named vitals follow.

Lab data versus field data: why your tools disagree

The most expensive misunderstanding in performance work is treating a Lighthouse score as a core web vitals test. They are different things measured from different data, and confusing them leads teams to ship "fixes" that move the lab number while the field number sits still. Industry guides are blunt about this: Core Web Vitals are measured from real user data collected via Chrome-based field signals, not synthetic tests, which is exactly why PageSpeed Insights, Search Console, and Lighthouse can return contradictory verdicts for the same URL on the same day.

Lab data

Lab data is generated by a synthetic test on demand. Lighthouse loads your page in a controlled environment with a fixed CPU throttle (4x slowdown by default), a simulated network (Slow 4G), and an empty cache. It is reproducible, fast, and available before you ship, which makes it ideal for catching regressions in development. But it is one load, on one simulated device, with no real-user variance. It cannot measure INP at all, because INP requires actual human interactions; Lighthouse reports Total Blocking Time as a proxy instead.

Field data

Field data is the CrUX dataset: a rolling 28-day aggregation of real Chrome users. It is what Google uses for the page-experience signal, and it is the only data that determines whether you pass. The tradeoffs are the inverse of lab data. Field data is real but slow to update, requires sufficient traffic to populate (low-traffic URLs show no field data at all), and reflects your visitors' devices and networks rather than a fixed simulation. A page that loads in 1.2 seconds on your office fiber connection can post a p75 LCP of 3.4 seconds in CrUX because a meaningful share of your audience is on older phones over LTE.

The practical rule: use lab data to debug and prevent regressions, use field data to judge whether you pass. When the two disagree, field data wins, because field data is what ranks. A 100 Lighthouse score with a failing CrUX INP means your synthetic test simply is not exercising the interactions your real users perform.

Prerequisites and tools with exact versions

You can run a basic core web vitals test in a browser with zero setup, but a real diagnostic and monitoring workflow needs a defined toolchain. Below is the stack this guide uses, with the versions current as of June 2026. Pin these or newer; older Lighthouse versions predate the INP-as-default change and will mislead you.

• Google Chrome 126 or newer: ships Lighthouse and the Performance panel, and is the browser whose users feed CrUX.
• Lighthouse 12.x: the CLI and DevTools audit engine. Version 12 reports INP-aligned diagnostics and TBT.
• Node.js 20 LTS or 22 LTS: required for Lighthouse CI, the web-vitals library, and the CrUX scripts below.
• web-vitals JavaScript library 4.x: the official Google library for measuring real-user vitals in your own analytics.
• Lighthouse CI (@lhci/cli) 0.14.x: runs Lighthouse in your build pipeline and asserts thresholds.
• A CrUX API key: free from the Google Cloud Console, enables programmatic field-data queries.
• A Google Search Console property: verified ownership of your domain, for the Core Web Vitals report.
• PageSpeed Insights: no install, browser-based, combines lab (Lighthouse) and field (CrUX) data in one report.

To confirm your local environment, run the versions check below. If any command errors or returns an older major version, update before continuing. The CrUX API key step requires enabling the "Chrome UX Report API" in a Google Cloud project, then generating an API key under Credentials; budget five minutes for it.

node --version    # expect v20.x or v22.x
npx lighthouse --version    # expect 12.x
npm ls web-vitals    # expect [email protected] after install
npx @lhci/cli --version    # expect 0.14.x

One environment caveat that wastes hours: browser extensions inject scripts and styles that alter both timing and layout, corrupting lab results. Always run Lighthouse in an Incognito window or a fresh Chrome profile with extensions disabled. Antivirus software and corporate proxies also distort TTFB. When a lab result looks implausibly bad, rule out the local environment before touching your code.

Step-by-step: running your first core web vitals test

This is the core procedure. Twelve numbered steps take you from a cold start to a verified, automated test. Follow them in order the first time; later you will jump straight to the surface you need. Each step lists what you do and what the output should look like so you know whether it worked.

Step 1: Open PageSpeed Insights. Navigate to pagespeed.web.dev, paste your full URL including the protocol, and click Analyze. Wait roughly 15 to 30 seconds. Output: a report header showing either "Passed" or "Failed" the Core Web Vitals assessment, followed by mobile and desktop tabs. The verdict at the top reads from field data; trust it over the performance number below.

Step 2: Read the field data block first. Scroll to "Discover what your real users are experiencing." Output: four colored bars for LCP, INP, CLS, and FCP, each with your p75 value. Green is good, orange is needs improvement, red is poor. If this block says "The Chrome User Experience Report does not have sufficient real-world speed data for this page," your URL lacks traffic; fall back to origin-level data or lab data.

Step 3: Note the assessment scope. Below the bars, PageSpeed Insights shows whether the data is for this specific URL or aggregated for the whole origin. Output: a toggle reading "This URL" or "Origin." Origin data smears all your pages together; URL data is precise. Always prefer URL data when available.

Step 4: Switch to the lab "Diagnose performance issues" section. Output: a Lighthouse performance score (0 to 100) and the lab metrics including TBT. This is your debugging view. Remember: this score does not determine ranking; the field block in Step 2 does.

Step 5: Expand the Opportunities and Diagnostics. Output: a ranked list such as "Reduce unused JavaScript, est. savings 1.2s" and "Properly size images, est. savings 0.8s." Each estimate is the potential lab time saved. Sort your work by the largest estimated savings.

Step 6: Open Chrome DevTools for an interaction-level test. In Chrome, press F12, go to the Performance panel, click record, interact with the page (click menus, open modals, type in fields), then stop. Output: a flame chart with interaction markers. Long red-flagged tasks over 50ms are the main-thread blockers driving INP up.

Step 7: Run Lighthouse from the command line for a repeatable baseline. Use the CLI command in the next section. Output: an HTML and JSON report saved locally, identical in structure to the DevTools audit but scriptable and version-controllable.

Step 8: Query the CrUX API for historical field trends. Field data in PageSpeed is a single snapshot; the CrUX History API returns weekly trends. Output: a JSON time series of p75 values per metric, which reveals whether you are improving or regressing over the 28-day windows.

Step 9: Instrument real-user monitoring with the web-vitals library. Add the snippet from the INP section to your site and send the values to your analytics. Output: a live stream of real LCP, INP, and CLS values segmented by page, device, and country, which neither PageSpeed nor CrUX gives you at this granularity.

Step 10: Check Google Search Console's Core Web Vitals report. Under Experience, open Core Web Vitals. Output: URL groups labeled Good, Needs improvement, or Poor for mobile and desktop, grouped by shared issue (for example, "CLS issue: more than 0.25"). This is the report Google itself uses to summarize your site's status.

Step 11: Wire Lighthouse CI into your build pipeline. Add the configuration from the automation section so every pull request fails if a metric regresses. Output: a passing or failing CI check with a link to the full report, blocking merges that would degrade performance.

Step 12: Validate the fix in the field after deployment. Because CrUX uses a rolling 28-day window, a fix shipped today does not show full effect for up to 28 days. Output: a gradual shift of your p75 values toward green over the four weeks following deployment. Use the CrUX History API from Step 8 to watch the trend rather than refreshing PageSpeed daily.

Reading a PageSpeed Insights report without misreading it

PageSpeed Insights is the most-used core web vitals test surface and the most misread. The single most important skill is separating the two halves of the report. The top half ("Discover what your real users are experiencing") is CrUX field data and is the half that determines whether you pass. The bottom half (the big performance score and the Opportunities list) is Lighthouse lab data and is a debugging aid only. Teams routinely celebrate a 95 performance score while the field block above it glows orange, then wonder why rankings do not move.

A worked example clarifies it. Suppose the field block reads LCP 3.1s (orange), INP 180ms (green), CLS 0.04 (green), and the lab performance score is 92. The verdict is FAIL, because LCP at p75 exceeds 2.5 seconds, and one failing metric fails the whole assessment. The 92 is irrelevant to the verdict. Your entire optimization effort should target LCP. The Opportunities list below will likely point at the hero image or render-blocking CSS, and those are the levers to pull.

Now suppose the same page on a low-traffic URL returns "not enough data" in the field block. PageSpeed falls back to origin-level field data if the origin has enough traffic, labeled accordingly. If even the origin lacks data, you have only the lab score, which means you must rely on Lighthouse and real-user monitoring you install yourself. Do not assume a missing field block means a problem; it usually means low traffic. The NitroPack Core Web Vitals guide and other practitioner resources reinforce that the broader performance score is not the same thing as passing Core Web Vitals, a distinction worth repeating to stakeholders who fixate on the round number.

One more reading tip: the field metrics are p75, but PageSpeed also shows the distribution as three colored segments per metric. A metric can show mostly green with a long red tail and still fail at p75. Read the numeric p75 value, not the visual impression of the bar. The number is the verdict; the bar is decoration.

Pulling field data with the CrUX API

PageSpeed gives you one snapshot. To track trends, alert on regressions, and build dashboards, query CrUX directly. There are two endpoints: the CrUX API (current 28-day snapshot) and the CrUX History API (weekly time series). Both are free with the API key from the prerequisites. The example below requests the current record for a URL on the phone form factor, returning p75 values for each metric.

curl -s "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/pricing",
    "formFactor": "PHONE",
    "metrics": [
      "largest_contentful_paint",
      "interaction_to_next_paint",
      "cumulative_layout_shift"
    ]
  }'

The response contains a percentiles object per metric. The field you want is p75, expressed in milliseconds for LCP and INP and as a unitless number for CLS. A small Node script turns the raw JSON into a pass/fail verdict you can pipe into alerts. Note how it applies the exact 2026 thresholds and requires all three to pass, mirroring Google's all-or-nothing rule.

const THRESHOLDS = { lcp: 2500, inp: 200, cls: 0.1 };

async function cruxVerdict(url) {
  const res = await fetch(
    `
.com/v1/records:queryRecord?key=${process.env.CRUX_KEY}`,
    { method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ url, formFactor: 'PHONE' }) }
  );
  const data = await res.json();
  const m = data.record.metrics;
  const lcp = m.largest_contentful_paint.percentiles.p75;
  const inp = m.interaction_to_next_paint.percentiles.p75;
  const cls = parseFloat(m.cumulative_layout_shift.percentiles.p75);
  const pass = lcp <= THRESHOLDS.lcp && inp <= THRESHOLDS.inp && cls <= THRESHOLDS.cls;
  return { url, lcp, inp, cls, pass };
}

For trend analysis, swap the endpoint to records:queryHistoryRecord, which returns roughly 25 weekly data points. Plot the p75 series and you can see a deployment's effect propagate through the rolling window over about four weeks, which is the only honest way to confirm a field-data fix. If you lack a CrUX key or want a managed version of this, our team builds these pipelines as part of the internal tooling we deploy for clients. The CrUX API is documented officially by Google and is the same dataset Search Console and PageSpeed read from, so there is no discrepancy risk in using it as your source of truth.

Measuring INP in the real browser with the web-vitals library

INP is the metric you cannot measure in a lab, which makes it the metric most teams ignore until rankings drop. The fix is real-user monitoring with Google's official web-vitals library. It hooks the browser's Event Timing and Layout Instability APIs and reports actual values from actual users, including the worst interactions that a synthetic test never triggers. Install it and wire it to your analytics in a few lines.

import { onLCP, onINP, onCLS } from 'web-vitals';

function send(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,   // 'good' | 'needs-improvement' | 'poor'
    id: metric.id,
    page: location.pathname
  });
  navigator.sendBeacon('/analytics/vitals', body);
}

onLCP(send);
onINP(send);
onCLS(send);

The rating field is computed against the same thresholds in our reference table, so your backend can count the share of "good" ratings per page without hard-coding the cutoffs. The sendBeacon call survives page unload, which matters because INP often finalizes as the user leaves. Once this data lands in your warehouse, segment it. INP failures cluster: a specific component (a heavy filter dropdown, a third-party chat widget) usually drives them, and the segmentation points straight at the culprit.

To debug a specific slow interaction, use the experimental attribution build, web-vitals/attribution, which adds the event target, the load state, and the longest blocking script to each INP report. That turns a vague "INP is 320ms" into "the click handler on .add-to-cart spent 210ms in a script from a tag manager." Practitioner guides consistently identify long JavaScript tasks, oversized DOM trees, and third-party scripts as the dominant INP causes, and attribution data is how you prove which one is yours. For teams optimizing conversion paths, pairing this with our conversion rate optimization work surfaces where slow interactions and drop-off overlap.

Automating tests in CI with Lighthouse CI

Manual testing catches problems after they ship. Automated testing blocks them at the pull request, which is where a core web vitals test pays for itself. Lighthouse CI runs Lighthouse against a built version of your site on every commit and fails the build if a metric crosses a budget you define. Because lab data cannot measure INP, you assert against Total Blocking Time as the INP proxy, plus LCP and CLS directly.

// lighthouserc.js
module.exports = {
  ci: {
    collect: {
      url: ['
.com/', '
.com/pricing'],
      numberOfRuns: 3
    },
    assert: {
      assertions: {
        'largest-contentful-paint': ['error', { maxNumericValue: 2500 }],
        'cumulative-layout-shift': ['error', { maxNumericValue: 0.1 }],
        'total-blocking-time': ['error', { maxNumericValue: 200 }],
        'first-contentful-paint': ['warn', { maxNumericValue: 1800 }]
      }
    },
    upload: { target: 'temporary-public-storage' }
  }
};

The numberOfRuns: 3 setting matters: a single Lighthouse run varies by 10 to 20% due to environment noise, so three runs and the median value reduce false failures. The error severity blocks the merge; warn annotates without blocking, which is right for diagnostic vitals like FCP. Run it in your pipeline with two commands.

npm install -D @lhci/[email protected]
npx lhci autorun --config=lighthouserc.js

A common mistake is asserting tight budgets immediately and drowning in red builds. Start by setting budgets at your current values plus a small margin, so the gate prevents regressions without demanding instant perfection, then ratchet the budgets down as you optimize. This is the same discipline that makes performance budgets stick in any engineering org: enforce the floor you have, then raise it deliberately. Lighthouse CI is documented by Google and integrates with GitHub Actions, GitLab CI, and Jenkins with a few lines of YAML. Search Engine Land and other industry outlets have covered automated performance gating as a maturity marker for SEO-aware engineering teams, and it is the difference between a one-time audit and a durable program.

A comparison of core web vitals testing tools

No single tool does everything. PageSpeed gives a quick verdict, DevTools debugs interactions, CrUX provides trends, web-vitals provides real-user granularity, and Lighthouse CI enforces budgets. The table below maps each tool to its data type, what it is best at, what it cannot do, and its cost, so you can assemble the right combination rather than over-relying on one surface. Practitioner guides repeatedly recommend this same multi-tool stack rather than a single dashboard.

The minimum viable stack for a serious program is four free tools: PageSpeed Insights for spot verdicts, the web-vitals library for real-user data you control, the CrUX API for trends, and Lighthouse CI to stop regressions. Vendors like NitroPack and WP Rocket sit one layer up, automating common fixes on WordPress (image optimization, critical CSS, script deferral); they position their tooling explicitly around improving the three metrics. They are convenient on WordPress but not a substitute for measurement: you still need a field-data tool to confirm the automated fixes actually moved p75. WebPageTest earns its place when you need network waterfalls and device-specific filmstrips that DevTools does not surface as cleanly.

Common pitfalls and how to fix them

These five mistakes account for most failed core web vitals tests and most wasted optimization effort. Each is paired with the concrete fix. Recognizing the pattern saves you from chasing the wrong metric.

Pitfall 1: Optimizing the Lighthouse score instead of field data

Teams push the performance score to 100 and assume they pass. Fix: grade yourself only on the CrUX field block in PageSpeed or the Search Console report. Treat Lighthouse as a debugger, never as the verdict. If field and lab disagree, field wins.

Pitfall 2: Ignoring INP because the lab cannot measure it

Lighthouse shows no INP, so teams forget it exists, then fail on responsiveness. Fix: install the web-vitals library to capture real INP, and watch Total Blocking Time in the lab as an early-warning proxy. Audit every third-party script for main-thread cost.

Pitfall 3: Layout shift from images and ads without reserved space

Images, embeds, and ad slots load late and shove content down, spiking CLS. Fix: set explicit width and height attributes (or CSS aspect-ratio) on every image and reserve fixed-size containers for ad and embed slots so nothing reflows when they arrive.

Pitfall 4: Testing only desktop on office wifi

Developers test on fast connections and fast machines, then ship a page that fails mobile p75. Fix: always test the mobile tab, apply CPU and network throttling in DevTools, and weight your monitoring toward the devices your CrUX data shows your audience actually uses.

Pitfall 5: Expecting field results to change instantly after a fix

A fix ships, PageSpeed still shows red the next day, and the team assumes the fix failed. Fix: remember CrUX uses a rolling 28-day window. Confirm the fix in lab data immediately, then track the field trend with the CrUX History API over the following four weeks before judging it.

A sixth pitfall worth naming: chasing a perfect CLS of zero. CLS only penalizes unexpected shifts. Shifts within 500 milliseconds of a user interaction are excluded, so an accordion that pushes content down when clicked does not hurt you. Spend the effort on the late-loading images and fonts that move content without user input, not on interaction-driven layout changes that the metric already forgives.

Troubleshooting guide for common test failures

When a test returns a result that does not make sense, work through this list. Each item pairs a symptom with the most likely cause and the next action. These eight cover the large majority of confusing core web vitals test outcomes.

• "No field data available": the URL lacks the traffic CrUX needs. Action: check origin-level data in PageSpeed, and rely on lab data plus your own RUM until traffic accumulates.
• Lab score is 95 but the page fails: a Core Web Vital is failing in the field. Action: read the CrUX block, identify which of LCP/INP/CLS is red, and optimize that one specifically.
• LCP is high but the page looks fast: the largest element is offscreen or is a slow background image. Action: in DevTools, check which element is flagged as the LCP element and confirm it is the one you expect.
• INP fails only for some users: a third-party script or a heavy interaction is involved. Action: use web-vitals/attribution to identify the slow event target and the blocking script.
• CLS spikes intermittently: late-loading ads, fonts, or A/B test scripts. Action: record a Performance trace and look for Layout Shift entries; reserve space for the offending elements.
• Lighthouse results vary 15% between runs: environment noise. Action: run three times and take the median, close other tabs, and test in Incognito with extensions off.
• Search Console disagrees with PageSpeed: different aggregation windows and URL grouping. Action: trust Search Console for site-wide status and PageSpeed for a specific URL; both read CrUX.
• Mobile fails, desktop passes: mobile CPUs and networks are slower, and Google grades them separately. Action: prioritize the mobile experience, which is also what most users and the mobile-first index see.
• TTFB is high, dragging LCP: slow origin or no caching. Action: add a CDN, enable full-page caching, and reduce uncached database work before touching images.

If you have exhausted this list and a result is still inexplicable, the cause is almost always either a measurement artifact (extension, proxy, throttling mismatch) or an aggregation-window mismatch between two field surfaces. Reproduce in a clean Chrome profile, confirm which surface reads URL versus origin data, and the contradiction usually resolves itself.

Advanced tips for teams running tests at scale

Once the basics are automated, these techniques separate a maintenance routine from a competitive advantage. They assume you already have RUM and CI in place.

Segment INP by interaction type, not just by page. Aggregate p75 INP is an average of many different interactions. Break it down by event target and you will find that one component (a search-as-you-type box, a faceted filter) accounts for most of the failing tail. Fixing that one component often moves the whole page's p75 below 200ms without touching anything else.

Use the BFCache to your advantage. Chrome's back/forward cache restores pages instantly, posting near-zero LCP and INP for those navigations. Pages that opt out of the BFCache (often via an unload handler or a no-store cache header) lose this benefit. Audit your BFCache eligibility in DevTools' Application panel; removing an unload listener can lift your field metrics for free.

Prioritize the LCP image explicitly. Add fetchpriority="high" to the hero image and preload it, while lazy-loading everything below the fold. The browser otherwise discovers the LCP image late. This single attribute frequently cuts LCP by several hundred milliseconds on image-heavy pages.

Break up long tasks with scheduler.yield(). Long JavaScript tasks block the main thread and inflate INP. The newer scheduler.yield() API lets you yield to the browser mid-task so user input gets processed promptly, then resume. It is a cleaner replacement for the old setTimeout(0) pattern and is supported in Chrome 126+.

Tie vitals to revenue, not just rankings. Core Web Vitals are increasingly treated as an operational KPI, not only an SEO metric, because they are measured from real visitors and correlate with engagement and conversion.

"Core Web Vitals are real-world, field-based metrics that quantify key aspects of the user experience. A page that satisfies all three at the 75th percentile passes; failing any single metric fails the assessment overall." Google Search Central, Core Web Vitals documentation, 2026.

Join your RUM vitals to your analytics conversion data and you can put a dollar figure on a 200ms INP improvement for specific page templates, which is the argument that gets performance work funded. This is also where answer-engine visibility intersects with speed, and our work on answer engine optimization treats page experience as one input among several that determine whether a page gets surfaced and cited.

A complete working monitoring project

This is the end-to-end project the guide builds toward: a small but complete system that measures real users, stores the data, computes pass/fail against the 2026 thresholds, and blocks regressions in CI. It uses only the free tools from the prerequisites. Stand it up and you have a durable core web vitals test, not a one-off audit.

Part 1: the client collector. Drop this on every page. It captures real LCP, INP, and CLS and beacons them to your endpoint with enough context to segment later.

// vitals-collector.js (bundled into your site)
import { onLCP, onINP, onCLS } from 'web-vitals';

const report = (metric) => {
  navigator.sendBeacon('/api/vitals', JSON.stringify({
    metric: metric.name,
    value: Math.round(metric.value * 1000) / 1000,
    rating: metric.rating,
    path: location.pathname,
    device: matchMedia('(max-width: 768px)').matches ? 'mobile' : 'desktop',
    ts: Date.now()
  }));
};

[onLCP, onINP, onCLS].forEach((fn) => fn(report));

Part 2: the server aggregator. A minimal Node/Express endpoint that receives beacons, stores them, and exposes a p75 verdict per page. In production, swap the in-memory array for a database or warehouse.

const store = [];

app.post('/api/vitals', (req, res) => {
  store.push(req.body);
  res.sendStatus(204);
});

function p75(values) {
  const sorted = [...values].sort((a, b) => a - b);
  return sorted[Math.floor(sorted.length * 0.75)];
}

app.get('/api/verdict', (req, res) => {
  const T = { LCP: 2500, INP: 200, CLS: 0.1 };
  const out = {};
  for (const name of ['LCP', 'INP', 'CLS']) {
    const vals = store.filter(x => x.metric === name).map(x => x.value);
    const v = vals.length ? p75(vals) : null;
    out[name] = { p75: v, pass: v !== null && v <= T[name] };
  }
  out.overall = Object.values(out).every(m => m.pass);
  res.json(out);
});

Part 3: the CI gate. Reuse the lighthouserc.js from the automation section so no pull request can regress LCP, CLS, or TBT past budget. Part 4: the field trend job. Schedule the CrUX History API script to run weekly and post the p75 trend to a Slack channel, so the team sees the rolling-window effect of each deployment without manually refreshing PageSpeed.

Together these four parts form a closed loop: the collector measures real users, the aggregator computes the verdict in real time at full granularity, the CI gate prevents new regressions before they ship, and the trend job confirms field improvement over the 28-day CrUX window. That loop is the difference between knowing your score today and controlling it over quarters. If running this in-house is more than your team wants to own, our SEO services operate exactly this stack as a managed program.

How Core Web Vitals connect to rankings and AI citation

A core web vitals test is worth running because the results feed two distinct systems: classic search ranking and the newer answer engines. On the ranking side, Core Web Vitals are part of Google's page-experience signals. They are not the dominant factor (relevance and links still outweigh them) but they act as a tiebreaker and, more importantly, as a tax: a slow, unstable page suppresses the engagement signals that do drive rankings. Vendor and Google material is consistent that passing Core Web Vitals helps SEO, while cautioning that the broad performance score is not the same as passing the three named metrics.

"INP is now the standard responsiveness metric, having replaced First Input Delay. A page must satisfy LCP, INP, and CLS together to be considered passing overall, evaluated at the 75th percentile of real-user experiences." Core Web Vitals 2026 explainer, corewebvitals.io.

On the answer-engine side, the connection is indirect but real. Large language model search features and AI overviews crawl and render pages, and pages that render fast and stably are easier to parse, extract, and cite. A page that shifts layout during render or blocks the main thread for seconds is harder for both users and automated crawlers to consume cleanly. As AI-driven discovery grows, the operational case for fast, stable pages strengthens beyond classic ranking. Search Engine Land and similar outlets have documented the rising overlap between technical performance and AI search visibility, and the practical implication is the same: the engineering work that passes a core web vitals test also makes your content more extractable.

This is why we treat page experience as a shared input across services rather than a siloed SEO checkbox. Whether the goal is organic ranking, conversion, or getting cited by an answer engine, the underlying requirement (a page that loads in under 2.5 seconds, responds in under 200 milliseconds, and does not jump around) is identical. The measurement discipline in this guide is the same discipline that supports every one of those outcomes, which is why it belongs in any serious growth program rather than only on the technical SEO team's backlog.

How to get started Monday morning

You do not need the full project to begin. Here is the sequence to run this week, in order, with each step taking under an hour. Do them in this order because each one informs the next, and skipping to automation before you understand your field data wastes effort on the wrong metric.

• Monday: run your top 10 URLs through PageSpeed Insights, record the p75 field values for LCP, INP, and CLS, and mark which metric fails on which template. This is your baseline and your priority list.
• Tuesday: install the web-vitals library and start streaming real-user data, even to a simple log endpoint. You cannot improve INP without measuring it, and the lab will not give it to you.
• Wednesday: open Search Console's Core Web Vitals report and confirm the URL groups match what PageSpeed told you. Identify the single most common failing issue across your site.
• Thursday: fix the highest-impact issue on your worst template (usually an unoptimized hero image for LCP or a heavy script for INP), and verify the change in lab data immediately.
• Friday: add the Lighthouse CI config to your pipeline with budgets set at current values plus a small margin, so no future commit silently regresses what you just fixed.

Over the following four weeks, watch the CrUX field data shift as the rolling window absorbs your fix. Then repeat the loop on the next template. The teams that win at Core Web Vitals are not the ones with the cleverest single optimization; they are the ones who measure field data continuously, gate regressions in CI, and treat the three metrics as an operational KPI rather than a quarterly audit. Build the loop once and the test runs itself, freeing you to fix the next bottleneck instead of rediscovering the same one. If you want this implemented and monitored without building the pipeline yourself, that is precisely the work our technical SEO team takes on.

Marcus Vega

SEO Director

Marcus owns the technical SEO and link-building practice at Skitrate. Specializes in Core Web Vitals, indexation engineering at scale (10M+ URL catalogs), and digital-PR outreach that earns links journalists actually link to. Built the audit framework that Skitrate ships to every new enterprise client.

• Led technical SEO at two SaaS unicorns before joining Skitrate
• Specializes in JavaScript SEO, log-file analysis and crawl-budget engineering
• Runs Skitrate's digital-PR program: 200+ earned links per quarter
• Routinely interviewed by Search Engine Land, Search Engine Journal

More posts by Marcus Vega →