When it comes to the speed of your website, it’s important to think of speed as a necessary feature, not a luxury, and to treat it accordingly. There are a lot of things that go into the equation that determines how quickly site visitors begin to see content when they visit your website. Some of these things you can’t control: the speed of their internet connection, their geographic location, network congestion, and so forth. However, there are others things that you can and should control.
What does that actually mean?
I want to be clear on one point: it may too much effort or simply be impossible to remove all render-blocking resources. Doing so may even produce the dreaded FOUC (up) I mentioned just a minute ago. Just remember that it isn’t our goal to attain a perfect PageSpeed score. Instead, our goal is to deliver the best possible user experience, and that means a website that loads as fast as possible without flashing unstyled content.
In other words, use PageSpeed Insights to identify render-blocking files that you can try to eliminate, but let UX be your overruling guideline.
There’s a plugin for that, right? Well, sure, but you need to understand what’s going on before you start plugging in plugins. Many plugins are highly configurable, and knowing how render-blocking resources are eliminated will help you work more effectively with the plugin of your choice.
Clear JS from the Critical Rendering Path
The defer and async attributes are not created equal, and the difference can be important to understand.
- The async attribute tells the browser to start downloading the resource right away without slowing down HTML parsing. Once the resource is available, HTML parsing is paused so the resource can be loaded.
- The defer attribute tells the browser to hold off on downloading the resource until HTML parsing is complete. Once the browser has finished with the HTML it will then download and render all deferred scripts in the order in which they appear in the document.
Optimize Delivery of CSS Resources
Render blocking CSS can also be difficult if not impossible to entirely eliminate. The ideal arrangement is to:
- Identify the styles that are required to render above-the-fold content and deliver those styles inline with the HTML.
- Use the media attribute on the link elements that pull in CSS files to identify CSS resources that are conditional, that is, only needed for specific devices or situations.
I should also mention that I did not use any caching plugins during this process. My test site was set up on a Kinsta plan which comes with built-in caching at the server level. If you aren’t a Kinsta customer, setting up a good caching plugin will further improve your site’s performance.
However, before getting to the plugins, we need a benchmark score. What I’ve done is set up a simple test site on Kinsta and installed a popular, free, jQuery-loving theme from WordPress.org: Sydney. Without doing anything else, here’s where we stand.
Since my test site is hosted on Kinsta, the site is blazing fast right out of the gate and required 24 requests to load the homepage.
Let’s see how we can improve on that performance by trying out a few plugins.
Speed Booster Pack
First up is Speed Booster Pack. This plugin is active on over 40,000 WordPress sites and gets a 3.6 out of 5-star rating at WordPress.org.
The plugin’s settings are found at Settings > Speed Booster Pack and the menu is reasonably simple while simultaneously offering quite a few configuration options.
With the plugin configured, here’s how the site performed at PageSpeed Insights.
Curiously, the number of requests actually increased. While there was nothing to suggest the number should have decreased, increasing the number of requests is a surprise. The overall performance grade did improve a little, so I won’t call Speed Booster Pack a bust. However, there are more effective options available.
Next, let’s take a look at JCH Optimize. While the plugin has fewer active installs than Speed Booster Pack, it boasts an impressive 4.6 stars out of 5 rating.
The plugin adds a settings menu at Settings > JCH Optimize. The settings menu has several pages with many different configuration options. To make things relatively simple I selected the Average automatic settings in the Basic Options menu.
The results were a little puzzling.
That’s not what I expected to see. Let’s see what Pingdom’s Website Speed Test thinks of the changes.
As things stand, JCH Optimize is not very helpful for optimizing this particular test site.
With over 300,000 active installs and a 4.7 out of 5-star rating, Autoptimize is one of the most popular speed-optimizing plugins in the WordPress plugin directory. It also earns strong marks right off the bat thanks to the plugin author’s charitable and generous attitude.
This plugin is designed to be simple to use and it lives up to that promise. Whereas many of the other options I looked at had very complex menus, Autoptimize is very simple. All I did was go to Strong > Autoptimize and select the three primary checkbox options displayed on that page.
Here’s how my test site performed at PageSpeed Insights after that simple 30-seconds-or-faster optimization.
We’ve managed to reduce the number of render-blocking resources from a total of seven to four. Very good. Now to see how the number of requests has changed.
The total number of requests has gone down considerably from 24 to 17, and the performance grade has jumped to a very impressive 92. It looks like Autoptimize is popular for a very good reason. I should mention that Kinsta has noticed a trend of Autoptimize incompatibility with some sites that inline custom CSS in header.php. For example, if you have custom CSS coded into your theme’s header.php file take extra caution if you try out Autoptimize.
In the case of my test site,
async ended up loading some jQuery files before jquery.js which ended up breaking the site. So I went with the
defer method. With those options selected, here’s how the tests went. First up, PageSpeed Insights.
Combining Async JS and Autoptimize
Excellent. With both plugins set up, we’ve managed to trim the total number of render-blocking resources down to just three CSS resources. How have we affected the number of requests?
The site is blazing fast and only sends 17 requests.
The last plugin I tested was Hummingbird by WPMU DEV. This is a premium plugin that I use on some of my own websites. There is no free version of the plugin available, which means it’s starting with one strike against it. However, it provided the most significant reduction in render-blocking resources, so it bears mentioning.
I combined and minified all files and moved them all to the footer with two exceptions: the theme’s primary style.css file and jquery.js. I found that both of those files must appear in their original location to avoid breaking the site or producing a FOUC. With those settings, here’s how the site performed in PageSpeed Insights.
As expected, we’re down to just two render-blocking resources: style.css and jquery.js. Great. Let’s see what Pingdom can tell us.
While the overall performance grade isn’t as high as it was with Autoptimize, we have managed to trim the total number of requests to the lowest value we’ve seen so far: 16.
Async JS Works Well with Hummingbird
All that is left standing in the way is style.css. The last step to allow us to completely eliminate all render-blocking resources would be to inline style.css. However, we’ve managed to go from seeing a Should Fix message to a Consider Fixing message in PageSpeed Insights. I’m going to defer to Google’s definition of when to worry about a Consider Fixing message and say that what we’ve accomplished so far is a resounding success.