WordPress and page speed insights

I finally did it!

After a long time optimizing rewriting a lot of code asynchronously loading fonts and some stylesheet, I finally managed to have my wordpress site achieve a top score of 100 in google page speed insights.

So how did you do it?

To be fair, I used a combination of plugins to achieve it, and rewrote some parts of my theme to be compatible with said plugins.

I use various techniques such as static page caching, compression, asynchronous loading of assets, and last but not least some decent server hardware.

First things first.

From what I’ve come to learn there are quite a few show-stoppers that could prevent you from from achieving that sweet satisfactory score too.

Pagebuilders… pagebuilders… pagebuilders… because of the way most pagebuilders work, they tend to create A LOT of markup that can be heavy for the browser to parse.
Most of them even loads assets (stylesheets, javascript, fonts) directly in the body of some content, without properly enqueing their assets through the built-in wordpress API, this behaviour can make it really tricky to load such assets asynchronously.

Second, make sure you’re not using a cheap webhost, pay the buck for some real iron. Slows servers and bad hardware, or even misconfigurations can result in TTFB (Time To First Byte) being significantly high.
This is the number one source to a slow website, especially if you’re running with a plugin heavy wordpress installation.

Now that’s out of the way..

There are of course a lot to getting a good score on page speed insights, there’s the general tips.

Always serving GZIPPED content (This is easily done through either PHP or a .htaccess),
Leveraging browser cache (set sufficient caching lifetime on assets there are unlikely to change)
Upload sufficiently cropeed/sized images. don’t upload a 1200×800 image to a spot where it will be scaled down to a 300×100, this is assuming that your website is automatically cropping images to fit.
Try to have your images < 100KB in size. Google really cares about those precious bytes on cellular devices.
Asynchroniously load assets. Let the browser download and execute javascript AFTER the initial page load, and only prioritize the stylesheets that’s actually needed for your page to visually render. All the eye candy can easily wait a few hundred milliseconds before being rendered.
Javascript almost never belongs before the closing </head> tag, the primary use for javascript is to add interactive features to a website, and most users don’t care if it takes 500ms before their browser executes javascript, it feels way faster if CSS is prioritized for most users.

1st plugin: Cache Enabler

Compared to other caching plugins, this is really, the fastest and most lightweight caching plugin that actually works, and does what it supposed to do.

Create static copies of your website and cache them for e.g. 24 hours, and servea GZIP compressed version of that cache when the client (browser) asks for it, instead of going through the whole wordpress engine and render process

My best advice do not try to use caching plugins such as “WP Fastest cache” or “W3 Total Cache” while those plugin may have “many satisfied customers” and be the “best rated plugin” that’s pure marketing bulls**t.
The aforementioned plugins are so packed with features and bad code that they will actually slow down your site, contrary to speed it up.

2nd plugin: Autoptimize

The primary use for Autoptimize is to combine and aggregate my static assets such as stylesheets and javascript files.

If you site doesn’t have a lot of traffic, and don’t contain too many fancy effects, you can safely use the “Inline all CSS” option.

Alternatively it also let’s you define the “above the fold” CSS, which is the primary part of your stylesheet, that the browser should prioritize rendering.

And it is as this point the problems arise with page builders, because if assets aren’t properly enqueued through the wordpress functions, Autoptimize can’t detect it.
And many page builders don’t do it the proper way.

3rd plugin: Scripts to footer (optional)

If your site is more or less relying on custom plugins and themes, and is following good development practices, there’s a good chance you won’t need Scripts to footer.

However quite a number of 3rdparty plugins don’t care about performance and partout load their assets in the header of your website.
This simply forces all scripts to before the closing </body> tag, while maintaining the enqueued order of assets, to minimize potential conflicts.

Consider keeping jQuery in the header, as moving jquery down can cause errors, though this decision comes with a performance penalty.

4th plugin: WebP express (optional)

Most modern browsers doesn’t yet support the .webp image extension, check the caniuse page but that doesn’t stop google from throwing a hissy fit about you not using “Next generation images” and while WebP is an awesome format, so few browsers support it, that I would hardly consider it worth the effort to do this, but if you want to make google happy it will do the trick.

WebP Express takes some time to configure properly, and will still only serve WebP images to supporting browsers. How it manages to do that consists of a lot of .htaccess magic mumbo jumbo, and some quite hacky HTML parsing,
WebP express default settings isn’t very sensible, you’ll need to enable to “Alter HTML” setting for it to take effect.
I’d recommend to set it using output buffering too, that way you don’t have to worry about how other plugins inject images in random places.

Don’t forget to also convert your images initially.

Though if you use the cache enabler plugin, don’t forget to set the option
“Create an additional cached version for WebP image support.” within cache enabler.

So.. What about jQuery?

As I mentioned before, WordPress and most themes relies heavily on jQuery being loaded early (before the closing </head> tag) the problem with that is, this makes jQuery render blocking, forcing the browser to download and execute jQuery before it can continue onwars rendering the rest of the important parts.

The Scripts to footer plugin have the option to move jQuery to the footer, and Autoptimize the option to also aggregate jQuery.

It it almost guaranteed that it will require a custom theme to achieve this step, as moving jQuery to the bottom of your page requires all inline javascript, and javascript assets that relies on jQuery will have to be executed AFTER jQuery is loaded. otherwise you will get errors on your site

Last but not least, don’t forget to consult the grand tome of google, to see what others have done.