How CSS Is Rendered: Unveiling the Critical Rendering Path

CSS is a magical yet quirky force that controls everything we see on a web page; while it should be simple, writing scalable, high‑performance CSS is not easy.

Whether you view CSS as a necessary pain or a misunderstood tool, it remains a skill every web developer must master, and the depth of your CSS knowledge determines whether your site looks polished or plain.

This article is the first in a series that dives deep into CSS. By lifting the veil on CSS, we can write faster, cleaner, more beautiful styles that scale with our applications.

We will examine how CSS is rendered to the screen after a page’s initial load.

We care about CSS rendering for two reasons: load time and user retention.

Create the DOM from the received HTML.

If CSS (inline or external) is encountered, start building the CSSOM.

If a non‑async JavaScript is encountered, pause DOM construction until the CSSOM is built, then parse and execute the script.

Understanding how CSS influences the critical rendering path is crucial because unoptimized CSS can significantly increase load time.

HTML and the Critical Rendering Path

HTML is a blocking resource; the browser cannot render any content until the HTML is fully parsed.

DOM is a tree‑like structure that represents all HTML nodes. Each node contains data such as attributes, id, and class. The indentation of HTML mirrors the DOM structure.

From the critical rendering path perspective, HTML is a key resource that blocks rendering until it is fully parsed.

Creating the CSS Object Model

When the browser encounters a CSS stylesheet—whether inline or external—it parses the text to build a data structure called the CSSOM.

The CSSOM is constructed by parsing all selectors and inserting them into a tree at the appropriate positions; single selectors go under the root, while nested selectors are placed under their parent nodes. The parser traverses selectors from right to left to ensure correctness.

Parsing CSS into the CSSOM, like building the DOM from HTML, blocks rendering; starting to render before the CSSOM is ready would cause a flash of unstyled content.

Render Tree

The browser combines the DOM and CSSOM to create a render tree, which contains only the information needed to paint pixels on the screen. Invisible elements such as <script> tags and elements with the hidden attribute are removed.

The browser then walks the CSSOM, matches CSS selectors to nodes in the render tree, and applies the matching rules. An exception is the display: none; rule, which removes the matched node from the render tree entirely, whereas opacity: 0; keeps the node but makes it invisible.

Once the render tree is built, the browser can safely and precisely render the page.

Sprint Phase: Layout and Paint

With the complete render tree, the browser proceeds to layout and paint. Layout calculates positions and sizes using CSS properties such as margin , padding , width , and position , traversing the tree from top to bottom.

If you are familiar with the CSS box model, layout essentially draws a series of CSS boxes on the page.

After layout comes the paint phase, where the content is actually drawn to the screen, producing the first‑paint time. The browser traverses non‑layout CSS rules and fills the CSS boxes, ensuring each layer is painted in the correct order.

Some CSS properties, like radial-gradient , are more expensive to render than solid colors; reducing such costly rules can noticeably improve performance.

Why Care About CSS in the Critical Rendering Path?

Optimizing FPS or running A/B tests is futile if users leave before the page finishes loading. Knowing the steps the browser takes to render the first pixel is essential for improving load speed.

Since CSS blocks rendering until the CSSOM is built, removing non‑critical CSS from the initial HTML can dramatically reduce the time spent constructing the CSSOM and the render tree.

Non‑essential CSS can be lazy‑loaded after the first paint, which is especially important for single‑page applications where unseen CSS would otherwise impact performance.

Understanding how the CSSOM is built also helps you write more performant selectors; avoiding deep nesting reduces selector‑matching overhead, though in most applications selector performance is not the primary bottleneck.

Before modifying CSS, analyze load time using Chrome’s Performance panel. Look at events such as Recalculate Styles, Layout, and Paint to identify bottlenecks and target optimizations effectively.