Create an Editorial Page Performance Budget

This self-study workshop creates a performance budget for an imaginary editorial page. You will allocate resource allowances, classify three fictional observations and distinguish a size pass from a timing pass. The exercise uses invented numbers and local decision logic; it measures no live website and makes no speed claim about INTIAU.

The web.dev performance-budget introduction describes limits on quantities such as page weight, request count and timing. It explains that equal weight or request totals can still produce different rendering experiences because resource ordering matters.

Give each limit a meaning

Our fictional policy allows at most 500 KiB of transferred resources, twenty requests and 1,500 milliseconds to the chosen load event. These are exercise thresholds, not published standards or a complete definition of user experience. The quantities must be measured consistently before the policy can classify a result.

The allocated groups sum to 420 KiB. Adding the eighty-KiB headroom reaches the 500-KiB ceiling. Headroom is not a required extra download. It is space in the plan that a later decision may consume, and using it should still be recorded.

Worked classification and complete answers

Consider three supplied fictional observations. A has 432 KiB, eighteen requests and a 1,400-millisecond load value. B has 350 KiB, twenty-one requests and 1,300 milliseconds. C has 480 KiB, nineteen requests and 1,800 milliseconds. Apply each limit separately before producing an overall result.

A passes all three checks. B passes weight and time but fails requests by one. C passes weight and requests but fails time by 300 milliseconds. Calling B fast because it is lighter would discard one policy condition; calling C acceptable because it is under 500 KiB would discard another.

function budgetFailures(metrics) {
  for (const key of ["kib", "requests", "loadMs"]) {
    if (!Number.isFinite(metrics[key]) || metrics[key] < 0) {
      return ["invalid measurement"];
    }
  }
  const failures = [];
  if (metrics.kib > 500) failures.push("weight");
  if (metrics.requests > 20) failures.push("requests");
  if (metrics.loadMs > 1500) failures.push("load");
  return failures;
}

The complete function answer for A is an empty array, for B an array containing requests, and for C an array containing load. A value exactly equal to a limit passes because the comparisons reject only larger values. A negative or non-finite supplied value returns invalid measurement instead of receiving a green classification.

Diagnose the failed assumption

Do not subtract thirty KiB from C and claim that its load value must fall by 300 milliseconds. The supplied observations contain no transfer-rate or execution model that supports that conversion. Resource weight can guide an investigation without establishing a deterministic timing improvement.

Likewise, B’s extra request does not identify the expensive resource. The next useful output is an investigation question: which resource creates that request, when is it needed and what would change if it were combined, deferred or removed? A policy failure gives a boundary, not a complete cause.

Record the measurement conditions beside a future real observation: viewport, browser, authentication state, cache conditions, network treatment and the exact timing definition. A warm local sample and a cold field visit are not automatically comparable. In this workshop the observations remain invented, so none of those environments has actually been measured.

For a next paper exercise, propose a two-hundred-KiB image that would consume all the remaining headroom and exceed the ceiling by 120 KiB. Decide whether it replaces an existing allowance or adds to it. A replacement and an addition produce different totals; the request should state which operation is intended.

Questions and completion criteria

Submit the allocation sum, the three classifications, exact-limit and invalid-data answers, and one cause-investigation question for each failing observation. The important skill is keeping a planning rule, a measurement and a causal explanation separate.

This is an original INTIAU editorial self-study activity; no qualification is awarded. See Courses or Contact for institutional information.

View the study diagram