Vitals Compliance Score

What is Vitals Compliance Score?

Vitals Compliance Score is the percentage of eligible URLs or URL groups that pass Google’s Core Web Vitals thresholds using field data. I use it as a reporting shortcut for a simple question: of the pages Google can actually judge, how many are passing?

That sounds almost too simple. It isn’t.

I started using this KPI because Core Web Vitals reporting kept creating the same mess in meetings: one chart for LCP, another for CLS, another for INP, mobile grouped one way, desktop grouped another way, and then someone asks, “So… are we getting better?” Search Console is useful for diagnosis, but not always for portfolio-level communication. A Vitals Compliance Score turns that sprawl into one number.

Important distinction: Google does not publish an official metric called “Vitals Compliance Score.” This is an internal KPI you build from Google’s own Core Web Vitals definitions and reporting surfaces, usually from some combination of:

• Google Search Console Core Web Vitals report
• Chrome UX Report (CrUX)
• PageSpeed Insights field data
• Your internal URL inventory or template mapping

I used to resist creating “custom KPIs” like this because I thought they watered down the source data. After a few years of watching teams drown in raw CWV outputs, I changed my mind. The problem wasn’t simplification—the problem was simplifying badly.

Quick definition

Vitals Compliance Score = passing eligible URLs / total eligible URLs × 100

If 1,000 URLs have enough field data and 620 pass Core Web Vitals, the Vitals Compliance Score is 62%.

The metrics behind the score

This KPI is built on Google’s current Core Web Vitals:

• Largest Contentful Paint (LCP) for loading
• Interaction to Next Paint (INP) for responsiveness
• Cumulative Layout Shift (CLS) for visual stability

As documented by Google, the commonly used “good” thresholds are:

• LCP: 2.5 seconds or less
• INP: 200 milliseconds or less
• CLS: 0.1 or less

In practice, a page or page group counts as passing when it meets those thresholds at the 75th percentile of real-user visits in field data. That last part matters more than many teams realize. This is not a lab score. It’s not Lighthouse pretending to be your users. It’s a read on what actual visitors experienced through the Chrome ecosystem.

And yes—device context matters. Mobile and desktop can tell very different stories.

Why I like this KPI

It answers the executive question fast

Most stakeholders do not want three separate distribution charts for LCP, INP, and CLS. They want to know whether the site is healthier than last month. This score gives them that without forcing the SEO lead to translate six dashboards on the fly.

It stays tied to field data

I like Lighthouse. I use Lighthouse. I also think teams over-trust it when reporting upward. I’ve seen pages with excellent synthetic scores still fail badly in real usage because ad slots, consent layers, third-party scripts, or low-end mobile devices changed the experience after the initial render. (I should mention—we tried once to report only synthetic performance for a fast-moving content site, and the dashboard looked great right up until Search Console started filling with poor mobile groups.)

Vitals Compliance Score keeps the KPI anchored to the same reality Google is using in its reporting surfaces.

It helps with prioritization

One of the most useful implementations is by template: product pages, category pages, article pages, account flows, location pages, whatever structure the site actually has. If 82% of articles pass but only 19% of category pages do, you stop arguing in the abstract. The work queue becomes clearer.

It trends well over time

Not perfectly. Still well.

A single percentage is easier to track monthly than a pile of issue labels that may shift as Search Console regroups URLs or as your frontend changes. You can annotate launches, migrations, tag-manager accidents, and front-end refactors against one stable KPI.

What counts as “eligible”?

This is where most bad implementations go sideways.

An eligible URL is not every page on the site. It is a page—or page group—you have enough field data to judge. If you dump your whole indexable inventory into the denominator, including thousands of pages with no useful CrUX or Search Console visibility, your score stops meaning much.

I learned this the hard way on a large content-and-commerce hybrid site. The first version of the dashboard looked terrible, which initially felt honest. Then I traced the denominator and realized we were punishing the score with long-tail pages Google couldn’t meaningfully evaluate. My mental model was wrong there. I thought “complete inventory” meant “better truth.” It didn’t. It meant measurement noise.

Usually, eligibility comes from one of these:

• URLs appearing in Google Search Console Core Web Vitals groupings
• URLs with usable CrUX coverage
• Internal page groups where enough representative URLs have field data

In many cases, I recommend reporting two numbers, not one:

• Compliance among eligible URLs
• Coverage of eligible URLs vs total indexable URLs

That split matters. A low compliance rate means performance is weak. A low eligibility coverage rate means measurement is thin. Those are different problems—very different operationally.

URL-level vs group-level scoring

Google Search Console often reports Core Web Vitals by groups of similar URLs, not every individual URL. Because of that, you need to choose the unit of analysis.

Group-level score

Count each Search Console issue group or page group once.

Best for: quick operational reporting when Search Console is the main source.

Main limitation: one giant group and one tiny group may count equally unless you apply weighting.

URL-level score

Expand the groups to the URLs they represent and count URLs individually.

Best for: more precise portfolio reporting.

Main limitation: you need stronger data plumbing, and you need to be honest about assumptions when group status is inherited by member URLs. (Quick caveat: this is the part teams often over-engineer. If your source data is group-based, pretending you have perfect URL-level truth can create fake precision.)

My default these days: start with group-level if that’s what you can maintain consistently, then graduate to URL-level only when the pipeline is reliable enough to justify it.

Weighted vs unweighted scoring

A plain Vitals Compliance Score treats every eligible URL equally. That’s often the right starting point.

But not always.

A site can improve hundreds of low-traffic pages while its money pages remain broken. An unweighted score may rise while the business barely feels it. That’s why I often pair the standard score with a weighted version, such as:

• weighted by organic sessions
• weighted by revenue contribution
• weighted by template importance
• weighted by indexable URL count within a group

A Shopify store we worked with had this exact issue. Their unweighted compliance improved after they cleaned up a large set of low-value informational pages. Nice win. But the category and collection templates—the pages driving search revenue—were still failing due to a combination of oversized hero media and app-script overhead. The executive dashboard looked healthier than the business actually was. Once I added a traffic-weighted view, the story changed immediately.

That’s why I usually want both:

• Unweighted compliance rate for technical health
• Traffic-weighted compliance rate for business impact

Both matter. Different lenses.

How to calculate Vitals Compliance Score in practice

A workable process usually looks like this:

1. Export Core Web Vitals data from Google Search Console, or pull from CrUX if you already have a reporting pipeline.
2. Choose the reporting unit: URL, page group, or template.
3. Mark each unit as pass/fail based on LCP, INP, and CLS thresholds.
4. Filter to eligible units only so your denominator reflects measurable pages.
5. Calculate the percentage passing.
6. Segment the result by device, template, market, traffic bucket, or business line.
7. Trend it over time and annotate frontend releases, migrations, CDN changes, consent changes, and third-party script additions.

A monthly scorecard might include:

• Sitewide mobile compliance
• Sitewide desktop compliance
• Compliance by page template
• Compliance among top landing pages
• Weighted compliance by organic sessions

Keep the methodology visible. Always.

Real-world example

A few months ago I was looking at a site that had a strange pattern: Lighthouse scores were respectable, but Search Console kept showing poor mobile groups on key landing templates. We dug into the field data and found the culprit wasn’t one dramatic failure—it was a stack of smaller issues. Late-loading review widgets. A chat script waking up too aggressively. Image containers reserving space inconsistently. A sticky mobile header changing height during interaction.

Nothing looked catastrophic in isolation. Together, they hammered INP and CLS.

When I rolled the site into a Vitals Compliance Score, the headline number was worse than the team expected—just under half of eligible mobile groups were passing. That stung. But it also gave product and engineering a target they could rally around. Not “make performance better,” which usually goes nowhere. Instead: get the mobile compliance rate on commercial templates above the current baseline, then track movement release by release.

The score improved after fixes, but not immediately everywhere because field data takes time to catch up. That’s another reason I like this KPI: it forces patience. Sometimes deserved patience…

How to interpret changes in the score

A rising score usually means more measurable pages are meeting Google’s real-user thresholds. Good sign. But don’t over-narrate it.

The score can change because:

• engineering fixes improved real-user performance
• slow templates lost eligibility or traffic
• Search Console regrouped URLs differently
• seasonality changed device mix or connection quality
• third-party scripts were added or removed
• page templates changed enough to alter field behavior

So when the score moves, I try to ask two questions:

1. Did the user experience likely improve?
2. Did the measurement system or page mix change?

You need both questions. Otherwise teams celebrate phantom wins or panic over reporting artifacts.

Relationship to SEO

Core Web Vitals matter for SEO, but I’d be careful with the claim set here.

Google has said page experience signals are among many ranking systems, not the dominant factor for most queries. So I would not tell a client, “Improve Vitals Compliance Score and rankings will rise.” That’s too neat. I used to be more optimistic about direct SEO visibility effects from performance work alone. Over time—and after enough before/after reviews where rankings barely moved despite better vitals—I revised that view.

What I believe now is more grounded:

• it reduces friction for users
• it helps prioritize technical work on search landing pages
• it creates a shared language across SEO, engineering, and product
• it helps you monitor whether high-value organic pages deliver acceptable real-user experience

Sometimes rankings improve. Sometimes conversions improve more than rankings. Sometimes the biggest win is that engineering finally has a performance KPI leadership can understand.

Good reporting practices

If you report this KPI internally, include the methodology beside the number. Say:

• which data source you used: Search Console, CrUX, or blended
• whether the score is URL-level or group-level
• whether it is weighted or unweighted
• whether it is mobile, desktop, or both
• what counts as eligible
• the reporting date and trailing window

Without that context, dashboards start fights.

Decision tree: should you use Vitals Compliance Score?

Use this quick decision tree:

If your team needs one top-line KPI for Core Web Vitals

Use Vitals Compliance Score.

If you only need debugging on a few URLs

Don’t start with this. Use Lighthouse, DevTools, RUM, and page-level analysis first.

If Search Console is your main source and data is grouped

Start with a group-level compliance score.

If you have strong internal URL mapping and reliable data plumbing

Consider a URL-level score.

If leadership cares about business impact more than technical breadth

Add a traffic-weighted or revenue-weighted version.

If many pages have no usable field data

Report eligibility coverage alongside the compliance score.

Common mistakes

Here are the mistakes I see most often:

1. Counting all indexed pages in the denominator

This is the classic one. If pages have no usable field data, they usually should not be counted as eligible.

2. Reporting one number without methodology

A 68% score means almost nothing if nobody knows whether it’s mobile-only, weighted, URL-level, or based on Search Console groups.

3. Treating lab data as interchangeable with field data

Lab tools are for diagnosis. Vitals Compliance Score is usually for reporting real-user outcomes.

4. Ignoring device splits

Mobile can fail while desktop passes comfortably. Combining them too early hides useful signal.

5. Using the score as a debugging tool

This KPI tells you how much is passing, not why pages are failing.

6. Over-claiming SEO impact

Better CWV can help the overall site experience and support SEO work, but it is not a guaranteed ranking lever by itself.

7. Mistaking severity for pass/fail

A barely failing page and a wildly broken page are both just “fail” inside this metric. That simplification is useful—but it also hides nuance.

Self-check

If you’re implementing this KPI, ask yourself:

• Have I defined eligible URLs clearly?
• Am I using field data, not just lab data?
• Is the score mobile, desktop, or split by both?
• Am I reporting at URL level or group level?
• Do I need a weighted version for business relevance?
• Am I pairing the score with diagnostic views for LCP, INP, and CLS?
• Have I documented the methodology so someone else can reproduce it?

If you can’t answer those cleanly, the KPI probably isn’t ready yet.

Limitations to remember

I like this metric, but I don’t romanticize it.

It can hide which specific metric is failing. It can hide severity. It depends on field-data availability. It can shift when Google’s grouping changes. And it should never replace proper debugging with Lighthouse, Chrome DevTools, or your own RUM instrumentation.

Top-line KPI. Not diagnosis.

That’s the right mental model.

FAQ

Is Vitals Compliance Score an official Google metric?

No. It’s an internal reporting construct built from Google’s Core Web Vitals definitions and reporting sources like Search Console and CrUX.

What is the formula for Vitals Compliance Score?

Passing eligible URLs or groups / total eligible URLs or groups × 100.

What makes a URL “eligible”?

Usually, it means the URL or page group has enough field data to be judged. If there’s no meaningful field data, I generally wouldn’t include it in the denominator.

Should I calculate it at the URL level or group level?

Use group level if Search Console is your main source and you want something maintainable. Use URL level if your internal data pipeline is strong enough to support it without pretending to be more precise than the source data.

Should the score be weighted?

Often, yes—but as a second view. I usually want an unweighted technical-health score and a traffic- or revenue-weighted business-impact score.

Is this better than Lighthouse scores?

For debugging? No. For a portfolio KPI tied to real-user performance? Usually yes. They answer different questions.

Can improving this score improve SEO rankings?

It can help overall page experience and may support SEO outcomes, but I would not promise ranking gains from this metric alone.

How often should I report it?

Monthly is a sensible default for most teams because field data moves more slowly than lab tests. Weekly can work if your organization needs tighter operational tracking and understands the lag.

Should mobile and desktop be combined?

I prefer reporting them separately first. Combining them too early can hide important problems, especially on sites with heavy mobile traffic.

What’s a good Vitals Compliance Score?

Higher is better, but I care less about some universal benchmark and more about whether the score is improving on the templates and devices that matter to the business. A sitewide 70% can be less useful than a focused 90% on critical landing templates.

A practical definition to use internally

If you need a concise version for docs or dashboards, use this:

Vitals Compliance Score is the percentage of eligible URLs or URL groups that pass Google’s Core Web Vitals thresholds in field data, used as a sitewide or template-level KPI for real-user page experience.