Question 1

What does the Core Web Vitals Revenue-Impact Gate do?

Accepted Answer

It grades each page against Google's published 2026 Core Web Vitals thresholds — LCP, INP, and CLS at the 75th percentile of real mobile visitors — and returns PASSING, NEEDS WORK, or BLEEDING. It names the worst metric to fix first and, using your own conversion value and your own per-100ms sensitivity assumption, estimates the revenue at risk on each slow page. It grades the page, not people, and reads no live data: you paste field values you measured.

Question 2

What are the Core Web Vitals thresholds it uses?

Accepted Answer

Google's published 2026 values, at the 75th percentile of field data, mobile-first: LCP good is 2.5 seconds or under (needs improvement 2.5-4.0s, poor over 4.0s); INP good is 200ms or under (needs improvement 200-500ms, poor over 500ms); CLS good is 0.1 or under (needs improvement 0.1-0.25, poor over 0.25). These have been stable for years for LCP and CLS, and for INP since it replaced FID in March 2024. The kit ships with them and you can edit them if Google changes them.

Question 3

Why does a page with two perfect metrics still read BLEEDING?

Accepted Answer

Because Google grades a page on its worst metric, not its average. A page passes Core Web Vitals only when all three metrics are good at once — Search Console assigns a URL group the status of its worst-performing metric, so one poor metric fails the whole page even if the other two are flawless. The gate mirrors that exactly: the verdict is the worst of LCP, INP, and CLS. In the worked sample, a category page with good LCP and good CLS still reads BLEEDING because its INP is poor.

Question 4

Where does the revenue-at-risk number come from? Is it a real prediction?

Accepted Answer

It comes entirely from your own inputs — your monthly sessions, conversion rate, and value per conversion, multiplied by a per-100ms sensitivity figure that you set in a clearly-labeled, editable cell (default 1%, which is yours to change). RedHub asserts no industry lift multiplier and guarantees no recovery. It is an illustrative figure built from your assumption, useful for prioritizing and for making the business case internally — not a promise that fixing the page returns that exact amount.

Question 5

What's the difference between field data and lab data, and which do I enter?

Accepted Answer

Enter field data — the real-user numbers from the Chrome User Experience Report, shown in Google Search Console's Core Web Vitals report or the field section of PageSpeed Insights. Lab data (a Lighthouse score) runs on a simulated fast device and can look great while your real mobile users sit in the poor bucket. Google ranks on the field data, so that's what this gate grades. If you only have a Lighthouse score, treat it as a diagnostic, not the number to enter here.

Question 6

Will fixing my Core Web Vitals guarantee better rankings or more sales?

Accepted Answer

No. Core Web Vitals are a confirmed ranking signal but a tiebreaker, not the primary one — content relevance and authority outweigh them, and improvements take about 28 days to show in Search Console because the field window is a rolling 28-day average. This kit tells you which pages fail and which metric to fix first, and quantifies the stakes from your own numbers. It does not guarantee a ranking change or a revenue recovery, and it is not legal or financial advice.

Core Web Vitals Revenue-Impact Gate

A respectable-looking dashboard can still be failing.

Three metrics, one rule: all three must be good.

LCP — loading

INP — responsiveness

CLS — visual stability

Your numbers — no invented multiplier.

Worst metric wins

Your sensitivity, your call

Field data, not lab

Enter one page's field values and your numbers.

A verdict per page, a number for the site.

Anyone making the case to fix page speed.

Fix the speed, then the rest of the funnel.

Straight answers before you buy.

Find the slow pages. Price the leak.