Critical rendering path

What it means

HTML supplies document structure, represented by the DOM, while CSS supplies style information, represented by the CSSOM. The browser uses structure and styles to determine what to render, calculate layout, and paint pixels. These are distinct stages, not a single download timer.

A dependency gate is a simpler idea within that process: it opens only when every selected prerequisite is ready. Here, the relevant HTML and one required render-blocking stylesheet are assumed to be prerequisites for an illustrative paint. “Relevant HTML” does not mean that the entire document must finish loading.

Try it

Simulation: change CSS ready at (ms) from 300 to 50, leaving Relevant HTML ready at (ms) at 100. Inspect the recalculated result, then select Compare with baseline to see the two outcomes together. Editing either input clears an existing comparison; you can compare again after the edit.

These controls only recalculate a local example; they do not inspect or change your site. Without JavaScript, the initial example and explanation remain readable, but changing inputs and comparing require JavaScript.

Earliest illustrative paint gate: 300 ms. At the initial values, the selected CSS becomes ready later than the relevant HTML, so CSS determines this two-prerequisite gate. The result is not an observed browser paint time.

Keep Relevant HTML ready at (ms) at 100. The shared starting point and the assumption that both selected inputs are required stay unchanged; additional rendering work is outside the model.

Reset restores CSS ready at (ms) to 300 and Relevant HTML ready at (ms) to 100, removes input errors, and clears the comparison. It does not change whether you have opened or closed individual FAQ answers or About this model.

How it works

The lab compresses the rendering process into one prerequisite check: the selected CSS and the relevant HTML must both be ready. It uses their supplied finish times; it does not derive those times from file sizes, transfer speeds, or parsing work.

The rule is:

gate time = max(CSS ready time, relevant HTML ready time)

The later prerequisite determines when both conditions have become true. Passing that gate does not perform layout or paint; it only removes the two waits represented here. Real resource discovery, parsing, script execution, layout, and painting can add or overlap work.

The rule is symmetric. If CSS is ready at 100 ms but relevant HTML is ready at 400 ms, the illustrative gate is 400 ms. CSS is not automatically the limiting dependency just because the example includes a render-blocking stylesheet.

Worked example

This is a synthetic baseline, not a captured browser trace. Both ready-at times use the same assumed starting point.

At 100 ms, the HTML prerequisite is ready, but the CSS prerequisite is not. The gate therefore remains closed. At 300 ms, both selected prerequisites are ready, producing Earliest illustrative paint gate: 300 ms. The interval between those points illustrates waiting for CSS, not 200 ms of measured browser execution.

What changes when the condition changes

Change CSS ready at (ms) from 300 to 50, keeping Relevant HTML ready at (ms) at 100. The result becomes Earliest illustrative paint gate: 100 ms.

CSS is now ready first. Between 50 and 100 ms, the model is waiting for HTML rather than CSS. Moving CSS readiness 250 ms earlier therefore moves the gate only 200 ms earlier, from 300 to 100 ms. Making CSS ready even earlier would not move this gate while HTML remains fixed at 100 ms. This overturns the assumption that every reduction in CSS readiness time produces an equal reduction in paint time.

In practice

For a page you own or are authorized to investigate, begin with read-only inspection of a representative browser performance trace. Choose the visible content you want to understand, then look for evidence of whether required resources were still unavailable or execution work remained before rendering. A resource finishing late is not, by itself, proof that it blocked that content.

The useful distinction is dependency waiting versus work still being performed. Required styles that are not ready and a busy main thread are different conditions; reducing a download will not necessarily address both.

STOP before choosing a loading change if the recording does not establish which dependency or task held the target content back. Collect clearer evidence rather than removing required CSS or changing script loading based on this simulation. This page provides no asset-splitting or loading-attribute change procedure. When comparing real observations, keep the page, target content, and test conditions comparable, and check the actual rendering outcome.

Limits and unknowns

Only synthetic finish times are evaluated; there is no real browser scheduling or main-thread execution. The model assumes that both selected inputs are prerequisites. It does not discover which resources a real page needs or calculate when those resources become usable.

For valid inputs, the result is a gate time—not a predicted first-paint or LCP timestamp. The real rendering time remains unknown without observations of the actual page. Even a gate of 0 ms would mean only that the two supplied prerequisites are ready at the assumed starting point, not that the browser paints instantly.

If the current input is invalid, the lab removes the calculated outcome rather than continuing to display a result from an earlier valid input. Correct the value or use Reset before interpreting another result.

What to carry forward

A faster resource helps a rendering milestone only if it removes a dependency that was holding that milestone back. Once another prerequisite becomes the limiting one, further improvement to the earlier resource may not move the result. Use that rule to guide what you investigate, then verify the actual rendering outcome rather than treating the simulated gate as a performance measurement.