Field First Core Web Vitals Audit for UK SMEs: Reach 75% Good Visits

Start with field data, not lab scores. Open Search Console’s Core Web Vitals report and PageSpeed Insights for your top pages, install the web-vitals library if you have no real user monitoring, then triage every URL group marked “Poor” or “Needs improvement” by traffic value. Success looks like 75% or more of visits hitting “good” thresholds for LCP, INP and CLS on the pages that matter most.

TL;DR:

• Focus on improving the percentage of visits that meet Google’s thresholds, aiming for at least 75%, rather than just fixing scores visually.
• Prioritize fixing high-traffic and high-value pages with poor Core Web Vitals metrics to reduce leaks in revenue and rankings.
• Use combined field data from real visitors with lab diagnostics to accurately identify and address performance issues, especially on mobile devices.
• Address common causes of slow LCP by optimizing server response times and images, and fix CLS by reserving space for dynamic content and images.
• Regularly monitor budgets with automated tools, enforce performance standards via CI pipelines, and treat audits as ongoing habits rather than one-time projects.

Why audit Core Web Vitals in the first place?

Slow, jumpy, unresponsive pages lose people before they convert, and Google treats that experience as a ranking signal. That’s the honest case for running a core web vitals audit: it protects revenue and visibility at the same time, not one or the other.

The three metrics measure distinct moments in a visit:

• LCP (Largest Contentful Paint): how long the biggest visible element takes to render.
• INP (Interaction to Next Paint): how responsive the page feels when someone clicks, taps, or types, measured across the entire visit.
• CLS (Cumulative Layout Shift): how much content jumps around unexpectedly while loading.

Pro Tip: Google judges a page by the share of visits that fall in the “good” band, not the average. Chase the percentage, not the mean.

Google’s own guidance sets 2026 thresholds at LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, and a page only passes when at least 75% of visits meet all three. INP replaced FID as the responsiveness metric in March 2024, and it’s a stricter test because it watches every interaction on the page, not just the first one.

Field data versus lab data: what to collect first

Field data comes from real visitors and it’s the only data Google uses for ranking purposes, so it has to lead your audit. The Chrome UX Report (CrUX) that feeds Search Console updates on a rolling 28-day basis, which means changes you ship today won’t show up in that report for weeks.

That lag is exactly why you also need your own real user monitoring (RUM). A combined approach, drawing on both field and lab measurement, is the standard recommended by Web, and the lightest way to get RUM running is Google’s own web-vitals JavaScript library, which mirrors CrUX’s own methodology so the numbers you collect are directly comparable.

At minimum, capture:

• LCP, INP and CLS values per page load, tagged with URL and connection type.
• Device category (mobile skews worse almost everywhere).
• Timestamp, so you can correlate spikes with deploys or campaign launches.

Lighthouse, WebPageTest and Chrome DevTools sit downstream of this. They’re diagnostic tools for explaining why a page is slow, never the source of truth for whether it’s actually failing in the real world.

Quick measurement checklist: which pages to fix first

1. Open the Core Web Vitals report in Search Console and list every URL group tagged “Poor” or “Needs improvement”.
2. Run PageSpeed Insights against a representative URL from each group, noting both the field data box and the lab score below it.
3. Rank the list by traffic volume and conversion value, not by how bad the score looks.
4. For low-traffic pages with no CrUX data yet, fall back on synthetic tests (Lighthouse, WebPageTest) until enough real visits accumulate to populate RUM.
5. Flag any page that’s both high-value and failing on multiple metrics as the first fix.

This ordering matters more than most audits admit. A “Poor” score on a page nobody visits is a rounding error; a “Needs improvement” score on your product or booking page is a leak in the business.

How to run the audit: a step-by-step workflow

A structured audit moves through five phases, and skipping any one of them is how teams end up “fixing” a Lighthouse score that never reflected reality.

1. Baseline. Configure the web-vitals library or a RUM provider, connect your CrUX dashboard, and export current figures for every priority page before touching any code.
2. Select. Pick representative pages and user flows, homepage, category page, checkout, main form, rather than trying to test everything at once.
3. Reproduce. Recreate the failure in a lab environment using Lighthouse user flows, WebPageTest’s waterfall and filmstrip views, or a recorded DevTools performance trace.
4. Diagnose. Read the waterfall for render-blocking requests, check long-task traces for main-thread congestion, and use the Long Animation Frames API for INP-specific script attribution.
5. Fix and validate. Ship the change, run it through CI checks, then watch field data over the following weeks to confirm the fix held under real traffic.

Practitioners who run this kind of audit regularly point out that combining field data, lab analysis and a look at the underlying architecture beats chasing a single Lighthouse number every time. A page can score 100 in a lab test and still frustrate real visitors on a slow mobile connection, because the lab run never accounted for their network or device.

Two things worth keeping close during diagnosis:

• Waterfalls reveal what loaded slowly; long-task traces and LoAF reveal why the browser was too busy to respond.
• A fix validated only in the lab is a hypothesis, not a result, until field data confirms it.

Diagnostic checklist and fixes for LCP

Find the LCP element first. Chrome DevTools, Lighthouse and WebPageTest all highlight it directly, usually a hero image, a heading, or a large background element above the fold.

The usual suspects behind a slow LCP:

• Slow server response time (TTFB) before the browser can even start rendering.
• Render-blocking CSS or JavaScript sitting between the request and the paint.
• Oversized or unoptimised images serving far more pixels than the layout needs.
• Hero content that loads late because it’s buried behind other requests.

Pro Tip: Check your TTFB before anything else. If the server takes 1.5 seconds just to respond, no amount of image compression will rescue your LCP.

Fixes that consistently move the number: cache or server-render the above-the-fold HTML so the browser has something to paint immediately, serve images at the correct dimensions with modern formats, preload the actual LCP resource, and defer anything that isn’t needed for that first paint. These are the same tactics web.dev’s guidance on optimising Core Web Vitals for business points to, and they’re covered in more practical detail in our own piece on website performance best practices.

Diagnostic checklist and fixes for INP

INP replaced FID because a fast first interaction tells you nothing about the ninth or tenth. It records the worst interaction latency across an entire visit, which is why sites that comfortably passed FID are now failing INP under the newer standard, a pattern reported widely since the 2024 rollout.

To capture the actual slow interactions, use the DevTools Performance panel’s interactions lane, your RUM traces, or the Long Animation Frames API, which gives script-level attribution for long main-thread tasks so you can see exactly which file or function is blocking the thread.

Common causes worth checking:

• Long JavaScript tasks that block the main thread when someone clicks or types.
• Heavy third-party scripts firing on interaction, not just on load.
• Event handlers doing expensive work synchronously instead of deferring it.

Fixes that help: break long tasks into smaller chunks, move heavy computation to a web worker, virtualise long lists instead of rendering every row, and debounce or throttle handlers that fire repeatedly. Reducing overall JavaScript bundle size and hydration work on framework-driven sites tends to help every interaction on the page at once, rather than patching one at a time.

Diagnostic checklist and fixes for CLS

CLS is calculated from how far elements move and how much of the viewport they affect, and Chrome DevTools can visualise every shift directly on the page as it loads, useful for spotting the exact moment something jumps.

The recurring causes are almost always the same few things:

• Images or embeds with no width and height set, so the browser reserves no space for them.
• Content inserted above existing elements after the initial render, pushing everything down.
• Web fonts swapping in late and reflowing text.
• Ad slots that load asynchronously without a reserved container size.

The fixes are equally consistent. Set explicit width, height, or aspect-ratio on every image and embed, use placeholders that match the final size of dynamic content, apply a sensible font-display strategy so text doesn’t visibly reflow, and never insert new content above what a visitor is already reading. None of this is glamorous work, but it’s the difference between a page that feels stable and one that makes people distrust the site entirely.

Monitoring and regression prevention: stop the slide back

Most performance gains erode within months if nobody’s watching, because a new hero banner, a fresh tracking pixel, or an unoptimised campaign landing page can undo weeks of fixing without anyone noticing until rankings slip. Treating budgets as a checkbox exercise rather than an enforced gate is the single biggest reason audits need repeating every year.

Set concrete budgets for LCP, INP, CLS and resource sizes, then make them enforceable rather than aspirational:

• Add Lighthouse CI or a scripted Lighthouse-plus-Puppeteer flow to pull requests, so a regression fails the build, not just the report.
• Run scheduled synthetic tests alongside live RUM dashboards, with alerting when a metric crosses its budget.
• Assign a named owner for performance, the same way you’d assign one for uptime.

Pro Tip: A budget that doesn’t block a merge or trigger an alert is just a number in a document. Wire it into your CI pipeline or it will be ignored the first time a deadline gets tight.

Our guide to essential website maintenance for better SEO covers the recurring checks worth scheduling alongside this. Marketing pages are a particular risk zone: our piece on optimising landing pages for South East businesses walks through how a fresh campaign asset can quietly wreck a page’s CLS score overnight.

Tools and workflows: which tool for which job

Different stages of the audit call for different tools, and using the wrong one at the wrong stage is how teams end up debugging a problem that field data never actually confirmed.

Treat this as a pipeline rather than a pick-one menu. Field tools tell you if there’s a problem, lab tools tell you why, and automation stops the same problem coming back next quarter.

MB Web’s approach to Core Web Vitals audits

The team has extensive experience working with local and national brands across web design, development, hosting, maintenance and SEO, and a technical audit runs through the same field-first process outlined above every time.

A typical MB Web audit includes:

• Scoping the priority pages by traffic and conversion value, not guesswork.
• Establishing a RUM baseline before recommending a single change.
• A prioritised, plain-English fixes list ranked by impact, not by how impressive it sounds.

If you’d rather have someone else run the diagnosis, request a free website audit and we’ll tell you honestly what’s actually holding your pages back.

Want an honest second opinion on your site’s performance?

MB Web is the practical alternative to guessing your way through a performance fix or hiring a large agency for a problem that often needs a focused, honest diagnosis instead. We design and build websites, but we also fix the ones already live, technical audits, website development work to resolve root causes, and ongoing website maintenance and updates so fixes don’t quietly regress six months later.

The agency works mainly with businesses, estate agents, industrial firms, charities and SMEs across the South East, who want a straight answer rather than a jargon-heavy report. If your Core Web Vitals report is showing red or amber and you’re not sure where to start, request a free website audit and we’ll walk you through exactly what’s slowing your pages down and what it would take to fix it. If hosting itself is part of the problem, our managed website hosting plans start from £290 per year.

Sources

• Understanding Core Web Vitals and Google search results
• Web
• Core Web Vitals Audit Checklist (2026 Update) | Alex Mayhew
• WebPageTest

FAQ

Recommended

• Why website audits matter: boost your business online
• The role of analytics in web: a 2026 guide for UK businesses
• Top industrial website optimisation tips for more leads
• Website optimisation tips for small businesses in 2026