Performance

What it means for a web client

“The site should be fast” is not a requirement, because fast is an adjective and you cannot test an adjective. Performance becomes engineering when you write numbers down before you build. The course uses Google's RAIL model as a starting set, and its numbers come from people, not servers: respond to input within 100 ms, produce each animation frame in about 10 ms, do background work in slices of 50 ms or less, and load in 5 seconds on a mid-range phone over a slow connection. Core Web Vitals measure the same concerns from real visits: LCP for when the main content appeared, INP for how quickly the page answers input, and CLS for whether things jump while you read.

Two kinds of time matter to a web client. The first is arrival: round trips, requests and bytes on a network you do not control. The Request Lifecycle makes this rung two of its ladder: a page that needs thirty seconds on a hotel connection is, for that visitor, down. The second is responsiveness: once the page is there, the main thread runs your JavaScript, style, layout and paint one thing at a time and any long task means dropped frames and unanswered taps.

The course compresses the arrival half into one line, the Performance Law: send less data, less often, from nearby, and only when needed. The responsiveness half has its own version: do less on the main thread, and do it less often. Both start from who is actually visiting. Your laptop on campus Wi-Fi is not a typical visitor. A mid-range phone on a slow network is much closer to one.

Where it lives in each layer

Structure

HTML is a list of other URLs, and each one becomes a request, so the markup decides the shape of the load. Content that arrives in the HTML is usable before any script runs. A plain <script> in <head> stops the parser; defer, async and module scripts do not. loading="lazy", preload and preconnect tell the browser what matters first, and declared image dimensions reserve space so nothing shifts when the image lands.

Presentation

Stylesheets block rendering on purpose, and every font weight is another download. A visual change costs according to where it enters the pipeline: width or top forces layout, paint and composite; transform and opacity run on the compositor alone. Late-arriving images and fonts that change geometry cause layout shift, the pipeline's most user-hostile behavior.

Interaction

JavaScript runs to completion on the same thread that renders, so a 40 ms handler costs dropped frames and ignored input. High-frequency events such as scroll and pointermove call for throttle or debounce, and { passive: true } lets scrolling proceed without waiting for you. Alternating DOM writes and geometry reads causes layout thrash; observers, event delegation, yielding and Web Workers keep work off the critical path.

Delivery

Every request pays in round trips: a DNS lookup, a TCP handshake, a TLS exchange and the request itself, about four on a cold start, more with a redirect. The HTTP cache skips the trip entirely while a response is fresh and turns a stale one into a small 304. Compression shrinks text. The bytes you choose to send (a whole page or a fragment, JSON or multipart) and the timeouts you set decide how your client behaves on a slow link.

Where the course teaches it

• Availability: rung two of the ladder, where weight, blocking scripts and the client-rendering bet decide whether the page arrives in time.
• A Budget for Patience: the RAIL budgets, Core Web Vitals, and turning “fast” into numbers you can check.
• The Localhost Effect: why your own machine is the worst place to judge speed, and the Performance Law.
• Before the First Byte: counting the round trips that happen before any of the page can move.
• One URL, Seventy Requests: the request tree, critical chains, compression, caching and loading hints.
• Engineering for the Extreme?: what heavy bundles and fixed timeouts do to people on a satellite link.
• 304: one cache revalidation, start to finish.
• The resource model: discovery, the waterfall, render-blocking, priorities and the critical rendering path.
• Style, layout, paint, composite: what a change costs and why layout shift happens.
• The JavaScript engine and the event loop: the frame budget, long tasks, yielding and workers.
• State, storage, and caching: the HTTP cache, compression and cache invalidation.
• Taming the storm: throttle, debounce and passive listeners.
• Geometry and observers: layout thrash and IntersectionObserver for lazy work.
• The postback problem: the arithmetic of bytes sent against bytes that changed.
• Who is visiting?: pick a visitor, set a page weight, and see the seconds it costs them.

Check your own page

1. Open the Network panel with the cache disabled and count the requests and total transfer size.
2. Throttle to a slow mobile profile and reload. Note how long until real content appears, and whether anything in <head> holds it back.
3. View source. If the main content is not in the HTML, the page is waiting on a script for its existence.
4. Reload with the cache enabled. Check that your CSS, scripts and images come from the cache or return 304, and read their Cache-Control headers.
5. Record a Performance trace while scrolling and clicking. Look for long tasks, and for layout or paint running every frame during an animation.
6. Find every <img> without width and height, and every scroll or input handler that runs real work on each event.