Website Speed Requirements to Put in Your Web Design Scope
By Parker Gawryletz · Local Cochrane Web Design · Last updated: · 7 min read
Website speed requirements belong in the design scope as measurable acceptance criteria, not the word "fast." Specify Google's Core Web Vitals thresholds — LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1 — plus a page-weight budget, mobile testing conditions, and who fixes failures before launch.
"The site will be fast" is the least enforceable sentence in any proposal. Without numbers, fast means whatever the designer's laptop says on launch day. Real website speed requirements for web design are written as thresholds you can test — and they belong in the scope before you sign anything.
This guide gives you those numbers: the current Core Web Vitals thresholds, the budgets that keep pages light, and the verification step that proves it all before launch. It reflects how custom web design engineered for performance is scoped — targets first, design second.
The short answer
- Write speed into the scope as measurable thresholds, never as "fast".
- Core Web Vitals targets: LCP under 2.5s, INP under 200ms, CLS under 0.1.
- Set a page-weight and JavaScript budget before design starts.
- Test on real phones over mobile networks, not office Wi-Fi.
- Put verification and remediation responsibility in the proposal itself.
Replace 'fast' with measurable requirements
Replace the word "fast" with acceptance criteria: named metrics, numeric thresholds, the testing tool, and the testing conditions. "Passes Core Web Vitals in PageSpeed Insights mobile testing before launch" is enforceable. "The site will be fast" is not — it cannot fail, so it cannot protect you.
The pattern for every requirement is the same: metric, threshold, tool, condition. Anyone can verify it, including you, and nobody can argue about what was promised. When a provider resists putting numbers in writing, that tells you what their launches usually score.
Current Core Web Vitals thresholds
Google publishes three Core Web Vitals with pass thresholds: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1 — each assessed at the 75th percentile of page loads. These are the numbers to write into your scope.
| Requirement | Threshold | How to verify |
|---|---|---|
| Largest Contentful Paint (LCP) | Under 2.5 seconds | PageSpeed Insights, mobile test, before launch |
| Interaction to Next Paint (INP) | Under 200 milliseconds | PageSpeed Insights, plus CrUX field data once live |
| Cumulative Layout Shift (CLS) | Under 0.1 | PageSpeed Insights, checked on each key page template |
The thresholds come from Google's web.dev documentation, and each one is assessed at the 75th percentile of real page loads — meaning the site has to be fast for most visitors, not just the average one.
Set a page-weight and JavaScript budget
A performance budget caps how heavy pages are allowed to get: total download size, image sizes, and how much JavaScript ships to the phone. There is no single correct number — the point is agreeing limits before design begins, so every feature request is weighed against the budget it spends.
- Total page weight — the full download size of each key template
- Images — modern formats, compressed, sized for the screens they serve
- JavaScript — the scripts a phone must run before the page feels usable
- Fonts — how many families and weights load, and how
- Third-party embeds — chat widgets, feeds and trackers, each justified
Make the hero/LCP image discoverable and prioritized
The largest element at the top of the page — usually the hero image or headline — is what LCP measures. Require that this image is compressed to a modern format, sized for the screen it serves, and flagged in the code so the browser fetches it first rather than last.
This is a build detail owners never see and always feel. Ask one plain question in the scope conversation: "How will the hero image be optimized so LCP passes on mobile?" A capable designer has a specific answer; a template-reseller changes the subject.
Reserve dimensions to prevent layout shift
Layout shift happens when images, embeds or late-loading content push the page around while someone is reading it. The fix is structural: every image and embed declares its dimensions so the browser reserves the space in advance, and fonts load without reflowing text that is already visible.
Layout shift is the metric visitors describe in plain words: "I went to tap the button and it moved." On a contact page, that moment costs enquiries — which is why CLS belongs in the acceptance table, not in the designer's private judgement.
Limit fonts, animation and third-party scripts
Every font family, animation library and third-party script — chat widgets, trackers, embedded feeds — costs load time on mobile. Require a justification for each one: what it does for visitors, what it weighs, and whether it loads after the page instead of blocking it. Most sites carry more than they need.
None of these is banned; they are budgeted. Two font families cover almost every small-business brand, animation should be light and respect visitors who prefer reduced motion, and each third-party script should earn its place — or load only on the page that uses it.
Test on representative mobile conditions
Office Wi-Fi on a new laptop proves nothing. Require testing on real phones over throttled or genuine mobile connections, because that is how most visitors arrive — and where scores fall. Around Cochrane and Rocky View County, patchy rural mobile coverage makes mobile-first speed a business requirement, not a nicety.
You can run this test yourself before hiring anyone: put a designer's recent launches through PageSpeed Insights on the mobile setting and see what they ship when nobody is checking. The full method — including what else to look for — is in how to evaluate web design portfolios.
Use lab tests for diagnosis and field data for outcomes
Lab tests such as PageSpeed Insights run a controlled page load and tell you what to fix before launch. Field data from Google's Chrome UX Report (CrUX) shows how real visitors actually experience the site over time. Use lab data to diagnose, and field data as the measure of success.
Field data only accumulates after real visitors arrive, which is why performance is an ongoing responsibility as well as a launch requirement — website performance monitoring and care keeps the measurements running long after the launch invoice is paid.
Put verification and remediation in the proposal
The scope should state three things in writing: the thresholds the site must meet, how and when they are verified, and who fixes failures at whose cost. Verification on real devices before launch — with remediation included rather than billed extra — is the standard worth asking every provider for.
This is a fair test of any provider's confidence in their own work. Local Cochrane Web Design's written guarantees include a performance budget verified on real devices before launch — ask everyone on your shortlist whether they will commit to the same. Building that shortlist now? Start with compare Cochrane web designers.
Frequently asked questions
What is a good website load speed?
Google's published thresholds are the practical standard: the largest visible element should load within 2.5 seconds, the page should respond to taps within 200 milliseconds, and the layout should barely shift while loading. Test with PageSpeed Insights on the mobile setting, since that is where most visitors are.
What Core Web Vitals should a site pass?
Three metrics, all published by Google: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. Each is assessed at the 75th percentile of page loads, meaning the site must hit the numbers for most real visits.
Should speed be in a web design contract?
Yes, as measurable acceptance criteria: the thresholds the site must meet, the tool used to verify them, the testing conditions, and who fixes failures at whose cost. Without numbers in writing, a speed promise cannot fail — which means it cannot protect you after launch either.
Why are mobile scores lower?
Mobile tests simulate slower processors and slower networks, which is exactly how many real visitors browse. A page that feels instant on office Wi-Fi can take several times longer on a mid-range phone over a mobile connection. That is why mobile results, not desktop results, should set the requirement.
Do animations slow websites?
They can. Animation libraries add JavaScript weight, and effects that move or resize elements force the browser to recalculate layout, which causes stutter on phones. Well-built animation is lightweight and smooth — but every effect should justify its cost, and respect visitors who prefer reduced motion.
How should speed be measured before launch?
Run PageSpeed Insights on each key page template in mobile mode, check the results against the agreed thresholds, and test on at least one real mid-range phone over a mobile connection. Record the results in writing, because field data from real visitors only starts accumulating after launch.
Sources
Request a performance-engineered scope — a Cochrane build scoped with Core Web Vitals thresholds, a page-weight budget, and real-device verification written in before work begins.