Set performance requirements with Core Web Vitals
Core Web Vitals are three of Google's metrics for how fast and stable a web page feels: loading, responsiveness, and visual stability. As the client, you write their thresholds into the requirements spec and turn speed into a measurable delivery requirement instead of a hope. At acceptance, you can easily verify the outcome with Google's own free tools.
“The page should be fast” is one of the most common lines in a requirements spec, and one of the most useless. Fast for whom, measured how, and what happens if it isn’t? Core Web Vitals turns that fuzzy wish into something concrete: measurable targets that both you and your vendor can agree on and verify. Here’s how to use them as a client.
The three metrics without tech jargon
Core Web Vitals are three metrics from Google that together describe how a page feels. Behind the acronyms are three everyday questions.
- Loading (LCP): how long does it take before the main content appears? It’s the wait from click to the page feeling like it’s “arrived.” A visitor staring at a blank space gets impatient fast.
- Responsiveness (INP): how quickly does the page react when someone does something – clicks a button, opens a menu? It measures whether the page feels snappy or sluggish to interact with.
- Visual stability (CLS): does the content stay put, or does it jump around while the page loads? Everyone has accidentally tapped the wrong thing because a button shifted at the last second. That’s exactly what this metric captures.
The point is that these three cover what most people mean by “fast and pleasant” – that you see the content quickly, that it responds instantly, and that it doesn’t skitter around. None of it requires a technical background to understand.
Exact thresholds to write into the requirements spec
What makes Core Web Vitals useful as a client requirement is that Google has set clear limits for what counts as good. They can be written straight into the requirements spec.
| Metric | Threshold for good performance |
|---|---|
| Loading (LCP) | Under 2.5 seconds |
| Responsiveness (INP) | Under 200 milliseconds |
| Visual stability (CLS) | Under 0.1 |
Don’t just write in the numbers, but also the conditions: that they should apply to the most important page templates – home page, product page, checkout, or equivalent – and be measured on mobile, since that’s usually where performance is hardest to achieve and where most visitors are. The wording can be simple: “Home, category, and product pages must meet Google’s thresholds for LCP, INP, and CLS, measured on mobile, at delivery.” That turns a hope into an acceptable, testable requirement.
Verification with free tools at acceptance
A requirement you can’t check offers no real assurance. The great thing about Core Web Vitals is that verification is free and open – you don’t need any special expertise to look.
Google’s PageSpeed Insights gives you a measurement right in the browser: paste in the page’s URL and you get the values and a color code. Lighthouse, built into the Chrome browser, does the same thing locally. Run the measurement on exactly the page templates you’ve agreed on, in mobile mode, and check it against the thresholds in the requirements spec.
A concrete approach at acceptance: go through the three or four most important page types, run each one through PageSpeed Insights, and note the values next to the requirements. If something is red, it’s not approved, and the vendor needs to fix it before final payment. Since the tool is public, you and the vendor are looking at exactly the same numbers – there’s no room for different versions of reality.
Why lab measurements and real-world data differ
One thing to know: the values can differ between a single measurement in the tool and the data Google collects from real visitors over time. A lab measurement is taken under controlled conditions, while real users have different phones, connections, and locations. A page can therefore look green in your measurement but lag in the real-world data – often because many visitors have weaker devices than the computer you’re testing on.
For you as the client, that means two things. Write the requirement so it applies when measured on mobile, since that’s closer to the reality of your weakest-connected visitors. And treat the acceptance measurement as a minimum bar, not final proof: follow up with the real-world data once the service has been live for a while. Understanding that difference keeps you from being lulled into false confidence by a nice number that only holds under ideal conditions.
Building a service that meets these metrics from the start is part of how we work at Weapp on our services. Want help wording the right performance requirements in your requirements spec? Get in touch and we’ll look at what’s reasonable for your specific service.
Frequently asked questions
What is Core Web Vitals?
Core Web Vitals is a set of metrics from Google that describe how a web page is experienced by the visitor: how fast the main content loads, how quickly the page responds to interaction, and how stable the content stays without jumping around. They're an attempt to turn the elusive feeling of speed into something measurable and comparable, and they also affect how the page ranks in Google.
Why should I, as the client, care about Core Web Vitals?
Because they turn perceived speed into a requirement you can follow up on instead of a pious hope. Without measurable targets, performance easily becomes something everyone nods along to but nobody is responsible for. With thresholds in the requirements spec, it's clear what needs to be delivered, and you can verify it at acceptance. Speed also directly affects both conversion and Google ranking.
Which thresholds should I write into the requirements spec?
Google's own benchmarks for good performance are a solid starting point: loading (LCP) under 2.5 seconds, responsiveness (INP) under 200 milliseconds, and visual stability (CLS) under 0.1. Specify that they should apply to your most important page templates, measured on mobile, and hold up in the tool you verify with. That makes the requirement concrete and testable.
How do I verify Core Web Vitals at delivery?
With Google's free tools. PageSpeed Insights gives you a measurement right in the browser if you paste in a URL, and Lighthouse is built into Chrome. Run the measurement on the page templates you've agreed on and check it against the thresholds in the requirements spec. Since the tools are free and public, both you and your vendor can look at the same numbers.
Is Core Web Vitals the same as the page being fast?
Almost, but not quite. Core Web Vitals capture three important aspects of perceived performance, but a page can have green scores and still feel sluggish in some way they don't measure. They're an excellent shared language and a good minimum bar, but should be seen as a clear starting point rather than the whole truth about how fast a service feels.