Start with journeys, not a site-wide average
List three to five journeys where delay has a clear customer or operational cost: landing on a campaign page, finding a product, submitting a lead form, signing in, or completing a support request. For each, write the start, useful outcome, main device class, and page or interaction that must work well.
Give every journey its own budget row. A dashboard may carry more code than a public article, but its filter action needs a responsiveness target. A media-rich product page may accept larger images, but needs a limit for the main visible image. This prevents a weak critical path from disappearing in an origin-wide average.
Name what the visitor can see or do, such as reading the offer, seeing a result, or receiving form confirmation.
Caching can materially change asset cost, so record whether the budget covers a first visit, repeat visit, or both.
Choose outcomes and controllable inputs
Use both outcome metrics and input limits. Google describes Largest Contentful Paint, or LCP, as loading performance; Interaction to Next Paint, or INP, as interaction responsiveness; and Cumulative Layout Shift, or CLS, as visual stability. Its recommended good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1 at the 75th percentile, considered separately for mobile and desktop.
Add limits that expose a cause early: initial JavaScript, images needed before the main content, total transfer for the route, third-party requests, and a known expensive widget. Track compressed transfer sizes consistently. A diagnostic like Time to First Byte can help investigate slow loading, but it is not the customer outcome by itself.
Use LCP when the journey depends on the main content becoming visible.
Use field INP for search, filtering, menus, and checkout; use a lab proxy only before field data exists.
Cap the initial route and largest contributors so owners know what must change after a breach.
Set numbers from your baseline
Capture a baseline for each journey. In PageSpeed Insights, distinguish Chrome User Experience Report field data, which aggregates real Chrome-user experiences, from Lighthouse lab data, which is a controlled test. Field data checks the experience reaching users; lab tests make a change repeatable before release.
Segment at least by mobile and desktop and, where possible, by critical template or URL. PageSpeed Insights can fall back from URL data to origin data, and some pages have no CrUX data. Label that case as a lab baseline and add real-user measurement for important journeys. Keep the test URL, device and network profile, cache state, date, and tool version with each baseline.
Choose a target that improves the baseline in a planned step, then test it on representative conditions. A budget that blocks normal releases gets bypassed; one above today’s experience protects no one.
The 75th percentile is the value at or below which 75% of observed experiences fall; it is not an average.
Make the budget a release rule
Keep the budget in a versioned, reviewable place beside the code or release checklist. Each row needs the journey, metric, test profile or population, warning threshold, error threshold, owner, measurement method, and exception route. MDN recommends warning and error levels: the warning supports proactive planning, while the error is an upper bound with noticeable negative effect.
Automate reliable checks. A bundler can reject an oversized asset or initial entry point; webpack supports maximum asset and entry-point limits and production error hints. Run repeatable lab tests for the affected journey in pull requests or release candidates. Keep field metrics for post-release verification and prioritization rather than an unreliable build gate.
When a limit fails, reduce an asset, defer nonessential code, alter the experience, split the release, or approve an exception. Do not silently raise the threshold to pass the build.
Record a product and technical owner, customer impact, expiry date, and remediation task before release.
Block a reproducible error threshold on a protected journey; notify and investigate warning thresholds.
Verify and remediate after launch
Page weight does not predict the full experience. Request order, render-blocking work, device capability, network conditions, caching, and third parties also matter. Keep input limits to catch growth and outcome measures to test whether the path is usable. The W3C Resource Timing interface exposes resource timings and transfer, encoded, and decoded sizes for deeper diagnosis. Cross-origin timing detail can be restricted by timing permissions, so an incomplete waterfall does not prove no third-party cost.
Review field results after significant template, platform, marketing-tag, or traffic changes. If LCP worsens, inspect server response, the LCP resource, and render-blocking work. If INP worsens, inspect actual interactions; Lighthouse cannot measure INP because it has no user input, though Total Blocking Time is a lab proxy. Use SIU’s proactive optimization workflow to triage a breach, stabilize the critical path, and verify the fix in the same measurement context.
Expired exceptions quickly reveal temporary performance debt that became permanent.