Render Tree

The render tree describes the DOM content that participates in visual rendering, together with the computed styles needed to render it. It is derived from the document structure and style information, and it can differ from the DOM tree because not every DOM node produces visual output.

The browser first parses HTML into a DOM tree and processes CSS into style information. It then determines which nodes participate in rendering and combines those nodes with their computed styles to form the render tree.

A render-tree entry generally contains the information needed to determine how an element should appear, such as its computed display behavior, dimensions-related properties, colors, and other applicable styles. Text that is rendered also contributes to the visual representation.

The render tree is not necessarily a one-to-one copy of the DOM. For example, an element with `display: none` does not participate in the render tree, while an element with `visibility: hidden` still occupies layout space and therefore remains relevant to rendering and layout.

After the render tree is available, the browser can perform layout, determining geometric information such as positions and sizes, and then paint the visual output. Modern browser engines may optimize or organize these stages differently, so the render tree should be understood as a conceptual model rather than a promise about a specific internal data structure.

Changes to DOM structure or styles can cause the browser to update the rendering-related structures. The amount of work depends on what changed; some changes require layout and repaint work, while others may affect only painting or later compositing.

Key points

• The render tree represents content that participates in visual rendering.
• It combines render-relevant structure with computed style information.
• `display: none` removes an element from rendering and layout participation.
• `visibility: hidden` keeps the element's space while hiding its contents.
• The render tree is followed conceptually by layout and painting.
• The DOM tree and render tree are not necessarily identical.

Interview questions

What is the render tree?

The render tree is a browser rendering concept that represents content that participates in visual output, along with the computed styles needed to render it. It is derived from the DOM and CSS information. Unlike the DOM, it does not necessarily contain every node because some nodes do not produce visual output. The browser uses this information as part of the process leading to layout and painting.

Does every DOM element appear in the render tree?

No. Some DOM nodes do not participate in visual rendering. A common example is an element whose computed `display` value is `none`, which is excluded from layout and rendering. Other DOM constructs, such as purely structural or non-visual content, may also not correspond directly to a rendered object. Therefore, the DOM and render tree should not be assumed to have a one-to-one relationship.

What is the difference between `display: none` and `visibility: hidden`?

`display: none` makes the element not participate in layout, so it does not occupy space in the rendered page. `visibility: hidden` hides the element while preserving its layout space. This distinction matters when reasoning about both rendering behavior and layout changes. Changing between these states can therefore have different consequences for surrounding elements.

Where does the render tree fit into browser rendering?

Conceptually, the browser parses HTML into the DOM and processes CSS, then determines the render-relevant content and computed styles. The resulting rendering structure is used during layout to determine geometry. The browser then paints the visual representation and may perform additional compositing work. Exact implementation details vary between browser engines, so these stages are best treated as a conceptual pipeline.

Why can changing CSS have different performance costs?

Different changes invalidate different parts of the rendering process. A change that affects geometry can require layout recalculation and may cause subsequent painting work. A change that affects only visual appearance may avoid a full layout pass but still require repainting. Some properties and browser optimizations can allow work to be handled later during compositing. The actual cost depends on the property, affected elements, and browser implementation.