Do It Yourself

Tools & Resources
Not interested? Want me to do it for you? Find out how

Front-end site (not logged in)

For the front-end I primarily use my own custom plugin SpeedifyPress. This isn’t available on general release, but is available for paid subscribers to this newsletter. Otherwise, I use a handful of plugins and Cloudflare.

  • Expires headers - PageSpeed Insights will complain if your assets expire from the browser cache too soon. There are lots of ways to fix this, but a nice easy way is to use a setting on Cloudflare (Caching > Configuration > Browser Cache TTL)

  • Images - getting the images right can be absolutely key to getting a top page speed score. They need to be as lightweight as possible, lazy loaded and, in certain cases, preloaded. Here’s what I used to get that done:

  • Fonts - Google fonts loaded via the external Google servers can cause a big hit to your page speed. Luckily though, there is a solution - you load the font files from your own server and, ideally on dekstop only, preload them.

  • Root Document - First off, you need to make sure the HTML for your page is sent out speedily. So it needs to be cached! (The non-cached version should be quick too, but that’s a whole other story…) Even when cached though, we don’t want the document to be too big. Caching is easy(ish), but the latter can be tricky. Here’s what I do:

  • CSS - this is a big one! The CSS in WordPress sites can be all over the place. All the plugins add their own CSS files and not all the CSS being loaded will be used. This causes unncessary files to be loaded, and CSS files are render blocking. It can be a big drain on your page speed. There are solutions, but I was never a big fan of any of them. This was the main reason I started building SpeedifyPress, so it should come as no surprise that’s what I turn to in order to fix this.

  • JavaScript - this is the other big one for render blocking. Just like CSS, there’s lots of JavaScript that isn’t used, most of your plugins will add some and it can often be a big mess. But unlike CSS, we can’t easily remove unused JavaScript. So, what’s the solution? Well, we need to delay the loading of the scripts until the page has loaded. There are a few plugins that can help you here, but, of course, I use my own where I can (on some client sites I have used WP Rocket and FlyingPress)


Front-end site (logged in)

When users on the front-end are logged in or have an item in the cart, we shouldn’t cache the page content. Caching plugins (and correctly configured Cloudflare) will not cache when certain cookies are present, which is right, but it does mean users can often face very slow pages. So what to do?

Well, although optimising such pages is not simple, there are options.

  • Plugin reduction

    • Freesoul Deactivate Plugins can be extremely useful in reducing plugin usage on pages where it’s not required. Setup and configuration does take some expertise, however. It’s not quite plug and play!

  • Database optimisation

    • Index WP MySQL For Speed is a great first place to start for optimising indexes (before getting more advanced, analysing the queries on your site and adding custom optimisations)

    • Redis Object Cache generally works well, although you will need to test thoroughly and keep an eye on things until it’s stable

    • Query Monitor can also be extremely useful for debugging database and peformance issues, if used correctly.

    • WooCommerce HPOS is a great way to speed up those ecommerce tables but, again, it does require some care.

  • Code Refactoring - this requires digging into the code and fixing any bottlenecks. My go to for this is new relic. It’s not perfect, but it’s an excellent way of digging into the code and finding out once and for all what’s causing your site’s slowness. Often, it’ll be a rogue bit of theme code or a plugin, and will require some custom coding to fix.

Not interested in DIY? Want me to do it for you? Find out how