Skip to content

Chapter 2 of 8

The Critical Rendering Path and Resource Loading

To act on performance you have to understand the path the browser walks from bytes to pixels. The critical rendering path is the sequence in which the browser parses HTML, builds the CSSOM, combines it with the DOM into a render tree, lays the tree out, paints pixels, and finally composites layers onto the screen. Anything that delays any of these steps delays first paint. Synchronous JavaScript in the head of the document and stylesheets that the page must use both block this path. Moving scripts to the end of the document or marking them with the defer or async attributes keeps the browser from waiting on them.

The two script attributes behave differently and choosing between them is a frequent performance lever. With defer, the browser downloads scripts in parallel with HTML parsing and executes them in document order after parsing finishes, which is ideal for scripts that depend on one another or on the DOM. With async, downloads still happen in parallel, but execution happens as soon as each script is ready, out of order, which suits independent scripts such as analytics. Beyond script tags, resource hints let you shape what the browser fetches and when. Preload fetches a specific critical resource early without blocking parsing and is best reserved for assets the current page needs immediately. Preconnect opens DNS, TCP, and TLS to a domain you will use soon, while dns-prefetch is a cheaper hint that does only the DNS lookup. Prefetch grabs likely next-navigation resources at low priority, and modulepreload extends preload to capture an ES module's dependency graph.

Priority Hints give the browser more direct guidance. The fetchpriority attribute on a tag such as a hero image, combined with preload, ensures the LCP image starts downloading immediately. The HTTP layer also plays a role: HTTP/2 server push historically let servers send resources before the client requested them, but it has largely been deprecated in favor of 103 Early Hints, which let the server share preload links ahead of the main response without locking the client into receiving them.

Reducing the request waterfall is often as important as any individual optimization. Chained requests, where the browser discovers a needed resource only after parsing the response to a previous one, force sequential latency. Preloading the LCP image, preconnecting to third-party origins, and shrinking the dependency graph between the document and its critical assets collapse this chain and shorten the time to a fully usable page.

All chapters
  1. 1Foundations of Frontend Performance
  2. 2The Critical Rendering Path and Resource Loading
  3. 3Network, Compression, and Delivery
  4. 4Images, Fonts, and Media
  5. 5JavaScript Bundle Optimization
  6. 6CSS Performance
  7. 7Runtime Performance and Responsiveness
  8. 8Rendering Architecture, Tooling, and Long-Term Strategy

Drill it

Reading is not remembering. These come from the Frontend Performance deck:

Q

What is frontend performance?

Frontend performance is how quickly and smoothly a web application loads, renders, and responds to user input.

Q

Why does frontend performance matter?

It affects user satisfaction, accessibility, SEO, conversion, and perceived product quality.

Q

What is Time to First Byte (TTFB)?

TTFB measures how long it takes the browser to receive the first byte of the response after making a request.

Q

What is Largest Contentful Paint (LCP)?

LCP measures when the largest visible content element finishes rendering, indicating perceived load speed.