Having a render-blocking resource can degrade a site's performance on many levels. Using Google's PageSpeed Insights audit tool, C2 Group front-end developer Vince Bolhius shares three simple ways to pass Google's task of eliminating render-blocking JavaScript assets to improve site performance.

As the largest and most influential search engine, Google has a lot to say about expectations for how businesses present themselves online. I've already talked a bit about using Google's PageSpeed Insight tool and how to eliminate blocking CSS rendering in the portion of the page visible on the screen . Based on the feedback I received on my first blog, I thought I'd share how to go about Google's task of eliminating blocking rendering resources to improve page performance. I strongly recommend using PageSpeed Insights to see which sources may be causing issues with your site's overall performance.

I will show you how to go through some common audit failures to improve site performance.

Using the preload attribute of critical resources
Most resources defined in JavaScript and CSS degrade performance due to the initial shallow document parsing. Fortunately, by using preload attributes in the HTML header, you can define the critical resources that should be fetched, including when and how each resource should be applied. Pre-load attributes allow you to specify the resources that will be used soon after they are loaded and ensure that they are executed in a specific order, ultimately improving page performance.

Firstly, here is an example of a typical way of loading a CSS resource into the head section of a page:

Here's how you can preload this request. I've also added a noscript fallback option for browser-blocking scripts:

We specified a preload value using the rel attribute, loaded the resource in the href, used the as attribute to specify the type of resource being preloaded, and then used the onload event to load the resource when it was ready. Again, preload attributes are great for starting to download resources that we know the browser will need soon.

Using Webfontloader to load fonts into JavaScript
Another common performance ding is the way the site loads fonts. If you're having trouble loading external fonts such as Typekit or Google Fonts, using a webfontloader provides additional control when injecting @font-face via JavaScript. By adding this code outside of the header section, we can alleviate the penalised blocking of custom font rendering. You will need to refer to the JavaScript library, and then you will be able to add fonts using the WebFont object.

Check out the following example of webfontloader code:

WebFont.load({
google: {
families: ['Open Sans:400,400i,700′, 'Assistant:300,400′]
},
active: function() {
sessionStorage.fonts = true;
}); WebFont.load({
typekit: {
id: 'xxxxxxxx'
},
active: function() {
sessionStorage.fonts = true;
}
});

Simply add custom Google fonts to the family table or specify a Typekit ID to load an external font package.

NOTE : In this case, it may happen that the rest of the page is rendered before the web font loader module is run, which may result in Flash of Unstyled Text (FOUT) or Flash of Invisible Text (FOIT), so it is important to have a font reserve in your CSS.

Flash of Unstyled Text (FOUT) will occur when a font starts to load and immediately displays text with an alternate font family until the web font is loaded and the alternate font is replaced with the default font called from CSS styles.

Flash of Invisible Text (FOIT) will occur when a font starts downloading and appears as non-existent until a web font is loaded and replaces this 'invisible' text.

To accommodate this, I have added arial and sans-serif as a provision for the Google Open Sans font:

font-family: 'Open Sans', arial, sans-serif;

As I mentioned, it is important to have an alternate font that you can rely on for CSS styles in the event (and likelihood) that a custom font takes some time to download and load. The Web Font Loader will then load the actual font when the JavaScript is launched.

Using Async and Defer attributes to load a script
This is reactively simple. Best practice is to load all script resources below and above the tag . This will enable the page to load first and eliminate JavaScript blocking rendering. If this is not possible, you can use async or deferred attributes to load the scripts in the tag . Async and Defer attributes can be used to control how and when external files are downloaded and executed.

Async allows a file to be downloaded asynchronously and then executed immediately after download. This means that the downloading of the file starts while the HTML document is being parsed, and after downloading the parsing is stopped to execute the script and then continues parsing.

Using the async attribute to load a resource might look more or less like this:

Defer retrieves the file asynchronously, but is only executed after the HTML document has finished parsing. This means that the file starts downloading while the HTML document is being parsed, and even after the file has finished loading it waits to be executed until the HTML has been fully parsed. When using deferral, the scripts are executed in the same order that they are called. Deferral is a great option when a script depends on another script.

Below is an example of how we can use the defer attribute to load resources:

A good practical rule of thumb is to use async first and defer when necessary and only when the element