How does a browser create a web page?

As a technical SEO, it is important to understand how a browser creates a web page. This can help, later, to understand the difference between human and search-engine bot interpretations of a page, or to diagnose page speed issues, among other things. I’ll be looking at it with an eye to improving page speed.

This is the first of this series of 4 articles about the browsers’ phases of creating a page and its reflection on Pagespeed.

In order to display content, each browser must complete the DOM and CSSOM processes before creating the rendering-tree to create a web page.

DOM or Document Object Model is constructed from HTML markup. The DOM is a data representation of the elements that make up the structure and content of the web page. This representation is used by different programs, like JavaScript scripts, that might modify either the structure, the content, or both.

CSSOM is created by CSS MarkUp such as animation, keyframe, media queries along with selectors, properties and values semantically parallel to the DOM.

This is a screenshot from the first web browser of history. It can’t render Javascript and doesn’t have lots of CSS Properties. It can’t use modern HTML Rules also. Experiencing these kinds of primitive web browsers (such as Lynx) can help you to understand browser engines and their natures in terms of web performance. You may visit this page!

How is the DOM created by a browser?

No browser sees content or source code on a page as people do. First of all, it will see everything on the preDOM in bytes. It will then convert the bytes to specific characters and solve what they mean to form the page structure as a hierarchy.

Note: preDOM is the version of the DOM that appears in source code and has not yet been read and processed by the browser. The preDOM is then read and interpreted by the browser:

1. Using the ‘charset’ code of your file, the browser will convert the bytes to characters.
2. The ‘tokenizing’ process is initiated to create meaningful commands for adjacent characters.
3. Generated tokens are converted to objects and receive rules and properties according to HTML5 standards. (In other words, it converts them to nodes.)
4. The DOM Construction process is started. Each HTML tag is placed within one another, forming a hierarchy and creating the structure of the web page.

Improving DOM performance: Why is it so important?

Before I give you a few tips, you’ll need to understand the DOM Load Event types and their meaning.

Here are some of the DOM Event Types in web page creation

• domLoading: Starting point of DOM process.
• domInteractive: End of DOM process.
• domContentLoaded: End of DOM and CSSOM processes. At this point, the browser is ready to create the rendering tree. Also, JavaScript execution should usually start at this point.
• domComplete: Downloading of all of the page’s resources is completed.
• loadEvent: After finishing downloading resources and creating page structure, any existing “onload” JS events are triggered.

If you want to only calculate DOM Process Time, you should focus on the domInteractive event. However, this event is not shown in Chrome’s devTools. You may use or consult your IT team for PerformanceNavigationTiming API which can calculate all of these events, as well as additional subEvents such as domContentLoadedEventStart.

You can also look at domInteractive preferences in Google Analytics > Behaviour > Site Speed > Page Timings > DOM. However, the information here is not particularly stable and reliable. Still, it may give you a place to start.

You may also calculate DOM Interactive Timing with DevTools but only with console codes. It is a little bit of a slow method but you may try “performance.timing” code library. Above, you will see at the left side, performance.timing which shows most of the performance metrics. Only the last three or four digits are important here. If you want to see a custom metric, for example DOMInteractive, you can write performance.timing.domInteractive – performance.timing.responseStart. On the right, DOMInteractive, DOMComplete, Total Page Load Time are given respectively.
Example is from the same news site.

In this article, the domContentLoaded event and DevTools will be enough for our purposes.

Note that when resources are correctly organized and loaded, domInteractive and domContentLoaded times are not so different from each other. Because the real challenge is separating JS files and CSS files from one another without interrupting HTML parsing or creating a bottleneck in the main thread. If you can do this successfully, it is likely that both the DOM and the CSSOM (domContentLoaded Event) are fired in the fastest way.

An example DOM from a HTML Document

DOM process optimization and tips

If we were in 2019 and before, I might say that as a Technical SEO Expert, you don’t have to know how to code.

But in 2020 and beyond, you actually have to know some beginner level coding. To understand how to optimize a Document Object Model or an HTML Node structure, you need to examine it with enough experience to create a new code structure.

Here are some tips for optimizing DOM size:

1.  Examine existing DOM Node Tree and try to find any unnecessary HTML nodes. For example, if you see any or with a ‘display: none’ class, you should remove them.
2. You can advise your IT Team to use more ::before and ::after pseudo-elements instead of creating new HTML nodes.
3. Try to focus on big parent HTML elements with lots of child elements. Control your CSS Classes and their effects to create shorter HTML nodes while working to unify HTML elements.
4. If you call your HTML node structure with JavaScript, you also may use or advise your IT Team to use Subtree Modification DOM Change Breakpoints to determine which nodes are changing which initiator.
5. If you can’t shrink the HTML node size, then you may want to think about using Shadow DOM or, according to your JS Library and rendering technologies, you may be interested in Virtual DOM.
6. You should also consider gzip, brotli or deflate compression technologies on the server side.
7. You may compress your HTML documentation by deleting spaces for better and faster browser speed support.

Using Virtual DOM

You can use different DOM types for better page speed, UX and crawl budget. One example is Virtual DOM.

Virtual DOM loads only the parts of the DOM that change when a new page is opened, instead of reloading all of the DOM elements. This creates a faster and lighter page presentation for the user or search engine bot.

Virtual DOM works well with the JavaScript libraries Vue or React.

Why is DOM performance important for Technical SEO?

DOM size is directly related to page speed and to the initial contact with the user.

If you have a big DOM size and don’t use Shadow DOM or similar preventive methods to avoid loading and styling all of the HTML nodes that are not visible during the initial page load, you will probably delay your speed index and initial contact speed for user.

A short comparison between browsers for reflow processes.

If your DOM size is large, you will probably suffer from browser reflow.

Reflow refers to resizing, styling or painting and positioning an HTML Element in the re-rendering process. If an HTML parent element changes, the child elements are also affected. The length and count of this sort of HTML element chains can harm your page speed.

Reflow loops can harm your crawl budget, increase the load on the server and the network. It can consequently affect conversion rate and even rankings.

Google has actually published a nice and brief presentation video on this topic:

How does a browser create the CSSOM and rendering tree?

Browsers tend to start the CSSOM process after completing the DOM process.

Since modern browsers are aware that the DOM will not make any sense until CSSOM is completed, some HTML elements are not displayed by the browser until it has read the style codes. A good example of this would be the CSS background-image.

Above is an example of a CSS code snippet which needs to be refactored. ‘Zoom’ property is used more than 19 times for different selectors. They can be unified.

How is the CSSOM process started and completed by modern browsers?

1. The browser follows the bytes, characters, tokens, and standard rules (nodes) loop that is generated when the DOM is created.
2. The browser matches each DOM Element with the CSS element that will affect it. This process is called “Style.”
3. After mapping, the browser determines the dimensions of each DOM element according to CSS rules in a hierarchical structure. Since the size of the parent element also affects the child elements, hierarchically encoded CSS files are useful for page speed. This process is called “Layout.”
4. The Visual DOM process starts. All images, borders and colors are painted according to CSS rules. This process is carried out in different layers.
5. Composite is the final stage of CSSOM. The browser combines all of the painting operations in different layers.

You can check CSS properties and their costs to the browser engine via CSS Triggers in terms of different browser engines.

How to optimize the CSSOM process

1. As a Technical SEO, you should first focus on complex CSS selectors and mutual properties. In other words, if a CSS selector has more than 3 child elements, you should try to shorten it or you should report it to your IT Team for CSS refactoring. Mutual properties means that your IT Team may be using the same CSS properties on different classes and ids. You should try to unify them for smaller CSS file size.
2. Find out whether your IT Team compresses CSS files or not.
3. For each of your site’s categories and sections, try to find commonly used CSS code and commonly unused CSS code. Advise your IT Team to divide CSS files for better resource efficiency.
4. Search for important codes in your CSS files. They are probably making some subsequent code unnecessary.
5. Try to determine whether your CSS files have a parallel hierarchical structure with regards to your HTML nodes. If they are parallel, your rendering tree will be easier for browsers to construct.
6. Try to reduce the number of HTML elements that need to be restyled or resized. Images are a good example of this.
7. You may advise your IT Team to use ‘Contain’, ‘Will-change’, ‘CSS Scope’ features and properties for better browser performance.
   The ‘Contain’ property determines the scope of HTML element and the CSS effects which will it receive. This way it won’t affect the rest of DOM. The ‘Will-change’ property tells the browser which elements change and in what way so that the browser can make optimizations even before the process starts.
8. Try to inline critical CSS code before render blocking CSS Files.
9. Try to advise IT Team not to use style codes in HTML tags. This affects both DOM/CSSOM processes as well as crawl budget.
10. Don’t put your image source addresses into the CSS files. This is against Google’s indexing guidelines (Chrome DevSummit 2019, How to Make Your Content Shine on Google Search, Martin Splitt).
11. Don’t use @import feature in CSS files. This creates a nested second CSS request.
12. Try to use fewer external CSS files to shorten CSSOM or try to bundle them to decrease DNS lookup and resource connection times.
13. You can also check your long selectors and their specificity. If they are too long, you need to report them to your IT Team or you may try to improve them by yourself as a Technical SEO. Long selectors and repetitive unnecessary CSS properties with same values are heavy burdens for browsers and phone CPUs.
    

Remember, the CSSOM has a hierarchical tree just like the DOM. It applies the current rules to the largest element first, and the child elements remain affected until the browser reads the code written specifically for them.

In CSSOM, all CSS ID, Class and Properties and Value elements are listed according to the semantic structure of the HTML DOM elements. CSSOM is taken from the same HTML document as the DOM. The main reason I have not indicated HTML nodes in CSSOM is to draw attention to the hierarchical structure of CSS Codes.

How do browsers render a page?

Executing the CSSOM is not the same thing as rendering. When the DOM and the CSSOM are read in the same hierarchy, rendering is the process of joining these two code-trees from the top down in the viewport.

During rendering, some code snippets that exist during DOM and CSSOM processing may be disabled. The main reason for this is that they are not visible or are disabled by a different code. Therefore, optimization of code that is not included in the rendering tree but that appears in the DOM and the CSSOM is useful for page speed.

Above, the DOMContentLoaded data in Chrome’s DevTools shows the time it takes to load and parse the HTML and CSS documents.

Therefore, consistency between the performance main thread and call tree sections yield close results. All examples are from the same site.

If you want to calculate only DOM, you need to check domInteractive time, which is not shown by DevTools but can be measured with the Navigation Timing API.

After the DomContentLoaded event, your browser will start the rendering tree and you will see that pixels of your screens are colored with meaningful information and design. During this time, Javascript rendering will also come into play and will instantly split, change, and repaint the rendering tree.

What’s next?

A properly structured resource order, resource request count, and rendering-tree and Javascript rendering relationship reduce cost in terms of page speed.

The next article in this series will look at how this relates to advanced page speed metrics and how Google perceives page speed.