Perceived Web Performance – What is Blocking the DOM?

blocking the DOM

When it comes to web performance and optimizing speeds on a page-level basis it is very important to understand the relationship between HTML and how a page is actually constructed in your browser, so that you can pinpoint delays in page loads due to render blocking. In this post, we will dig deeper into what is blocking the DOM and ways you can prevent it from happening.

What is the DOM?

The DOM is an acronym for Document Object Model. It is a programming interface for HTML and XML documents and provides a structured representation (node tree) of a document, defining ways it can be accessed and manipulated using scripting languages such as Javascript. A node tree is made up of different elements, parents, children, siblings, etc. and they all have a hierarchical relationship with each other. Below is an example of an HTML DOM.


HTML DOM Source: SitePoint

DOM in Laymen Terms

To put it simpler, when you are using a tool like Chrome DevTools, this is showing you a visual representation of the DOM. Your plain HTML is not the DOM, Chrome DevTools shows you the DOM after it has been manipulated, by HTML or Javascript. You can also think of it as the parsed HTML.

What is Blocking the DOM?

When it comes to analyzing the speed of your web pages you always need to take into consideration what might be blocking the DOM, causing delays in your page load times. These are also referred to as render blocking resources, such as HTML, CSS (this can include web fonts), and Javascript.

One of the easiest ways to see what is currently blocking the DOM is to use Chrome Devtools and PageSpeed Insights. In our examples below we are using the latest developer tools in Chrome Canary.

  1. Launch developers tools in Google Chrome.
    • Windows: F12 or also Ctrl + Shift + I
    • Mac: Cmd + Opt + I
  2. Browse to the “Network” panel and refresh the page by pressing Ctrl + R (Cmd + R).
  3. You will now see a waterfall with load times. There are two things we want to look at here, first is the total DOMContentLoaded, which is 342ms and then also the resources that are before (left of) or touching the blue line.

Since we know CSS and Javascript are both render blocking resources, and they are loading before/on the blue DOMContent line, we can assume they are blocking the DOM. Remember, images aren’t render blocking so if you have images on the blue DOM line you can safely ignore those; although you will still want to optimize your images. In this example below we can see that the style.css file and the jquery.min.js file are both blocking the DOM.

You can also verify this information by running it through Google PageSpeed Insights. As you can see below it confirms both of these files are render blocking.

Follow the recommendations below on how you can prevent your CSS and Javascript from blocking the DOM by optimizing your critical rendering path. While HTML is also a render blocking resource, the DOM can be built incrementally.

Note, it is not always necessary to go for that 100/100 score on PageSpeed Insights. For example, if you link to a Google web font using their external stylesheet this is always going to be a render blocking resource, no matter what you do. The important thing is to recognize how to fix them so that on larger sites when you are dealing with 10+ files blocking the DOM you understand what is causing delays and have strategies in place to more efficiently load them.


Non-Render Blocking CSS

If you are going for completely non-render blocking CSS then you really only have one good option, and that is to inline your CSS. You include the CSS required for the initial rendering, typically styles for the above-the-fold content, directly in the HEAD section in the <style></style> elements and move the rest of your CSS to the bottom before the </body> element. This will prevent render blocking.

Inline CSS plugins for automated task systems

You could also load your CSS using Javascript, but then you will deal with the page having to repaint at the end of the load, which is not always ideal for the visitor.

As you can see in Chrome Devtools we now inlined our CSS and the DOMContentLoaded was slightly faster at 279ms.

And now when we test it in Google PageSpeed Insights we no longer have our render blocking CSS.

While this is great, it all depends upon your site. Most sites will not want to inline all of their CSS because depending upon how much CSS you have this could significantly increase the download size of that page. For smaller sites or even possibly landing pages inlining CSS thought could be a good alternative if you are wanting to avoid render blocking completely.

Our CSS Recommendations

Even on our KeyCDN homepage we have one render blocking CSS file. However, there are things we have done to improve the load times of our CSS. Below are some recommendations.

  1. Properly call your CSS files
  2. Use media queries to mark some CSS resources as non-render blocking
  3. Lessen the amount of CSS files (concatenate your CSS files into one file)
  4. Minify Your CSS (remove extra spaces, characters, comments, etc)
  5. Use less CSS overall

Minify CSS plugins for automated task systems


Non-Render Blocking Javascript

When it comes to Javascript there are some best practices to always keep in mind.

    1. Move your scripts to the bottom of the page right before your </body> tag.
    2. Use the async or defer directive to avoid render blocking.

Loading Javascript Asynchronously

Async allows the script to be downloaded in the background without blocking. Then, the moment it finishes downloading, rendering is blocked and that script executes. Render resumes when the script has executed.

<script async src="foobar.js"></script>

Deferring Javascript

The defer directive does the same thing, except it guarantees that scripts execute in the order they were specified on the page. So, some scripts may finish downloading then sit and wait for scripts that downloaded later but appeared before them.

Patrick Sexton has a good example of how to defer loading of javascript properly.

  1. Less the amount of Javascript files (concatenate your JS files into one file)
  2. Minify your Javascript (remove extra spaces, characters, etc)
  3. Inline your javascript if it is small

Minify Javascript plugins for automated task systems

By moving our javascript to the bottom and adding the async directive we were able to get the DOMContentLoaded down significantly to 144ms. As you can see the jquery.min.js file now appears after the DOM blue line.

In Google PageSpeed Insights after we loaded our javascript asynchronously, it is no longer considered render blocking and we were able to achieve a 100/100 score.

Web Fonts

Web fonts can also be a render blocking resource as they are loaded with CSS.  You really have two choices, either block the render or repaint later (then you have to deal with FOUT). For example, in Chrome (36+), Opera (23+), and Firefox there is a three-second timeout, after which the fallback font is shown.

There are a couple recommendations when it comes to loading fonts and optimizing the critical rendering path.

  1. Use a web font loader or font loading API
  2. Optimize font loading with inlining
  3. Use other storage methods such as localStorage

See our post on analyzing web font performance to see a more in-depth explanation of the different options you have for loading web fonts so you avoid render blocking and FOUT/FOIT.


So hopefully now you understand a bit better what it means when you hear the term, blocking the DOM, and how the construction of the DOM tree can be delayed by render blocking CSS Javascript, and even web fonts. Remember it might not always be possible to score that 100/100 on PageSpeed Insights, the important thing to understand is how your render blocking resources block the DOM and how you can properly optimize and deliver them for faster page speeds.

Related Articles

Perceived Web Performance – What is Blocking the DOM? was last modified: January 11th, 2017 by Brian Jackson
  • Great article.

    Not always possible to stick JS in footer. Depending on theme used. For many modern premium themes like ThemeForest The7 as example or others, site style can break. Or the mobile responsive menus may not work. This kind of thing needs very careful testing.

    Some CSS minifications can ruin a site as well. Some file may need to be excluded – dep on how minification is done.

    For WordPress users there are some excellent caching plugins – if one is not caching on server level. We tried many on various sites we have and my personal favorite for easiest setup, great overall performance and usually perfect css and JS minification is ZenCache Pro plugin.
    However, I recently got WP Rocket plugin to test it out on our new site and it out performed in speed the ZenCache one, though it needed some time to get the minification exclusion right without breaking site. They also enable on a per-page basis to exclude what to minify.

    • Thanks Eileen! Yes, whenever you are optimizing CSS and JS files, testing is always going to be required, especially when it comes to concatenation and minification. My advice would be to take them one by one, which takes some time, but in the end the performance benefits are worth it. You might also enjoy our Speed Up WordPress post:

  • mik_123

    Will putting the render blocking javascript and css on a CDN cache help solve the render-blocking issue?

Share This