Here’s what I learned about making our site even faster.

One of our goals here at WPShout is to have a fast site. There are lots of reasons this is an important goal: it’s better for you, it’s better for us, and it’s impressive and lets us boast. We’ve done a lot of little things to help with that historically, and recently I set out to boost our performance and speed-up WordPress even more. Here’s what I learned about making our site even faster.

I decided to focus on improving our performance in Google’s PageSpeed Insights tool. There are a number of good tools for checking and monitoring overall site performance. But this is the one I chose, because Google’s opinion matters more than most other tools (they move lots of internet traffic). One complexity of talking about Google’s results is that they aren’t super deterministic (two runs against the same site-configuration regularly give slightly different results) and they have both a desktop and a mobile number.

Structurally, this article starts with a few things we’ve historically done with respect to web performance, then improvements I did make, and finally touches on some of the things that Google still complains about and why I’m not fixing them (at least right now). Let’s go!

Things We’d Done to Speed-up WordPress that You Might Not Have

Our site is hosted on SiteGround. We’re on their biggest shared hosting plan, “GoGeek”, and we’ve enabled all of their basic WordPress caching layers. SiteGround’s hosting has led the way in my experience of what non-WordPress-specific hosts offer. It’s historically blown away other similar tiers from Bluehost, GoDaddy, etc. Though I’ve not followed that very closely in recent years, and have heard noise that Bluehost, at least, is encouraging or forcing more aggressive WordPress caching.

We’ve also done a number of small things to improve the site that you may want to consider. Here’s a list of things we’ve done in the past, to memory:

We’ve not used expensive and complex WordPress themes or page-builders. This isn’t universal, but in general if you’re looking to ace a thing like PageSpeed Insight I’d say look at minimizing the plugins you’re using, and also weight (in the sense of options, etc) in your theme. Our theme is home-rolled.

We’ve taken step to minimize the image size of files on our site. It used to be common that both uploaded media and files that we may have used in plugins or themes would get Google complaining about our images. It doesn’t complain about those any more.

We’re running Jetpack’s Photon Image CDN. A CDN is often sold as a performance silver bullet. It is not one. But it does make a non-trivial difference, and helps us speed-up WordPress. Jetpack’s CDN is free, and images are really the only “expensive” media we serve, so its value is there for us.

What Google’s PageSpeed Insights Complained About

Google basically has a standard list of things that it’ll complain about, and then it’ll let you look more closely at the items inside of that list. Given the things already mentioned above, what complaints did Google have for me as I embarked on this optimization adventure? Well here’s the screenshot:

And if you don’t want to read an image, here’s what it says:

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

Leverage browser caching

Enable compression

Reduce server response time

Minify HTML

Minify CSS

Minify JavaScript

Optimize Images

If these all already make sense to you, you’re great. If they don’t, no worries. I’ll explain each of these in more detail as we discuss why and how I eliminated the concern from Google’s list, or why I wasn’t able to fix the issue.

What I Did to Improve Page Speed and Speed-Up WordPress

In this section, we’ll cover the changes I made in an effort to boost our page speed score, and speed-up WordPress. The specific way you can accomplish these will vary depending on your hosting, but the general outline will likely be similar.

Leverage Browser Caching with .htaccess

Browser caching is where you instruct a visitor’s browser that it can save and reuse some assets that it may get from your server for a longer time. Keep in mind that we’re on SiteGround, and this might work a little differently on your site. But for us, Apache is the the way that SiteGround still serves our WordPress site, so we just have to use an Apache module to enable browser side caching. We’ve done this by taking advantage of a file called .htaccess which most hosts support. We’ve just added the following block to our .htaccess file, per a knowledge-base article from SiteGround. Here it is in full:

<IfModule mod_expires.c> ExpiresActive on ExpiresByType text/css "access plus 14 days" ExpiresByType text/xml "access plus 0 seconds" ExpiresByType text/javascript "access plus 14 days" ExpiresByType application/x-javascript "access plus 14 days" ExpiresByType image/ico "access plus 14 days" ExpiresByType image/jpg "access plus 14 days" ExpiresByType image/jpeg "access plus 14 days" ExpiresByType image/gif "access plus 14 days" ExpiresByType image/png "access plus 14 days" ExpiresByType image/svg+xml "access plus 1 month" ExpiresByType text/html "access plus 14 days" ExpiresByType video/ogg "access plus 1 month" ExpiresByType audio/ogg "access plus 1 month" ExpiresByType video/mp4 "access plus 1 month" ExpiresByType video/webm "access plus 1 month" ExpiresByType application/x-font-woff "access plus 1 month" ExpiresByType application/vnd.ms-fontobject "access plus 1 month" ExpiresByType application/xml "access plus 0 seconds" ExpiresByType application/json "access plus 0 seconds" ExpiresByType application/rss+xml "access plus 1 hour" ExpiresByType application/atom+xml "access plus 1 hour" </IfModule>

This is pretty expressive, so you probably don’t need a very thorough explanation. Basically, every line that says “ExpiresByType” is setting how long we want browsers to keep specific resources. So for image/jpeg resources, we’re telling the browser it can keep them for 14 days, so too with CSS and JavaScript files.

How We Enabled Compression in .htaccess

Like the above ruleset for browser caching, we’ve used the SiteGround knowledgebase recommendation for this. Essentially, this kind of compression is called GZip. And we’ve set this up again within Apache. That code added to our .htaccess file looks like:

<IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/x-javascript </IfModule>

Each file will now be a little smaller. Nothing super dramatic for an individual resource, but it can add up over a few dozen files. Plus Google wants us doing it, which on its own is a good enough reason for me.

Switching PHP Version to Lower Server Response Time

Server response time is a very complex topic. This is actually a great example of something that I also didn’t do. But one of the easy things that I knew I could do to lower server response time was to change which version of PHP our server used to run all the PHP code WordPress uses on each page request. What was in our .htaccess file when we started was:

AddHandler application/x-httpd-php56 .php .php5 .php4 .php3

What’s there now is:

AddHandler application/x-httpd-php71 .php .php5 .php4 .php3

So what did I change? I made our PHP used on the site into PHP 7.1, where previously it was 5.6. This is likely to have some impact on overall server-side performance, as PHP 7 is a great deal faster than even the relatively fast PHP 5.6. So we’re likely to see some small victory here with regards to speed, but it’s probably not going to be enough to stop Google sometimes complaining about our server response time. But it’s quick to do, and as long as you aren’t using a plugin or theme which is not compatible with PHP 7(.1) will be very quick and painless.

Minify HTML, CSS, and JS with Autoptimize

To minify CSS and JavaScript, there are a number of options. But the easiest one for me and for most people will be using a WordPress plugin to do it. It is possible to do this out-of-the-box for plugins you make, but if you’re using plugins and themes and you don’t create, minification must be handled in WordPress with (yet another) plugin.

Autoptimize actually does concatenation, and for HTML as well. I could go into more detail on using it, but last Thursday we published a Quick Guide on exactly this topic:

What I Didn’t Do, And Why

Above I detailed the complaints of Google’s which I addressed. But when I was finished PageSpeed Insights still had complaints. These complaints aren’t wrong, nor or they unsolvable, but I chose not to do so. Here’s what they are and why…

I Didn’t Work on “Eliminate render-blocking JavaScript and CSS in above-the-fold content”

The logic here is that this, especially, is actually pretty complicated, especially in WordPress. And while I love our readers and take pride in putting together great content for them, digging deep into this optimization is way beyond the scope of this article and what makes sense inside of a reasonable word count.

The core idea here is that you want to minimize the number of resource of both CSS and JavaScript that a browser needs to load before it can start “drawing” the page. The ways to do this aren’t something I’ll cover here. Things like inlining essential CSS, minimizing the number of stylesheets, and deferring the load of as much JavaScript as possible is generally what is recommended here. We’re already defer ing most of our JS files, as Fred’s article on the topic mentions. But there’s more to this whole complaint than that, and it’ll have to wait for another time.

(Know of a way to do this? Have a great way to? Please don’t hesitate to comment or email. I’d love to know more about it.)

Google Still Complains About Our Server Response Time

Optimizing server response time in WordPress, especially when you’re using a variety of plugins, is hard. You get very blunt types of advice, and they’re not wrong, but hard to really do. Things that might reduce server response time would include:

Paying for a more powerful server—We already have sub-second response from SiteGround‘s shared GoGeek plan. But we could probably push that lower (toward the idealized sub-200ms times) on super-performant non-shared servers from them or another provider. I’m not doing that now, as we’re quite happy with SiteGround’s product and support.

Disabling more plugins—Each plugin you run will slow the speed of a WordPress response, at least a little. And depending on what it does, it can slow it a lot. But disabling anything other than known-non-essential plugins was outside of the scope of this article.

Those are really the only two levers that are readily available on non-cached content. And we’ve got all the SiteGround caching options on. We could further reduce and optimize the plugins we use, but that only makes sense if we know them to be slow and we “own” them in the sense of being the maintainer of their code. That not true for anything I’ve got left.

We Still Get Complaints about Not Having Browser Caching on All Resources

The .htaccess rule I shared above has eliminated Google’s complaints about browser-cachable files served from the WPShout domain. But our pages also include some very-important JavaScripts that Google thinks could be better cached:

2 files from OptinMonster, which we use for email list popups, which specify no expiration.

One from Facebook, which we use for share bars

One from (perhaps ironically) Google itself, for Google Analytics

No quantity of .htaccess rules I can write on our server can fix these. Theoretically I could (1) stop using these tools, (2) write them about their cache rules, though only OptinMonster truly doesn’t set a lifetime, or (3) rewrite those to use my longer-lived rehosting of those files. The last is technically complicated and probably not worth it, and the first two we’ll consider in the longer term.

Google Still Wants me To Optimize Images that We Don’t Host

There is still some complaints when I run PageSpeed Insights about our homepage having an optimizable image. But it’s been my personal Gravatar, which is a bit of hard thing for me to fix. It’s possible if I optimize it before I put it on Gravatar the complaint will go away, but I’ve not fiddled with it sufficiently, and that it’s not hosted here makes it a bit harder.

What We Learned About Site Performance

I did speed-up WordPress, and WPShout, just by following my nose and the advice of PageSpeed Insights. If you’re not on SiteGround, some of these performance optimizations may look subtly different for you, or be impossible. It all depends on your host. But for most hosts they’re both likely to be possible and likely to be quite similar to doing them on SiteGround.

WPShout’s site performance is still is not perfect, from a browser perspective. But it’s better, and that’s a win. From the lowest number I got while testing—a 61% on mobile—to the highest—a 89% on desktop (up from desktop scores as low as 72%), I can claim an impressive gain. But that’s a lie. When I got an 89% on desktop, Google still gave me a 74% “Needs Work” for mobile. But still, some of the optimizations you need to make your site faster for both Google and your visitors are pretty easy, and I hope this article has shown you how.

We also followed up this post with a guide to WordPress lazy loading, which explains how we accompanied the theoretical improvements to our WordPress site speed with actual real-life improvements. Thanks for reading!