Critical Rendering Path

The browser parses the raw HTML bytes into characters, tokens, nodes, and finally a tree structure representing the document's content and hierarchy.

• Incremental Parsing: The browser builds the DOM incrementally, allowing it to start rendering before the full HTML is downloaded.
• Blocking Behavior: The parser halts when it encounters a synchronous <script> tag without async or defer attributes, as the script may modify the DOM via document.write.
• Tokenization: The tokenizer consumes the input stream and emits tokens (start tags, end tags, character data) that the tree construction algorithm uses to build the DOM.

The browser parses all external and inline CSS into a tree structure that maps selectors to their computed styles. Unlike the DOM, CSSOM construction is render-blocking and cannot be incremental.

• Cascade Resolution: The browser resolves the final styles for each element by applying the cascade, inheritance, and specificity rules.
• Complete Before Render: The browser must build the entire CSSOM before rendering any content because subsequent rules can override earlier ones.
• Media Query Filtering: Using media attributes on <link> tags (e.g., media='print') prevents non-matching stylesheets from blocking the initial render.

The browser combines the DOM and CSSOM to create the render tree, which captures only the visible content and its computed styles. Nodes with display: none are excluded entirely.

• Visibility Filtering: Elements with visibility: hidden occupy space in the render tree, while display: none elements are omitted.
• Pseudo-Element Inclusion: Pseudo-elements like ::before and ::after are added to the render tree as if they were real DOM nodes.
• Style Computation: Each render tree node receives its final, resolved CSS property values, converting relative units (em, rem, %) to absolute pixels.

The browser calculates the exact position and size of each render tree node within the viewport. This geometry computation produces the box model for every visible element.

• Containing Block: The position of each element is calculated relative to its containing block, which is determined by the nearest ancestor with a position value of relative, absolute, or fixed.
• Dirty Bit System: Browsers use a dirty bit system to mark elements that need layout recalculation, batching changes to avoid redundant reflows.
• Forced Synchronous Layout: Reading layout properties (e.g., offsetHeight, getBoundingClientRect()) immediately after a DOM mutation forces the browser to perform layout synchronously, causing jank.

The browser converts the layout geometry into actual pixels on the screen by rasterizing each render tree node into layers. This is the pixel-filling stage.

• Layer Promotion: Elements that will be animated or scrolled independently (e.g., transform, opacity, will-change) are promoted to their own compositor layers to avoid repainting.
• Paint Order: Elements are painted in the order defined by the stacking context, respecting z-index and the document's natural flow.
• Rasterization: The paint records are converted into bitmaps in a process called rasterization, which occurs on the compositor thread for GPU-accelerated layers.

The compositor thread assembles the painted layers into a final image for the screen. This is the only stage that runs on the GPU and can be performed without blocking the main thread.

• Layer Tree: The compositor maintains its own layer tree, which is a subset of the render tree, containing only elements promoted to their own compositing layers.
• Transform-Only Animations: Animations using only transform and opacity can run entirely on the compositor thread, achieving 60fps even when the main thread is busy with JavaScript.
• Tiling: Large layers are broken into smaller tiles that are rasterized and uploaded to the GPU independently, improving memory efficiency and scrolling performance.

The tree-like structure built by the browser from parsed HTML. Every element, attribute, and text node becomes a programmable object. The DOM construction is incremental—the browser builds nodes as it receives HTML chunks—but a render-blocking script halts construction until the script executes. The DOM is the structural backbone of the Critical Rendering Path; without a complete DOM, the render tree cannot be assembled.

A tree representation of all CSS styles applied to a document. Unlike the DOM, the CSSOM is not incrementally constructed—the browser must download and parse all CSS before building the final model because later rules can override earlier ones. This makes CSS a render-blocking resource. Optimization strategies include:

• Inlining critical, above-the-fold CSS directly in the <head>
• Deferring non-critical stylesheets with media attributes or rel='preload'
• Minimizing selector specificity to reduce computation time

The merged output of the DOM and CSSOM that captures only the visible content and its computed styles. The browser combines these two trees, discarding nodes with display: none and elements like <head> and <script>. The render tree is the direct input to the layout stage. Key characteristics:

• Each node contains its computed style (resolved CSS values)
• Pseudo-elements like ::before are added as separate nodes
• A deep or complex render tree directly increases layout and paint costs

The geometry calculation phase where the browser computes the exact position and dimensions of every render tree node. Layout is a recursive, top-down process that flows from the root element. It's one of the most expensive operations in the rendering pipeline. Triggers include:

• DOM manipulation (adding/removing nodes)
• Style changes affecting size or position (width, margin, padding)
• Browser window resizing
• Accessing layout properties like offsetHeight forces a synchronous reflow

The final visual output stages. Paint rasterizes each render tree node into pixels on multiple layers—filling backgrounds, drawing borders, and rendering text. Compositing takes these layers and assembles them in the correct order onto the screen. Compositor-only properties like transform and opacity can be animated without triggering layout or paint, enabling 60fps animations. Understanding the layer model is critical for avoiding jank and achieving smooth interactions.

A user-centric performance metric measuring the time from navigation to when the browser renders the first piece of DOM content—text, image, or non-white canvas. FCP is a direct reflection of Critical Rendering Path efficiency. Optimization targets:

• Eliminate render-blocking resources (critical CSS inlining)
• Reduce server response time (Time to First Byte)
• Avoid multiple page redirects
• Use text-based placeholders instead of loading spinners A fast FCP (< 1.8 seconds) signals to users that the page is loading.