75% Rule: Core Web Vitals Playbook for Small Businesses

Core Web Vitals are three field metrics: Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift, that measure real-user loading speed, responsiveness, and visual stability. Google judges a page as “Good” when at least 75% of real visits meet each threshold, so field data should set your priorities. Start by pulling your Chrome User Experience Report numbers, then fix whatever metric is failing at that 75th percentile first.

TL;DR:

  • Prioritize fixing the metric that fails at the 75th percentile rather than just the worst-performing page in Lighthouse.
  • Use real-user field data from Chrome User Experience Report and Search Console to identify which pages and metrics need attention.
  • Critical fixes include compressing images, preloading assets, breaking long JavaScript tasks, and reserving space to prevent content shifts.
  • Focus on high-traffic pages impacting conversions first, then monitor regularly with tools like CrUX, Search Console, and Lighthouse CI to maintain scores.
  • Avoid treating Lighthouse scores as the full picture; always verify fixes with actual user data to ensure sustained improvements.
King Digital Marketing Agency
kingdigitalpros.com
Turn Faster Pages Into More Leads
King Digital combines technical SEO, conversion optimization, and tailored web design to help local businesses improve visibility and generate leads.

Visit King Digital

Table of Contents

What the three Core Web Vitals actually measure

Each Core Web Vital answers a different question about how a page feels to use.

  • Largest Contentful Paint (LCP) tracks how long the biggest visible element, usually a hero image or headline, takes to render.
  • Interaction to Next Paint (INP) measures how quickly the page responds when someone clicks, taps, or types, across the entire visit rather than just the first interaction.
  • Cumulative Layout Shift (CLS) scores how many content jumps around unexpectedly while a page loads.

Google and web.dev define “Good” at the 75th percentile: LCP at 2.5 seconds or under, INP at 200 milliseconds or under, and CLS at 0.1 or under. Teams chasing a competitive edge often aim higher. Web points to stretch targets of LCP at 2.0 seconds, INP at 150 milliseconds, and CLS at 0.05.

The 75th percentile matters because it is not an average. It means three out of four real visits need to clear the bar simultaneously, not just on their best metric. A page can pass LCP for most visitors and still fail the overall assessment if INP or CLS drags behind for that same slice of traffic.

Three Core Web Vitals At 75Th Percentile

Lab data vs field data: which tools to trust and when

Lab tools and field tools answer different questions, and mixing them up is one of the most common optimization mistakes. Lab testing, run through Lighthouse or Chrome DevTools, simulates a single page load under controlled network and device conditions. Field data, collected through the Chrome User Experience Report or your own real-user monitoring, reflects what actual visitors experienced on actual devices and connections.

Google’s own guidance is direct about which one governs decisions: field data should guide prioritization, while lab tools are for diagnosing root causes once you know what to fix. A page can score perfectly in Lighthouse and still fail its real-world CLS threshold because a slow third-party script shifted content for actual visitors on throttled connections.

Tool Data type Best use
CrUX Field, 28-day rolling Site-wide and page-level real-user trends
PageSpeed Insights Field plus lab Single-URL snapshot combining both views
Search Console Field, grouped Finding which URL groups are failing at scale
Lighthouse Lab Diagnosing why a specific page is slow
Chrome DevTools Lab, live Watching metrics change as you test a fix

The CrUX dataset is the foundation here: it provides origin-level and page-level field data refreshed on a rolling basis, and it feeds both PageSpeed Insights and the CrUX API for teams that want to build their own dashboards. Use CrUX and Search Console to find which pages and metrics are failing, then drop into Lighthouse or DevTools to find out why.

Step-by-step fixes for LCP, INP, and CLS

Once you know which metric is failing and on which pages, the fixes are specific enough to hand straight to a developer.

  1. Fix LCP by speeding up the critical path. Preload the hero image or font, compress and correctly size images, move to a faster CDN, and shrink server response time (TTFB) before touching anything else.
  2. Fix INP by reducing main-thread work. Break long JavaScript tasks into smaller chunks, defer or load non-critical scripts asynchronously, and use event handlers that yield control back to the browser between steps.
  3. Fix CLS by reserving space before content loads. Add explicit width and height attributes to images and iframes, reserve ad slot dimensions in advance, and load fonts in a way that avoids a visible text swap.
  4. Recheck dynamic content insertion. Anything injected above existing content after load, banners, cookie notices, promotional bars, tends to be the hidden cause of layout shift scores that otherwise look unexplainable.

Web.dev’s remediation guidance also flags bfcache eligibility (making sure a page can be restored instantly from the back/forward cache) as a quietly effective win for perceived speed on repeat visits. For INP specifically, optimization guidance from web.dev notes that INP requires a broader approach than the old First Input Delay metric: every interaction across the session counts, not just the first one, so the goal is consistently fast responses rather than a single fast click.

Pro Tip: Fix the metric that is failing at your 75th percentile first, not the one that looks worst in a single Lighthouse run; they are often different pages.

Prioritize by traffic and business value. A product page with heavy visits and a failing LCP deserves attention before a low-traffic blog post with a mediocre CLS score. Pair quick wins (image compression, font preloading) with a scheduled developer sprint for harder structural fixes like third-party script audits. Our performance improvement guidance for small and medium businesses walks through this same sequencing in more depth.

Building a workflow to monitor and protect your scores

Fixing Core Web Vitals once is easy. Keeping them fixed after a redesign, a new plugin, or a marketing team’s new embedded widget is the harder, ongoing job.

  • Pick pages by impact, not alphabetically: start with high-traffic landing pages and anything tied to conversions.
  • Rotate your sources: check Search Console’s URL groups weekly, pull CrUX field data monthly, and run PageSpeed Insights after any deploy that touches the homepage or key templates.
  • Add real-user monitoring with the web-vitals JavaScript library if you want metrics specific to your own traffic rather than waiting on the 28-day CrUX refresh.
  • Build a regression gate: run Lighthouse CI in your deployment pipeline so a performance-degrading change gets flagged before it ships, not after.

Achieving “Good” status requires at least 75% of real-user visits to clear every threshold at once, according to Google’s field-versus-lab guidance, which is why a monitoring cadence matters more than a one-time audit. A score that passes today can slip the moment a new tracking pixel or affiliate banner gets added without review.

Where Core Web Vitals optimization goes wrong

A few recurring mistakes cost teams more time than the actual fixes do.

The first is treating a single Lighthouse score as the full picture. Lighthouse runs one simulated load on one device profile; it will never capture the spread of real connections, phones, and locations that make up your CrUX data. The second is fixing metrics in isolation. A developer who chases a perfect LCP score while ignoring a creeping CLS problem has not actually improved the page’s overall standing, since Google scores against all three together at the 75th percentile.

Third-party scripts are a frequent blind spot. Chat widgets, ad tags, and analytics snippets often load late and shift layout or block the main thread, and they rarely show up clearly in a quick glance at Lighthouse. Teams also tend to under-invest in font loading strategy, not realizing that a font swap with no fallback sizing can cause a visible layout jump that tanks CLS even on an otherwise well-optimized page.

Illustration Of Scripts Causing Layout Shifts

Finally, many site owners chase the stretch targets before they have cleared the basic “Good” thresholds. That is backward. A page failing LCP at 4 seconds does not need a push to 2.0 seconds, it needs to clear 2.5 seconds first, then refine from there. Treating every fix as equally urgent, instead of ranking by which metric is actually failing at the 75th percentile, is the single most common way optimization effort gets wasted on the wrong page.

What before-and-after optimization typically looks like

A hypothetical but representative example: say an e-commerce product page carries a 4.2 second LCP, driven by an unoptimized hero image and a slow third-party font request. A developer compresses and resizes the image, switches to a preload hint for the hero asset, and self-hosts the font instead of pulling it from an external domain. The page’s LCP in Lighthouse testing drops into the 2-second range, and the real improvement shows up in CrUX data over the following weeks as the 75th-percentile score crosses into “Good.”

The same pattern applies to CLS. A blog layout showing a 0.25 CLS score, well above the 0.1 threshold, often traces back to an ad slot with no reserved height and a cookie banner that pushes content down after the page has already rendered. Reserving the ad slot’s dimensions in the page’s CSS and loading the cookie banner in a fixed overlay instead of pushing content eliminates most of the shift immediately, no server changes required.

These examples illustrate the shape of a fix, not a guaranteed outcome: actual results depend on your hosting, your third-party scripts, and your traffic mix. The consistent lesson across both cases is that the fix usually targets one specific technical cause rather than a general “make the site faster” effort, which is why diagnosing with Lighthouse before changing code saves time.

How Core Web Vitals relate to other speed metrics

Core Web Vitals do not replace the older performance metrics, they sit alongside them. First Contentful Paint (FCP) measures when the first piece of content appears at all, which is a useful early signal but does not tell you whether the page is actually usable yet. Time to Interactive (TTI) measures when a page can reliably respond to input, a concept that INP has largely superseded for real-user measurement because TTI relies on lab conditions rather than actual interaction data.

Think of FCP as the first impression, LCP as the moment the page feels loaded, INP as how responsive it feels once someone starts using it, and CLS as whether it holds still while they do. A page can have an excellent FCP and still fail LCP if the main image lags behind the first visible text. Lighthouse reports all of these together in a single lab run, which is why it remains useful for diagnosis even though CrUX field data governs the actual Core Web Vitals assessment that affects search.

Treating Core Web Vitals as the complete performance picture is its own small mistake. They are the three metrics Google weights most heavily for page experience, but a full performance audit still benefits from watching FCP and server response time as supporting signals that explain why LCP or INP are behaving the way they are.

King Digital’s approach to Core Web Vitals for small businesses

I’m Bernadette, and I’ve spent my career helping small and medium-sized businesses compete online without the budgets that larger companies throw at the problem. At King Digital, we treat Core Web Vitals the same way we treat any other ranking factor: diagnose with field data first, fix what actually moves the 75th percentile, and verify with another round of CrUX data before calling it done.

We follow a roadmap that typically includes a field-data audit, a batch of quick wins like image compression and font preloading, a developer sprint for structural fixes, and ongoing monitoring. If your in-house team already owns a CI pipeline, DIY fixes from this guide will likely get you most of the way. If you lack developer bandwidth or need the work folded into a broader SEO-friendly web design project, that is where handing it to a dedicated team tends to pay for itself faster than training one internally.

— Bernadette

FAQ

What are the Core Web Vitals?

Core Web Vitals are three metrics Google uses to measure page experience: Largest Contentful Paint for loading speed, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. They are field-based measurements drawn from real user visits rather than a single test.

Are Core Web Vitals still relevant?

Yes, they remain Google’s current standard for assessing page experience, with INP having replaced First Input Delay as the responsiveness metric. They continue to be tracked through the Chrome User Experience Report and surfaced in Search Console for site owners.

What is considered a good Core Web Vitals score?

A page is rated “Good” when LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less, each measured at the 75th percentile of real visits. Some practitioners aim for tighter stretch targets of LCP at 2.0 seconds, INP at 150 milliseconds, and CLS at 0.05 for a sharper competitive edge.

How do I pass a Core Web Vitals assessment?

Start with field data from CrUX or Search Console to find which metric is failing on which pages, then use Lighthouse or Chrome DevTools to diagnose the specific cause. Fix the highest-impact issue first, whether that is image optimization for LCP, breaking up long tasks for INP, or reserving layout space for CLS, then recheck your field data over the following weeks since CrUX reports on a rolling basis rather than instantly.

Sources

Resources for deeper Core Web Vitals diagnostics

A few sources are worth bookmarking if you plan to keep working on this beyond a single fix cycle.

  • Google’s Core Web Vitals documentation covers the official definitions and how they factor into search.
  • Web.dev’s learning path walks through each metric with worked examples.
  • CrUX methodology and tools explains the dataset behind PageSpeed Insights and Search Console.
  • WebPageTest offers filmstrip views and synthetic testing that complement Lighthouse for diagnosing rendering delays.
  • Developer-focused guidance on speed optimization techniques extends the remediation steps covered here, and a look at why measuring SEO performance matters reinforces the case for letting field data drive priorities.

Author