A practical guide to web performance budgets

POSTED: 18.06.2024AUTHOR: ADMIN7 MIN READCOMMENTS: 0

Performance budgets convert an abstract ambition—“the site should be fast”—into constraints a delivery team can test continuously.

Begin with the user experience

A budget should describe outcomes before file sizes. Set thresholds for Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift at a defined percentile, network profile and device class. Lab checks are useful gates; field data remains the operational truth.

performance_budget:
  lcp_p75: <= 2500ms
  inp_p75: <= 200ms
  cls_p75: <= 0.10
  javascript_initial: <= 180kb
  third_party_cpu: <= 300ms

Assign weight where it changes decisions

Bundle limits only work when they are enforced before merge. Treat JavaScript, fonts, media and third-party execution as separate budgets because they have different owners and failure modes. A single total page-weight target allows expensive script to hide behind well-compressed imagery.

FIELD NOTE 04A

The analytics container is part of the product. Measure its main-thread cost and failure behaviour like any other production dependency.

Make regression visible

Run repeatable tests against representative templates, compare results with the main branch and block changes that exceed an agreed tolerance. Review the budget quarterly: a threshold that never influences a decision is documentation, not governance.