- The Document Object Model (DOM) is created as the HTML is parsed.
- The HTML includes or makes requests for styles, which in turn builds the CSS Object Model (CSSOM).
- The browser engine combines the two to create the Render Tree.
- Layout determines the size and location of everything on the page.
- Once layout is determined, pixels are painted to the screen.
A Web page is a document. This document can either be displayed in the browser window or as the HTML source.
The DOM represents the document as nodes and objects. That way, programming languages can connect to the page. How are these nodes generated? Let's look into that next.
The browser requests the HTML Document from the server or local file system which is read as a sequence of bytes and converts them into recognisable characters. These characters go through a process of tokenisation in the browser to produce tokens (startTag tokens and endTag tokens) which are the final input to generate the DOM Nodes. A lexical analyser of some sort in the browser is responsible for converting said tokens into nodes. A node starts with a startTag token and ends with an endTag token and contains all relevant information about the HTML element described by the tokens.
The final DOM Tree is constructed(incrementally) by connecting the nodes based on token hierarchy.
The CSS Object Model (CSSOM) is a map of all CSS selectors and relevant properties for each selector in the form of a tree, with a root node, sibling, descendant, child, and other relationships and is similar to the DOM. But it is also different.
While the DOM is constructed incrementally, the CSSOM is not and is render-blocking because CSS rules can be overwritten, so the content can't be rendered until the CSSOM is complete.
Due to the Cascading nature of CSS, the CSSOM can not be constructed incrementally because subsequent rules may be overwritten and as a result, the CSS Object Model gets built as the CSS is parsed, but can not be used to build the render tree until it is completely parsed by the web browser.
The Render Tree is the combination of both the DOM and CSSOM trees. To construct the render tree, the browser checks every node, starting from the root of the DOM tree and determines which CSS rules are attached to each DOM Node. Through this process, the render tree only contains nodes and styles required by the page (visible content).
<header> is in most cases not included in the render tree as it does not usually contain any visible content. Also, any HTMLElement with it's
display set to
none, is not included in the render tree as well as all it's children elements.
Once the render tree is built, laying out a web page becomes possible and the process is dependent on the size of the screen. This stage calculates the exact position and size(height & width) of DOM Nodes in the viewport.
The viewport meta tag defines the width of the layout viewport, which impacts the layout. Without it, the browser uses the default viewport width to lay out the web page, which is generally 960px for full-screen browsers. By setting
<meta name="viewport" content="width=device-width">, the width will be the width of the device instead of the default viewport width of the browser (such as your phone browser). The
device-width changes when a user rotates their phone between landscape and portrait mode. Layout happens every time a device is rotated or browser is otherwise resized.
Performance of the layout stage is affected by the DOM as the more the number of nodes in the DOM tree, the longer it takes to layout a web page.
It is also known as the Reflow Stage because layout is also done when the browser re-calculates the positions and dimensions of elements in the document, for the purpose of re-rendering part or all of the document. This process of re-calculation and re-rendering by the browser is known as 'Browser Reflow' and is a user-blocking operation i.e it prevents the user from interacting with the web page while the browser is re-calculating and re-rendering the document. Hence, minimising the number of browser reflows needed by a web page improves performance also.
The last step to rendering a web page is to paint the pixels onto the viewport according to the box model (yeah, the nifty diagram in our DevTools). After painting, only impacted areas of the screen will be repainted, as browsers are optimised to repaint the minimum area required. But paint times differ from scenario to scenario so, it is advised to account for it (and layout time) when improving performance on the web (and deciding how long those animations should take 😏).
We can improve rendering performance and in extension page load by prioritising which resources get loaded, controlling the order in which they are loaded, and reducing the file sizes of those resources. Performance tips include:
- Minimising the number of critical resources by deferring their download, marking them as async, or eliminating them altogether (know more),
- Optimising the number of requests required along with the file size of each request (know more), and
- Optimising the order in which critical resources are loaded by prioritising the downloading critical assets, shorten the critical path length.
There is a request from a client/user,
The web browser Parses HTML document and builds the DOM Tree,
It checks for and Parses CSS documents and builds the CSSOM Tree,
It Combines DOM and CSSOM Tress into a Render Tree,
Builds a Layout from the Render Tree by computing the position and size of each node,
Paint nodes on the screen based on box model.
In summary, the browser goes through some processes to display a website page, to make this process efficient, it is important to go through the points mentioned above which will have a positive impact on user experience and maximise web performance.
Until next time, keep building great web applications. 🙋