WordPress Eliminate render blocking resources.
WordPress eliminate render blocking resources. In this post I’ll be talking about browser rendering, render blocking resources, what these are, why they’re a problem and how to eliminate render blocking resources in WordPress.
Before you can address render blocking resources, you’ll need to know what browser rendering is, what resources are used when rendering, and the rendering process itself.
You can skip to the part that covers how to deal with render blocking resources by clicking here but if you have the time, it would be worth reading this post in full to gain a greater understanding of this issue.
What is Browser rendering?
When a web page is requested by a browser, page output is served to the browser, and the browser turns this page output in to the page that you see in the browser. The “turns this page output in to the page that you see” part is rendering.
In the context of WordPress, when a web page is requested, the PHP that makes up your WordPress (WordPress core, the theme you’re using and all the plugins) is executed, this interacts with the site’s database, and the two between then generate page output. The page output that’s generated is then served to the requesting browser via the web server.
This is what browsers do. They turn page output in to the web page that you see. The purpose or browsers is to render page output in to something that’s readable by humans. There’s a much more in depth explanation of how a browser renders a web page in this post.
What gets rendered by browsers?
CSS (Cascading Style Sheet) is styling information (think along the lines of colours, fonts, text sizes, margins, padding, borders, and backgrounds). It’s very much related to HTML, and it is possible include CSS styling information within an HTML document, as well as using individual .css files that the HTML of the page calls. In the context of (pre-Wordpress) flat HTML pages, a single CSS file or a group of CSS files will referenced (or pointed to) in the HTML of a page to bring their styling in to effect for an entire site. These files can then be modified to alter the styling of a site as a whole. The idea being that updating one file makes more sense than updating all the HTML based pages individually. As WordPress generates page output, CSS being included on individual pages isn’t as much of a problem as the CSS can generally be universally updated within WordPress itself. Again CSS is more like a markup language (orientated to appearance and formatting) rather than containing logic control.
- Things that move (animations and sliders).
- Things that change with user interaction (drop down menus or buttons that change in appearance when you hover your mouse over them).
- Form validation (“you haven’t entered a valid email address” for example).
- Dynamic content (a change in appearance based on what a visitor does, or the size of the screen of the device).
- Dynamic generation of CSS (Google Fonts works like this)
- Captcha protection on contact forms (Google’s recaptcha works using this).
How browsers render page output.
I’m going to paraphrase this a bit in an effort to make it easier to understand. There’s a much more in depth explanation of browser rendering in this post if you’d like the full version.
The browser starts by fetching the HTML document from the web server.
The browser then uses the HTML code to create the Document Object Model (DOM). The DOM represents the structure of the web page as a tree of objects, with each object representing an HTML element. H1 goes here, paragraph goes there, for example.
The browser uses the fetched CSS to create the CSS Object Model (CSSOM). The CSSOM represents the style rules and properties defined in the CSS. The CSSOM is then applied to the DOM, to “style” the page according to what’s in the CSS. H1 uses this font in this size and colour, paragraph uses this font in this style and colour, for example.
The process of applying the CSSOM to the DOM is known as style computation.
For want of a better analogy imagine a child with a colouring book and some crayons. The DOM is the black and white picture in the book, the crayons are the CSSOM that’s applied to the picture in the book. Here’s a picture of a man (DOM) his hat is red (CSSOM). Red is applied to man’s hat, just as CSSOM is applied to DOM.
Once the styles are computed (CSSOM applied to DOM), the browser calculates the dimensions and positions of each element on the web page. This process is referred to as layout or reflow and takes into account factors like margins, padding, borders, and the positioning of elements.
After the layout is complete, the browser proceeds to paint the web page by rendering the pixels on the screen. This involves filling in the shapes defined by the layout with the appropriate colours, gradients, and images.
Wait a minute, hasn’t the DOM and CSSOM part already been done?
The multiple application of things to the DOM causes rendering cycles. These are kind of like loops in the rendering process that update the DOM with each cycle.
At this point you might be wondering why I’m telling you all this. Well there is a reason, which is:
Delays in process I’ve outlined above cause delays in rendering. It’s these delays and the resources to which the delay is specific that are considered render blocking. Therefore resources that cause delays in rendering, are render blocking resources.
What are render blocking resources?
These are fairly valid questions. Now let me ask you a question. Who’s the better bar tender? is it?:
A) The bartender that takes an order of multiple drinks, goes off and makes them all, then presents you with a tray of drinks and a total price.
B) The bartender that takes and order one drink at a time, presents you with each drink individually, giving you each drink’s individual price, asking you to pay for each one individually.
I’ll give you a clue. There’s nobody drinking in the bar that bartender B works at (they all died of thirst).
I’ll admit the above is a bit of a tangent to take, but I’m using this to illustrate that when there are multiple components that need to be processed to achieve an outcome, there’s a bad way of doing things, and a good way of doing things.
A good way of doing things is for your site to call it’s scripts in a way that don’t cause a delay in page rendering. A bad way of doing things, is to have scripts being called in a way that cause a delay in page rendering. This is really what render blocking resources are. Let’s go in to this in a bit more detail.
So when you see the “Eliminate render blocking resources” message in https://pagespeed.web.dev/ this is Google’s way of saying “your site is bartender B”, or “this is a bad way to do things” or more optimistically “your site could take less time to render than it currently does”. This is what you’ll see in https://pagespeed.web.dev/:
And if you expand this section you’ll see the scripts that are render blocking (you can hover your mouse over them to see the URL of the script):
And there’s a handy link to Google’s developer resources specific to render blocking resources.
Keeping with the bartender analogy, what Google are pointing out as problematic is that your “bar tender” is effectively stood there looking at a pint of Guiness to settle and doing nothing but this, when they could be pouring other drinks.
OK, I’ll stop with the bartender analogy now.
In terms of your website, what this really means is “these scripts are being downloaded and processed and the page rendering can’t continue until this has all been done”, where as what should really be happening is “rendering is being carried out while these scripts are downloaded and processed”.
Let’s examine what Google’s initial piece of advice is on the page linked to above:
“Lighthouse flags two types of render-blocking URLs: scripts and stylesheets.
A <script> tag that:
- Is in the <head> of the document.
- Does not have a defer attribute.
- Does not have an async attribute.
A <link rel=”stylesheet”> tag that:
- Does not have a disabled attribute. When this attribute is present, the browser does not download the stylesheet.
- Does not have a media attribute that matches the user’s device specifically. media=”all” is considered render-blocking.”
Did you get all that? OK, great, I’m off to get a few drinks from an organised bartender.
Really, the short way of saying what this issue is would be “the way you’re calling your scripts will cause a delay in page rendering”.
The “in the <head> of the document” part means that the script is being called in the <head></head> part of the HTML (so gets processed first).
If a script doesn’t have the defer attribute, it is fetched and executed immediately, potentially delaying the rendering of the rest of the HTML content.
Alternatively if a script DOES have the defer attribute it is fetched in the background while the HTML is used to make the DOM, then the script is executed after the DOM is completed. This allows the script to manipulate the DOM and perform actions after the basic structure of the page is ready.
So without defer:
The browser fetches the script in the <head>.
While fetching the script, the HTML parsing (to create DOM) is paused.
After fetching is complete, the script is executed.
Once the script is executed, the HTML parsing resumes and the DOM construction begins.
After the DOM construction is complete, any manipulations made by the script are applied to the DOM.
But with defer:
The browser fetches the script in the <head>.
While fetching the script, the HTML parsing and DOM construction continue.
After fetching is complete and the DOM is constructed, the script is executed.
The script can interact with and manipulate the DOM elements that are already constructed.
Consequently, using defer prevents a delay in DOM creation, as the script is being downloaded while DOM creation takes place.
So without async:
If a script is included without the async attribute, the HTML parsing and DOM construction are usually paused while the script is fetched and executed. This can lead to a delay in the construction of the DOM because the browser needs to wait for the script to be downloaded and executed before continuing with the parsing and DOM creation.
But with async:
The script is fetched asynchronously while the HTML parsing and DOM construction continue. The script execution is independent of the HTML parsing and DOM construction, meaning it won’t block those processes. The script may execute as soon as it’s downloaded, regardless of whether the DOM is fully constructed.
At this point you might be thinking “Which is better, async or defer?”. There’s not a straight answer to this, because different scripts do different things.
If a script does something to do with with styling, it’s better for it to have the defer attribute. This is because the script will be applied AFTER the DOM has been created, and update the DOM as it’s supposed to. If a script isn’t specific to styling (Google Analytics, for example) then using async is fine, because if it’s independent download and execution occurs before the DOM is created it doesn’t matter. The thing to avoid would be styling specific scripts using async, as these scripts could potentially be executed before the DOM is created, so they’d be effectively trying to do something the DOM upon execution, which might or might not have been generated when the script execution takes place.
The “<link rel=”stylesheet”> tag” is what’s used to call CSS files.
If this tag includes the disabled attribute the CSS isn’t applied to the page (so can’t be render blocking) even though the CSS is mentioned in the page output. This is what the “does not have a disabled attribute” is referring to. Google are saying “if the stylesheet/CSS is mentioned in the HTML but disabled, it’s not render blocking”.
The “does not have a media attribute that matches the user’s device specifically. media=”all” is considered render-blocking.” part isa bit trickier to understand. Really what Google are saying here is that CSS should be device specific (if this device, use this CSS, if that device, use other CSS), and if your site’s page output says apply this CSS to all devices, it’s considered render blocking.
You don’t really need to get massively stuck in to “use this stylesheet for this device and that stylesheet for that device” to address render blocking CSS, as there are “other ways” of making CSS non-render blocking.
There’s some CSS needed by your site’s page to be rendered (critical) as well as additional CSS for elements that are not immediately visible on the screen or are not required for the initial user interaction (non-critical). Due to the critical/non-critical element, CSS files should be handled in a different manner should they be critical or non-critical.
You can do a few things with the CSS that make it non-render blocking:
- Inline your critical CSS (the CSS that’s actually needed to render the page), so that it’s included in the HTML rather than being called separately as a file.
- Using a preload attribute to make your non-critical CSS load ahead of time (before it’s needed) . Using preload for critical CSS may cause a delay in rendering so it’s not advisable to preload critical CSS.
- Deferring non-critical CSS so that it’s loaded and applied toward the end of the rendering process.
Luckily, there are a lot of plugins that will do this for you.
In summary what’s deemed to be render blocking is:
A CSS file that’s enabled and called explicitly as a file (so not inlined) in a non-device-specific manner, and is called without a preload (non-critical) or defer (non-critical) attribute.
If we translated this in to explicit guidance it would be:
- You might consider putting the script in <body> so that it’s not prioritised, and therefore isn’t render blocking.
- Inline critical CSS (in the <body> of the HTML document.
- Ideally defer (or less ideally preload) non-critical CSS.
Critical and non-critical CSS.
I’ve touched on critical and non-critical CSS at the end of the section above, so I’d probably better explain this as well as give some guidance covering how to work out what’s critical and non-critical CSS.
Critical CSS: Critical CSS is required for your page to render.
Non-critical CSS: Additional CSS for elements that are not immediately visible on the screen or are not required for the initial user interaction.
Obviously we need critical CSS for the page to render, but why do we have this non-critical CSS?
Non-critical CSS is usually used to do something after the initial page rendering has taken place. This could be something based on user interaction (such as a drop down menu, hover over buttons, or a tab), secondary content (sidebars or footers), animations or transitions that take place after the initial page render, or device specific (screen size based) styling.
Although non-critical CSS isn’t required for the page rendering, it is required for a page to look and behave as it should.
The coverage tab in Google Chrome’s developer tools can be used to see what CSS is critical and non-critical.
To open chrome’s developer tools browse to a web page, then right click on it and then click on “inspect”:
And the developer tools will open toward the bottom of the browser:
Then press Command+Shift+P (Mac) or Control+Shift+P (Windows, Linux, ChromeOS) and the command menu opens:
At the prompt type:
Then click on “Show coverage”:
And the coverage section will then open:
If you click the record button you should see a list of scripts/CSS loaded by the page (you may need to reload the page):
The red part is the non-critical CSS, and you can click on a CSS file itself to see what parts are critical (blue) and non-critical (red):
Minifying and combining.
The last thing you’d really need to know before getting stuck in to dealing with the render blocking resources on your site, are minifying and combining.
Disabling anything you can that isn’t used prevents having to manage this, as you’re effectively working upstream of what this post covers, and when minifying and combining takes place.
Maybe think of it like:
Why would I combine and minify something I’m not using? Yeah, I probably don’t want to do that!
WordPress Eliminate Render Blocking Resources, how to do this.
There are an awful lot of plugins that can be used to inline critical CSS and there’s an awful lot of plugins that can be used to defer less important resources.
Some will do just one aspect, others will do both and more, a few have some paid only features and some do everything for free and they all work in different ways, but acheive roughly the same thing.
One of my personal favourites is W3 Total Cache as it’s got a lot of features, so you can use this to acheive more than addressing render blocking resources. That said, to get the most out of this plugin, the platform your site runs on needs to support object caching.
The WP Fastest Cache plugin is very lightweight and easy to use, but to get the full feature set this plugin offers you have to pay.
The Debloat plugin is very straightforward to use, but it does recommend the use of a caching plugin in addition.
You’re most likely going to have to try out a few plugins, and maybe even do something like use a combination of plugins. There isn’t a one size fits all answer here, and you’re going to have to try things out to see what works well for your site. A checklist of the features that the plugin (or combination of plugins) you use would be as follows:
- Fix render blocking CSS
- Inline CSS
- Minify CSS
- Combine CSS
- Remove unused CSS
- The ability to exclude specific scripts is handy as well
Due to the wide variety of plugins and all the variables to be considered across WordPress installations, I can’t specifically tell you what to do here. You’re going to need to work out what works best for you and your site.
It’s advisable to try things out on a staging or development site (or at the very least ensure that you have a backup you can restore from, and know how to restore it). This is because there will be some features that you’ll enable or configure that are likely to break things on sites.
You’ll need to change the config of plugins and check your site as you go, in an incremental manner. The main one to keep an eye out for is the mobile menu not working, but there can be other things that might happen, like form styling failing, or aspects of styling failing.
After a lot of configure, check , configure, check you’ll eventually end up with your site working and appearing as it should with no, or at least a very minimal amount of, render blocking resources. By doing this, you’ll be well on your way to improved performance metrcis:
- Render blocking resources cause delays in page rendering.
- Page rendering is the process of your browser turning page output in to a displayed page.
- Both https://pagespeed.web.dev/ and Chrome’s developer tools coverage tab can be used to analyse rendering blocking resources.
- There are a wide range of plugins that can be used to address render blocking resources.
- It’s advisable to use a staging or development site (or have a backup available) before trying to address render blocking resources, as things can break.
- You’re likely to have to try out various combinations of plugin configurations to eliminate render blocking resources in WordPress.