Sass, WordPress & PageSpeed Insights

Monday, June 15th, 2015

I was a late convert to Sass but I have to say ever since making the switch I’ve been amazed at how much more efficient it has made me during my development.

I now use Sass on pretty much every web build I start, so much so I’ve built it into my own WordPress framework which I use to start builds with.

Recently I’ve been using Google PageSpeed Insights a lot and one of the issues which appears over and over again is this;

Eliminate render-blocking JavaScript and CSS in above-the-fold content

The issue

Basically we need to reduce the amount of time it takes for content, which appears ‘above the fold‘ to render on the device viewing that content.

Therefore reducing the number of HTTP requests which the browser is making for CSS and JavaScript files is key to this. To start with if you aren’t already combining all your CSS and JS into single file, as well as minifying them you should be. This will help with smaller file sizes but it still won’t remove the issue.

The Guardian newspaper reduces render-blocking in a really smart way. They simply load a huge amount of CSS and JavaScript directly into the head section of their site. In fact they add so much, at the time of writing this article they have 211 lines of code in just the head section of their homepage.

My solution

I should start off by saying that what follows isn’t a tutorial and I assume you know the basics of Sass to get anything out of this.

I’ve basically taken a leaf out of The Guardian’s book, I write my Sass, compile it into compressed CSS and load this straight into my head between a couple of style tags. My JavaScript I do the same but pop it just before the closing body tag.

This may seem strange but let’s first of all look at what exactly the style.css file in WordPress does.

It mainly serves as one of these two functions.

  1. It styles the markup in exactly the same way all CSS files do
  2. It makes the theme active within the Appearance > Themes option in the dashboard

We’ve already decided that we are intending to load all our minified CSS directly into the head section so the first reason is no longer valid. We therefore only need our style.css to contain the data required to register the theme in the back end.

I tend to keep this within my build directory as a Sass file and rename/move it using Grunt with my compiled code. If you intend to do the same then remember to change the comment to a Sass comment which won’t be stripped out during compression.

I then create a new Sass file called style.preload.scss which looks something like this depending on the project.

When it come to the compile stage I use grunt-contrib-sass and convert this file into a .php file called style.preload.php which is located in my theme directory.

To then output the contents of this file into the head section of the site by adding the following to header.php.

Remember this .php file contains no php code whatsoever, it only contains the the compressed CSS which was compiled from the Sass file.

Lazy loading css

If you require additional CSS to be included such as fonts you can use this great snippet from Google’s own PageSpeed team.

Obviously replace the link to Font Awesome with your own.

If you have more than one css file then you can use a solution using an array, like so taken from Stackoverflow

Things to note

This does obviously add a bit of page weight to the pages, and users will need to download the additional content every time they visit pages rather than reading from a cached file, therefore if you have a large amount of CSS / JS you should run some tests and decide if this is the approach you want to take or not.

Plugins often add additional CSS and JavaScript to your head section. You can shift these to the footer but if this causes an issue ask yourself, can the function of the plugin be achieved any other way, chances are it can. If you’ve answered yes then remove the plugin and recode whatever is needed, you’ll have a faster, more secure site if you do.