Composed Page Budget

When several independently-owned fragments compose into one page, each team can meet its own budget while the assembled result is far over. Every team is compliant and the user's experience is poor, and no individual team is wrong.

A composed page budget makes the total an owned number, measured on the page as delivered.

Why per-fragment budgets cannot work

The failure is structural, not cultural. Per-fragment budgets are locally satisfiable and globally unconstrained, and the total grows with the number of fragments.

It is compounded by duplication: independently-built fragments each ship their own framework and dependency copies, so a page assembling five of them may download five runtimes. Shared-dependency configuration prevents that and requires the cross-team version alignment that independent deployment was adopted to avoid — which is the central tension of the architecture rather than a configuration detail.

Implementation patterns

• Measured on the composed page in CI, on the routes that matter, with the check blocking.
• An owner for the total, with the authority to allocate. Budgets with no owner are everyone's responsibility and therefore nobody's.
• Per-fragment allocations derived from the total, so the arithmetic is explicit and reducing one fragment's share is visibly a negotiation rather than an edict.
• Shared dependencies enforced, with the version alignment treated as a standing cost of the architecture.
• Third-party scripts counted, since they are frequently the largest contributor and arrive through a tag manager rather than through code review.
• Attribution per change, showing which fragment or dependency added what.
• An exception process with an expiry, so exceeding the budget is possible when justified and does not silently become permanent.

Industry example

Organisations that adopt micro-frontends across many teams report a consistent pattern at the two-year mark: the product is slower, visually less consistent, and harder to change than before. The performance half is the composed budget problem; the consistency half is the absence of a design system adopted before splitting.

The changeability finding is the one that surprises people. Cross-cutting changes now require coordination across every team, which is worse than in a monolith where a single change reaches everything. The architecture optimises for change within a boundary and penalises change across boundaries — so if the product's valuable changes are navigation redesigns, authentication changes and design refreshes, it is working against the actual change pattern.

Failure scenarios

• Per-fragment budgets only, satisfied individually and breached in aggregate.
• Duplicated frameworks, invisible to any single team's measurement.
• No owner for the total, so the number drifts with nobody accountable.
• Third-party scripts excluded from the budget.
• The budget as a target rather than a gate, which cannot resist accumulation because no one ever chooses to exceed it.

Trade-offs

Enforcing an aggregate budget reintroduces coordination between teams that adopted the architecture to reduce it — a team blocked because another team's fragment grew is exactly the coupling micro-frontends promised to remove.

That is an honest cost and the alternative is worse. The deeper point is that it should inform the original decision: if the composed budget requires this much coordination anyway, the independence being purchased may be smaller than it looked, and the real constraint may have been a slow build rather than deployment coupling.

Interview question

"Five teams each meet their frontend performance budget and the page takes eight seconds to become interactive on a mid-range phone. Who is wrong, and what would you change about how the budgets are set?"