Performance Budget Limits per page type for field data and resources, with an owner, alerts and an exception process

By Christian Schreiber, Web Performance Consultant for AEM and Magnolia, updated 10 November 2026

A performance budget defines how slow a page may become at most and how much it may load at most, separately for each page type and market. It turns target values into a rule that every release, every campaign and every new tag passes through. The budget is the benchmark for ongoing performance control: measurement, sign-off and reporting all run against it. Implementation stays with the team that develops the platform.

Components of a performance budget: limits for field data and resource budgets

web.dev distinguishes budgets based on quantities such as page weight and number of requests, on milestones in page loading and on rule-based scores, and recommends combining quantities with user-centric metrics (Performance budgets 101). For enterprise platforms, a split into two levels works well:

• Limits for field data: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift at the 75th percentile on mobile, per page type and market, plus Time to First Byte as a diagnostic value. They are the benchmark for sign-off.
• Resource budgets: compressed JavaScript transfer size, image weight, number of third parties and main-thread time, measured in the lab as Total Blocking Time. They can be checked before the merge.

The two levels have different jobs. Field data shows the effect only after go-live and, in the Chrome User Experience Report, averaged over 28 days. Resource budgets act earlier but only approximate the field data. A Lighthouse score belongs in neither level, because it is a weighted lab measurement without consent and without interaction, as described under Measuring Core Web Vitals.

Target value, limit and alert: three thresholds with different consequences

Three thresholds of a performance budget

Threshold	Meaning	Consequence
Target value	value aimed for, with a margin to Google's threshold	planning in the backlog, reporting in the monthly report
Limit	value no release may exceed	build or release is rejected unless an exception has been approved
Alert	approaching the limit or a deviation in the field	ticket with release, page type and cause

An example for Largest Contentful Paint: Google rates values up to 2.5 seconds as good (web.dev: Web Vitals). The limit is 2.5 seconds, the target value 2.2 seconds, so that variance is absorbed before Google's field data tips over. The alert fires when real user monitoring sees the target value exceeded on two consecutive days.

Deriving budget values: baseline measurement, Google's thresholds and steps

1. Baseline measurement per page type, market and device: the 75th percentile of field data from the Chrome User Experience Report and your own monitoring, resources and main-thread time from lab measurements over several runs.
2. Google's thresholds as the upper bound for field data: 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint, 0.1 for Cumulative Layout Shift, 800 milliseconds for Time to First Byte (web.dev: TTFB).
3. If the baseline is below the threshold, today's level becomes the limit. The budget then prevents regression.
4. If it is above, today's level is also the limit, and the target value drops in quarterly steps until it reaches the threshold.
5. Resource budgets follow the field target: page types that pass in the field provide the order of magnitude for JavaScript, images and third parties of the others.

The Core Web Vitals Benchmark 2026 shows how wide the gap is in the market: on smartphones, 65.1 percent of AEM websites and 64.2 percent of Magnolia websites pass the Core Web Vitals; across all websites recorded in Germany, Austria and Switzerland, the figure is 68.7 percent. A passing value is a state that the budget protects against the next release.

Performance budget in the delivery pipeline: Lighthouse CI, PerfDelta and real user monitoring

Resource and lab budgets are checked by a measurement per page type in the delivery pipeline. Lighthouse CI runs Lighthouse in the pipeline and compares the results with defined limits; a build that breaks them fails. web.dev describes how budgets work with Lighthouse under Use Lighthouse for performance budgets. The limitation of this check: it measures in the test environment, where production tags, consent and differences between markets are often missing.

Performance budgets in PerfDelta apply to a project or a single page and cover page weight, JavaScript, images, fonts, third parties, number of requests, lab values and the mobile field data of LCP, INP, CLS, FCP and TTFB. When a value comes within ten percent of its limit, the tool warns; when it is exceeded, the check fails. Optionally, a limit is lowered step by step towards the target value after 30 days without a breach. The result can be fed into the pipeline via the REST API. Disclosure: PerfDelta is Christian Schreiber's own tool; details are under Measuring Core Web Vitals.

Real user monitoring checks the field data limits daily per page type, with a monthly comparison against the Chrome User Experience Report. Only the three levels together, pipeline, monitoring and Google's data, turn a budget into control.

Responsibility and exception process: who may exceed a performance budget

• One owner per page type. Usually the product owner who also decides on features and campaign components for that page type.
• Exceptions are approved by the owner, not by the implementing team. The request states the reason, the affected value, the expected overrun, the duration and a plan to make up for it.
• Every exception is time-limited. When it expires, the budget applies again, or it is redefined deliberately and on record.
• New tags go through the same process. Whatever comes from marketing and tag management is checked against the budget before go-live, as described under Third-Party Scripts.
• Sign-off separate from implementation. Whoever produces a result does not check it themselves. The process is described under Website Performance Optimization.

Budget per page type and market: example table with separate limits

A single budget for the whole domain hides the page types where things get stuck. Home pages carry the most campaign components, product pages the most images, form flows the most interactions. Markets differ in devices, networks, content and tags; a separate budget per market pays off as soon as different tags or content run there. The following values are an example without reference to any specific platform. They show the structure, not a recommendation.

Example: performance budget for three page types, one market, mobile (example values)

Metric	Home page	Product page	Form flow
LCP, 75th percentile field	2.5 s, target 2.2 s	2.5 s, target 2.2 s	2.5 s, target 2.0 s
INP, 75th percentile field	200 ms, target 180 ms	200 ms, target 180 ms	200 ms, target 150 ms
CLS, 75th percentile field	0.1, target 0.05	0.1, target 0.05	0.1, target 0.05
JavaScript, compressed	450 KB	400 KB	300 KB
Image weight	1,200 KB	1,000 KB	300 KB
Third-party hosts	12	10	6
Total Blocking Time, lab	400 ms	300 ms	200 ms

In this example, the form flow carries the strictest responsiveness targets, because every input counts there. How such values turn into tickets that can be signed off is shown in the Core Web Vitals acceptance criteria.

Book a free performance analysis

30 minutes via video call. You see Google's user data for your platform per page type as the starting point for a performance budget.

Frequently asked questions about performance budgets