No Lighthouse in requirements Sign-off is against field data at the 75th percentile per page type, not against a lab score
In requirements specifications and sign-offs, I often come across a Lighthouse score as the performance requirement, such as "at least 90 on mobile". I consider that a mistake. The score measures something different from the assessment by which Google and visitors judge a website, and it can be reached without any improvement in the experience of real users. Requirements and sign-off need field data: the 75th percentile per page type, separately for mobile and desktop.
Lighthouse is a good diagnostic tool, and that is where it belongs. My objection concerns only its use as a target value. The reasons are documented, partly by Google itself, partly in my own Core Web Vitals Benchmark 2026.
The Lighthouse score weights metrics differently from Google's Core Web Vitals assessment
The Lighthouse performance score is a weighted average of five lab metrics. According to Google's documentation, Total Blocking Time counts for 30 percent, Largest Contentful Paint and Cumulative Layout Shift for 25 percent each, and First Contentful Paint and Speed Index for 10 percent each (Lighthouse performance scoring).
Google's Core Web Vitals assessment has no average, only three thresholds: Largest Contentful Paint up to 2.5 seconds, Interaction to Next Paint up to 200 milliseconds, Cumulative Layout Shift up to 0.1, each at the 75th percentile of visits (web.dev). A page passes only if it meets all three thresholds. This results in three differences:
- Half of the score is made up of metrics that are not Core Web Vitals: Total Blocking Time, First Contentful Paint and Speed Index.
- Interaction to Next Paint is missing entirely, because a lab measurement without interaction cannot capture it. Total Blocking Time is only an approximation (web.dev on TBT).
- In an average, a very good value compensates for a poor one. In Google's assessment, a page with a slow Largest Contentful Paint fails, no matter how stable its layout is.
The AEM Core Web Vitals Benchmark shows how much the missing responsiveness matters: of the 127 websites that fail in the separate crawl, 47.2 percent miss the threshold for Interaction to Next Paint, which is exactly the metric that does not appear in the Lighthouse score.
Lab measurement without consent and interaction: the score does not see production
Lighthouse measures a single page load under fixed conditions. For mobile, its default setting simulates a Moto G Power with a throttled connection and a CPU slowed down four times (Lighthouse configuration). What is missing is exactly what determines the values on enterprise platforms:
- Consent: in the lab, nobody accepts the consent dialog. Tags that only load afterwards, such as analytics, testing tools and personalization, are absent from the measurement.
- Interaction: nobody clicks, taps or opens a menu. Responsiveness stays invisible.
- Diversity: real visitors arrive with different devices, connections, caches and entry pages. The 75th percentile reflects this spread; a single run does not.
On top of that comes the variance between two runs. The Lighthouse team itself describes that the score fluctuates even without code changes and recommends taking the median of several runs (Lighthouse variability). An acceptance criterion that can produce two results for two measurements of the same version creates debate instead of clarity. Google explains why lab and field data diverge in Why lab and field data can be different.
Edge Delivery Services: 100 Lighthouse points before go-live do not determine field values
The difference is most visible with Adobe's Edge Delivery Services. In Keeping it 100, Adobe describes how projects keep a Lighthouse score of 100, and its go-live checklist names 100 points for mobile and desktop as the goal. The architecture is genuinely lean, and I consider it a good starting point.
In the field, the benchmark shows a more sober picture. In the HTTP Archive data, 54.0 percent of the 87 recorded websites on Edge Delivery Services pass the Core Web Vitals on smartphones. In the separate crawl, it is 45.1 percent of 51 websites, with a median server response time of 782 milliseconds. Both groups are small.
Whether these websites scored 100 at go-live is not something the benchmark shows. It does show that the platform alone does not determine the result in the field: tag manager, consent dialog and personalization are added after go-live and are not part of the lab value of a preview. More on this in AEM Edge Delivery Services.
Sign-off against field data: 75th percentile per page type, mobile, over 28 days
What belongs in the requirements instead fits into one sentence: for the page types homepage, listing page, detail page and form, target values for Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift apply on mobile at the 75th percentile of field data over 28 days. Google's thresholds are the starting point; stricter values can make sense for page types that carry a lot of revenue. Complete wording is provided in the templates AEM performance requirements and Magnolia performance requirements.
Three specifications make this requirement verifiable:
- Per page type instead of per domain: an average across the domain hides the page types where things get stuck.
- Named source: real user monitoring provides values per page type, and the Chrome User Experience Report adds them for sufficiently visited URLs. Which tools use which source is described in Measuring Core Web Vitals.
- Lab as a pre-check: before go-live, a lab measurement under defined conditions checks whether a change works in the right direction. It decides on the merge, not on the sign-off.
Ticket templates with this split are available in the Core Web Vitals acceptance criteria.
Objections to field data: delay and comprehensibility can be solved
I regularly hear two objections. The first: field data comes too late, because Google collects for 28 days. For the Chrome User Experience Report, that is true. This is why sign-off has two stages: the lab pre-check before go-live and the proof in the field afterwards. Real user monitoring shortens the second stage considerably, because it evaluates daily.
The second: a score is easier to understand than three percentiles per page type. That is true as well. But a requirement that is easy to understand and measures the wrong thing protects neither the operator nor the agency. An agency that delivers 95 points while the field data fails has met the requirements and missed the goal. Only a criterion that matches Google's assessment prevents this conflict.
Book a free performance analysis
30 minutes by video. You receive Google's real-user data for your platform compared with two competitors, regardless of whether we work together.
Frequently asked questions about Lighthouse and field data in sign-off
Does Lighthouse still have a place in projects?
Yes, as a diagnostic tool and as a pre-check in the delivery pipeline. Lighthouse shows the waterfall, the main thread and individual elements reproducibly and is suitable for comparing two versions of the same page. As a target value in the requirements and as a sign-off criterion, the score is unsuitable, because it does not measure what Google assesses.
What applies to page types with too few visitors for field data?
Real user monitoring also captures page types for which the Chrome User Experience Report shows no values. If the number of visits is still too low, similar page types are grouped, or a lab measurement under defined conditions is agreed as a substitute and explicitly labeled as such. How this looks in tickets is shown in the Core Web Vitals acceptance criteria.
Why does PageSpeed Insights show 100 points and still failed Core Web Vitals?
PageSpeed Insights shows two sources side by side. At the top is the field data from real visitors over the last 28 days, below it a Lighthouse measurement on simulated hardware. The score belongs to the lab measurement and is not part of Google's assessment. More in Measuring Core Web Vitals.