Hands On Improving Google PageSpeed

What Is Google PageSpeed?

Google PageSpeed is a free tool that assesses the performance and usability of your website for mobile and desktop platforms. It’s extra important because Google uses it in determining key elements of our SEO ranking, i.e. how high we appear in their search results.

If you want more background about the benefits of increased site speed, read Moz’s Why Site Speed Optimisation Should Be Part of Your SEO Strategy, which highlights, “…several case studies have shown faster loading pages strongly correlate to higher revenue.”

In this tutorial, I’m going to walk you through some technical approaches to optimize your WordPress website’s PageSpeed. While basic changes can be quite simple and easy, more comprehensive updates can actually be quite challenging.

Interestingly, custom websites may be easier to optimize than WordPress sites—it’s because of the framework’s extensive use of third-party themes and plugins. It’s also based on an architecture that was designed before its popularity and relies on an imperfect architecture for backward compatibility.

Before we get started, please remember, I do try to participate in the discussions below. If you have a question or topic suggestion, please post a comment below or contact me on Twitter @reifman. I’m interested in your experience with WordPress and PageSpeed.

My Initial PageSpeed Score

For this tutorial, I’m going to focus on improving my personal website, JeffReifman.com.

A while back, my PageSpeed was Mobile 65 and Desktop 64 — not that great:

Note: here’s the article to read if you’re curious about the funny mobile screenshot with Russell Wilson.

Before we get started on making optimizations, let’s talk about some of the basic WordPress performance factors.

Basic WordPress Performance

There are a few major ways to begin optimizing your WordPress site for performance and increased PageSpeed.

Theme Selection

The PageSpeed of various themes is greatly affected by the number and size of JavaScript files and CSS they use, the number of images used and their size, and the approach of their mobile implementation, i.e. typically responsive nowadays.

If you’re in the market for a new WordPress theme and want to evaluate PageSpeed, you may be surprised that the scores for well-known themes often run in the 60s and 70s but also up to the 90s. Here are a couple of articles assessing themes and PageSpeed via ColorLib and WPMU. In any case, I expected higher.

I’ve used My Site My Way’s Construct theme for several years. Interestingly, the company’s support site went silent recently, and they’ve left no explanation for users.

However, because there will be no more updates to the theme, it makes it a bit easier for me to make some radical changes to its performance for this tutorial without having to deal with future code updates from the company. I’ll get to this shortly.

Hosting Company

Using dedicated servers will very likely perform better than increasingly common and more affordable shared virtual servers. In the past, I’ve written about how to install WordPress at shared providers such as Digital Ocean. There’s also the in-between of services like WP Engine, which offer an attention to developers and both shared and dedicated servers.

The quality of the host will matter too. A lot of bare-bones shared WordPress providers may provide inconsistent performance.

For example, I use the KnowHow theme on both Publishing with WordPress hosted at a Digital Ocean virtual server and Flee the Jungle hosted at WP Engine. The sites are fairly similar in content weight, e.g. text and image usage. The PageSpeed for Publishing with WordPress’s PageSpeed is Mobile 73 and Desktop 88, while Flee the Jungle at WP Engine was a bit faster (Mobile 78 and Desktop 91); WP Engine’s managed hosting is a bit faster than my self-hosting with a shared server.

I’ve also seen poor performance with Amazon’s low-end AWS hosting. You get what you pay for.

Caching

WordPress caching is critical for performance, and I’ve regularly written about my favorites: W3TC and Varnish Cache, e.g. Optimizing WordPress with Varnish and W3 Total Cache.

Content Delivery Network (CDN)

Another service that’s critical is a content delivery network. Earlier I wrote about Accelerate Your Content Delivery With KeyCDN for Envato Tuts+ and then decided to switch to them.

Image Optimization

Regularly reducing the dimensions and file size of images across WordPress is time-consuming yet critical.

I regularly use Acorn as a lightweight tool to quickly scale down images for the web. I laughed when someone tweeted recently that they’d just opened Photoshop and would be available for phone calls for awhile while it loaded—Acorn is small and fast. That Adobe subscription model is so slow to load—sorry, subscribers.

There are also automated image optimization plugins like WP-Smush. I recently began experimenting with KeyCDN’s new Optimus. Also, here’s WPMU’s summary of the 10 Best Image Optimization Plugins to Speed Up Your WordPress Site.

Increasingly, I also access images on my post externally from Flickr. For example, when my post about Seattle’s Amazon-driven neighborhood growth went viral on Slashdot, there were no performance issues or bandwidth costs for all the photos, because Flickr handled it.

You can read Google PageSpeed’s Image optimization Guide, but I’ve increasingly found that Google help is overly research oriented (which is nice to have as a resource) but not very useful for resolving issues on your own. There may be one too many PhDs there and one too few actual users.

My Updated PageSpeed Scores

While I’ve always had W3TC and Varnish, adding KeyCDN and Optimus increased my PageSpeed to Mobile 72 and Desktop 82, a good improvement from 65 and 64:

Interestingly, Google’s image caching complaints seem as if they can go on indefinitely, no matter what you improve. For this tutorial, I experimented with optimizing some of the identified remaining offenders to see what would happen. The result was interesting, and I’ll tell you more about it shortly.

The PageSpeed Optimization Challenge

If you’ve done all the major basics above, improving your PageSpeed with WordPress turns out to require significant effort and can be quite time-consuming. 

The Challenge of WordPress

A static site usually has one file with CSS and JS includes that can be easily minified and combined. WordPress is a lot more complex.

So much is created dynamically through WordPress’s—ahem—less than perfect architecture. It can take time to find where files are being created, whether they are in the themes or plugins, and how to address these issues. It turns out that when you have seven plugins including JavaScript files and you want to minimize and combine them into one include while allowing regular plugin upgrades, it’s quite a challenge.

Using Minification

HTML Minification

Updating my W3TC HTML minify settings quickly resolved PageSpeed’s complaint about that.

CSS Minification

For CSS, I had to individually add the files PageSpeed alerted me about to W3TC’s CSS File Management. W3TC then began minifying my CSS and combining the named files into a single file to include.

This resolved PageSpeed’s CSS minification requirement.

It also reduced the number of CSS files being reported for render blocking from seven to four theme-related files (listed first under Optimize CSS Delivery):

The three remaining files were from plugin directories outside of my theme (which we’ll explore later):

I hope this gives you a sense of the rabbit’s hole that WordPress PageSpeed optimization quickly becomes. 

JavaScript Minification

While minifying and merging CSS is generally pretty easy, JavaScript tends to fail a lot when you try to do this, creating major, site-breaking bugs.

Interestingly, PageSpeed now offers complete zipped downloads of its compressed versions of your files which it doesn’t like.

It listed ten of my JS files that it wanted me to fix:

For reference, here are more of Google PageSpeed’s minimization resources for HTML, CSS and JS. I also made use of Refresh SF, which provides easy web access to various compression tools.

Compressing and combining JavaScript can definitely create bugs, so I had to take things step by step. Using W3TC’s JS File Management, I minified and combined the seven JS files within the Construct theme:

This didn’t allow me to address my plugins’ JS files or problems I was seeing with a mysterious unfindable externally hosted base.js file. Let’s move on to Render Blocking problems and then return to JS minification after.

Eliminating Render Blocking

If you have a large variety of files that need to be loaded to style (CSS) and activate (JS) the functionality of your web page, most browsers will slow down after four resources are requested in parallel. 

Here’s an example of the CSS render blocking complaint in PageSpeed:

While W3TC had combined many of them into its include.c46b63.css, the next three above were from my plugins.

Blogger Justin Tadlock offered some guidance explaining how to ask WordPress not to load the CSS files that my plugins had enqueued for loading. The answer is to deregister them and then load a combined file on your own.

Here’s my Table of Contents plugin enqueuing its JS and CSS files:

/**
* Register and load CSS and javascript files for frontend.
*/
function wp_enqueue_scripts()
{
    $js_vars = array();
	
	// register our CSS and scripts
	wp_register_style( 'toc-screen', $this->path . '/screen.min.css', array(), TOC_VERSION );
	wp_register_script( 'toc-front', $this->path . '/front.min.js', array('jquery'), TOC_VERSION, true );
	
	// enqueue them!
	if ( !$this->options['exclude_css'] ) wp_enqueue_style("toc-screen");
	
	if ( $this->options['smooth_scroll'] ) $js_vars['smooth_scroll'] = true;
	wp_enqueue_script( 'toc-front' );

Following Tadlock’s suggestion, I deregistered my plugin includes in my theme’s functions.php, first the CSS—you have to find the references used by the plugin developer:

  add_action( 'wp_print_styles', 'my_deregister_styles', 100 );

  function my_deregister_styles() {
      wp_deregister_style( 'toc-screen' );
  	wp_deregister_style( 'blogsynthesis_jss_css' );
  	wp_deregister_style( 'edd-styles' );  	
  }

I manually created a combined CSS files with those three plugin stylesheets. Then, I asked W3TC to minify and combine that file into its own mega-stylesheet:

There is a major issue here in that when I update my plugins, I may need to update this combined CSS file and its accompanying JS files.

Here’s a blog post with some other approaches you can use for these challenges. 

Using Tadlock’s approach, here’s what the PageSpeed render blocking looked like afterwards:

I followed the same steps for JS files, just a bit more carefully. Gradually, my PageSpeed’s JS complaint for my site became fairly minor:

However, as you can see below, it was also complaining about browser caching issues with JS files I couldn’t find links to in my codebase such as ad_status.js from Doubleclick.

Removing a Legacy YouTube Player Embed

Eventually, I figured out that both the JS minification issue and this caching issue were related to my use of an external YouTube video player.

While I was curious to try a small fix suggested here to prevent video from loading without user action, I decided to just remove the video from my home page slideshow.

It’s likely that the way my Construct theme embedded YouTube files was a legacy solution. YouTube’s HTML5 support may work a lot better now. Still, it’s kind of funny how a Google service impacts performance scoring of another Google service.

Removing the one feature on my home page that embedded a YouTube video solved a few problems:

Since I don’t want you to miss out on seeing my better half before I was corrupted by WordPress, I’ll include the video here. I used to be a nice guy.