Understanding how the browser loads and renders a web page is the key to improving your page loading speed.
The browser needs to construct the render tree to start rendering the page. To create the render tree the browser has to create the DOM (Document Object Model) tree and the CSSOM (CSS Object Model) tree first.
So, the render tree = DOM tree + CSSOM tree.
If we can make creating these trees faster, we make the page load faster.
Before learning how to make the page load faster, let’s see how the browser loads the page.
It’s worth mentioning that the steps the browser takes to load and render a page is called critical rendering path.
The loading steps
When you visit a site, the browser starts by requesting the HTML of the page. The server takes its time to prepare the HTML code and send it as a response. The server might send it in chunks (each one 14KB), but the browser does not have to wait until all the HTML is sent as a whole.
Once the browser receives the first chunk, it starts parsing the HTML. This means that the parsing process is incremental. The browser parses the HTML character by character to convert them into tokens. Tokens include things like start and end tags along with their attribute names and values.
Parsing the HTML involves the process of building the DOM tree. The DOM tree shows the elements in the document as well as the relationship between them. As a random example, the DOM tree can show that the BODY tag has two children: H1 and P. The H1 has class="title" and a TextNode Hello World.
As the browser is parsing the HTML, it will encounter some external resources such as JavaScript, CSS, images, etc. The loading process is different for each one. For example, loading JavaScript forces the parser to stop and wait until it’s loaded and executed, but for CSS or images, it can continue parsing while they are being downloaded.
By the time the browser has finished parsing the HTML, it should have the DOM tree constructed. But, it has to wait for the CSS to load to construct the CSSOM tree so it can build the render tree and start rendering the page.
Now we know what steps the browser needs to take to start rendering the page. Let’s take a step back and learn how the loading and parsing of the CSS and JavaScript is done so we know how we can optimize them.
Loading the CSS
CSSOM tree has to be built before the browser starts rendering the page. To build it, the browser has to parse the CSS first. I said parse and not load because your CSS can be inlined (in a <style> tag).
CSS is render-blocking, which means you can’t start rendering the page until it’s parsed. But it’s not parser-blocking, which means the browser can continue parsing the HTML while the CSS is being downloaded (if it was linked externally).
The main takeaway here is that the larger your CSS file is the longer it will take to start rendering the page because it’s a render-blocking resource.
Loading JavaScript
JavaScript is a parser-blocking resource. This means once the browser finds any JavaScript code, it will stop parsing immediately to download and execute the JavaScript. After the JavaScript is executed, the parser can continue parsing the document.
So JavaScript can delay rendering because the browser can’t complete building the DOM until it has parsed the HTML.
JavaScript has to wait for CSSOM
To make things even worse, your JavaScript code can’t start executing if there’s CSS being downloaded. In other words, if you have <link rel="stylesheet" href="/style.css> above your JavaScript code, then the browser has to wait for that CSS file to download and for the CSSOM tree to be built before starting executing the JavaScript code, which means it will delay building the DOM, which consequently delay the rendering.
Optimizing your page load time
Now we get to the fun part; making our pages load faster.
Getting into the details of each technique is beyond the scope of this article, but I will give you a quick overview of each one. After that, it should be easier to learn more about each one on your own.
Only load the used/critical CSS
Most of the time we load CSS that we don’t need in the current page. So, we can split the CSS file into smaller ones and use each one based on what the current page needs.
A common case we can apply this to is loading some third party CSS code only in the pages that need them. For example, only use the code syntax highlighter CSS library on the pages that display code.
There’s also a well-known technique called critical CSS. It’s used to load only the CSS code that you see above the fold (the visible part of the browser on the initial load), and then lazy-load the rest asynchronously. And you can make this even better by inlining the critical CSS and lazy-load the rest externally.
Loading JavaScript asynchronously
Two popular attributes to achieve this: defer and async. Using either will not cause the browser to wait until they are downloaded to continue parsing.
The main difference between them is the time and order of execution.
Defer scripts start executing after the whole DOM is constructed but before DOMContentLoaded event is fired. This also means you should see the page rendered before executing the script.
Defer scripts execute in the order they were defined. So if script1 is above script2, script1 will always start executing before script2 even if script2 is loaded before.
Async scripts will start execute as soon as they are fetched. Async scripts don’t wait for the DOM to be constructed, which means they can block the parser if an async script is fetched before the DOM is built.
Async scripts execute in the order they were fetched. The one that loads first executes first.
The rule of thumb is to use defer scripts when they depend on the content (DOM) of the page, and use async scripts for things that don’t need the DOM such as analytics, etc.
Minify and compress resources
There are many build tools that help you minify your CSS and JavaScript. Minification is the process of removing any unnecessary characters for execution like spaces, comments, etc.
Compressing your resources is done by the server. gzip and brotli are the most popular compression types nowadays.
Minifying and compressing your resources will make them much smaller, which will improve your loading time.
Preloading important resources
The browser fetches the resources as it finds them while parsing the HTML. Sometimes it would be useful if we request these resource as soon as possible even before the parser finds them.
An example would be having two synchronous external JavaScript files below each other. If we don’t use preload, then we have to wait for the first script to load and execute before loading the second one. But with preload we can tell the browser to fetch that second script even while it’s parsing the HTML.
Preloading is also used for fetching other resources like CSS, images, fonts, etc.
Preloading can be done with <link>. Example:
<link rel="preload" href="style.css" as="style" />
<link rel="preload" href="main.js" as="script" />
Reduce your server response time
No matter how many optimization you do to your client code, it will not make your page load faster if your server takes a long time to send the requested HTML code.
Usually this is the least we can control especially if we don’t maintain the backend code. But if we do, we can do things like optimizing the database queries (how fast we pull data from our database), using caching, compressing and minifying responses, upgrading the server hardware, etc.
Now you can learn more
In this article we barely scratched the surface of loading performance optimizations. But it should be easier now to dive deeper into each one as you should have a full understanding of how the browser loads pages.
An important part we didn’t touch in this article is the tools we can use to measure the performance of the page and the impact of the optimizations we do. Google Chrome provides us with two good tools for this: the performance tab in the devtools and Lighthouse. So I encourage you to check them on your own.