Loading and Critical Path

Deferring offscreen images and iframes saves bytes, requests and connection capacity for content the user never scrolls to, leaving more bandwidth for what is on screen first. It does not make the deferred content itself arrive faster — it arrives later, on demand.

preload fetches a resource the current page definitely needs, at high priority, during this navigation. prefetch fetches something a likely next navigation will need, at the lowest priority, using idle time. Same syntax, opposite intent.

Parser-blocking stops the HTML parser from building more DOM; render-blocking only withholds the first paint while parsing continues. A synchronous script waits for preceding stylesheets because it may read computed styles, which requires a complete CSSOM.

Deferring everything delays content the user is already looking at, so the page starts slower rather than faster. Draw the line by viewport probability: anything that paints in the first screen loads eagerly, and only content the user may never reach is deferred.

Triage every script by what depends on it: render-critical code stays inline and tiny, anything the first paint does not need is deferred, anything used only after an interaction loads on demand, and unused tags get deleted.

Streaming sends the <head> immediately, so the browser parses it and starts downloading CSS, fonts and scripts while the server is still querying. The query time, the byte count and the work the browser must do are unchanged.

A request priority is the browser's internal ranking of how urgently it thinks each resource is needed. Bandwidth and connections are limited, so the browser issues and services top-ranked requests first — download order follows that ranking, not markup order.

A skeleton improves perceived speed: it shows the page's structure immediately, so the wait feels shorter and more predictable. It does not make data arrive any sooner, and a skeleton whose size differs from the real content causes the page to jump.

Built-in lazy loading is free, needs no JavaScript and works before scripts run, so it is the default for ordinary offscreen images and iframes. A custom IntersectionObserver is worth it when you need your own trigger distance, placeholders, or to defer something the browser cannot — background images, video, components or data.

Browsers rank a request first by resource type — render-blocking CSS and blocking scripts at the top, fonts high, images and async scripts low — and only afterwards by position. Viewport position is applied late, because the browser cannot know an image is visible until layout has run.

Priority is a relative ranking, not extra bandwidth. Marking twelve requests urgent flattens the ordering back to roughly what it was, while discarding the browser's own sensible demotions — so nothing is served sooner and some genuinely low-value work now competes with the critical path.

Preconnect the two or three origins that serve something needed early — it pays DNS, TCP and TLS up front. Use dns-prefetch for origins used later; it resolves DNS only and costs almost nothing. Preconnecting everything wastes connections and contends for bandwidth.

Fonts are always fetched in anonymous CORS mode, so a preload without the crossorigin attribute produces a request the real font request cannot reuse, and the file downloads twice. The as attribute sets the request's destination, priority and Accept header.

Inline only code that must run before the first paint and is small enough that a separate request would cost more than the bytes — a few hundred bytes at most. Inlined code cannot be cached separately and ships with every HTML response.

Stream a placeholder element where the slow widget belongs, continue writing the rest of the page, then send the widget's real markup in a later chunk with a small inline script that moves it into the placeholder.

Inlining critical CSS removes the render-blocking stylesheet round trip, so the page can paint from the HTML response alone. The costs are uncacheable bytes on every response, extraction that drifts out of sync with the templates, restyling if the wrong rules were picked, and Content-Security-Policy friction.

A critical request chain is a series of render-blocking requests where each one is discovered only after the previous response is parsed. Depth costs a round trip per link regardless of size, so the same bytes fetched in parallel arrive far sooner.

Replace each embed with a lightweight facade — a static thumbnail or button that looks like the widget — and create the real iframe only when the user interacts or scrolls close. The trade is one extra interaction and a visible wait before the widget becomes usable.

Priority ranks requests the browser already knows about; it cannot rank one that has not been discovered. A CSS background image is invisible to the preload scanner and is requested only after the stylesheet downloads, parses, and an element matches — so the fix is shortening that discovery chain, with priority as the follow-up.

Preload is a mandatory high-priority fetch, so fourteen of them jump the queue ahead of the resources that determine first paint and share the same finite bandwidth. Keep only hints for critical resources the browser would otherwise discover late.

Deferring changes when JavaScript runs, not how much runs. All that execution now lands in one burst right after the page paints, occupying the main thread exactly when the user starts interacting. Only shipping or running less code reduces blocking time.

A script the page must fetch and run before it renders makes your availability depend on the vendor's: if their server hangs, the browser waits until the request times out. Containment means never letting third-party code sit on the critical path, and capping anything that gates visible content.

Compare time to first byte with total transfer time for the document at each hop — browser, CDN, reverse proxy, origin. Whichever hop is the first to report them as nearly equal is the one buffering the response.

The gap is client-side JavaScript downloading, parsing and executing to attach behaviour to the server-rendered markup — work that occupies the main thread, so clicks queue. Hydrating progressively splits that work per region and defers most of it until each region is needed.

Evaluate it by proving from field data that render-blocking CSS actually dominates first paint, sizing the ongoing maintenance of per-template extraction, comparing it against cheaper fixes such as per-route stylesheets, and deciding who owns it when it drifts.

Set a per-page script budget expressed as a measured cost with a named owner and a real consequence when it is exceeded, require every tag to carry an owner, a stated purpose and a review date, and give marketing a fast approved path so governance does not become a queue.

modulepreload fetches the module, parses it and puts it in the module map ready to evaluate, and browsers may follow its static imports to fetch the dependency graph too. A plain script preload only stores raw bytes and never looks at the imports.

content-visibility: auto tells the browser to skip style, layout and paint work for a subtree while it is far offscreen, rendering it only when it nears the viewport. Without contain-intrinsic-size the skipped element measures as empty, so the page height and scrollbar jump as sections render.

A 103 Early Hints response is sent before the real response and carries Link headers with preload or preconnect, so the browser starts fetching assets and warming connections while the origin is still generating HTML. It pays only when server think-time is genuinely long.