One of the most important improvements for the user experience is to reduce the timing of the first contentful paint, which is what the visitors will immediately see once the page loads which is the `above the fold` content. Asset CleanUp (Pro) can help you reduce this timing so your visitors will have the experience they need.

Asset CleanUp never generates and loads render-blocking resources (both CSS & JavaScript files) as it’s against the purpose of a plugin that is meant to reduce the way resources are loaded (in this case synchronous). To understand why some resources are shown as render-blocking, referencing /wp-content/cache/asset-cleanup/ as a location, please check this article: Can Asset CleanUp (Lite/Pro) generate render-blocking CSS?

Dealing with CSS resources

There are two ways of improving the page speed score for “Eliminate render-blocking resources” (CSS files) using Asset CleanUp (and in general):

#1 Remove unused CSS files wherever you can

Let’s suppose you have 10 stylesheets loaded as render-blocking and you found out that 3 of them are not needed and they could be unloaded from the targeted page. Once you perform the unload action, the page will load only 7 of them, thus the page speed score will be improved as there will be fewer resources to download and the first contentful paint will show up faster. Now it all depends on the size of the files as well. If they are very small, it won’t make much difference, but still better than before. If those unloaded files are large in size, then this could improve the score significantly as Google PageSpeed Insights checks the sie of the render-blocking CSS 😉

Moreover, by stripping the “fat”, you will also improve other grades including, but not limited to: “Remove unused CSS” (main one), “Minify CSS” (since there won’t be any possible non-minified CSS files loaded anymore), “Keep request counts low and transfer sizes small” (fewer files loaded, fewer KB downloaded by the browser), etc.

#2 Load CSS files asynchronously via “Preload (Async)” (Pro version)

This one is very useful in case there are CSS files (it’s often the case, especially if many plugins are loaded on the website) which are not critical enough to delay access to the content. The browser needs to download these ones asynchronously. This is done by altering the LINK tag combined with JavaScript code. You can read more about it here if you’re interested in the technical side of it: Modern Asynchronous CSS Loading.

When you manage the list of CSS/JS files on any page using Asset CleanUp Pro, you have the following option: “Preload (if kept loaded)?”. Please select “Yes, async” for the files that are not critical for the styling of the above the fold content which is the first one showing up when the visitor loads the page. Now, it’s recommended to avoid doing that for your main theme CSS or the file that deals with the top menu styling (if it’s separate), etc. Basically, anything that is for the top content of the page, should be left to be loaded synchronously (render-blocking) at least for now.

Files that are not critical and can be loaded asynchronously include, but not limited to:

  • Popup’s CSS which is in most cases not triggered immediately on page load. The popup’s CSS can be downloaded later on after the `above the fold` is shown. One example of a popular popup is Magnific Popup that is used on many WordPress websites
  • CSS related to the footer of the page (if it has its own style)
  • Contact Form 7 is a popular plugin for generating forms. If your pages are printing forms in the footer or towards the end of the page, then you can mark its CSS file to load asynchronously. I won’t recommend doing that on the “Contact” page where the form is printed right at the top of the page.
  • CSS files that are needed only after the user interaction. For example, a shopping cart that shows its contents (having a separated CSS file for styling) only on `hover` or `click` event.

What if I apply the Preload (async) option to CSS files that are not supposed to be asynchronous?

If this happens, it’s very likely that you will notice (depending on your internet connection and other things such as the hosting provider) a flash of unstyled content, abbreviated as FOUC (it can be for a second or two, it depends) because the web browser is loading the content before the styling is downloaded. The most common example is the main theme’s styling. Technically, all CSS files can be set as render-blocking, and it will result in a higher page speed score, but it will affect the user experience, as you likely don’t want your visitors to load your website’s content unstyled for a few seconds (if their internet connection is not great at that time) until the CSS files are downloaded and everything is showing fine.

Is there a way to avoid the flash of unstyled content and also have all the CSS files loaded asynchronously?

Yes, it is, by implementing critical CSS that will be necessary only to render the above the fold, while all the CSS files will be loaded asynchronously. Note that this requires extra maintenance as the website’s styling and `above the fold` content could change and the critical CSS needs to be changed/regenerated as well. There are automatic solutions that are generating it, although it’s not often 100% accurate and requires manual intervention (e.g. editing the CSS syntax to make sure it works flawlessly and no part of the `above the fold` is experiencing any FOUC.

A special post has been created to help Asset CleanUp Pro users with the implementation: Critical CSS: How to implement it to completely reduce render-blocking stylesheets

If you’re a developer or just want to know more about reducing render-blocking CSS (e.g. perhaps you start building your website), please check this article from Varvy.com: Eliminate render blocking css

Dealing with JavaScript resources

There are three ways of improving the page speed score for “Eliminate render-blocking resources” (JavaScript files) using Asset CleanUp (and in general):

#1 Remove unused JavaScript files wherever you can

Let’s suppose you have 5 JavaScript files loaded as render-blocking (no “async” or “defer” attributes are applied) and you found out that 2 of them are not needed and they could be unloaded from the targeted page. Once you perform the unload action, the page will load only 3 of them, thus the page speed score will be improved as there will be fewer resources to download, and the first contentful paint will show up faster. Now it all depends on the size of the files as well. If they are very small, it won’t make much difference, but still better than before. If those unloaded files are large in size, then this could improve the score significantly as Google PageSpeed Insights checks the size of the render-blocking JavaScript.

Moreover, by preventing unneeded JS files to load on the targeted page, you will also improve other grades including, but not limited to: “Does not use passive listeners to improve scrolling performance“, “Reduce the impact of third-party code” (if you unload any 3rd party one such as Google Maps), “Minimize main-thread work“, “Reduce JavaScript execution time“, “Keep request counts low and transfer sizes small” (fewer files loaded, fewer KB downloaded by the browser), etc.

#2 Defer parsing of JavaScript using the “async” and “defer” attributes

Both attributes let the browser download the JavaScript files without pausing HTML parsing.

  • async does not pause HTML parsing (as the default method without any attributes does). However, it does pause the HTML parser to execute the script, once it finished download it.
  • defer (most used for page speed) does not block the parsing of the HTML page and the script is fetched asynchronously and executed only after the HTML parsing has been completed

Growing with the Web explains in a nice, understandable way, the difference between the two, as you can notice in the following print screen:

Note that while many JS files can be loaded via “async” or “defer” attributes, there are some that are more sensitive to it so to say. Unless you really know what you’re doing, it’s recommended to leave them as they are. This includes the jQuery library, which is loaded as render-blocking by default. You might be able to get away with deferring it, but if you later install a plugin that prints jQuery code that is render-blocking, then that code will return an error because of the jQuery library is not loaded yet (because you deferred it). If jQuery is deferred, then you have to make sure all the other JS code (the inline one as well, not just the one loaded from files) is also deferred. If you’re not sure about it, it’s better to leave it as it is, as you can still have a fast website and fully functional which is the most important.

Was this post helpful?