Tracking Budget Compliance Over Time

A single failing release tells you almost nothing. What leadership and the platform team actually need is a direction: is the share of the site that meets its performance budget getting larger or smaller with each ship? This page, part of the Performance Budget Reporting and Scorecards reference, shows how to turn a pile of per-route pass/fail results into one honest, trendable number — a budget-compliance rate — and how to store, chart, and defend it release over release.

The compliance rate is deliberately coarse. It collapses dozens of routes and several metrics into a percentage that a director can read in two seconds, while still resting on rigorous per-route thresholds underneath. The craft is in defining it precisely, weighting it so a high-traffic checkout page counts for more than an obscure settings screen, and persisting it as a time series you can plot with confidence.

Defining the Compliance-Rate Metric

Start from a crisp definition, because a vague one produces a number nobody trusts. The budget-compliance rate is the share of tracked routes whose field metric sits at or below its budget at the 75th percentile (P75), measured on mid-range mobile over a Fast 3G-class connection unless the route is desktop-only. A route "complies" for a given metric when its P75 for the trailing 28-day window is within the ceiling written into the budget; a route complies overall when it passes on every metric it is scored against — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).

Anchoring on P75 rather than an average matters: the average hides the slow tail, while P75 is the value three of four real sessions beat, which is why it underpins percentile-based threshold tuning across the site. Compute the rate as passing routes divided by scored routes, expressed as a percentage. If 68 of 80 tracked routes are within budget at P75 on mid-range mobile, the compliance rate is 85.0 percent for that window.

Computing Per-Route Pass or Fail

Underneath the headline number sits a deterministic per-route check. Pull each route's P75 for the window from your aggregation store — the same pipeline described in building P75/P99 aggregation pipelines — and compare it to the route's budget. A route passes only if every scored metric is at or under its ceiling. Keep the logic boring and auditable.

// budgets keyed by route; each value is a per-metric ceiling at P75
// measured on mid-range mobile over a Fast 3G-class connection.
const budgets = {
  "/": { lcp: 2500, inp: 200, cls: 0.10 },
  "/checkout": { lcp: 2500, inp: 200, cls: 0.10 },
  "/product": { lcp: 3000, inp: 200, cls: 0.10 },
};

// p75 is the trailing 28-day P75 for each route+metric from RUM.
function routeComplies(route, p75) {
  const budget = budgets[route];
  if (!budget) return null; // untracked routes do not count
  return Object.entries(budget).every(([metric, ceiling]) => {
    return p75[route][metric] <= ceiling;
  });
}

function complianceRate(routes, p75) {
  const scored = routes.filter((r) => budgets[r]);
  const passing = scored.filter((r) => routeComplies(r, p75) === true);
  return {
    scored: scored.length,
    passing: passing.length,
    rate: Number(((passing.length / scored.length) * 100).toFixed(1)),
  };
}

Two rules keep the number honest. First, a route that lacks enough field samples in the window is excluded, not counted as a pass — silently promoting under-sampled routes inflates the rate. Second, a route is scored on exactly the metrics named in its budget, so adding a CLS ceiling to a route only tightens it, never loosens the arithmetic elsewhere.

Aggregating and Weighting by Traffic

An unweighted rate treats a rarely visited admin page and the checkout flow as equals. That is fine for an engineering scoreboard but misleading for a business one, because a regression on a route carrying 40 percent of sessions hurts far more users than one on a 0.5 percent route. Compute both: an unweighted route rate for the platform team and a traffic-weighted rate for the executive scorecard.

Weight each route by its share of real sessions in the same window, then sum the weights of the passing routes. Formally, the weighted compliance rate is the sum of session shares for within-budget routes. If your two highest-traffic routes are over budget, the weighted rate can sit well below the unweighted one — and that gap is exactly the signal executives should see.

Storing the Time Series

A trend needs history, so append one row per snapshot rather than overwriting a live figure. A snapshot is a compliance measurement for a defined window, tagged with the release it belongs to. Store the rate, the raw passing and scored counts, and the weighted rate, so you can recompute or audit later. A narrow, append-only table is enough.

If you keep field data in a SQL store, the write is a single insert per snapshot. Recording the counts alongside the percentage lets you re-derive the rate if a budget changes, and lets a chart show sample-size shifts.

CREATE TABLE IF NOT EXISTS budget_compliance (
  snapshot_date DATE NOT NULL,
  release TEXT NOT NULL,
  scored_routes INTEGER NOT NULL,
  passing_routes INTEGER NOT NULL,
  rate NUMERIC(5,1) NOT NULL,
  weighted_rate NUMERIC(5,1) NOT NULL,
  PRIMARY KEY (snapshot_date, release)
);

INSERT INTO budget_compliance
  (snapshot_date, release, scored_routes, passing_routes, rate, weighted_rate)
VALUES ('2026-07-24', 'v4.14', 82, 72, 87.8, 84.0);

Charting the Trend and Setting a Target Trajectory

With history in a table, plotting is straightforward — a time-series panel in your dashboard, covered in depth in visualizing budget trends with Grafana. Plot the compliance rate on the vertical axis against release on the horizontal, and overlay a target trajectory: the straight line from where you are today to the goal you have committed to, by the date you have committed to it. The gap between the actual series and the trajectory is the whole conversation in one glance.

Set the target as a slope, not a cliff. Committing to raise mobile compliance at P75 from 62 percent to 90 percent over one quarter implies roughly a two-point gain per two-week release; the trajectory line makes that pace visible and turns "we should be faster" into a checkable weekly expectation.

Verifying the Compliance Signal

Before anyone builds a goal on this number, verify it end to end. Pick one release, list the routes it marked as passing and failing, and hand-check three of each against the raw P75 values in the store — the counts must match the recorded rate exactly. Confirm that under-sampled routes are excluded rather than counted as passes, and that a route appearing or disappearing between snapshots changes the scored count, not the definition. Finally, re-run the calculation for a past snapshot from stored counts and confirm you reproduce the historical rate to one decimal place; a number you cannot reproduce is a number you cannot defend when a director asks why the line moved. When the P75 percentile source itself is in doubt, reconcile it against your P75 versus P90 target choice so the compliance rate and the underlying budgets speak the same statistical language.

Frequently Asked Questions