---
title: 'Frontend Quality'
source: 'https://academia.sh/en/courses/frontend-quality'
language: en
updated: '2026-08-17T14:25:35+00:00'
license: 'CC BY-SA 4.0'
lessons: 27
outcomes:
- 'Defines a performance budget and verifies it by measurement'
- "Applies accessibility criteria at the standard's level"
- 'Reduces client-side security risks with layered defenses'
---
# Frontend Quality
The measurable quality axes of a published interface; budgeting performance with user-centric metrics, tying accessibility to standard criteria, client-side security defenses, and the testing and monitoring that verify behavior.
## Performance
Defining user-centric metrics, shortening the critical rendering path, image and font loading strategies, tuning the network layer with headers, long tasks at runtime, and tying it all to a budget that catches regressions.
### User-Centric Metrics
Source: https://academia.sh/en/courses/frontend-quality/user-centric-metrics
Measuring a published interface's speed by the events the user perceives; the definitions of loading, interactivity, and visual stability metrics, computing a layout shift's score, and summarizing a distribution with percentiles.
The North Slope Measurement Station application gets built, bundled, and published. The
build output ships to a hosting target, releases can be rolled back, and environment
variables stay separated. The deployment pipeline answered one question — does the code
reach the user — and the answer was yes.
The unanswered question is: how well does what arrives work for the user? This lesson
builds the measurable form of that question. The metrics tie to events the user
perceives; tying them to a budget is left to this topic's last lesson.
#### Technical Milestones Answer the Wrong Question
A page loading is a process with events defined for the browser: document parsing
finishes, subresources arrive, the load event fires. These events are measurable and
recordable. The problem is not measurability — it is what they represent.
Consider the station list page. The list arrives inside the HTML from the server and
appears immediately; a map component further down the page downloads a large script and
becomes ready two seconds later. The load event fires when the map is ready. The user,
meanwhile, saw the list in one second and has already tapped the station they were
looking for.
The reverse case exists too: the document finishes early, but nothing readable is on
screen because the content gets produced by script. The load event is early; what the
user sees is a blank screen.
In both cases the technical milestone is accurate and describes the experience wrong. A
metric's subject should not be the browser's internal flow — it should be what the user
sees on screen and does.
#### Three Questions, Five Metrics
User-centric metrics separate three questions.
**When did I see something?** This question has two measures. Time to first byte is the
time between sending the request and the response's first byte arriving; it is the first
segment of the timing that the Network Panel Diagnostics lesson breaks into stages. It
measures the server side and sets the ceiling for any optimization done on the client:
every later metric stacks on top of this time. First contentful paint is the moment any
content from the document — text, an image, a canvas drawing — first gets painted on
screen. It reports that the blank screen has ended, not that the page is ready.
**When did I see the real content?** Largest contentful paint is the moment the largest
content element in the viewport gets painted. The metric's idea is this: a page's feeling
of being "loaded" comes from the arrival of the element that occupies the most space. On
the station list page, this element is the list itself; on the measurement detail page,
it is the station photo. The metric keeps updating through loading; if a larger element
gets painted later, the candidate changes and the metric moves forward.
**When did I get a response to my touch?** Interaction to next paint is the time from a
user interaction — a click, a tap, a key — to the screen's next paint that reflects it.
What gets measured is not the handler's own duration but the user's entire perceived
delay: the time the input waits to be processed, the handler's duration, and producing
the frame. Many interactions happen over the course of a page; the metric gives a single
value representing the worst of them.
**Did the screen shift under my feet?** Cumulative layout shift is the sum of unexpected
displacements. It is the quantitative counterpart of the phenomenon introduced as content
shift in the Web Fundamentals and HTML course, and unlike the other metrics it gives not
a duration but a unitless score.
#### The Score for Visual Stability
A shift's score is the product of two fractions. The impact fraction is the ratio of the
union of the shifting element's visible areas across two consecutive frames to the
viewport area: how much of the screen got affected? The distance fraction is the ratio of
the largest distance the element traveled to the viewport's larger dimension: how far did
it go?
The following computation assumes the shifting elements span the full width of the
viewport; under this assumption the impact region reduces from a two-dimensional area to
a single vertical interval. For narrower elements, the same product scales by the width
ratio.
```js
// shift.mjs — a single layout shift's score and the session window total
const VIEWPORT = { width: 390, height: 844 }; // viewport size, CSS pixels
// Each shift: the unstable element's vertical range before and after the shift.
const shifts = [
{ name: "announcement banner opened", before: [96, 700], after: [196, 800] },
{ name: "station image settled", before: [200, 444], after: [224, 468] },
{ name: "measurement badge arrived", before: [512, 560], after: [520, 568] },
];
function shiftScore(shift) {
const [beforeTop, beforeBottom] = shift.before;
const [afterTop, afterBottom] = shift.after;
// Impact region: the union of the visible areas across two frames.
const unionTop = Math.max(0, Math.min(beforeTop, afterTop));
const unionBottom = Math.min(VIEWPORT.height, Math.max(beforeBottom, afterBottom));
const impactFraction = (unionBottom - unionTop) / VIEWPORT.height;
// Distance fraction: the largest distance the element traveled / the viewport's larger dimension.
const distance = Math.abs(afterTop - beforeTop);
const distanceFraction = distance / Math.max(VIEWPORT.width, VIEWPORT.height);
return { impactFraction, distanceFraction, distance, score: impactFraction * distanceFraction };
}
console.log("shift".padEnd(28) + "moved".padStart(8) + "impact".padStart(8) +
"distance".padStart(10) + "score".padStart(8));
let total = 0;
for (const s of shifts) {
const r = shiftScore(s);
total += r.score;
console.log(
s.name.padEnd(28) + `${r.distance}px`.padStart(8) +
r.impactFraction.toFixed(3).padStart(8) + r.distanceFraction.toFixed(3).padStart(10) +
r.score.toFixed(4).padStart(8));
}
console.log("-".repeat(62));
console.log("session window total".padEnd(28) + total.toFixed(4).padStart(34));
console.log(`threshold rating: ${total <= 0.1 ? "good" : total <= 0.25 ? "needs improvement" : "poor"}`);
```
```
shift moved impact distance score
announcement banner opened 100px 0.834 0.118 0.0988
station image settled 24px 0.318 0.028 0.0090
measurement badge arrived 8px 0.066 0.009 0.0006
--------------------------------------------------------------
session window total 0.1085
threshold rating: needs improvement
```
The three shifts have very different impact. The hundred-pixel announcement banner that
opens above the page pushes down everything below it, so it affects eighty-three percent
of the screen and alone produces nearly the entire score. The measurement badge's
eight-pixel jitter, by contrast, amounts to six-hundredths of a percent.
Two rules follow from this. A shift's cost is proportional not to the shifting element's
size but to **how much content sits beneath it**: a small element at the very top of the
page is more expensive than a large one at the very bottom. And because the score is a
product, when either fraction approaches zero the result approaches zero — a shift
outside the viewport counts for nothing at all.
The summing rule is also part of the definition: shifts get summed within a **session
window**, and the page's score is the largest of these windows. A window groups shifts
that have no long gap between them; a page left open for hours does not get a poor score
from small shifts accumulating over that time.
Shifts that start with user movement do not enter the metric. A panel that opens on a
button press and pushes down what is below it is an expected outcome; what gets measured
is the **unexpected** shift.
#### Field Data and Lab Data
The same metric gets collected two separate ways, and the two answer different
questions.
Lab data is a measurement produced under controlled conditions: a fixed network
throttle, a fixed device profile, a browser with no extensions, a cold cache. Because it
is reproducible, it suits comparison; it is the only reliable way to measure the
difference between two builds. The question it does not answer is what real users
actually experience.
Field data is a measurement collected from real visits. It carries device diversity,
network conditions, and user behavior. The question it does not answer is why: it
reports that a metric got worse, not which resource caused the delay.
Neither substitutes for the other. Field data shows that a problem exists; lab data
shows where. Metrics like interaction to next paint arise only through user interaction,
so they cannot be produced directly under lab conditions; measuring them requires
simulating the interaction, and a simulation does not represent a real usage pattern.
#### Summarizing a Distribution
Field data is not a single number but a distribution, and which number summarizes that
distribution changes the conclusion.
```js
// distribution.mjs — two different summaries of the same page: the mean and percentiles
// The distribution is a generated sample, not measured field data:
// a deterministic generator produces 500 visits.
let seed = 20260728;
const random = () => (seed = (seed * 1103515245 + 12345) % 2147483648) / 2147483648;
const visits = Array.from({ length: 500 }, () => {
// Roughly a third of visits are in the slow condition (distant network, slow device).
const slow = random() < 0.3;
return slow
? Math.round(3400 + random() * 2100)
: Math.round(1200 + random() * 800);
});
function percentile(arr, p) {
const sorted = [...arr].sort((a, b) => a - b);
const position = (p / 100) * (sorted.length - 1);
const lower = Math.floor(position);
const upper = Math.ceil(position);
return sorted[lower] + (sorted[upper] - sorted[lower]) * (position - lower);
}
const mean = visits.reduce((a, b) => a + b, 0) / visits.length;
console.log("largest contentful paint summary (generated sample distribution, 500 visits)");
for (const [label, value] of [
["mean", mean],
["median (50th)", percentile(visits, 50)],
["75th percentile", percentile(visits, 75)],
["95th percentile", percentile(visits, 95)],
]) {
const rating = value <= 2500 ? "good" : value <= 4000 ? "needs improvement" : "poor";
console.log(`${label.padEnd(16)}${(value / 1000).toFixed(2)} s -> ${rating}`);
}
const goodRatio = visits.filter((v) => v <= 2500).length / visits.length;
console.log(`share of visits under the threshold: ${(goodRatio * 100).toFixed(1)}%`);
```
```
largest contentful paint summary (generated sample distribution, 500 visits)
mean 2.38 s -> good
median (50th) 1.73 s -> good
75th percentile 3.56 s -> needs improvement
95th percentile 5.15 s -> poor
share of visits under the threshold: 72.4%
```
The distribution is built inside the program with a deterministic generator; it is not
measured field data but a sample generated to show the difference between two
summarization methods. A third of the visits are assumed to be in the slow condition,
the rest in the fast condition.
The result gives the same data two conflicting answers. The mean is 2.38 seconds and
falls in the good rating; the 75th percentile is 3.56 seconds and falls in the
needs-improvement rating. The gap is not a computation error — it is how the mean works:
fast visits hide the weight of the slow ones.
A percentile cannot do that. The 75th percentile means "three-quarters of users saw
better than this value," and it corresponds directly to a share of users. The share of
visits under the threshold gives the same information: in this distribution, 72 percent
of visits fall under the good threshold.
The metrics' standard thresholds are also defined over a distribution. For largest
contentful paint, up to 2.5 seconds counts as good and up to 4 seconds as needs
improvement; for cumulative layout shift the limits are 0.1 and 0.25; for interaction to
next paint they are 200 and 500 milliseconds. The classification applies not to a single
visit but to the chosen percentile.
#### Choosing Metrics for the Station Pages
The application's two pages are not judged by the same metrics.
The **station list page** is a navigation starting point. The user comes here to see the
list and immediately taps a row. The decisive metrics are largest contentful paint and
cumulative layout shift: if the list arrives late, the user waits; if it shifts late, the
user taps the wrong row.
The **measurement detail page** is a working surface. The user changes the date range,
filters the chart, converts units. The decisive metric is interaction to next paint;
loading happens once, interaction happens dozens of times.
Metric selection therefore depends on the page's job. Tracking every metric with the
same weight on every page hides which job broke.
#### Summary
- Technical milestones measure the browser's internal flow; user-centric metrics measure
what the user sees and does, and the two can degrade independently of each other.
- The three questions map to five metrics: time to first byte and first contentful paint
measure the blank screen ending, largest contentful paint measures the real content's
arrival, interaction to next paint measures response time, cumulative layout shift
measures visual stability.
- A layout shift's score is the product of the impact fraction and the distance
fraction; what determines the cost is not the shifting element's size but how much
content sits beneath it.
- Field data shows that a problem exists, lab data shows where; one is reproducible, the
other is representative.
- When a distribution is summarized with the mean, slow visits get hidden; because a
percentile corresponds directly to a share of users, metric thresholds get applied to
a percentile.
#### Next Step
The metrics are defined, and which number to read them by is settled. The next question
is where the measured time gets spent. If largest contentful paint happens late, the
delay sits in one of three places: the server producing a response, the response being
transported, or the resources the browser has to wait for before it can paint anything.
The third is entirely under the developer's control and is often the largest share. The
next lesson addresses which resources the first paint waits for, and computes how many
round trips that wait costs, through a calculable model.
### Critical Rendering Path
Source: https://academia.sh/en/courses/frontend-quality/critical-rendering-path
The resources first paint has to wait for; the distinction between render-blocking CSS and parser-blocking scripts, computing the round-trip count, and the markup patterns that remove blocking.
The previous lesson defined the metrics: if largest contentful paint happens late, there
is a problem. The delay can have three sources — the server producing the response, the
response being transported, and the resources the browser has to wait for before it can
paint anything. The third is entirely under the developer's control.
This lesson defines that wait. The critical rendering path is the chain of work that
must complete before first paint can happen. The chain's length can be measured and
shortened.
#### Two Different Kinds of Blocking
The browser parses the document top to bottom and requests the resources it encounters
along the way. Two kinds of resource stop this flow, and they stop it differently.
**Render-blocking CSS.** Until an external stylesheet gets downloaded and resolved, the
browser paints nothing. The reason is the cascade: by the rule the Visual Presentation
with CSS course establishes, an element's computed value can change because of a
declaration in a file that has not arrived yet. Painting with incomplete style would mean
a page that looks completely different seconds later. So the browser waits. Parsing the
document continues — a stylesheet does not stop parsing — but painting stops.
**Parser-blocking script.** A script written directly into the document, carrying
neither `defer` nor `async`, stops parsing until it has downloaded and run. The reason is
that the script can modify the document: it can produce or delete the content that
follows it, so the browser cannot continue. Because parsing stops, nothing after it can
get discovered; painting cannot happen either.
The two kinds of blocking compound. A stylesheet that comes before a script also delays
the script's execution: because the script might read computed values, the browser has
to wait for the stylesheet to resolve. A single ordering decision thereby ties three jobs
together.
#### Three Variables
The wait's length depends on three separate quantities, and separating them determines
which optimization will actually help.
**Byte count** is the part that depends on bandwidth. Compression and dead-code
elimination affect this.
**Round-trip count** is the part that depends on latency. When data gets sent over a
connection, the congestion window starts small and grows with each round trip; a large
file therefore does not arrive in a single round trip. This behavior, defined in the
Network Models and Protocols course, produces the following performance consequence: the
first bytes are cheap, the later ones are expensive.
**Chain depth**, in turn, depends on discovery order. If a resource's existence only
becomes known after another resource has downloaded, the two cannot be requested in
parallel; their durations add up.
The following model computes all three together.
```js
// critical-path.mjs — a computation modeling how many round trips first paint costs
const MSS = 1460; // bytes: the payload one segment carries
const INITIAL_WINDOW = 10; // segments: how many segments can be sent in the first round
// The connection carries the congestion window across rounds; the window doubles each round.
function connection() {
let window = INITIAL_WINDOW;
return {
get window() { return window; },
// One stage: resources requested concurrently share the same window.
stage(bytes) {
let remaining = bytes.reduce((a, b) => a + b, 0);
let round = 0;
do {
remaining -= window * MSS;
window *= 2;
round += 1;
} while (remaining > 0);
return round;
},
};
}
function firstPaint(scenario) {
const b = connection();
let round = scenario.connectionSetup;
const breakdown = [["connection setup", scenario.connectionSetup, "-"]];
for (const stage of scenario.stages) {
const previousWindow = b.window;
const t = b.stage(stage.bytes);
round += t;
breakdown.push([stage.name, t, `${previousWindow} -> ${b.window} segments`]);
}
return { round, breakdown };
}
// North Slope Measurement Station — the station list page.
// Connection setup: name resolution 1 + transport handshake 1 + secure handshake 1 = 3 rounds.
const scenarios = [
{
name: "A: blocking style and script up front",
connectionSetup: 3,
stages: [
{ name: "HTML body", bytes: [18_400] },
{ name: "blocking style + script", bytes: [62_000, 141_000] },
{ name: "style discovered by the script", bytes: [24_000] },
],
},
{
name: "B: script deferred",
connectionSetup: 3,
stages: [
{ name: "HTML body", bytes: [18_400] },
{ name: "blocking style", bytes: [62_000] },
],
},
{
name: "C: critical style inlined",
connectionSetup: 3,
stages: [
{ name: "HTML body (+ inlined style)", bytes: [18_400 + 9_800] },
],
},
];
console.log("--- slow start: total bytes sendable by the end of round k ---");
let accumulated = 0;
let window = INITIAL_WINDOW;
for (let k = 1; k <= 4; k++) {
accumulated += window * MSS;
console.log(`round ${k} window ${String(window).padStart(3)} segments total ${String(accumulated).padStart(7)} bytes`);
window *= 2;
}
console.log("\n--- round-trip breakdown to first paint ---");
const results = [];
for (const s of scenarios) {
const r = firstPaint(s);
results.push({ name: s.name, round: r.round });
console.log(`\n${s.name}`);
for (const [name, t, p] of r.breakdown) {
console.log(` ${name.padEnd(30)} ${t} rounds ${p}`);
}
console.log(` ${"TOTAL".padEnd(30)} ${r.round} rounds`);
}
console.log("\n--- comparing the scenarios ---");
const baseline = results[0].round;
for (const s of results) {
console.log(`${s.name.padEnd(34)} ${String(s.round).padStart(2)} rounds ratio to A: ${(s.round / baseline).toFixed(2)}`);
}
```
```
--- slow start: total bytes sendable by the end of round k ---
round 1 window 10 segments total 14600 bytes
round 2 window 20 segments total 43800 bytes
round 3 window 40 segments total 102200 bytes
round 4 window 80 segments total 219000 bytes
--- round-trip breakdown to first paint ---
A: blocking style and script up front
connection setup 3 rounds -
HTML body 2 rounds 10 -> 40 segments
blocking style + script 3 rounds 40 -> 320 segments
style discovered by the script 1 rounds 320 -> 640 segments
TOTAL 9 rounds
B: script deferred
connection setup 3 rounds -
HTML body 2 rounds 10 -> 40 segments
blocking style 2 rounds 40 -> 160 segments
TOTAL 7 rounds
C: critical style inlined
connection setup 3 rounds -
HTML body (+ inlined style) 2 rounds 10 -> 40 segments
TOTAL 5 rounds
--- comparing the scenarios ---
A: blocking style and script up front 9 rounds ratio to A: 1.00
B: script deferred 7 rounds ratio to A: 0.78
C: critical style inlined 5 rounds ratio to A: 0.56
```
The first table shows the congestion window growing: in the first round a little over
fourteen kilobytes of data can be sent, and by the end of the fourth round that exceeds
two hundred kilobytes. This number is not a limit but a starting assumption; the initial
window depends on configuration, and the model exposes the value as a constant up front.
The three scenarios build the same page with three different markups. In scenario A, the
blocking style and script sit at the top of the document, and a second stylesheet gets
discovered only after the script has downloaded. In scenario B, the script gets deferred;
both its own bytes and the chain it discovers drop out of the critical path. In scenario
C, the first screen's style gets inlined into the document and no external request
remains.
The result reads through ratios: scenario B waits seventy-eight percent of A's time,
scenario C fifty-six percent. An absolute duration cannot be given, because a round's
duration depends on the network — but the round count follows from the markup itself and
is comparable.
The model simplifies reality at two points. It assumes that concurrent requests within a
stage share the same window, and it does not account for the window shrinking after idle
time. Both push the result in favor of A, not B and C; the real difference, in other
words, is not smaller than what the model shows but larger.
#### Removing the Blocking
The ways of shortening the critical path correspond to the two kinds of blocking.
**Taking the script out of the critical path.** The `defer` attribute lets the script
download in parallel with parsing and run, in write order, only after document parsing
finishes. `async` also downloads in parallel but runs the moment it arrives; there is no
order guarantee, and running it still interrupts parsing at that moment. `defer` suits
scripts that depend on each other; `async` suits scripts that are independent and
self-contained. Scripts loaded as modules behave as deferred by default.
**Making a stylesheet conditional.** When the `media` attribute gets written on a
stylesheet link, the file does not block painting if the condition does not currently
hold. Print stylesheets and styles that only apply on wide screens get taken out of the
critical path this way. The file still downloads, but at low priority and without
holding up painting.
**Inlining critical CSS.** The declarations sufficient to paint the first screen get
written directly into the document; the remaining style loads through a non-blocking
path. This is the source of scenario C's gain, and it has a cost: inlined style cannot be
cached separately, arrives again with every page request, and enlarges the document. The
decision depends on the repeat-visit rate — a gain on a page dominated by first visits is
a loss on a panel opened every day.
**Moving a late-discovered resource earlier.** If a resource only gets discovered after a
stylesheet resolves or a script runs, it can be requested at the top of the document with
a `preload` declaration. This declaration is a correction, not an optimization: it should
not get used when a direct way to shorten the chain exists, because written incorrectly
it makes a resource download twice or takes bandwidth away from a resource that is
genuinely critical.
#### The Discovery Chain
Scenario A's fourth line — "style discovered by the script" — alone produces more than
one round's cost, because that round can only start after the script has downloaded and
run.
The browser's preload scanner skims the document quickly before parsing it and requests
the resources it sees ahead of time. The one thing the preload scanner cannot see is
resources not written in the document: links inserted by a script, other stylesheets
called from within a stylesheet, addresses determined only after a configuration file
gets read.
This is why the most effective step in critical-path optimization is often not reducing
bytes but **flattening the chain**: making every critical resource visible in the
document's first bytes.
#### The Station List Page's Document Head
```html
North Slope Measurement Station — Stations
```
The second link is a markup trick and needs explaining: a stylesheet written with
`media="print"` does not block painting, and once the file has downloaded, the `onload`
handler sets the media to `all`, applying the style. The second link inside `noscript`
makes sure the style still arrives when the script does not run. The trick exists because
there is no direct "blocking" declaration available for a stylesheet link.
The `min-height` declaration in the inlined style is for stability, not performance: the
list rows take their height before the data arrives, so the layout shift computed in the
previous lesson does not happen. Two goals meet in the same declaration.
#### Summary
- The critical rendering path is the chain of work first paint has to wait for;
render-blocking CSS stops painting, and a parser-blocking script stops both parsing
and painting.
- The wait's three components get handled separately: byte count depends on bandwidth,
round-trip count on latency, and chain depth on discovery order.
- Because the congestion window grows with rounds, the first bytes are cheap; taking a
resource out of the critical path can give a much larger gain than shrinking it.
- `defer`, `async`, and `media` declarations remove blocking; inlining critical style
erases the external request entirely but gives up cacheability.
- The preload scanner sees only resources written in the document; flattening the chain
is often more effective than reducing bytes.
#### Next Step
When the critical path shortens, first paint moves earlier, but on most pages largest
contentful paint is not a block of text — it is an image. The card images on the station
list and the station photo on the measurement detail page carry far more bytes than the
document itself; font files, in turn, determine when the text becomes readable. Both have
their own decisions about size, format, and loading. The next lesson takes up these
decisions and computes which candidate file downloads under which condition.
### Image and Font Optimization
Source: https://academia.sh/en/courses/frontend-quality/image-and-font-optimization
Separating an image's transfer, decode, and paint costs; computing the correct file selection from a candidate set, deciding by format class, and the timeline of a font-loading strategy.
When the critical path shortens, first paint moves earlier. Largest contentful paint, on
most pages, is not a block of text — it is an image: the card images on the station list
and the station photo on the measurement detail page carry far more bytes than the
document itself. Font files, in turn, determine when the text becomes readable.
This lesson takes up the size, format, and loading decisions for both asset types.
#### An Image's Three Separate Costs
Image optimization usually gets reduced to a single number: file size. Yet the same
image produces cost in three separate places, and they are independent of each other.
**Transfer cost** is the number of bytes downloaded. Compression lowers this.
**Decode cost** is turning the compressed bytes into pixels. It spends processor time,
and the result occupies memory independent of compression: four bytes per pixel. This is
the image counterpart of the transferred-size–resource-size distinction from the Network
Panel Diagnostics lesson, and here the gap is far larger. A photo that compresses well
does not tax the network — it taxes memory.
**Paint cost** is scaling the decoded pixels to the box on screen. If the source pixel
count exceeds the target box, the surplus gets rescaled on every frame.
The second and third costs depend on the selected file's **pixel dimensions**, not its
file size. The following computation puts this distinction into numbers.
```js
// candidates.mjs — which file gets selected from a candidate set, and the decoded pixel cost
// station card image: aspect ratio 3:2
const candidates = [400, 800, 1200, 1600, 2400]; // width descriptors (w)
const ASPECT_RATIO = 2 / 3;
// sizes declaration: full width under a 720px viewport, 360px above it
const layoutWidth = (viewportWidth) =>
viewportWidth <= 720 ? viewportWidth - 32 : 360;
function selectedCandidate(viewportWidth, pixelRatio) {
const needed = layoutWidth(viewportWidth) * pixelRatio;
return candidates.find((a) => a >= needed) ?? candidates[candidates.length - 1];
}
const decodedBytes = (width) => Math.round(width * width * ASPECT_RATIO * 4);
console.log("viewport".padStart(9) + "ratio".padStart(7) + "layout".padStart(9) +
"needed".padStart(9) + "selected".padStart(10) + "decoded".padStart(10) +
"largest candidate".padStart(20) + "multiple".padStart(10));
for (const [viewport, ratio] of [[390, 2], [390, 3], [768, 1], [768, 2], [1280, 2]]) {
const selected = selectedCandidate(viewport, ratio);
const needed = layoutWidth(viewport) * ratio;
const selectedBytes = decodedBytes(selected);
const largestBytes = decodedBytes(candidates[candidates.length - 1]);
console.log(
`${viewport}px`.padStart(9) + `${ratio}x`.padStart(7) +
`${layoutWidth(viewport)}px`.padStart(9) + `${needed}px`.padStart(9) +
`${selected}w`.padStart(10) +
`${(selectedBytes / 1024 / 1024).toFixed(2)} MB`.padStart(10) +
`${(largestBytes / 1024 / 1024).toFixed(2)} MB`.padStart(20) +
`${(largestBytes / selectedBytes).toFixed(1)}x`.padStart(10));
}
console.log("decoded = width x height x 4 bytes (1 byte per channel, RGBA)");
console.log("multiple = how many times larger decoded memory would be if the largest candidate got selected");
```
```
viewport ratio layout needed selected decoded largest candidate multiple
390px 2x 358px 716px 800w 1.63 MB 14.65 MB 9.0x
390px 3x 358px 1074px 1200w 3.66 MB 14.65 MB 4.0x
768px 1x 360px 360px 400w 0.41 MB 14.65 MB 36.0x
768px 2x 360px 720px 800w 1.63 MB 14.65 MB 9.0x
1280px 2x 360px 720px 800w 1.63 MB 14.65 MB 9.0x
decoded = width x height x 4 bytes (1 byte per channel, RGBA)
multiple = how many times larger decoded memory would be if the largest candidate got selected
```
Selection happens in two steps. First, the element's **layout width** gets resolved from
the `sizes` declaration; this is a rule set written with media queries, and the browser
produces a single CSS pixel value by looking at the viewport. Then this value gets
multiplied by the pixel ratio, and the smallest file in the candidate set that meets that
number gets selected.
What the table really shows is the last column. The same image's largest candidate
produces fourteen and a half megabytes of pixel data whenever it gets decoded, no matter
the condition; on a narrow screen, though, a four-hundred-pixel file is enough and spends
thirty-six times less memory. This gap does not show up in file sizes — the ratio between
the two files' compressed sizes is far smaller.
The same table holds a second observation: the card is smaller on a wide screen. In a
responsive layout, a single card's width drops as the column count rises, so the
assumption that desktop always wants a larger image is wrong. The `sizes` declaration
must get derived from the layout, not from a guess.
#### Format Selection
The format decision gets made by content class, not by product names.
**Vector or raster?** Icons, charts, logos, and line graphics get defined by geometry;
stored in vector format, they stay sharp at every scale, and their decoded memory depends
on geometric complexity, not pixel count. A photograph is raster; it cannot get converted
to vector.
**Lossy or lossless?** A lossy encoder compresses by discarding information the eye does
not distinguish, and it is the right choice for a photograph. A lossless encoder
preserves every pixel; in content with sharp edges — a screenshot, an image containing
text, flat color regions — the blur lossy compression leaves behind becomes visible.
**Is transparency needed?** A format that supports an alpha channel should get chosen if
it is; it should not if it is not, because a fourth channel adds data.
**Does it offer progressive rendering?** Some formats let a low-resolution version get
produced from the file's first bytes. On a large image, this separates the time between
the user seeing something and seeing everything.
Different formats being supported by different clients gets solved with the `picture`
element: each option in the source list declares its own content type, the client skips
a type it does not recognize, and it eventually falls back to the `img` element. This is
the markup-level counterpart of feature detection; it requires no assumption about which
format will be supported.
#### When It Gets Requested
Once the correct file is selected, two decisions remain: when to request it, and whether
to reserve its space up front.
**Lazy loading** defers requesting images outside the viewport. The rule's one exception
matters: the image that is a candidate for largest contentful paint must not be
lazy-loaded. A deferred request delays the metric itself.
**Fetch priority** is the other end of the same problem. Every image in the document
gets requested at low priority by default; writing `fetchpriority="high"` on the hero
image in the first screen moves its request ahead of the others.
**Space reservation** is a stability decision, not a performance one, but it gets given
on the same element. When `width` and `height` attributes are written on an image, the
browser knows the aspect ratio before the file downloads and reserves the box up front.
Left unwritten, everything beneath the image shifts the moment it arrives — this is the
most common source of the score computed in the first lesson.
#### The Font's Timeline
The Font Loading lesson in the Visual Presentation with CSS course separated
`font-display` values by two periods: during the block period no text gets painted,
during the swap period text gets painted with a fallback font. The question asked here is
different: what does the user see if the file arrives at a given moment?
```js
// font-timeline.mjs — the state of the text depending on the file's arrival time
// The three periods defined in the specification: block, swap, fallback retreat.
const PERIODS = {
block: { blockDuration: 3000, swapDuration: Infinity },
swap: { blockDuration: 100, swapDuration: Infinity },
fallback: { blockDuration: 100, swapDuration: 3000 },
optional: { blockDuration: 100, swapDuration: 0 },
};
function timeline(value, arrival) {
const { blockDuration, swapDuration } = PERIODS[value];
const invisibleDuration = Math.min(arrival, blockDuration);
if (arrival <= blockDuration) {
return { invisibleDuration, fallbackDuration: 0, result: "requested font" };
}
const swapEnd = blockDuration + swapDuration;
if (arrival <= swapEnd) {
return { invisibleDuration, fallbackDuration: arrival - blockDuration, result: "requested font" };
}
return { invisibleDuration, fallbackDuration: Infinity, result: "fallback font stays" };
}
const duration = (ms) => (ms === Infinity ? "for the page's lifetime" : `${ms} ms`);
console.log("--- state of the text by file arrival time ---");
console.log("value".padEnd(10) + "arrival".padStart(9) + "invisible".padStart(11) +
"fallback".padStart(24) + " final state");
for (const value of Object.keys(PERIODS)) {
for (const arrival of [80, 900, 4200]) {
const c = timeline(value, arrival);
console.log(
value.padEnd(10) + `${arrival} ms`.padStart(9) +
`${c.invisibleDuration} ms`.padStart(11) + duration(c.fallbackDuration).padStart(24) +
" " + c.result);
}
}
```
```
--- state of the text by file arrival time ---
value arrival invisible fallback final state
block 80 ms 80 ms 0 ms requested font
block 900 ms 900 ms 0 ms requested font
block 4200 ms 3000 ms 1200 ms requested font
swap 80 ms 80 ms 0 ms requested font
swap 900 ms 100 ms 800 ms requested font
swap 4200 ms 100 ms 4100 ms requested font
fallback 80 ms 80 ms 0 ms requested font
fallback 900 ms 100 ms 800 ms requested font
fallback 4200 ms 100 ms for the page's lifetime fallback font stays
optional 80 ms 80 ms 0 ms requested font
optional 900 ms 100 ms for the page's lifetime fallback font stays
optional 4200 ms 100 ms for the page's lifetime fallback font stays
```
When the file arrives quickly, all five values give the same result; the distinction
appears in the slow condition. For a file arriving at nine hundred milliseconds, `block`
leaves the text invisible for nine hundred milliseconds, `swap` and `fallback` paint it
with a fallback font after a hundred milliseconds, and `optional` never uses the file on
that page at all.
The decision gets made by which metric gets protected. `swap` protects first contentful
paint and accepts the layout shift: text painted with the fallback font changes measure
when the real font arrives. `optional` protects layout stability and gives up the
designed font. `block` breaks both and is only defensible where a fallback would be
meaningless — icon fonts, for instance.
The duration values get given in the specification as recommendations and vary by
implementation; the numbers in the model are taken from these recommendations. A changed
number does not change the values' ordering relative to each other.
There are three ways to reduce font cost, and all three improve this table: subsetting
the file to its own text reduces the bytes to download, requesting the file early with
`preload` moves the arrival time earlier, and bringing the fallback font's metrics closer
to the real font with `size-adjust` and similar descriptors brings the shift at swap time
closer to zero.
#### The Station Card's Markup
```html
North Slope 1
```
The file extension in the example is a placeholder; it gets written according to the
selected format. The rule lies in the structure, not the extension: the candidate set
gets declared with real pixel widths, the `sizes` declaration gets derived from the
layout, `width` and `height` give the aspect ratio up front, and the priority declaration
gets written only on the first-screen card. If more than one format will be offered, the
same `img` element gets wrapped in a `picture`, and each `source` declares its own
content type; `img` remains as the last resort.
Cards in the list that fall outside the viewport carry no priority declaration;
`loading="lazy"` gets written on them instead. Two different instances of the same
component receive different declarations, and this distinction gets exposed as an option
in the component's interface.
#### Summary
- An image's transfer, decode, and paint costs are separate; decoded memory depends on
pixel count, not file size, and the gap between them can span multiples.
- Candidate selection is two steps: the layout width gets resolved from the `sizes`
declaration, gets multiplied by the pixel ratio, and the smallest candidate that meets
it gets selected; the declaration must get derived from the layout.
- The format decision gets made by content class, not product name: vector or raster,
lossy or lossless, whether transparency is needed, whether it offers progressive
rendering.
- The image that is a candidate for largest contentful paint does not get lazy-loaded;
the priority declaration gets written only on the first-screen image, and space
reservation gets done on every image.
- Font display behavior is a metric preference: `swap` protects first contentful paint,
`optional` protects layout stability.
#### Next Step
Every decision up to this point concerned the document and the assets themselves: which
file, how big, when it gets requested. One more layer exists, and there a gain can get
achieved without reducing a single byte. Does the same user opening the station list a
second time have to redownload the same files? Does connection setup happen from scratch
every time? The answer to these questions lies not in the request but in the headers the
response carries and the connection hints written into the document. The next lesson
takes up these headers by measuring them on a local server.
### Network Performance
Source: https://academia.sh/en/courses/frontend-quality/network-performance
Separating freshness from validation, measuring cache headers on a local server, the immutability promise of content-hashed names, and what connection hints actually earn.
The previous three lessons dealt with the document and the assets themselves: which
file, how big, when it gets requested. One more layer exists, and there a gain can get
achieved without reducing a single byte. Does the same user opening the station list a
second time have to redownload the same files?
The answer to this question lies not in the request but in the headers the response
carries. The Caching Strategies lesson in the Browser and the Web Platform course took up
program-controlled caching; the subject here is what the server determines with headers
alone, without a program getting written.
#### Freshness and Validation Are Two Separate Decisions
The HTTP cache answers two separate questions, and confusing them is the most common
cause of misconfiguration.
**Freshness lifetime** answers this question: how long can this response be used
without a query? The `max-age` directive in the `Cache-Control` header gives a duration;
until the duration expires, the browser **makes no request at all**. The cheapest request
is the one never made.
The **validator** answers this question: is the copy I have still valid? The `ETag`
header carries a signature tied to the content. Once the freshness lifetime expires, the
browser sends this signature back in an `If-None-Match` header; if the content has not
changed, the server returns a response with no body.
The two decisions complement each other. Freshness prevents the request entirely;
validation makes the request cheap. The `no-cache` directive leads to a
misunderstanding: it does not forbid storage, it only requires validation before every
use. The directive that forbids storage is `no-store`.
#### Measuring the Headers
The following server serves three resources under three separate policies and genuinely
handles the conditional request.
```js
// cache-server.mjs — shows freshness and validation headers on three separate resources
import { createServer } from "node:http";
import { createHash } from "node:crypto";
const bodies = {
"/assets/station.9f2c1a.css": {
type: "text/css",
content: ".station-list{display:grid;gap:12px}",
// Content-hashed name: if the address changes, the content has changed.
cache: "public, max-age=31536000, immutable",
},
"/api/stations": {
type: "application/json",
content: JSON.stringify({ stations: ["north-slope-1", "north-slope-2"] }),
// Gets validated on every use; the body only gets sent if it changed.
cache: "no-cache",
},
"/api/announcement": {
type: "application/json",
content: JSON.stringify({ announcement: "Maintenance window: 03:00-04:00" }),
// Fresh for one minute; stale served and revalidated in the background for the next five.
cache: "public, max-age=60, stale-while-revalidate=300",
},
};
const tag = (content) =>
`"${createHash("sha256").update(content).digest("hex").slice(0, 16)}"`;
createServer((req, res) => {
res.sendDate = false;
const resource = bodies[req.url];
if (!resource) {
res.writeHead(404, { "Content-Type": "text/plain" });
return res.end("not found\n");
}
const validator = tag(resource.content);
const headers = {
"Cache-Control": resource.cache,
ETag: validator,
Vary: "Accept-Encoding",
};
// Conditional request: the body does not get sent if the client's validator is still valid.
if (req.headers["if-none-match"] === validator) {
res.writeHead(304, headers);
return res.end();
}
res.writeHead(200, {
...headers,
"Content-Type": resource.type,
"Content-Length": Buffer.byteLength(resource.content),
});
res.end(resource.content);
}).listen(8241, "127.0.0.1", () => console.log("listening: 127.0.0.1:8241"));
```
```bash
#!/usr/bin/env bash
# Starts cache-server.mjs, measures freshness and validation behavior, stops it.
node cache-server.mjs > /dev/null &
server=$!
sleep 1
base=http://127.0.0.1:8241
for path in /assets/station.9f2c1a.css /api/stations /api/announcement; do
printf '%s\n' "$path"
curl -sS -o /dev/null -D - "$base$path" \
| grep -iE '^(HTTP/|cache-control|etag|content-length)' \
| tr -d '\r' | sed 's/^/ /'
done
printf '\n--- conditional request ---\n'
tag=$(curl -sS -o /dev/null -D - "$base/api/stations" \
| awk 'tolower($1) == "etag:" { print $2 }' | tr -d '\r')
printf 'validator held by the client: %s\n' "$tag"
curl -sS -o /dev/null -H "If-None-Match: $tag" "$base/api/stations" \
-w 'conditional request -> status %{http_code}, downloaded body %{size_download} bytes\n'
curl -sS -o /dev/null "$base/api/stations" \
-w 'unconditional request -> status %{http_code}, downloaded body %{size_download} bytes\n'
kill "$server"
```
```
/assets/station.9f2c1a.css
HTTP/1.1 200 OK
Cache-Control: public, max-age=31536000, immutable
ETag: "f4c1b262ab403423"
Content-Length: 36
/api/stations
HTTP/1.1 200 OK
Cache-Control: no-cache
ETag: "be211c47597a1001"
Content-Length: 46
/api/announcement
HTTP/1.1 200 OK
Cache-Control: public, max-age=60, stale-while-revalidate=300
ETag: "510bd98694f649be"
Content-Length: 50
--- conditional request ---
validator held by the client: "be211c47597a1001"
conditional request -> status 304, downloaded body 0 bytes
unconditional request -> status 200, downloaded body 46 bytes
```
The validator values are stable in this output because they get produced from a digest
of the content; they change when the content changes. Port 8241 is an arbitrary choice
and must be free.
The measured difference is clear: the conditional request returns with no body. The
round trip still happened — a conditional request does not eliminate latency, only
transfer. Freshness lifetime eliminates the round trip too. This difference between the
two determines which policy gets written on which resource.
#### The Immutable Asset, the Changing Document
The `immutable` directive makes a promise: the content at this address will never
change. The promise can only be kept if the address gets derived from the content. The
cache-busting approach in the Rendering Strategies and Infrastructure course provides
exactly that: when a content hash gets written into the file name, the address changes
whenever the content changes, and the old address staying fresh forever creates no
problem.
The document cannot make this promise, because its address is fixed and its content
changes with every release. The correct policy for a document is validation, not a long
freshness period.
For the case in between, there is the `stale-while-revalidate` directive: after the
freshness period expires, the old copy gets served immediately for a specified duration
while the refresh happens in the background. The user does not wait; the data refreshes
with one round trip's delay. It suits content that tolerates delay, like an announcement
banner; it does not suit content like an account balance.
How many bytes each of these three policies transfers on a repeat visit can be computed.
```js
// repeat-visit.mjs — how header policy affects bytes transferred on a repeat visit
const HEADER_OVERHEAD = 320; // bytes: the approximate share of request + response headers
// The station list page's resources and their selected policy.
const resources = [
{ name: "document", bytes: 18_400, policy: "no-cache" },
{ name: "style", bytes: 62_000, policy: "immutable" },
{ name: "entry script", bytes: 148_112, policy: "immutable" },
{ name: "shared script", bytes: 101_760, policy: "immutable" },
{ name: "font", bytes: 41_600, policy: "immutable" },
{ name: "card image", bytes: 86_400, policy: "immutable" },
{ name: "station data", bytes: 9_240, policy: "max-age=60" },
];
const fullSize = (k) => HEADER_OVERHEAD + k.bytes;
const firstVisit = resources.reduce((t, k) => t + fullSize(k), 0);
// Bytes transferred for one resource on a repeat visit.
function repeatBytes(resource, elapsedSeconds, changed) {
const hasChanged = changed.has(resource.name);
switch (resource.policy) {
case "immutable":
// Content-hashed name: if it changed, the address has changed, and the new resource downloads from scratch.
return hasChanged ? fullSize(resource) : 0;
case "no-cache":
// Gets validated on every use: if unchanged, only the headers arrive.
return hasChanged ? fullSize(resource) : HEADER_OVERHEAD;
case "max-age=60":
if (elapsedSeconds <= 60) return 0; // still fresh: no request
return hasChanged ? fullSize(resource) : HEADER_OVERHEAD;
default:
return fullSize(resource);
}
}
const scenarios = [
{ name: "after 30 seconds, same version", elapsed: 30, changed: new Set() },
{ name: "after 300 seconds, same version", elapsed: 300, changed: new Set() },
{
name: "new version published",
elapsed: 300,
changed: new Set(["document", "style", "entry script"]),
},
];
console.log(`first visit: ${(firstVisit / 1024).toFixed(1)} KB`);
for (const s of scenarios) {
console.log(`\n--- ${s.name} ---`);
console.log("resource".padEnd(14) + "repeat".padStart(10) + " policy");
let total = 0;
for (const k of resources) {
const b = repeatBytes(k, s.elapsed, s.changed);
total += b;
console.log(k.name.padEnd(14) + `${(b / 1024).toFixed(2)} KB`.padStart(10) + " " + k.policy);
}
console.log("-".repeat(36));
console.log("TOTAL".padEnd(14) + `${(total / 1024).toFixed(2)} KB`.padStart(10));
console.log(`ratio to first visit: ${(total / firstVisit).toFixed(4)}`);
}
console.log("\nif no freshness header had been written, every repeat visit ratio would be 1.0000.");
```
```
first visit: 458.7 KB
--- after 30 seconds, same version ---
resource repeat policy
document 0.31 KB no-cache
style 0.00 KB immutable
entry script 0.00 KB immutable
shared script 0.00 KB immutable
font 0.00 KB immutable
card image 0.00 KB immutable
station data 0.00 KB max-age=60
------------------------------------
TOTAL 0.31 KB
ratio to first visit: 0.0007
--- after 300 seconds, same version ---
resource repeat policy
document 0.31 KB no-cache
style 0.00 KB immutable
entry script 0.00 KB immutable
shared script 0.00 KB immutable
font 0.00 KB immutable
card image 0.00 KB immutable
station data 0.31 KB max-age=60
------------------------------------
TOTAL 0.63 KB
ratio to first visit: 0.0014
--- new version published ---
resource repeat policy
document 18.28 KB no-cache
style 60.86 KB immutable
entry script 144.95 KB immutable
shared script 0.00 KB immutable
font 0.00 KB immutable
card image 0.00 KB immutable
station data 0.31 KB max-age=60
------------------------------------
TOTAL 224.41 KB
ratio to first visit: 0.4892
if no freshness header had been written, every repeat visit ratio would be 1.0000.
```
The resource sizes are the computation's input, not the output of a measured
application; the header share is also an assumption. What gets computed is the policy's
consequence.
In the first two scenarios, the repeat visit is nearly free. The third scenario teaches
the real lesson: when a new version gets published, only the parts that **changed**
download again. Because the shared script did not change, its address did not change
either, and it never gets requested. This is where bundling decisions have a performance
consequence — if frequently changing code and rarely changing code get grouped into the
same chunk, every release redownloads both.
#### Vary and the Cache Key
If a response varies according to request headers, this must get declared with the
`Vary` header. Left undeclared, intermediate caches serve a single copy to everyone: a
compressed response can go to a client that does not support compression, or a page
produced for one language can go to a user in another.
The rule is a correctness rule, and it affects performance too: adding an unnecessary
header to the `Vary` list splits the cache key more than it needs to be and lowers the
hit rate. If a user-specific header enters the list, the cache is effectively disabled.
#### Connection Hints
Connection hints written into the document tell the browser to do a job early. Each one
moves a different stage earlier.
`dns-prefetch` performs only name resolution. It is the cheapest hint and earns the
least.
`preconnect` performs name resolution, the transport connection, and the secure
handshake ahead of time. It spends the rounds counted as "connection setup" in the
critical-path model before the resource even gets requested. It has a cost: a connection
that gets established and goes unused holds resources on both the client and the server,
so it should get written only for origins that will definitely be used.
`preload` requests a specific resource early. As described in the Critical Rendering
Path lesson, this is a correction: it moves a late-discovered critical resource earlier.
The `as` attribute is required; written incorrectly, the resource downloads twice.
`prefetch` downloads, at idle priority, a resource that will be needed on the **next**
navigation. Its priority is the lowest, and it is wasted bandwidth if the user never goes
to that page.
The order is a priority order: flatten the chain first, then `preconnect`, and `preload`
last. A hint written without measurement often does harm by taking bandwidth away from
the critical resource.
#### Summary
- Freshness lifetime prevents the request entirely, the validator makes the request
bodiless; the two solve separate problems, and `no-cache` forbids not storage but
unvalidated use.
- A content-hashed address is the condition for the `immutable` promise to be kept; a
document with a fixed address cannot make this promise and gets managed through
validation.
- In a new release, only the parts whose address changed download again; a bundling
decision is therefore a caching decision.
- The `Vary` header is a correctness matter before it is a performance matter: its
absence serves the wrong response, its excess splits the cache.
- Connection hints move different stages earlier and each one has a cost; a hint written
without measurement cuts off the critical resource.
#### Next Step
Once the network side is arranged, bytes arrive on time and a repeat visit makes almost
no request. The application can still feel heavy, though: the list stutters while
scrolling, a letter typed into the filter box appears on screen late, the page may freeze
for a moment when the date range changes. None of these problems are in the network; all
of them come from downloaded code running in a single queue. The next lesson takes up
this queue: it computes how long tasks get measured, what chunking earns, and how layout
thrashing scales with row count.
### Runtime Performance
Source: https://academia.sh/en/courses/frontend-quality/runtime-performance
Measuring long tasks on the main thread with total blocking time, the measured effect of chunking work, layout thrashing scaling with row count, and ways to avoid painting what is not visible.
Once the network side is arranged, bytes arrive on time and a repeat visit makes almost
no request. The application can still feel heavy: the station list stutters while
scrolling, a letter typed into the filter box appears on screen late, the page may freeze
for a moment when the date range changes.
None of these problems are in the network. All of them come from downloaded code
running in a single queue. The Performance Recording lesson in the Browser and the Web
Platform course took up the tool that makes this queue visible; this lesson takes up how
to drain it.
#### Long Tasks and Total Blocking Time
The main thread is a queue of tasks. Once a task starts, it cannot get split: for as
long as it runs, user input cannot get processed and no frame can get produced. A task
exceeding fifty milliseconds counts as a **long task**, and the threshold's
justification is input response.
The metric is not the count of long tasks but the sum of the portions that exceed the
threshold.
```js
// blocking.mjs — total blocking time and the same work chunked into pieces
const LONG_TASK = 50; // ms
const tasks = [
{ name: "document parsing", duration: 42 },
{ name: "bundle evaluation", duration: 186 },
{ name: "station list construction", duration: 128 },
{ name: "measurement formatting", duration: 61 },
{ name: "input handler", duration: 18 },
{ name: "scroll handler", duration: 33 },
];
console.log("task".padEnd(28) + "duration".padStart(10) + "blocking".padStart(12));
let totalBlocking = 0;
for (const t of tasks) {
const blocking = Math.max(0, t.duration - LONG_TASK);
totalBlocking += blocking;
console.log(t.name.padEnd(28) + `${t.duration} ms`.padStart(10) + `${blocking} ms`.padStart(12));
}
console.log("-".repeat(50));
console.log("total blocking time".padEnd(28) + `${totalBlocking} ms`.padStart(22));
// If the same work gets split into pieces not exceeding 50 ms, blocking drops to zero.
const chunked = tasks.flatMap((t) => {
const pieces = Math.ceil(t.duration / LONG_TASK);
return Array.from({ length: pieces }, () => t.duration / pieces);
});
const chunkedBlocking = chunked.reduce((t, s) => t + Math.max(0, s - LONG_TASK), 0);
console.log(`if the same work gets split into ${chunked.length} pieces: ${chunkedBlocking} ms of blocking`);
console.log(`total work duration unchanged: ${tasks.reduce((t, g) => t + g.duration, 0)} ms`);
```
```
task duration blocking
document parsing 42 ms 0 ms
bundle evaluation 186 ms 136 ms
station list construction 128 ms 78 ms
measurement formatting 61 ms 11 ms
input handler 18 ms 0 ms
scroll handler 33 ms 0 ms
--------------------------------------------------
total blocking time 225 ms
if the same work gets split into 12 pieces: 0 ms of blocking
total work duration unchanged: 468 ms
```
The task durations are the computation's input; what gets computed is the metric
itself. Of the 468 milliseconds of work, 225 milliseconds is blocking. The
42-millisecond parsing task does not count at all, because it sits under the threshold —
the metric measures not the entirety of the work but the excess the user would wait
through.
The last two lines say what matters: when the same work gets split into pieces not
exceeding fifty milliseconds, blocking drops to zero and the total work duration does
not change at all. What gets done is not reducing the work — it is **inserting exit
points in between.**
#### Measuring Chunking
What the model claims can be measured. The following program does the same work three
different ways and, for each, records how long the event loop stays blocked using a
responsiveness probe.
```js
// chunking.mjs — measuring the same work done in one chunk versus chunked
// Responsiveness probe: reschedules itself every turn and records its delay.
function startProbe(log) {
let running = true;
let previous = performance.now();
const turn = () => {
if (!running) return;
const now = performance.now();
log.push(now - previous);
previous = now;
setTimeout(turn, 0);
};
setTimeout(turn, 0);
return () => { running = false; };
}
const ROWS = 300_000;
function rowText(i) {
// Some work per row: producing a formatted measurement line.
const temperature = -12 + ((i * 37) % 240) / 10;
const timestamp = new Date(Date.UTC(2026, 0, 1, 0, 0, i % 60)).toISOString();
return `north-slope-${String(i).padStart(5, "0")} ${timestamp} ${temperature.toFixed(1)} C`.length;
}
async function inOneChunk() {
let total = 0;
for (let i = 0; i < ROWS; i++) total += rowText(i);
return total;
}
async function chunked(chunkSize) {
let total = 0;
for (let i = 0; i < ROWS; i++) {
total += rowText(i);
if ((i + 1) % chunkSize === 0) await new Promise((resolve) => setImmediate(resolve));
}
return total;
}
async function measure(name, work) {
const delays = [];
const stop = startProbe(delays);
await new Promise((resolve) => setTimeout(resolve, 20)); // let the probe warm up
delays.length = 0;
const start = performance.now();
const result = await work();
const elapsed = performance.now() - start;
await new Promise((resolve) => setTimeout(resolve, 20)); // let the final poll get recorded
stop();
const longest = Math.max(...delays);
return { name, elapsed, longest, result, turns: delays.length };
}
const measurements = [
await measure("in one chunk", inOneChunk),
await measure("2000-row chunks", () => chunked(2000)),
await measure("500-row chunks", () => chunked(500)),
];
console.log("--- same work, different chunking (durations depend on the machine) ---");
console.log("approach".padEnd(24) + "total".padStart(10) + "longest block".padStart(19) +
"polls".padStart(9));
for (const m of measurements) {
console.log(m.name.padEnd(24) + `${m.elapsed.toFixed(1)} ms`.padStart(10) +
`${m.longest.toFixed(1)} ms`.padStart(19) + String(m.turns).padStart(9));
}
const baseline = measurements[0];
console.log("\nratio of longest block to the single chunk:");
for (const m of measurements) {
console.log(` ${m.name.padEnd(24)} ${(m.longest / baseline.longest).toFixed(3)}`);
}
console.log(`all approaches produced the same result: ${new Set(measurements.map((m) => m.result)).size === 1}`);
```
```
--- same work, different chunking (durations depend on the machine) ---
approach total longest block polls
in one chunk 123.6 ms 124.9 ms 16
2000-row chunks 126.6 ms 2.1 ms 141
500-row chunks 130.7 ms 1.7 ms 146
ratio of longest block to the single chunk:
in one chunk 1.000
2000-row chunks 0.017
500-row chunks 0.014
all approaches produced the same result: true
```
The durations depend on the machine and its load; they vary on every run. What does not
change are the ratios. The total duration stays close across the three approaches —
chunking does not reduce the work, and it even adds a small per-turn overhead. The
longest block, though, drops by roughly two orders of magnitude: the single block,
measured here at about a hundred and twenty-five milliseconds, spreads into blocks of
only a couple of milliseconds.
The poll count shows why. In the single-chunk approach, control never returns to the
queue while the work runs; in the chunked approach, control returns after every chunk,
and waiting input can get processed.
This measurement was taken not in a browser but in a single-threaded runtime; it
correctly models the main thread's behavior, but the exit point in a browser is not
`setImmediate`. Its browser counterpart is a wait or an idle-callback that hands control
back to the event loop.
Chunking also has a limit: the smaller the chunk, the larger the per-turn overhead
grows. In this measurement, the 500-row chunks take a longer total than the 2000-row
chunks. The right chunk size is not "as small as possible" — it is the largest chunk
that fits inside the frame budget.
#### Taking Work Out of the Queue Entirely
Chunking keeps the work in the main queue and allows interruption. A second approach is
to take the work out of the queue entirely.
Workers, introduced in the Browser and the Web Platform course, run on a separate thread
and never occupy the main queue. The work they suit is clear: pure computation, parsing,
compression, filtering and sorting a large dataset. The work they do not suit is equally
clear — access to the document tree. Summarizing tens of thousands of measurements on
the measurement detail page can move to a worker; the result returns to the main queue
only as the rows to paint.
The cost is data transfer. Message passing requires copying, and on large arrays this
copying can eat the gain; transferable objects exist for this reason.
#### Layout Thrashing Scales with Row Count
The Animation Performance lesson in the Layout Systems and Responsive Design course
defined forced synchronous layout: a write invalidates layout, and a subsequent
measurement read forces the computation immediately. Ordering reads and writes this way
repeats the computation on every turn, and this gets called **layout thrashing**.
What got counted there was the number of computations. The question here is what that
number does as the list grows.
```js
// thrashing.mjs — how layout thrashing scales with row count
const FRAME_BUDGET = 1000 / 60; // ms, assuming 60 frames per second
const COMPUTE_COST = 0.05; // ms: the assumed cost of a single layout computation
const VISIBLE_ROWS = 20; // rows that fit in the viewport
// Three approaches: how many layout computations does each force for N rows?
const approaches = {
"read-write inside the loop": (n) => Math.max(0, n - 1),
"reads then writes": () => 0,
"only visible rows": (n) => Math.max(0, Math.min(n, VISIBLE_ROWS) - 1),
};
console.log("rows".padStart(7) +
Object.keys(approaches).map((a) => a.padStart(30)).join(""));
for (const n of [10, 50, 200, 1000, 5000]) {
const cells = Object.values(approaches).map((f) => {
const computations = f(n);
const duration = computations * COMPUTE_COST;
return `${computations} computations / ${duration.toFixed(1)} ms`.padStart(30);
});
console.log(String(n).padStart(7) + cells.join(""));
}
console.log(`\nframe budget: ${FRAME_BUDGET.toFixed(2)} ms`);
console.log("how many frame budgets get consumed:");
console.log("rows".padStart(7) +
Object.keys(approaches).map((a) => a.padStart(30)).join(""));
for (const n of [10, 50, 200, 1000, 5000]) {
const cells = Object.values(approaches).map((f) =>
(f(n) * COMPUTE_COST / FRAME_BUDGET).toFixed(1).padStart(30));
console.log(String(n).padStart(7) + cells.join(""));
}
console.log("\nthe compute cost is an assumption; when it changes, the columns' ratios do not.");
```
```
rows read-write inside the loop reads then writes only visible rows
10 9 computations / 0.5 ms 0 computations / 0.0 ms 9 computations / 0.5 ms
50 49 computations / 2.5 ms 0 computations / 0.0 ms 19 computations / 1.0 ms
200 199 computations / 10.0 ms 0 computations / 0.0 ms 19 computations / 1.0 ms
1000 999 computations / 50.0 ms 0 computations / 0.0 ms 19 computations / 1.0 ms
5000 4999 computations / 250.0 ms 0 computations / 0.0 ms 19 computations / 1.0 ms
frame budget: 16.67 ms
how many frame budgets get consumed:
rows read-write inside the loop reads then writes only visible rows
10 0.0 0.0 0.0
50 0.1 0.0 0.1
200 0.6 0.0 0.1
1000 3.0 0.0 0.1
5000 15.0 0.0 0.1
the compute cost is an assumption; when it changes, the columns' ratios do not.
```
On a ten-row list there is no difference between the three approaches; this is why the
problem stays invisible during development. At five thousand rows, the first approach
consumes fifteen frame budgets — meaning no frame gets produced for a quarter of a
second.
The two solutions differ in character. Batching reads and writes drops the cost to
**zero** and is independent of list size; processing only the visible rows **fixes** the
cost, and it does not change no matter how large the list grows. The second leaves the
thrashing itself in place but cuts off its scaling.
#### Not Painting What Is Not Visible
The idea of processing only what is visible is not limited to layout thrashing; it
applies to the browser's entire rendering pipeline.
**Virtualization** puts only the list's visible portion into the document tree. Nodes
get reused as the list scrolls. The cost is that content absent from the tree is also
absent from in-page search and from the accessibility tree.
**Content visibility** approaches the same goal without breaking the markup: the
`content-visibility` property lets paint and layout work get skipped while a box is
off-screen. The skipped box still has to occupy space; otherwise the scrollbar jumps as
content comes into view. This is why an estimated size gets given along with the
declaration.
**Containment**, in turn, keeps a box's effect confined to its own boundaries. The
`contain` declaration, introduced in the Animation Performance lesson, prevents a change
inside a card from spreading its layout computation across the entire page.
#### Interaction Delay's Three Components
Interaction to next paint is a single number, but it is the sum of three separate
delays, and their fixes differ.
**Input delay** is the time between the user interaction and the handler starting. Its
cause is another task running at that moment. Its fix is chunking or moving the work to
a worker; speeding up the handler does not touch this portion.
**Processing time** is the handler's own duration. Its fix is shrinking the handler and
deferring work that can be deferred: make the change the user sees immediately, leave
logging and analytics for later.
**Presentation delay** is the time between the handler finishing and the frame getting
produced. Its cause is the size of the layout and paint work the handler triggers. Its
fix is shrinking the area that gets updated.
A recording showing which component grew also tells you which fix not to try. An
optimization done without measurement often gets applied to the wrong component.
#### Summary
- Total blocking time is the sum of the portions of long tasks that exceed the
fifty-millisecond threshold; chunking the work can drop this metric to zero without
changing the total duration.
- Measurement confirms this: when the same work gets chunked, the longest block drops by
roughly two orders of magnitude while the total duration stays close; the smaller the
chunk, the larger the per-turn overhead grows.
- Workers take work out of the main queue entirely; their limits are not being able to
access the document tree and the cost of copying data.
- Layout thrashing's cost grows linearly with row count; batching drops the cost to
zero, working with only the visible rows fixes it.
- Interaction to next paint is the sum of input delay, processing time, and presentation
delay, and each component's fix is different.
#### Next Step
Five lessons defined the metrics, shortened the critical path, sized the assets, tuned
the network layer, and drained the runtime. All of this shares one gap: every
improvement was made once. When a new feature gets added, the bundle grows; when a new
image gets placed, the first screen's weight increases; when a library enters the shared
chunk, the repeat-visit gain erodes. This erosion needs to get noticed at the next
release, not months later through a complaint. The next lesson ties the metrics to a
written budget and builds a checker that compares two build outputs to catch
regressions.
### Performance Budget
Source: https://academia.sh/en/courses/frontend-quality/performance-budget
Tying performance decisions to a written limit; budget types, where the limit gets derived from, a program that checks build output against the budget, and catching regressions by comparing two builds.
The previous five lessons built a series of improvements: the metrics got defined, the
critical path got shortened, the assets got sized, the network layer got tuned, the
runtime got drained. All of them share the same gap — they were done once.
When a new feature gets added, the bundle grows; when a library enters the shared
chunk, the repeat-visit gain erodes. This erosion needs to get noticed at the next
release. This lesson builds that mechanism.
#### A Budget Is Not a Target
The two get confused, and when they do, a budget loses its function.
A **target** is a value someone wants to reach. It has direction and no enforcement;
nothing happens when it gets exceeded.
A **budget** is a limit that is not allowed to get exceeded. Something happens when it
does: the build counts as failed, the merge stops, the release does not ship. A number
with no enforcement is not a budget.
The practical consequence of this distinction is that a budget gets drawn where it is
reachable. A limit set far below the current value shows red from day one and quickly
starts getting ignored. The right approach is to set the limit slightly above today's
value and lower it over time.
#### Three Budget Types
Budgets get separated by what they measure, and all three are needed, because each one
catches what the other misses.
A **metric budget** sets a limit on user-centric metrics: largest contentful paint stays
under this value, cumulative layout shift does not exceed this score. Because it
directly measures the experience, it is the most meaningful budget; it is also the
noisiest, because it is sensitive to measurement conditions.
A **quantity budget** sets a limit on countable magnitudes: chunk sizes, request count,
image weight, font file count. It is deterministic — the same build always produces the
same number — and so it is the budget best suited to enforcement. Its link to the
experience is indirect: a small bundle does not always mean a fast page.
A **rule budget** contains not a number but a condition: no render-blocking external
stylesheet on the first screen, no synchronous script in the document, no lazy-loading of
the image that is a candidate for largest contentful paint. It protects decisions that
cannot get reduced to a number.
A solid setup combines all three: quantity and rule budgets get checked on every build,
the metric budget at regular intervals.
#### Where the Limit Comes From
For a number to be a budget, it needs a justification. There are three ways to justify
one.
**Deriving from a metric's standard threshold.** The classification limits noted in the
first lesson — 2.5 seconds for largest contentful paint, 0.1 for cumulative layout shift,
200 milliseconds for interaction to next paint — can get written directly as a metric
budget. The check applies to the 75th percentile.
**Working backward from a metric to a quantity.** A target metric value gets chosen, a
target network and device profile gets assumed, and the budget in between gets converted
to bytes. The round-trip model from the Critical Rendering Path lesson is the skeleton of
this computation: once how many rounds can get spent is decided, how many bytes can get
sent follows.
**Leaving headroom above today's value.** The most practical and least ambitious way. A
small margin gets added on top of the measured value, and the limit gets set there. This
budget delivers no improvement; it **stops things from getting worse.** For most teams,
this is the right starting point.
Whichever way gets chosen, the budget must be written down and live in the repository. A
limit no one can see is a limit that does not exist.
#### The Checker
The following program compares a build manifest against the budget, then compares two
builds and reports regressions.
```js
// budget.mjs — compares chunk sizes against a budget and finds regressions between two builds
const KB = 1024;
// Budget: the aggregation rule per group, the upper limit (bytes), and the growth tolerance (ratio).
// "sum" measures the whole group; "largest" measures the single heaviest piece in the group.
const BUDGET = {
entry: { aggregation: "sum", limit: 170 * KB, tolerance: 0.03 },
shared: { aggregation: "sum", limit: 120 * KB, tolerance: 0.03 },
route: { aggregation: "largest", limit: 45 * KB, tolerance: 0.05 },
style: { aggregation: "sum", limit: 40 * KB, tolerance: 0.05 },
};
const TOTAL_LIMIT = 360 * KB;
// Build manifest: each piece's name, group, and compressed size.
const previousBuild = [
{ name: "entry.4a1c.js", group: "entry", bytes: 148_112 },
{ name: "shared.9d02.js", group: "shared", bytes: 101_760 },
{ name: "route-stations.1f77.js", group: "route", bytes: 38_240 },
{ name: "route-measurements.55be.js", group: "route", bytes: 21_904 },
{ name: "station.6b3e.css", group: "style", bytes: 31_648 },
];
const newBuild = [
{ name: "entry.7e90.js", group: "entry", bytes: 151_296 },
{ name: "shared.c214.js", group: "shared", bytes: 124_368 },
{ name: "route-stations.02ab.js", group: "route", bytes: 39_120 },
{ name: "route-measurements.55be.js", group: "route", bytes: 21_904 },
{ name: "route-report.8c4d.js", group: "route", bytes: 17_856 },
{ name: "station.a9f1.css", group: "style", bytes: 32_960 },
];
const kb = (bytes) => `${(bytes / KB).toFixed(1)} KB`;
function sumByGroup(build) {
const measure = new Map();
for (const [group, { aggregation }] of Object.entries(BUDGET)) {
const pieces = build.filter((p) => p.group === group).map((p) => p.bytes);
measure.set(group, aggregation === "largest"
? Math.max(0, ...pieces)
: pieces.reduce((a, b) => a + b, 0));
}
return measure;
}
const grandTotal = (build) => build.reduce((t, p) => t + p.bytes, 0);
// --- 1. Budget check ---
function check(build, title) {
const totals = sumByGroup(build);
let passed = true;
console.log(`--- ${title} ---`);
console.log("group".padEnd(8) + "rule".padEnd(9) + "size".padStart(11) +
"limit".padStart(11) + "usage".padStart(10) + " result");
for (const [group, { limit, aggregation }] of Object.entries(BUDGET)) {
const size = totals.get(group);
const usage = size / limit;
const result = size <= limit ? "pass" : "FAIL";
if (size > limit) passed = false;
console.log(group.padEnd(8) + aggregation.padEnd(9) + kb(size).padStart(11) +
kb(limit).padStart(11) + `${(usage * 100).toFixed(1)}%`.padStart(10) + " " + result);
}
const overallTotal = grandTotal(build);
const totalResult = overallTotal <= TOTAL_LIMIT ? "pass" : "FAIL";
if (overallTotal > TOTAL_LIMIT) passed = false;
console.log("-".repeat(55));
console.log("TOTAL".padEnd(8) + "sum".padEnd(9) + kb(overallTotal).padStart(11) +
kb(TOTAL_LIMIT).padStart(11) +
`${((overallTotal / TOTAL_LIMIT) * 100).toFixed(1)}%`.padStart(10) + " " + totalResult);
console.log(`budget check: ${passed ? "pass" : "FAIL"}\n`);
return passed;
}
check(previousBuild, "previous build");
const newPassed = check(newBuild, "new build");
// --- 2. Regression detection: growth that stays under the limit also gets reported ---
console.log("--- comparing the two builds ---");
const previousTotals = sumByGroup(previousBuild);
const newTotals = sumByGroup(newBuild);
console.log("group".padEnd(8) + "previous".padStart(11) + "new".padStart(11) +
"diff".padStart(11) + "ratio".padStart(9) + " warning");
const warnings = [];
for (const [group, { tolerance }] of Object.entries(BUDGET)) {
const a = previousTotals.get(group);
const b = newTotals.get(group);
const ratio = (b - a) / a;
const exceeded = ratio > tolerance;
if (exceeded) warnings.push(`${group}: ${(ratio * 100).toFixed(1)}% growth (tolerance ${tolerance * 100}%)`);
console.log(group.padEnd(8) + kb(a).padStart(11) + kb(b).padStart(11) +
`${b - a >= 0 ? "+" : ""}${((b - a) / KB).toFixed(1)} KB`.padStart(11) +
`${ratio >= 0 ? "+" : ""}${(ratio * 100).toFixed(1)}%`.padStart(9) +
" " + (exceeded ? "TOLERANCE EXCEEDED" : "-"));
}
// New pieces get reported separately: because the address changes, the name comparison
// happens with the content hash stripped out.
const rootName = (name) => name.replace(/\.[0-9a-f]{4,}\./, ".");
const previousNames = new Set(previousBuild.map((p) => rootName(p.name)));
const newPieces = newBuild.filter((p) => !previousNames.has(rootName(p.name)));
console.log(`\nnew pieces: ${newPieces.map((p) => `${rootName(p.name)} (${kb(p.bytes)})`).join(", ") || "(none)"}`);
if (warnings.length === 0) console.log("regression warning: (none)");
else {
console.log("regression warning:");
for (const w of warnings) console.log(` ${w}`);
}
const exit = newPassed && warnings.length === 0 ? 0 : 1;
console.log(`\nexit code: ${exit}`);
process.exitCode = exit;
```
```
--- previous build ---
group rule size limit usage result
entry sum 144.6 KB 170.0 KB 85.1% pass
shared sum 99.4 KB 120.0 KB 82.8% pass
route largest 37.3 KB 45.0 KB 83.0% pass
style sum 30.9 KB 40.0 KB 77.3% pass
-------------------------------------------------------
TOTAL sum 333.7 KB 360.0 KB 92.7% pass
budget check: pass
--- new build ---
group rule size limit usage result
entry sum 147.8 KB 170.0 KB 86.9% pass
shared sum 121.5 KB 120.0 KB 101.2% FAIL
route largest 38.2 KB 45.0 KB 84.9% pass
style sum 32.2 KB 40.0 KB 80.5% pass
-------------------------------------------------------
TOTAL sum 378.4 KB 360.0 KB 105.1% FAIL
budget check: FAIL
--- comparing the two builds ---
group previous new diff ratio warning
entry 144.6 KB 147.8 KB +3.1 KB +2.1% -
shared 99.4 KB 121.5 KB +22.1 KB +22.2% TOLERANCE EXCEEDED
route 37.3 KB 38.2 KB +0.9 KB +2.3% -
style 30.9 KB 32.2 KB +1.3 KB +4.1% -
new pieces: route-report.js (17.4 KB)
regression warning:
shared: 22.2% growth (tolerance 3%)
exit code: 1
```
The build manifests are the program's input; they are not the output of a measured
project but two lists written to demonstrate the checker's behavior.
#### What the Output Says
The `aggregation` field in the budget definition carries an important distinction. For
the entry, shared, and style groups, the limit applies to the **sum**: all of these
pieces load on every page. For the route group, the limit applies to the **single
largest piece**, because the user loads only one route at a time. The wrong aggregation
rule breaks the budget unfairly when a new route gets added.
The new build fails in two places. The shared piece exceeds its own limit by one and a
bit percent; the total exceeds its limit by five percent. The real reason the total gets
exceeded is the shared piece's growth, but the newly added route piece also contributes
to the total. Reading the two lines together tells you whether the problem comes from a
single change or from accumulation.
The comparison table catches what the budget cannot. The entry piece grew by 2.1 percent
and is still well under the limit; it produces no warning. The shared piece grew by 22
percent, and because the tolerance is 3 percent, it produces a warning — this warning
would have fired even if the piece had stayed under the limit.
This is the distinction. **A budget protects an absolute limit; a tolerance protects the
rate of change.** If only the budget gets checked, a bundle growing 2 percent with every
release stays silent for months and then suddenly crosses the limit one day; by that day,
which change was responsible can no longer be found.
This is also why new pieces get reported separately. Because content-hashed names change
with every release, the comparison happens with the hash stripped out; otherwise every
piece would look new.
#### The Budget's Place in the Deployment Pipeline
The checker returning an exit code is part of the design: in a validation step that runs
after the build, a nonzero exit code stops the step. The convention established in the
Shell Programming course is what carries the enforcement here.
Two decisions are required. **Where does it run?** A check that runs on every change
finds the problem before it gets merged; a check that runs only on the main branch
requires searching for the responsible change once the problem is found.
**What does it do?** The choice between a budget overage stopping the build and merely
producing a warning determines how serious the budget is. A budget that does not stop
the build turns into a target. Even so, an escape hatch is required: the limit must be
raisable deliberately, and raising it must leave a record. When the change made to the
budget file goes through review, the escape hatch gets checked too.
#### Noise and False Positives
Quantity budgets are deterministic; the same input produces the same number. Metric
budgets are not, and applied directly they produce false positives.
Three precautions are required. Measurement gets taken **multiple times** and the median
gets used; a single run is not enough for a decision. Measurement conditions get
**fixed**: the same network throttle, the same device profile, a browser with no
extensions — the reproducibility conditions from the Network Panel Diagnostics lesson are
the budget's precondition here. And the threshold gets chosen **clearly larger** than the
measurement's natural variability; a tolerance that sits inside the noise produces a
check that stays permanently red and therefore gets ignored.
There is also a scope decision. A budget applies not to every page but to
representative pages: the station list page and the measurement detail page. The first
lesson showed that these two pages get judged by different metrics; their budgets, for
the same reason, get written separately.
#### Summary
- A budget is a limit where something happens when it gets exceeded; a number with no
enforcement is a target, and it does not stop things from getting worse.
- The three budget types cover each other's gaps: the metric budget measures the
experience but is noisy, the quantity budget is deterministic but indirect, the rule
budget protects decisions that do not reduce to a number.
- A budget group's aggregation rule changes the outcome: pieces loaded on every page get
summed, and for optional pieces the largest one gets measured.
- An absolute limit and a growth tolerance protect different things; when only the limit
gets checked, small and steady growth stays invisible until it reaches the limit.
- Metric budgets can only get tied to enforcement once measurement conditions are fixed
and the median of multiple runs gets taken.
#### Next Step
Performance is no longer a matter of opinion: it has defined metrics, written limits,
and a check that runs on every build. That is not the whole of the quality axis, though.
A page can load fast and still be unusable — a list that cannot get navigated with a
keyboard, a button that tells a screen reader nothing, text with insufficient contrast.
These problems do not have to be a matter of opinion either; they too have defined
metrics, measurable thresholds, and conformance levels. The next lesson takes up
accessibility standards and defines usability with the same discipline — testable
criteria.
## Accessibility
The structure of accessibility criteria and conformance levels; how native elements map onto the accessibility tree, accessible name computation, correct and incorrect use of ARIA, keyboard access, live regions, contrast thresholds, and the limits of automated auditing.
### Accessibility Standards
Source: https://academia.sh/en/courses/frontend-quality/accessibility-standards
The four principles that make accessibility measurable, the structure of criterion numbers, the conjunction rule for conformance levels, and conformance being defined at the scale of a process rather than a page.
Performance was tied to a measurable budget at this point: a threshold was written for
each metric, a change that crossed the threshold counted as a regression, and the
regression was caught before release. The value of this discipline was moving the
decision out of debate and into measurement — the question "is the page fast" was
replaced by "which metric crosses which threshold."
The same discipline is needed on a second quality axis. Whether an interface is usable
cannot be measured if it is left as an impression a sighted user forms by trying it with
a mouse; what cannot be measured cannot be caught when it regresses. This lesson builds
the structure that answers the question: usability is tied to criteria that are countable
and testable as true or false.
#### Four Principles
Accessibility criteria are grouped under four principles. Principles are not criteria;
they cannot be tested. They are the framework that groups criteria and states which
question each one answers.
**Perceivable.** Content and interface components must be presented so a user can
perceive them. If a piece of information depends on a single sense alone, it does not
exist for a user who cannot use that sense. An image's alternative text, a video's
captions, color not being the sole carrier, and a text's contrast threshold all fall
under this principle.
**Operable.** Interface components and navigation must be usable. What this measures is
not whether the user reaches the information, but whether they can **operate** the
interface: reaching every control by keyboard, being able to exit wherever they entered,
seeing where focus is, having enough time.
**Understandable.** Information and the operation of the interface must be
understandable. Language declaration, predictable behavior, error identification, and
correction suggestions belong to this principle. A page that changes on its own when a
form field takes focus produces an interface that works but is not understood.
**Robust.** Content must be robust enough to be interpreted reliably by a wide variety of
user agents, including assistive technologies. This principle requires the markup we
produce to rely on defined contracts rather than the behavior of one particular
implementation. A component's name, role, and value being programmatically readable is
the criterion for this principle.
The order of the four principles is not arbitrary; it forms a dependency chain: something
that cannot be perceived cannot be operated, the understandability of something that
cannot be operated is never asked, and if none of them is declared robustly, none of the
three reaches assistive technology.
#### What the Criterion Number Says
Every criterion has a three-part number, and the number alone locates what is being
discussed.
The first digit is the **principle**: 1 perceivable, 2 operable, 3 understandable, 4
robust. The second digit is the **guideline** under the principle; guidelines cannot be
tested either — they group criteria by topic (2.4 navigability, 3.3 input assistance, and
so on). The third digit is the **success criterion** under that guideline, and it is the
only testable unit.
So when the number 2.4.7 is read, it is known to belong to the operable principle's
navigation guideline even if the criterion's name is unknown. Numbers are never reused
once published: when a criterion is added it gets a new number, and the meaning of
existing numbers does not change. This lets two people understand the same thing from the
same number, and it is why writing the criterion number in a bug report is valuable.
The shared property of criteria is that they are **testable**: each is written so it can
be answered true or false for a given piece of content. "The page should be accessible"
is not a criterion; "the contrast ratio between the text and its background must be at
least 4.5:1" is.
#### Conformance Levels
Criteria are distributed across three conformance levels: A, AA, and AAA. The level does
not describe the criterion's importance but the **cost of meeting it and the breadth of
its scope**. When level A is not met, user groups cannot use the interface at all; level
AA removes barriers that seriously hinder use; level AAA is additional requirements that
may not apply to every content type.
Levels are cumulative and evaluated by a **conjunction** rule: AA conformance means every
A criterion and every AA criterion is met. If even one A criterion fails, the surface
conforms to no level at all. The script below applies this rule to three surfaces of the
North Slope Measurement Station interface.
```js
// conformance.mjs — deriving the principle from a criterion number and computing conformance level
const PRINCIPLE = { 1: "perceivable", 2: "operable", 3: "understandable", 4: "robust" };
const CRITERION = {
"1.1.1": ["Non-text Content", "A"],
"1.3.1": ["Info and Relationships", "A"],
"1.4.1": ["Use of Color", "A"],
"1.4.3": ["Contrast (Minimum)", "AA"],
"1.4.6": ["Contrast (Enhanced)", "AAA"],
"1.4.11": ["Non-text Contrast", "AA"],
"2.1.1": ["Keyboard", "A"],
"2.1.2": ["No Keyboard Trap", "A"],
"2.4.1": ["Bypass Blocks", "A"],
"2.4.3": ["Focus Order", "A"],
"2.4.7": ["Focus Visible", "AA"],
"2.5.3": ["Label in Name", "A"],
"3.3.1": ["Error Identification", "A"],
"3.3.2": ["Labels or Instructions", "A"],
"3.3.3": ["Error Suggestion", "AA"],
"3.3.5": ["Help", "AAA"],
"4.1.2": ["Name, Role, Value", "A"],
"4.1.3": ["Status Messages", "AA"],
};
const LEVELS = ["A", "AA", "AAA"];
// North Slope station's three surfaces: "passed" | "failed" | "not-applicable"
const FAILED = {
"measurement-list": ["1.4.3", "1.4.6", "4.1.3"],
"measurement-entry": ["1.4.6", "3.3.5", "4.1.2"],
"submission-confirmation": ["3.3.5"],
};
const NOT_APPLICABLE = {
"measurement-list": ["3.3.1", "3.3.2", "3.3.3"],
"measurement-entry": [],
"submission-confirmation": ["3.3.1", "3.3.2", "3.3.3"],
};
const results = (surface) =>
Object.fromEntries(
Object.keys(CRITERION).map((n) => [
n,
FAILED[surface].includes(n) ? "failed" : NOT_APPLICABLE[surface].includes(n) ? "not-applicable" : "passed",
]),
);
const levelMet = (s, level) =>
Object.entries(CRITERION).filter(([, [, l]]) => l === level).every(([n]) => s[n] !== "failed");
function conformanceLevel(s) {
let result = "not conformant";
for (const l of LEVELS) {
if (!levelMet(s, l)) break;
result = l;
}
return result;
}
console.log("surface passed failed not-applicable pct conformance");
for (const surface of Object.keys(FAILED)) {
const s = results(surface);
const d = Object.values(s);
const passed = d.filter((v) => v === "passed").length;
const failed = d.filter((v) => v === "failed").length;
const na = d.filter((v) => v === "not-applicable").length;
console.log(
`${surface.padEnd(26)} ${String(passed).padStart(6)} ${String(failed).padStart(6)} ${String(na).padStart(14)} ` +
`${((100 * passed) / (passed + failed)).toFixed(1).padStart(5)} ${conformanceLevel(s).padStart(14)}`,
);
}
console.log("\nremaining criteria:");
for (const surface of Object.keys(FAILED)) {
for (const n of FAILED[surface]) {
const [name, level] = CRITERION[n];
console.log(` ${surface.padEnd(26)} ${n.padEnd(7)} ${level.padEnd(4)} ${PRINCIPLE[n[0]].padEnd(16)} ${name}`);
}
}
const PROCESS = ["measurement-list", "measurement-entry", "submission-confirmation"];
const lowest = PROCESS
.map((y) => conformanceLevel(results(y)))
.reduce((a, b) => (LEVELS.indexOf(a) < LEVELS.indexOf(b) ? a : b));
console.log(`\nprocess: ${PROCESS.join(" -> ")}`);
console.log(` process conformance level: ${lowest}`);
const all = PROCESS.flatMap((y) => Object.values(results(y)));
const p = all.filter((v) => v === "passed").length;
const f = all.filter((v) => v === "failed").length;
console.log(` criterion pass rate: ${((100 * p) / (p + f)).toFixed(1)}`);
console.log(` criteria audited for AA: ${Object.values(CRITERION).filter(([, l]) => l !== "AAA").length}`);
```
```
surface passed failed not-applicable pct conformance
measurement-list 12 3 3 80.0 A
measurement-entry 15 3 0 83.3 not conformant
submission-confirmation 14 1 3 93.3 AA
remaining criteria:
measurement-list 1.4.3 AA perceivable Contrast (Minimum)
measurement-list 1.4.6 AAA perceivable Contrast (Enhanced)
measurement-list 4.1.3 AA robust Status Messages
measurement-entry 1.4.6 AAA perceivable Contrast (Enhanced)
measurement-entry 3.3.5 AAA understandable Help
measurement-entry 4.1.2 A robust Name, Role, Value
submission-confirmation 3.3.5 AAA understandable Help
process: measurement-list -> measurement-entry -> submission-confirmation
process conformance level: not conformant
criterion pass rate: 85.4
criteria audited for AA: 16
```
The three rows show three separate situations. The measurement list meets every A
criterion but misses two AA criteria; its level is A. The measurement entry passes
fifteen criteria, yet because it fails a single A criterion (4.1.2 Name, Role, Value) it
conforms to no level at all. The submission confirmation misses only one AAA criterion
and is at level AA.
The **not-applicable** column is not an exemption. Because the submission confirmation
page has no form, the error criteria are not evaluated on that surface; the moment a form
is added to the page, three criteria come back into scope. A not-applicable result means
the criterion has no counterpart in that content — not that a criterion with a
counterpart was skipped.
#### Conformance Is a Property of the Process, Not the Page
The last part of the script shows why conformance cannot be reported surface by surface.
Submitting a measurement is a process that passes through three surfaces: the user
selects a record from the list, fills in the entry form, and sees the result on the
confirmation surface. If one link in the chain breaks, the process cannot be completed;
that is why the process's conformance level is the lowest of its links.
This rule has three extensions, and all three change a decision in practice.
**The whole page counts.** A surface's conformance is the conformance of the whole
surface, not of one part of it. A third-party component tucked in a corner of the page is
in the same scope.
**A process counts as a whole.** The listing surface alone being conformant does not mean
the measurement-submission process is conformant.
**Non-conforming content must not interfere.** Even when a section is left out of the
conformance scope, it must not block use of the rest of the page. A component that traps
focus, plays audio automatically, or locks keyboard navigation cannot be excused by being
declared out of scope.
A fourth condition concerns the choice of technology: the markup and scripts used must be
supported by assistive technologies. This condition excludes from conformance a component
declared in a way that has no defined counterpart — even if the component works in one
particular implementation.
#### The Difference Between a Budget and a Criterion
The difference between a performance budget and a conformance rule shows up in the
output's last lines. 85.4 percent of criteria pass across the three surfaces; even so,
the process has no conformance level. That percentage feeds no decision.
The reason is that the two measures have different mathematical structures. Performance
metrics are defined over a distribution: a load-time metric asks that 75 percent of users
stay below a given threshold, and the remaining 25 percent are knowingly accepted.
Accessibility criteria are a conjunction: either every criterion is met or there is no
conformance. There is no averaging, because the user does not navigate an average page —
they stop at the one surface they cannot use.
This does not mean accessibility cannot be budgeted; the shape of the budget changes. In
performance the budget is a list of thresholds; in accessibility it is a **count of
zero**: the release that ships must have zero unmet A and AA criteria. Known, not-yet-fixed
defects are kept in an open list with the criterion number, the affected surface, and a
fix date. The definition of a regression is the same: if a criterion that passed
yesterday fails today, that is a regression.
#### Summary
- Accessibility criteria are grouped under four principles: perceivable, operable,
understandable, and robust. Principles are not tested; they group criteria.
- The criterion number's first digit gives the principle, the second the guideline, and
the third the testable criterion; numbers are never reused, and they give bug reports a
shared language.
- Conformance levels are cumulative: AA conformance means every A and AA criterion is
met; when a single A criterion fails, the surface conforms to no level.
- Conformance is meaningful at the scale of a process, not a surface; the whole page
counts, a process counts as a whole, and out-of-scope content must not block the rest.
- A performance budget is a distribution threshold; accessibility conformance is a
conjunction — the criterion pass rate produces no decision, the count of unmet A and AA
criteria does.
#### Next Step
This lesson built the framework of criteria but did not open up the structure that the
criteria inspect. Criterion 4.1.2 requires a component's name, role, and value to be
programmatically readable; where does that triple live, and who produces it? The answer
is the accessibility tree introduced in the Semantic Markup and Media topic: the browser
derives a second tree from the document tree, and assistive technologies read that tree.
The next lesson takes up this derivation at the rule level, showing which element
produces which role and in what order an element's accessible name is computed.
### The Role of Semantic Markup
Source: https://academia.sh/en/courses/frontend-quality/role-of-semantic-markup
How the accessibility tree is derived from the document tree, the implicit roles native elements produce, the order in which the accessible name is computed, and an accounting of the cost paid for a meaningless container.
The previous lesson put criterion 4.1.2 on the list: an interface component's **name**,
**role**, and **value** must be programmatically readable. For the criterion to be
testable, this triple must actually exist somewhere. A button's name does not live in the
page's visual appearance; it lives in a second structure derived from the document.
That structure is the **accessibility tree** introduced in the Semantic Markup and Media
topic. This lesson takes up how the tree is derived at the rule level: which node enters
the tree, where the role of one that enters comes from, and in what order its name is
computed. All three answers live in the markup; none is read from the presentation layer.
#### The Tree Is Derived From the Tree
The browser walks the Document Object Model tree and builds a second tree. The second
tree's nodes are not the elements themselves but their **accessibility counterparts**:
each node carries a role, a name, a description, and a set of states.
Some nodes never enter the tree during derivation. The pruning rules are these: elements
not rendered in the presentation layer or whose visibility has been removed do not enter;
elements carrying the `hidden` attribute do not enter; an element declaring
`aria-hidden="true"` and its whole subtree do not enter; an image whose alternative text
has been left empty is treated as presentational and does not enter.
This produces a distinction. There are two ways to remove an element from the screen, and
they give different results in the tree. Taking an element out of rendering in the
presentation layer also deletes it from the tree; moving it off-screen or making it
transparent keeps it in the tree. A skip link being able to work while invisible rests on
the second path: the link is in the tree, it takes focus, and it is only invisible to the
eye.
#### Implicit Role
Every node that enters the tree has a role, and when no declaration is written, that role
comes from the element itself. This is called the **implicit role**. Part of the mapping
is conditional: the same element produces a different role depending on an attribute.
The `a` element produces the link role only when it carries an `href` attribute; without
one it is a meaningless node in the tree. The `input` element's role comes from its type
attribute: a text field, a search field, a number field, and a checkbox are separate
roles. The `th` element's role is column header or row header depending on its scope
attribute. The mapping from sectioning elements to landmark roles, and the conditions on
that mapping, were established in the Web Fundamentals and HTML course; here the same
derivation continues for form controls.
#### Computing the Accessible Name
The question after role is name. The **accessible name** is the string that introduces a
node to the user, and it does not come from a single source: it is computed by a defined
order of precedence. The script below implements the local part of that order. ARIA
sources sit at the very top of the order and are the next lesson's subject; here we see
what happens without them.
```js
// name.mjs — implicit role of native elements and accessible name computation (ARIA sources excluded)
function role(d) {
const a = d.attrs ?? {};
switch (d.element) {
case "a": return a.href === undefined ? "generic" : "link";
case "button": return "button";
case "input":
return { checkbox: "checkbox", radio: "radio", number: "spinbutton",
search: "searchbox", submit: "button" }[a.type ?? "text"] ?? "textbox";
case "select": return "combobox";
case "table": return "table";
case "th": return a.scope === "row" ? "rowheader" : "columnheader";
case "td": return "cell";
case "tr": return "row";
case "fieldset": return "group";
case "img": return a.alt === "" ? "— (presentational)" : "image";
case "ul": return "list";
case "li": return "listitem";
case "h1": case "h2": case "h3": return "heading";
case "output": return "status";
default: return "generic";
}
}
// roles that take a name from content in ARIA
const FROM_CONTENT = new Set(["button", "link", "heading", "cell", "columnheader",
"rowheader", "listitem", "checkbox", "radio", "option"]);
function text(d) {
if (typeof d === "string") return d;
const a = d.attrs ?? {};
if (a.hidden) return "";
if (d.element === "img") return typeof a.alt === "string" ? a.alt : "";
return (d.children ?? []).map(text).join(" ").replace(/\s+/g, " ").trim();
}
// Order: local source -> content text (roles that allow it) -> last resort
function name(d, labels) {
const a = d.attrs ?? {};
if (a.hidden) return ["", "hidden"];
if (d.element === "img" && typeof a.alt === "string" && a.alt !== "") return [a.alt, "alt"];
for (const [el, sub] of [["table", "caption"], ["fieldset", "legend"], ["figure", "figcaption"]]) {
if (d.element !== el) continue;
const c = (d.children ?? []).find((x) => x.element === sub);
if (c) return [text(c), sub];
}
if (["input", "select", "textarea"].includes(d.element)) {
if (labels[a.id]) return [labels[a.id], "label element"];
if (a.title) return [a.title, "title (last resort)"];
if (a.placeholder) return [a.placeholder, "placeholder (last resort)"];
return ["", "no name"];
}
if (FROM_CONTENT.has(role(d))) {
const m = text(d);
if (m) return [m, "content text"];
}
if (a.title) return [a.title, "title (last resort)"];
return ["", "no name"];
}
// --- North Slope: examples from the filter panel and the measurement table --
const LABELS = {
"filter-code": "Station code",
"filter-alert": "Only measurements with an alert",
value: "Measured value (°C)",
};
const EXAMPLE = [
["", { element: "button", children: ["Filter"] }],
['',
{ element: "button", children: [{ element: "img", attrs: { alt: "Clear filter" } }] }],
['',
{ element: "button", children: [{ element: "img", attrs: { alt: "" } }] }],
[' + label',
{ element: "input", attrs: { id: "filter-code", type: "search" } }],
['',
{ element: "input", attrs: { id: "search", type: "search", placeholder: "station" } }],
[' + label',
{ element: "input", attrs: { id: "value", type: "number" } }],
[' + label',
{ element: "input", attrs: { id: "filter-alert", type: "checkbox" } }],
["
