WordPress Eliminate Render Blocking Resources

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.

It would be worth considering carrying out the actions detailed in the reduce unused javascript post if you haven’t already done so, as this covers how to block unused Javascript, and the information in the “Managing assets” section of the reduce unused Javascript post can be used to completely turn off some CSS that isn’t used (rather than having to manage these resources which is what this post covers).

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.

The page output is usually a mixture of CSS, Javascript, and HTML.

If you view a site’s page source (right click on a page, then click “view source” in most browsers) you’ll see the page’s HTML and references to Javascript and CSS files. It’s all this that gets turned into the page displayed in the browser. The process of turning the CSS, Javascript and HTML in to the page that’s displayed is rendering.

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?

The “page output” that I’ve mentioned above consists of HTML, CSS and Javascript. These 3 components are different in nature, and it helps to understand a bit about how each plays their part in a page being rendered.

HTML

HTML (Hyper Text Markup Language) was invented before CSS and Javascript. It is possible to make a website using only HTML (but it won’t look that pretty!). Writing HTML isn’t really considered programming, as HTML isn’t really code. This is because it’s a “mark up” language. Mark up languages are more specific to how content appears, rather than having any kind of logic control. HTML controls an aspect of how the page appears (think page structure, paragraphs, titles, bullet points, tables) rather than what the page “does”.

CSS

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.

Javascript

Javascript is a programming language and it does have logical control (if this happens do this). Javascript code (in the context we’re talking about) tends to be executed client side, i.e. in the browser. Again Javascript can be embedded in the HTML of a web page, but can also called as separate files in a similar manner to CSS. Javascript can be used in a lot of different ways. To take a simple application of Javascript, you might think of it along the lines of “if the screen of a device is this big, display the page like this”. In practice this would be along the lines of “if the page is smaller than X and Y, display the mobile menu burger menu instead of the full menu”. In this context, it’s Javascript that makes pages “responsive” (automatically adjusting how a page is displayed according to the size of the screen on the device being used to view the page). It can be used to serve other purposes in addition to this, such as:

• 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).

All three of the above are present in page output generated by a WordPress site upon request when the site, or a page of a site is visited. I’ve mentioned using separate files for CSS and Javascript, so it can be the case that the HTML of a page isn’t just “here’s the page’s HTML” it’s more along the lines of “here’s the page HTML, which includes this CSS and that Javascript, you’ll need to process them to be able to display the page”.

It’s how the browser is told to handle these additional files or CSS and Javascript (by the page source code) that determines wether they’re render blocking or not.

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.

As the browser encounters external resources in the HTML (like images, CSS, and Javascript), it initiates additional requests to fetch those resources.

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.

If the browser encounters <script> tags with inline JavaScript or references to external JavaScript files, it starts fetching and executing the JavaScript code. JavaScript can (amongst other things) modify the DOM and CSSOM, creating dynamic changes in the web page’s structure and appearance.

Wait a minute, hasn’t the DOM and CSSOM part already been done?

It has, but it’s potentially then additionally modified by the Javascript.

Get HTML, work out DOM, get CSS files, work out CCSOM, apply CSSOM to DOM, get Javascript files, process Javascript, update DOM accordingly.

So there are three things being fetched (or downloaded): HTML, CSS and Javascript.

And the DOM has two things applied to it: The CCSOM and Javascript (or the product of processed Javascript).

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?

Render blocking resources are external assets such as stylesheets (CSS) and Javascript (JS) files that prevent a web page from fully rendering until they have been fetched and processed.

But don’t they have to be fetched and processed for the page to be rendered? Isn’t that something that’s just going to happen if you use external Javascript and CSS files on a web page, like WordPress does?

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.

or

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.

I’m joking.

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 <script> part means Javascript, I’ll cover this first.

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).

The “does not have a defer attribute” means that the Javascript isn’t being called with the defer attribute.

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.

The “does not have async” part means the Javascript is being called without the async attribute (async means asynchronous). This means that certain tasks or operations can be executed independently and without blocking the main execution thread.

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.

That’s the Javascript part covered, now on to the CSS!

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 script (javascript) that’s prioritised by being in the <head> of the HTML document that doesn’t have any async or defer attribute (so could delay page rendering).

And:

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:

• If you’re going to prioritise scripts (Javascript) by putting it in the <head> of your HTML, use the async or defer attributes.
• 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:

coverage

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.

Minifying is the process of removing whitespace and unnecessary characters (comments for example) from CSS or Javascript files. This reduces the total size of the CSS or Javascript file. Files of a smaller size take less time to download.

Combining is the processes of combining the contents of multiple CSS or Javascript files in to a singular CSS or Javascript file. If you do this, instead of having multiple calls to individual CSS or JS files, you’ll have one call to one file that contains all the CSS or Javascript to be used on your site’s pages.

The combination together reduces the number of calls to CSS and Javascript files that your site makes, and reduces the total size of the CSS and Javascript that has to be downloaded.

Before minifying and combining Javascript and CSS it would be strongly worth considering disabling any CSS and Javascript assets that aren’t actually used at all, otherwise you’re ultimately combining non-used code in to your singular combined CSS and Javascript files.

Most of how you’d do this is detailed in the reduce unused javascript post. This covers how to block unused Javascript, and the information in the “Managing assests” section of the reduce unused Javascript post can be used to completely turn off some CSS that isn’t used.

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
• Defer Javascript
• Minify Javascript
• Combine Javascript
• Delay Javascript
• 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:

In conclusion.

• Render blocking resources cause delays in page rendering.
• Page rendering is the process of your browser turning page output in to a displayed page.
• Page output usually consists of HTML, CSS and Javascript.
• Both https://pagespeed.web.dev/ and Chrome’s developer tools coverage tab can be used to analyse rendering blocking resources.
• Both CSS and Javascript can be minfied (to reduce file sizes) and combined (in to singular files).
• It’s advisable to manage CSS and Javascript assests upstream of minifying and combining, so that you’re not combining and minifying code that isn’t used.
• 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.