Choose a page and a test condition
Start with a representative page: an article, a search result, or a product detail. Record the viewport, network profile, and cache state you will use for comparisons. A cached desktop visit and a first visit on a slow phone answer different questions.
Use a small number of limits. Transfer size can catch a new dependency before release; a loading metric can reveal the effect of a late image request. Field measurements show what visitors experience. Resource budgets and user experience metrics serve different purposes, so keep both where they inform a decision.
Write down exactly what counts
An illustrative rule might cap compressed JavaScript transferred during an article's initial load at 100 KB. That number is a project choice, not a universal recommendation. Specify whether third-party scripts count and whether deferred downloads are measured separately. Otherwise a change can appear to pass simply by moving the same cost to a later request.
Give the rule an owner and a consequence. A pull request exceeding the limit should show its measured size and explain the added behavior. The team can reduce the cost, choose a smaller implementation, or accept a documented exception before merging.
Keep the test conditions in version control
Run the same page against the same configuration several times and compare a representative result such as the median. Keep the number of runs fixed. A single unusually fast result tells you little about a small regression.
When lab results improve but field results do not, check the comparison. The lab may use an empty cache while returning visitors dominate the field sample. The affected template may have too little traffic for a useful page-level result. Record the limitation instead of declaring the discrepancy solved.
Report the cost where someone can act on it
Suppose a syntax-highlighting package adds more JavaScript to every article, including articles with no code. A useful check identifies the affected entry point and the size increase. That suggests concrete options: highlight during the build, load the package only where needed, or use a smaller feature set.
For a large hero image, inspect when its request starts as well as its size. Compressing it will not remove a long delay before the browser discovers it. Show a request waterfall or trace with the budget failure so the reviewer can connect the number to a cause.
Make an exception expire
An exception should name the feature, the measured cost, and the person responsible for revisiting it. If an interactive chart is required for a release, record the affected pages and a review date. Link the follow-up work to the exception.
When that date arrives, check whether the feature is used and whether the cost can be reduced. Do not silently increase the limit whenever a build fails. A budget only influences design if exceeding it requires an actual decision.
Sources & further reading
Technical references checked on 17 September 2026.