A tender that says "the website should load quickly" describes a hope, not a target state. At acceptance it turns into measurement against measurement: the contractor shows a run from a development machine, the client one from a phone on a train, and both numbers are genuine. The way out is unspectacular, and in public procurement it is even mandatory – the subject of the contract must be described so unambiguously that every bidder understands it in the same sense (GWB). For load time, unambiguous means one number, one measurement method, one data source and one proof date, separately for each metric. The size of the market for such wording is on record: for 2024 German official statistics report 199,334 (Statistisches Bundesamt) awarded contracts worth 135.2 billion euros (Statistisches Bundesamt). The technical baseline comes from a Lighthouse audit taken before the first draft contract.
Key takeaways
- A target value without a measurement rule is not a criterion. It becomes acceptable with four entries: number, measurement method, data source and proof date. For the core metrics the definition supplies them: 2.5 seconds, 200 milliseconds and 0.1 (web.dev).
- The measurement rule is the 75th percentile (web.dev), and field data comes from a rolling period of 28 days (Google PageSpeed Insights). Acceptance on go-live day is therefore impossible: freshly published pages still have insufficient data.
- The target value has to be reachable. Across the whole corpus, 48 percent (Web Almanac 2025) of mobile and 56 percent (Web Almanac 2025) of desktop sites pass all three core metrics at once.
- The legal consequence rests on the agreement: a work is free of material defects if it has the agreed quality (BGB). Without a number in the contract there is no defect, without a defect no withholding – and the remuneration falls due at acceptance (BGB).
- Page weight belongs beside them as a line of its own, because it can be checked before go-live. The median mobile home page weighs 2.6 MB (Web Almanac 2025); below one megabyte 57 percent of mobile pages pass, from five megabytes upward only 30 percent.
Why fast is not an acceptance criterion
"Fast", "performant", "optimised to current standards" can neither be disputed nor demonstrated, which is exactly why procurement law asks for something else: the subject of the contract must be described as unambiguously as possible, so that the description is understandable in the same sense for all undertakings and the tenders can be compared with one another (GWB). Anyone tendering "fast loading" receives offers that lie far apart in price, because every bidder has priced something different – one an image format, the next a rebuild of the templates including frontend optimisation.
Under German contract law more than comparability hangs on this. A work is free of material defects if it has the agreed quality (BGB) – the agreement is the yardstick, not what the client had in mind. No number, no defect; and without a defect there is neither rectification nor withholding. The reverse also holds: a vague target offers no protection either, because acceptance may not be refused on account of insignificant defects (BGB), and wording nobody can measure is quickly declared insignificant in a dispute. Then there is deemed acceptance: a client who, after a deadline has been set, fails to refuse within that period while stating at least one defect has accepted the work (BGB).
No agreement, no defect
The five rows of an acceptance matrix
A usable acceptance matrix has one row per criterion and four documented columns: target value, measurement method, data source and proof date. Three rows come with their definition included. For the largest visible content element the target is 2.5 seconds (web.dev), counted from the moment the page starts loading. For input responsiveness the value is 200 milliseconds (web.dev). For layout stability it is 0.1 (web.dev) – a dimensionless ratio describing how much of the screen shifts unasked. How they interact in production is set out on our page about the Core Web Vitals.
The fourth row is server response time. It is not one of the core metrics but has a documented corridor: good values sit at 0.8 seconds (web.dev) or below, poor ones above 1.8 seconds (web.dev). It belongs in the matrix because it describes the one share that a contractor can influence only indirectly when hosting is provided by someone else – the boundary between server performance and the frontend belongs in the same contract section. The fifth row is page weight, and it is the only one that can be fully verified before go-live. How such a limit is anchored technically is described in the article on performance budgets in the build pipeline.
| Criterion | Target value | Measurement method | Data source | Proof date |
|---|---|---|---|---|
| Largest contentful paint | 2.5 s or less | 75th percentile, split by mobile and desktop | field data | 28 days after go-live |
| Input responsiveness | 200 ms or less | 75th percentile, split by mobile and desktop | field data | 28 days after go-live |
| Layout stability | 0.1 or less | 75th percentile, split by mobile and desktop | field data | 28 days after go-live |
| Server response time | 0.8 s or less | 75th percentile | field data and lab run | at handover and after 28 days |
| Page weight | cap per template | median of ten runs per template | lab run | at every delivery |
A fifth column is added only at acceptance: the status. That needs no invention either, because the common measurement tool sorts user experience into three classes – good, needs improvement and poor (Google PageSpeed Insights). That three-way split works unchanged as a traffic light entered per row at acceptance, because it can be read off the tool and does not have to be negotiated.
The measurement rule decides, not the target value
A target value without a percentile is an invitation to argue, because every page returns a different number on every visit. The documented rule reads: a page passes if it meets the recommended targets at the 75th percentile for all three core metrics (web.dev). The percentile establishes that three quarters of all real visits must stay within the value – not the average, which a handful of fast visits flatter. The tool's scoring logic confirms it explicitly: an assessment passes only if the 75th percentiles of all three metrics fall in the good range (Google PageSpeed Insights).
The second part of the measurement rule is the time window. Field data is formed over a trailing collection period of 28 days (Google PageSpeed Insights). One consequence follows that is missing from almost every project schedule: with field-based criteria, acceptance on go-live day is not possible. A page can even stand there with no data basis at all, because values are absent when it was published only recently or has too few real user visits (Google PageSpeed Insights). What works in practice is a two-stage acceptance: technical handover against lab measurement, final acceptance against field data once the window has elapsed. Which data source is good for what is separated in the article on field data and lab data.
{
"acceptance": {
"percentile": 75,
"window_days": 28,
"platforms": ["mobile", "desktop"],
"pages": ["home", "category", "detail", "search", "contact"],
"passes_when": "all criteria met per platform and per page",
"criteria": [
{ "metric": "LCP", "target_ms": 2500, "source": "field", "level": "good" },
{ "metric": "INP", "target_ms": 200, "source": "field", "level": "good" },
{ "metric": "CLS", "target": 0.1, "source": "field", "level": "good" },
{ "metric": "TTFB", "target_ms": 800, "source": "field+lab", "level": "good" },
{ "metric": "weight", "target_kb": 1500, "source": "lab", "runs": 10 }
],
"levels": ["good", "needs-improvement", "poor"],
"proof": {
"handover": "lab run per template, median of 10 runs",
"final": "field data, 28 days after release"
}
}
}Lab and field can move in opposite directions at the same time, which is why the data source belongs in every row. An example from the live corpus: the lab-measured blocking time of the median mobile page rose to 1,916 milliseconds (Web Almanac 2025) in 2025, up 58 percent (Web Almanac 2025) on the year before – while field values for input responsiveness improved over the same period. Anyone writing a lab score into the contract instead is mainly writing down a weighting: blocking time alone accounts for 30 percent (Chrome for Developers) of the performance score. How to read such a report properly is shown in the article on the Lighthouse report.
Three formulations that fail at acceptance
Target values that are reachable
A contract whose target value nobody reaches does not produce a fast website, it produces a change request. The corpus supplies the yardstick: up to 2024, 44 percent of mobile and 55 percent of desktop sites achieved a good assessment across all three core metrics; in 2025 it was 48 percent (Web Almanac 2025) on mobile and 56 percent (Web Almanac 2025) at the desk. A target of "all three green" is therefore no walkover, but no imposition either – it describes the better half of the web. The reference matters: the survey rests on measurements from July 2025 (Web Almanac 2025).
Splitting by device is not a nicety but the largest single difference in the matrix. For content paint, 74 percent (Web Almanac 2025) of desktop pages reach a good value against 62 percent (Web Almanac 2025) on mobile. For input responsiveness the mobile share of good values stands at 77 percent (Web Almanac 2025), after 74 percent the year before. Server response time is the hardest row: only 44 percent (Web Almanac 2025) of mobile sites reach a good value there. Writing a single number for both platforms means writing either too soft a target for the desk or too hard a one for the road – why the hardware is responsible is set out in the article on the target device rather than the test device.
Split by platform
Two rows per metric instead of one: one for mobile visits, one for the desk. A shared target value is the wrong one for at least one of the two sides.
Not only the home page
Secondary pages pass the assessment more often than home pages – the lead is 14 percent (Web Almanac 2025) on desktop and 11 percent (Web Almanac 2025) on mobile. Accepting only the home page means accepting the least favourable case and knowing nothing about the rest of the site.
Exclusions instead of a wish list
Some findings can be ruled out in advance because they are unambiguously testable. One example: roughly 16 to 17 percent (Web Almanac 2025) of pages lazy-load their most important image. A single sentence in the contract excludes exactly that, with nothing left to negotiate.
Page weight as its own contract line
Page weight is the only row in the matrix that is conclusively testable before go-live. The corpus provides the reference: in 2025 the median home page weighed 2.6 MB (Web Almanac 2025) on mobile and 2.9 MB (Web Almanac 2025) on desktop. Across all pages – not just home pages – the 75th percentile sits at 4,119 KB (Web Almanac 2025) on mobile and 4,570 KB (Web Almanac 2025) at the desk. Those values are a benchmark, not a target – a cap is set below the median, not above it, otherwise the contract merely writes down the average.
Why a weight cap works is visible in its link to the pass rate. Among pages up to one megabyte, 70 percent (Web Almanac 2025) of desktop and 57 percent (Web Almanac 2025) of mobile pages pass; from five megabytes upward the share falls to 38 percent (Web Almanac 2025) and 30 percent (Web Almanac 2025) respectively. Two sub-rows make sense: a separate cap for executable code – the median is 664 KB (Web Almanac 2025) per home page – and an upper limit for the number of requests, whose median stands at 77 (Web Almanac 2025) on desktop and 72 (Web Almanac 2025) on mobile. How such a limit is enforced day to day is described in the article on budgets for executable code.
The core in one sentence
What a missed target triggers
In a contract for work, acceptance is the payment date: the remuneration is to be paid at the acceptance of the work (BGB). The measurement rule therefore also decides about money, in both directions. If an agreed target value is missed, the client may refuse payment of a reasonable part of the remuneration; as a rule, reasonable means twice the cost required for removal of the defect (BGB).
The second legal consequence concerns the time afterwards. The limitation period for claims for defects in works of this kind is two years (BGB), and it begins with acceptance (BGB). The proof date in the matrix therefore also starts the clock on everything noticed later. And anyone who wants speed as a permanent state needs continuous measurement alongside acceptance, because content, extensions and campaigns move the values after the fact – the traps that arise there are shown in the article on A/B tests without flicker.
Acceptance is a date, not a state
Public procurement: numbers instead of adjectives
In public contracts, an unambiguous statement of work is not a recommendation but a duty (GWB). There is already a precedent there for how a quality requirement migrates into the description: for services intended for use by natural persons, accessibility criteria for people with disabilities must be taken into account except in duly justified cases (GWB). For consumer services, accessibility has additionally been anchored in law since 28 June 2025 (BFSG). Speed can be anchored on the same pattern: as a dedicated section of the statement of work with target value, measurement method and proof, not as a subordinate clause in the project description.
One pitfall is almost routine: prescribing a particular measurement tool narrows the field of bidders. German procurement regulation therefore requires that any reference to such a technical requirement carry the words "or equivalent" (VgV). In practice that means the metric and its definition belong in the contract, the tool only as an example. The model contracts themselves are in motion too – for the procurement of open source software, eight contract types (IT-Planungsrat) were revised; the corresponding resolution dates from 26 November 2025 (IT-Planungsrat).
- Choose the metrics and create one row per metric – content paint, input responsiveness, layout stability, server response time, page weight
- Enter the target value and quote the definition rather than paraphrasing it: 2.5 seconds (web.dev), 200 milliseconds (web.dev), 0.1 (web.dev)
- Add the measurement rule: 75th percentile, split by mobile and stationary use, all criteria at the same time (Google PageSpeed Insights)
- Determine the data source per row and record the difference between field and lab measurement in writing – the article on mobile optimisation shows how far apart the two can be
- Fix the page list: at least home, category, detail, search and contact page, because secondary pages perform systematically better than the home page
- Schedule the proof dates: lab run at handover, field data after 28 days (Google PageSpeed Insights), and put both dates into the project plan
- Name the legal consequence: what counts as insignificant, what triggers rectification, and which part of the remuneration stays open until proof is delivered (BGB)
What is missing from that list is deliberate: a target score. It sounds handy but shifts the definition into a tool whose weighting can change – blocking time alone contributes 30 percent (Chrome for Developers) there. A score works as an internal progress measure and as an argument in the project report, not as an acceptance criterion. How to separate progress measure and acceptance criterion cleanly is described by the technical analysis as the starting point of a project.
The question is rarely whether a website is fast. The question is who gets to prove the opposite, at which number, on which device and on which day – and that answer is in the contract or nowhere.
The effort behind an acceptance matrix is modest: a table with five rows, four documented columns and three dates. The return is that the discussion about speed moves from the end of the project to its beginning, where it still costs something, but little. Holding the matrix against your own corpus with a baseline run before the tender also shows immediately which target values are realistic and which mean a rebuild – the entry point for that is a Lighthouse audit on the five templates that will later appear in the matrix. What that means for the individual metrics is set out in the overview of the core metrics in 2026.
Sources and studies