Web Performance curriculum

Three metrics covering three different experiences — waiting for content, waiting for a response, and content moving under you — which is why one can be excellent while another is dreadful. Optimizing the one you happen to measure is how a page gets faster and no better.

The framing shifts the question from resource accounting to what the person is experiencing at each moment, which changes what counts as an improvement. A smaller bundle that moves none of these is work; a reordered tag that moves one is a result.

Three bands rather than a single line, and the middle one is not a pass — it is a warning that the metric is drifting. Reading it as acceptable is the most common misinterpretation, because it sounds like a grade rather than a threshold.

Assessment happens at a high percentile, so the experience being judged is the slow tail rather than the typical visit. A comfortable average with a long tail fails, which is why an average is close to useless for this work.

The assessment is conjunctive, so a page passes only when every metric is in the good band. That makes the weakest one the whole result, and it is why effort belongs on whichever is failing rather than on improving one that already passes.

Several widely-quoted measurements diagnose a core metric without being one, which matters when reporting: improving a diagnostic is evidence of progress and not the outcome. Confusing them produces dashboards that look green while the assessed metric does not move.

The population to optimize for is a mid-range phone on a slow connection, not the machine the site was built on — and the gap between them is large enough to hide every problem. Throttling deliberately is the cheapest way to see what most visitors see.

The link to conversion and bounce is what funds the work, which makes measuring the business metric alongside the technical one part of the job. Without it, performance work competes with features on assertion rather than on evidence.

Two boundaries defining three bands, assessed at the high percentile rather than the typical load. The number is worth knowing precisely because the middle band is where most sites sit, and the distance from it to the good band is what the work has to close.

Only a specific set of element types can be the candidate, which means the largest thing on screen visually may not be the thing measured. Knowing the set is what stops an optimization aimed at something the metric never considered.

The candidate is re-elected as content paints and then freezes at the first interaction, so the reported element depends on when the user acts. That is why a page can report different candidates across loads, and why the fix has to target whichever one wins on a real visit.

The size counted is the smaller of what is on screen and the resource's own dimensions, and area outside the viewport does not count. A large image scaled down therefore scores by its displayed size, which is what makes a modest hero the candidate over a huge clipped background.

One marks the first content of any kind and the other the paint of the largest, so a page can show something quickly and still take seconds to show the thing the visitor came for. Reporting the earlier one as progress is the standard way to make a slow page look fast.

When the candidate is text there is no resource to fetch, so the time is font loading and render blocking rather than bytes. That changes the fix entirely — compressing images does nothing, and unblocking the first paint does everything.

A client-side route change is not a page load, so no new value is produced and the metric reflects only the original entry. An application that navigates internally therefore reports on its first screen indefinitely, which flatters or damns it regardless of the rest.

Breaking the total into four consecutive pieces turns an unhelpful number into a diagnosis, because each piece has a different remedy — server time, discovery, transfer, and rendering. Measuring the split first is what stops effort landing on the largest-sounding rather than the largest part.

Knowing roughly how a healthy split is distributed lets you compare yours against it and see which piece is anomalous. It is a diagnostic ratio rather than a target: the point is that one piece being far out of proportion names the problem.

The delay between the server responding and the resource starting is usually the browser not knowing about it yet, because it is injected by script rather than present in the initial markup. That is a discovery problem, and no amount of compression touches it.

Deferring the image that defines the metric delays it until layout has established that it is visible, which is precisely the work the attribute exists to postpone. It is a one-attribute regression that is invisible in review and costly in measurement.

Images start at a low priority by default and are promoted only once layout proves they are visible, so telling the browser in advance skips that wait. It is one attribute on one element and one of the highest-value single changes available.

A responsive image has several candidates, so preloading it requires declaring the same candidate set the element uses or the browser fetches the wrong one and downloads twice. That is why the preload carries the descriptor attributes rather than a single URL.

The resource can be fully downloaded and still unpainted while a stylesheet or a script holds up rendering, which makes this the piece that network optimization cannot reach. The evidence is a load duration that ends well before the paint.

A unitless score with two boundaries, which makes it the least intuitive of the three — the number has no natural interpretation until you have seen a few pages. Reading it alongside the shifts that produced it is the only way to build that intuition.

Each shift scores the fraction of the viewport affected multiplied by how far it moved, both relative to the viewport. That product is why a small element moving a long way and a large element moving slightly can score the same, and why a full-width banner is so expensive.

The score is the worst burst within a bounded window rather than the sum of everything, which stops a long session accumulating a failing score from many trivial shifts. It also means a single bad moment defines the page, so fixing the worst one is the whole remedy.

A shift shortly after an interaction is treated as expected, because the user asked for something to change. That exclusion is what makes an accordion or a filter legitimate, and it is why moving content without a preceding interaction is what actually scores.

Moving an element with a transform changes where it is painted and not where the layout says it is, so nothing around it moves and nothing is scored. That is the mechanical reason animation guidance points at this property rather than at geometry.

Appearing is not itself a shift — what scores is the already-visible content pushed out of the way. That distinction is what makes reserving space the fix: the element still appears, and nothing around it has to move to accommodate it.

The metric keeps accumulating after load, so a shift caused by scrolling, a refreshing advertisement or a late widget counts as much as one during startup. Testing only the initial load therefore measures a fraction of what real users experience.

Supplying the dimensions gives the browser an aspect ratio before any bytes arrive, so the space is reserved and nothing moves when the image lands. It is the oldest fix in this area and it is still the one most often missing.

For media whose pixel dimensions are unknown or fluid, declaring the ratio in the stylesheet reserves the box the attributes would have. It is the fix for anything sized by its container rather than by its own intrinsic dimensions.

An advertisement slot should be sized from what that slot historically fills and should never collapse when nothing is served, because collapsing is itself a shift. Sizing from the best case is how a page shifts on every unfilled impression.

Inserting anything above existing content pushes the entire page down, which is close to the maximum possible score for a single shift. Overlaying it or reserving its space beforehand are the two ways to keep the banner and lose the shift.

Text reflows when the fallback and the web font occupy different space, and every line of affected text moves. That makes typography a stability question, and it is why the metric-matching techniques exist rather than simply choosing a display strategy.

Animating a geometric property produces a layout on every frame and therefore a scored shift on every frame, while the compositing properties produce neither. The visual result is often identical, which is what makes the wrong choice so easy.

Giving a placeholder a minimum height means the real component arrives into space that already exists, so nothing below it moves. It is the same reservation principle as image dimensions applied to anything that loads or hydrates late.

Two boundaries around the responsiveness metric, assessed at the high percentile of interactions. The good band is tight enough that an interaction feeling instant and one scoring well are close to the same thing, which makes it unusually intuitive to test by hand.

Only discrete interactions count — the ones where the user expects a response — while continuous gestures do not. That is why a janky scroll does not appear in this metric despite being obviously bad, and why scroll performance needs measuring separately.

Waiting for the handler to start, running it, and getting the result on screen are three separate costs with three different remedies. Most attention goes to the middle one, and the first and third are frequently where the time actually is.

The reported value is the page's worst interaction rather than a typical one, with a small allowance for outliers on pages with many interactions. That makes it a measurement of the failure case, which is the right thing to measure and an uncomfortable one to report.

The clock runs until the frame is painted, not until the handler returns — so finishing quickly and then queueing expensive rendering scores exactly as badly. That is why an optimization that shortens the handler and not the frame produces no improvement.

A single tap produces several events and the interaction's latency is the longest of the group, so a fast click handler does not save a slow pointer handler. Measuring one event in isolation therefore misses where the time went.

The predecessor measured only the delay before the first interaction's handler began, which ignored both the handler's own cost and every subsequent interaction. The replacement measures the whole response and the worst case, which is why sites that passed the old metric can fail this one.

A page nobody interacts with reports nothing, which is not the same as reporting a good value — the absence of data is often read as a pass. It also means coverage of this metric is worst on exactly the pages with the lowest engagement.

Any uninterrupted stretch of main-thread work beyond the threshold blocks input entirely, because there is no opportunity to handle it until the task ends. That is the mechanism connecting bundle execution to unresponsiveness — the page is not busy, it is unavailable.

Summing the excess beyond the threshold across long tasks produces the lab proxy for responsiveness, which is measurable without any user interaction. It is a proxy rather than the metric, so improving it is strong evidence and not proof.

Breaking work into separate tasks gives the browser a chance to handle pending input between them, which converts one unresponsive stretch into several short ones. The total work is unchanged; only its availability to interruption changes.

The dedicated primitive yields and resumes ahead of other queued work, which the timer-based technique cannot do — that one goes to the back of the queue. The difference matters for a long sequence, where the timer approach can be starved by unrelated tasks.

Moving non-visual work until after the next frame lets the response appear first and the bookkeeping happen afterwards, which improves the measured latency without reducing the work. It is a reordering rather than an optimization.

One waits for the input to stop and runs once; the other runs at a bounded rate throughout. Choosing between them is a question about whether intermediate results are useful, and using the wrong one either feels unresponsive or does far more work than needed.

A worker genuinely runs elsewhere and cannot touch the document, and everything crossing the boundary is copied unless explicitly transferred. That copy cost is the thing to measure — work too small to dwarf it is faster left where it was.

A growing heap lengthens collection pauses, and a pause is main-thread time like any other — so a memory leak surfaces as a responsiveness problem rather than as an out-of-memory error. That indirection is why the two are rarely connected.

Script is uniquely expensive because the cost is paid four times over — transferred, parsed, compiled and executed — while an image is merely transferred and decoded. That is why a kilobyte of script and a kilobyte of image are not comparable quantities.

Transfer tracks the compressed size and processing tracks the uncompressed one, so two bundles with identical download sizes can cost very different amounts of main-thread time. Reporting only the compressed figure hides the more expensive half.

Deferring a route's or a widget's code until it is needed removes it from the startup cost entirely rather than making it smaller. The choice of split point is the design work, and splitting something needed immediately adds a round trip for nothing.

Elimination needs statically analyzable modules and accurate side-effect metadata, and either being absent silently disables it. The failure produces a larger bundle with no error, which is why the output size is worth checking against expectation rather than assumed.

Compiling for very old targets emits more helper code and ships polyfills to browsers that need none, which penalizes the modern majority to serve a shrinking minority. Choosing the target from the actual audience is one of the cheaper size wins available.

Attaching behavior re-runs the component tree on the client, which is main-thread work that rendering on the server does not remove — it only changes when the markup appears. That is why a server-rendered application can paint early and remain unresponsive.

One large bundle invalidates entirely on any change while many small ones cost requests and coordination, so the split is a trade rather than a maximization. Stability matters as much as size — a strategy that renames every file on each build gives the caching benefit back.

Parsing stops at the tag until the script has downloaded and run, because the script might write into the document. That single behavior is the reason for every loading attribute that followed, and it still appears in pages copied from old templates.

Both avoid blocking the parse and differ on when they run: one preserves order and waits for parsing to finish, the other runs the moment it arrives. Dependent code needs the first, and independent third-party code suits the second.

Module scripts are deferred by default, so the attribute adds nothing and its presence suggests a misunderstanding rather than a bug. Knowing the default is what prevents reasoning about ordering that is already guaranteed.

A secondary parser races ahead fetching subresources it can see in the markup, which is why static tags start downloading during a blocking script. Anything injected by script is invisible to it, which is the mechanism behind most discovery delays.

A vendor tag executes on your main thread, at a priority you do not set, with a size nobody on your team controls. That combination is why third-party script is usually the largest single lever and the hardest one to pull.

Replacing a heavy embed with a lightweight placeholder that loads the real thing on interaction removes its entire cost from every visit where nobody uses it. For a video or a map embed that is most visits, which is what makes the technique so effective.

It bounds how early anything else can begin, which is why a poor value caps every downstream metric regardless of how well the page is built. It is a diagnostic rather than an assessed metric, so improving it is evidence of progress toward a different number.

Six distinct costs before the first byte arrives, only one of which is the server's own work — the rest are redirects, resolution, connection and encryption. Attributing the total to the application is the usual error, and the breakdown is what prevents it.

Each hop costs a full round trip before any content begins, and a chain multiplies it — all of it spent before the browser has seen a single byte of the page. It is also the cheapest thing to fix, because the fix is usually a configuration line.

Resolution, connection and encryption together cost roughly three round trips before the first request is even sent, which is why latency dominates on a distant or mobile connection. It is also why connection reuse and early hints matter more than bandwidth.

Interleaving many streams on one connection removed the limit that made splitting assets across hostnames worthwhile, so that old technique now costs extra connections for no benefit. Advice written before it is actively harmful rather than merely outdated.

Moving off the older transport removes the case where one lost packet stalls every stream sharing the connection, and it can resume without a full handshake. The benefit is largest exactly where conditions are worst, which is the population that matters most.

Compression applies to text and gains nothing on formats that are already compressed, so re-compressing media wastes processing on both ends. The newer algorithm beats the older one on text, which makes enabling it a configuration change with no code involved.

Opening resolution, connection and encryption early removes those round trips from the critical path when the resource is finally requested. Each one holds a connection open, so using it widely spends resources on origins that may never be used.

Resolving only the name is far cheaper than a full connection, which makes it safe to apply to more origins. It is the right hint for something probably needed later, where the full connection would be speculative.

The destination attribute sets the priority and the request context, and omitting it produces both the wrong priority and a second download when the real request does not match. A preload that downloads twice is worse than none.

Fetching something nothing consumes spends bandwidth on the critical path and produces a console warning, which is the browser telling you the hint was wrong. It happens most often when a preload outlives the code that used the resource.

A lowest-priority fetch for a page the user will probably visit next, which means it competes with nothing on the current page. Its value depends entirely on the prediction being right, so it belongs where the next step is genuinely predictable.

It preloads and pre-parses a module together with its dependency graph, which plain preloading does not — the graph is what makes the difference. Preloading a module the ordinary way fetches one file and leaves its imports to be discovered later.

It nudges a resource within its own class rather than promoting it above a different class, so a high-priority image does not overtake a stylesheet. Expecting it to reorder across classes is the usual misunderstanding of what it can do.

Stylesheets and blocking scripts start highest while images start low and are promoted once layout proves they are visible, which is exactly why the hero needs explicit help. The defaults are sensible in general and wrong for the one element the metric measures.

The newer formats are substantially smaller at equivalent quality, with a fallback chain covering older clients. The picture element supplies that chain, which makes adopting them a markup change rather than a compatibility decision.

Width descriptors let the browser choose by the layout width and the device's pixel density, which it can do before the stylesheet is available only if the sizes value tells it how wide the image will be. Both halves are required for the mechanism to work.

A value that does not match the actual layout makes the browser choose the wrong candidate, usually a larger one, so the responsive markup costs bytes instead of saving them. Nothing reports the mismatch, which is why it survives review.

With type conditions it provides format fallback and with media conditions it provides genuine art direction, which are two different jobs. Using it where descriptors would do adds markup without changing what is downloaded.

Deferring off-screen images saves real bytes on long pages, and applying it above the fold delays the element the loading metric measures. The rule is positional rather than universal, which is why a blanket application is a regression.

A large image costs main-thread decoding after it has downloaded, so transfer time is not the whole cost. Moving the decode off the critical path is a separate attribute from anything about fetching, and it matters most on the slow devices that matter most.

Images and video are the largest share of bytes on a typical page, which makes image work the highest-leverage saving available by a wide margin. Optimizing script first is common and is usually optimizing the smaller number.

Embedding a resource removes a request and adds roughly a third to its size, puts it in a file that must parse before rendering, and makes it impossible to cache separately. It is worth it for something tiny and critical, and a loss for everything else.

Telling the browser not to preload and giving it a still image means an unplayed video costs one small file instead of megabytes. Autoplaying muted video without this is one of the largest unnoticed costs a page can carry.

The values differ only in how long text stays invisible and how long a swap remains permitted, which makes the choice a trade between a blank moment and a visible change. Neither is free, and picking one without knowing which cost you are accepting is the usual approach.

One hides text until the font arrives and the other shows a fallback and swaps, trading invisible content for a reflow. Both are visible to the user; the question is whether you would rather they wait or see the page change under them.

A font is only requested once the stylesheet has parsed and a matching element exists, which puts it late in the sequence by construction. That is why the critical face is preloaded — the discovery, not the transfer, is what makes it late.

Splitting a family by character range means a script's glyphs are fetched only when those characters actually appear, which can remove most of a large family's weight. It is declarative, so the browser does the selection rather than the build.

One format is the one to ship, and a single variable file can replace a stack of individual weights — often for less than two of them cost separately. Both are straightforward changes with no markup consequence.

Adjusting the fallback's metrics so it occupies the same space as the real font removes the reflow when the swap happens, which turns a stability problem into a purely visual one. It is the fix that lets you have a fallback and no shift.

A separate font origin costs an extra connection, and cache partitioning removed the cross-site reuse that used to justify it. That change inverted the old advice, which is still widely repeated.

Both the document and the style model are required before anything can be painted, which is why a stylesheet blocks rendering and a script does not necessarily. The dependency is structural rather than a policy choice.

A stylesheet in the head holds up the first paint by default, which is why one slow style request leaves a blank page regardless of how fast the markup arrived. The blocking is deliberate — painting unstyled content and restyling it would be worse.

A media condition that does not match makes the sheet non-blocking while still downloading it, which is the mechanism behind the common deferral trick. The download still happens, so it reorders the cost rather than removing it.

An import inside a stylesheet is only discovered once the parent has parsed, adding a serial round trip that the preload scanner cannot anticipate. It is one of the few constructs that reliably makes a page slower with no visible cause.

Inlining the rules needed for the first screen and deferring the rest removes the blocking request entirely, at the cost of bytes that cannot be cached and a build step to extract them. It is the highest-impact and highest-maintenance technique in this area.

Rules that never match still cost download, parsing and recalculation on every style change, so an unused stylesheet is not free simply because nothing applies. The recalculation cost is the one people forget, and it recurs.

Style, layout and memory all scale with the number of nodes, which makes an unnecessarily deep or large document a performance problem in its own right. It is also the cost that component frameworks make easiest to create accidentally.

A frame's budget is small and the browser's own work consumes part of it, so the time genuinely available to application code is smaller than the headline figure. Working to the headline number is how something that looks affordable drops frames.

Five stages where each one you avoid is time you keep, which is why the cheapest change is the one entering the pipeline latest. That ordering is the whole basis of the property advice that follows.

Geometric properties re-run layout, color properties repaint, and two properties only composite — and the visual result is frequently indistinguishable. Choosing by appearance rather than by pipeline stage is how an animation becomes expensive for no benefit.

Reading a geometric value after writing a style forces layout immediately rather than at the frame boundary, because the browser must compute an answer. The read looks harmless and is the thing that triggers the work.

Alternating reads and writes in a loop forces one layout per iteration, so the cost is quadratic in an operation that looks linear. The fix is ordering rather than reducing work: batch every read, then every write.

Promoting an element to its own layer avoids repainting it and costs memory, so applying it broadly trades one bottleneck for another. It is a hint to be applied narrowly and removed when the animation ends.

Skipping rendering work for off-screen subtrees can remove most of the layout cost of a long page, provided an intrinsic size is supplied so scrolling stays sane. Omitting that size produces a page whose scrollbar jumps as content renders.

Declaring that an element's layout cannot affect outside geometry and its painting cannot escape its box lets the engine skip work it would otherwise have to consider. It is a promise you make, so an incorrect one produces rendering bugs rather than a warning.

Scrolling runs off the main thread until a listener that might cancel it forces the main thread to be consulted on every gesture. Declaring such a listener passive is what keeps scrolling smooth, and it is a one-word change.

Freshness is counted in seconds from when the response was generated rather than from when it arrived, which means time already spent in an intermediate cache counts against it. That is why a long value does not guarantee a long life in any particular browser.

One permits storage and requires revalidation before reuse; the other forbids writing the response down at all. The names suggest the opposite of what they do, which makes this the most commonly reversed pair in cache configuration.

It tells the browser not to revalidate a still-fresh response even on a reload, which removes the round trip that otherwise happens whenever a user refreshes. It is only safe on a URL whose content genuinely never changes.

Putting a content hash in the filename and caching it permanently gives safe indefinite reuse, because a change produces a different URL rather than a stale one. It is the combination that makes aggressive caching possible without risk.

A validator turns a re-fetch into a bodyless response, which saves the payload and still costs a full round trip. On a high-latency connection that round trip is most of the cost, which is why avoiding revalidation entirely is worth more than making it cheap.

Separate directives control intermediate caches and the browser, which is what lets a response be cached at the edge and not on the device, or the reverse. Conflating them is how personalized content ends up in a shared cache.

Serving the stale copy immediately and refreshing in the background hides the revalidation latency entirely, at the cost of one request seeing old content. That trade is almost always right for content where a few seconds of staleness is invisible.

The named headers join the cache key, so a header with high variability effectively disables caching for that resource. It is the mechanism behind content negotiation and the most common way caching is accidentally turned off.

One reuses resources from memory for the current session and the other survives a restart at a higher retrieval cost. Knowing which a resource is coming from explains why a repeat view within a session is instant and the same view tomorrow is not.

Application-controlled storage ignores the freshness rules entirely, which means a worker with a naive strategy can pin an old build indefinitely. The recovery path for that has to exist before it happens, because the stale worker also controls the page that would update it.

A declarative block naming URLs to fetch or render in advance, with an eagerness setting controlling how aggressively. Being declarative means the browser applies its own heuristics and constraints, which is safer than script-driven speculation.

The next page is actually executed in a hidden context, so activation is close to instantaneous — and everything the page does on load happens whether or not the user ever arrives. That is the cost, and it is the subject of the next concept.

Analytics, logging and anything else firing on load will fire during speculation, inflating counts and triggering work for a visit that may never happen. Deferring such work until activation is required rather than optional.

A page restored from the back-forward cache resumes with its memory intact, so nothing re-runs and a stale interface stays on screen. The dedicated event with its flag is the only place to refresh such state.

A small set of things disqualify a page entirely, including an unload listener and a no-store directive on the document. They are easy to add accidentally and the cost is losing an instant back navigation across the whole site.

An informational response sends link headers before the final response exists, so the browser can preload while the server is still assembling the page. It converts server think time into useful network time, which no client-side change can do.

Entries can fire before your observer exists, so the buffered option replays them — without it, the earliest and most important measurements are simply missed. It is a one-word difference between a complete picture and a systematically late one.

The document's own waterfall from redirect through to load, which is where a poor time to first byte is attributed to a specific phase. It is the most useful single object for a question about why the page started slowly.

Cross-origin timings are zeroed unless the serving origin opts in, so third-party resources appear to cost nothing. That is a privacy protection and it means a waterfall of third-party content is measuring almost nothing.

The metrics accumulate over the whole page lifetime, so a beacon sent at load reports a partial value — usually a flattering one. Reporting when the page is hidden is the only way to capture what the visit actually scored.

A rolling window of real users at a high percentile, which is what search uses and what a site is ultimately assessed on. Its lag means an improvement shipped today appears gradually, which is worth knowing before concluding a fix did not work.

A single throttled run weighted toward a few metrics, with no interaction and therefore no responsiveness measurement. It is a useful regression detector and is not the assessment, which is the confusion behind most arguments about the number.

Device, connection, cache state and real interaction all differ, so the two disagreeing is expected rather than an error in either. Treating a lab number as a prediction of field data is the mistake; treating it as a controlled comparison between builds is the use.

The attribution data names the element, the script and the long task responsible rather than reporting a number alone, which turns a metric into an actionable finding. Collecting the number without it produces dashboards nobody can act on.

Timing, quantity and score budgets each catch different regressions — a slow milestone, a grown bundle, a broken practice — and none substitutes for the others. Choosing one type is how a budget passes while the thing it was protecting degrades.

Setting the number from your current high percentile and the fastest comparable site grounds it in what is achievable and what users are comparing against. A round figure chosen because it sounds good is either unreachable or already met.

A budget that fails the build prevents regressions; one recorded in a document describes them afterwards. The difference is entirely in the enforcement, which is why the automation is the substance rather than the number.

Automated runs catch a bundle regression on the change that caused it, and field data confirms real users felt the improvement. Each answers a question the other cannot, which is why a program needs both rather than choosing.

Tying a speed change to the conversion or engagement metric it claims to move is what makes the result evidence rather than assertion. Without it, the next round of performance work competes for time on faith.