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? Here is a more in-depth explanation.
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.
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.
defer or the
async attribute to the
async attributes are not created equal, and the difference can be important to understand.
The big difference between the two is that
defer ensures that scripts are downloaded and applied to the webpage in the order they appear in the HTML document, while
async does not. The result is that if
async produces is broken jQuery resources that try to load before
jquery.js has been added to the document.
Render blocking CSS can also be difficult if not impossible to entirely eliminate. The ideal arrangement is to:
mediaattribute on the
linkelements 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.
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 600,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.
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 plugin that I use on some of my own websites. This used to be a premium plugin but it’s now available for free! 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.
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.
Send this to a friend