Speed Up WordPress: How I Optimized Site Performance on WPShout

screen shot from our tests to speed up wordpress

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 even more. Here’s what I learned about making our site even faster, to speed up WordPress.

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 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:

Minify CSS and JS with Autoptimize

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 defering 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!


6 Responses

Comments

  • Would have been interested on before and after optimization, Pingdom or GTmetrix results. Since actual site load time is more important than Google PageSpeed grade.

    https://tools.pingdom.com/#!/dqNJ2B/https://wpshout.com/

  • Great post thanks for the insights.

    I agree with you that the Google Page Speed test is well over the top I have dozens of sites that don’t score that well but have first page listings and do have caching, minify etc. all set up. We work with a SEO company who are very anal about this test and won’t guarantee their work until a benchmark score is met. I have spent hours trying to fix the render blocking issues and basically to do it all breaks the site so it is not possible, plus as you mention scripts not on the server (Google scripts for one) also show up which are not possible to fix without a lot of work.

    I do also look at the results from Pingdom and GT Metrix as these are easier to achieve a better score. I short I think the Page Speed results should be taken with a pinch of salt and you shouldn’t worry too much about getting the perfect score as long as your site loads quickly and has the basics in place.

  • Hey,

    I am using the exact same combination almost 90% of the times optimizing a web site. I have also added to my workflow https://wordpress.org/plugins/cache-performance/
    which helps a lot for making the web site pages static ( service as HTML ).

    I really do like how things go with it, simple a suggestion I hope you or any reader find useful.

  • Armands says:

    I often find these metric tools a little anoying if a client/manager just looks at the score and says – we need to get higher!
    They are good for getting insights on what can be improved but partly they are about chasing milliseconds (not saying milliseconds don’t count) and not always the effort is worth it and sometimes it just makes you dig in the wrong place.
    For example, on Google Pagespeed Insights only one metric is about actual response time from server. If it is 3-4 seconds then no amount of other optimisations listed there will help much.
    You can do all other optimisations but it still will be 3s+.
    Recently had a case like this and client wanted to get a higher Pagespeed insights score. And that we did by doing some of suggestions.
    But server response time was still 3 – 4 seconds (at least). Something on IIS server made it work pretty slow. And nobody wants to look at it (upgrade, optimise server, migrate to Linux)..score is higher, all is well. Although, it’s not.

    So..best to use these tools with some moderation.

  • Frank says:

    You have SSL enabled which gives you HTTP/2 headers. I’ve heard that combining CSS and Javascript isn’t as big of a deal since HTTP/2 does multiple downloads now.

  • Ratan Mia says:

    I also recommend the plugin – Plugin Organizer. It lets you choose which plugins to load by page or post. This helps a ton with page speed when you don’t need most plugins for most pages.

Add a comment

(required)

(required)

(optional)