Improving site load times

August 2020

When I got a minute, back in June, I took a closer look at site speed, as it seems very sluggish. It was. So I made a number of changes – mostly to widgets – and the page load time improved from over 40 seconds to under 3 seconds, without greatly hurting the look and feel of the site.

In a nutshell
After running various tests, I ripped out a lot of stuff GTmetrix wasn’t happy with (mostly the Facebook widget), and put back caching. Page speed improved from over 40s to 15s to under 3 seconds.

Damn, but Facebook is a massive hog!

Yet Googles test rating (via Lighthouse) dropped from 36% to 31% and showed the page load increased to over 11 seconds.

Taking out the Jetpack Community widget gave a further big improvement, most of which seems to be because Gravatar icons wouldn’t cache.

Next I took out the page slider (shame, but necessary) and the Google PageSpeed Insights jumped up to 70%.

Though still only with a shared server, I upped the hosting, adding more processors, memory and a dedicated IP. Only really shaved about half a second more, but I can feel the difference when I’m working and it is reflected in performance scores.

On theme choice and Font Awesome:

I played around with a few themes and got Google and Pingdom speeds up around 90. Once the widgets hogs are removes, and caching is in place, all most all of the bandwidth and server call hogging is down to WordPress and, far moreso, junk code in themes. It’s not simply all the flashy effects, it’s javascript and style sheets that are called and not used, or only partially used.

It is a balancing act between functions and aesthetics, but a lot of the sloth is down to lazy programming.

For instance, which is very common, themes can offer a rainbow of colour sets, to please all palettes. Which is nice, to have the choice, but if the theme offers red, blue, green, purple, pink, brown and monochrome, and you only want blue, well the associated styles sheets can be six times bigger than they need to be. All adds up.

Customizr is a nice theme and all, but needs work, especially as 2 seconds of the load time penalty was trying to load a huge (and arguably superfluous) style sheet that was set to be deferred. I went into the code and edited it out, it knocked 2 seconds off page load times. This site looks no different for the removal. Fontawesome was at the heart of it. I like Customizr, I really do, but there’s an awful lot of spelling missing in their code, comments and their web site, which does not inspire me, and their reliance on Font Awesome for needless effects is just nasty.

Customizr Pro Insight

It is a personal preference, and some people willingly add the Font Awesome plugin, but others cite the superfluous code and excessive load times. As I understand it, the problem is Font Awesome adds in a ton of code and icons for every possible social media app, despite knowing the vast majority of icons never get used. Case in point, they include an ‘alien’ icon. Or you can just use a html emoji like 👽 for a very similar icon or emoji, thus: 👽

Or you use use CSS to make it bigger, as needed: 👽

I’m old school. An .exe saying ‘Hello world’, to run in DOS, and written in C is about 6kb; the same .exe file written in C++ is about 100x bigger in size. I am not a fan of bloated code.

By the numbers

Ideally you want (but not need) to the PageSpeed up to 90% to get a green light. Not easy with bloated pages (the bloated being display weighted rather than content).

Google PageSpeed Insight

Similarly, Pingdom only give this site a C rating:

Pingdom speed results

GTmetrix currently gives the site a PageSpeed performance score of around 95%, at least.

GTmetrix pagespeed results

The slow shared server (with Bluehost) is not helping, at all, but a dedicated server or pro managed hosting costs around over £150 to £225 a month (1 to 3 years up front). I’d have to faff about finding a dozen or more paying clients to develop and host sites for to justify it. Then there’s added security layers, added backup and multi-site, upping the SSL to as high as multi-domain EV. Fine if you are pulling in the revenue to cover it, but you are taking several thousand a year to do it properly, so I’ll pass. Still, I have upped the server a bit, more memory, more CPU’s, dedicated IP, helps, without costing a fortune.

I tried to remove FontAwesome from the Customizr theme but it’s embedded deeper than a tick so, as a test, a swapped it for a comparable free theme (Astra, I think) and PageSpeed shot up from 68 to 88 instantly. More importantly, it knocked nearly 3 seconds off the load times! The current rule of thumb – and Google’s recommendation – is that if a page takes more then 3 seconds to load, people will walk away. According to Web Vitals any page that takes over 2.5 seconds to load needs improving!

Largest Contentful Paint (LCP): measures loading performance.
To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.

First Input Delay (FID): measures interactivity.
To provide a good user experience, pages should have a FID of less than 100 milliseconds.

Cumulative Layout Shift (CLS): measures visual stability.
To provide a good user experience, pages should maintain a CLS of less than 0.1.

I am OCD (clinically so), so I do have a tendency to get manically obsessed over things that I (intellectually) know do not matter. In this case, Google’s PageSpeed Insight doesn’t matter, even though it triggers me, but page load speed does, because it matters to others, including Google. Even half a second longer can drive people from your site, so adding seconds, not a good idea. Thus:

Create and Code: Just how important is your Google Pagespeed score?
“You should take your Pagespeed score with a large pinch of salt. It really isn’t that important. Your page load time is far more important, and Pagespeed isn’t a reflection of your load time.

We know from countless research sources over the past 20 years that engagement and conversion rates fall off significantly if a web page takes more than 2-3 seconds to load.”

See also WP-Rocket’s take, which is interesting: Why you Shouldn’t Care About Google PageSpeed Insights

It should be noted that over the decades I’ve used shared servers (like now), which are pretty much all overloaded and horribly slow, VPS, which are faster but can still be annoying slow, and dedicated servers, which are wonderful, but eye-watering expensive. For this blog, a dedicated server would be the equivalent would buying a Bentley to drive to the local corner shop, which is a minute walk away! So nice, but utterly ridiculous.

I also have 600 posts and several thousand images to work through because a Vaultpress incompatibility (WordPress .org vs .com issue) broke every single image link. Joy. On the plus side, even though it will take me a few months, all the larger images will be re-sized and optimised, so times will improve again. If you are displaying at a ‘large’ size of 900 pixel wide, remember to resize them according BEFORE adding them to WordPress!

See also GoDaddy: How to speed up WordPress

Downtime Donkey: How We Boosted Page Speed By 58% … and how you can too!

Colorlib: 39 Fastest Loading WordPress Themes for Incredible Page Speed 2020

From June 2020

Back in June I starting fixing a number of pages, but still not going round to going through 600-odd posts (that’s several thousand pages) to fix all the errors (character codes and image links) from the last two moves. Don’t get enough traffic for it to matter, but it annoys me anyway.

Working on speeding up the site’s page load. One speed tester claimed my performance was only 11% and that security was zero, so I knew that particular one was useless, but it
still showed a huge number of page calls (nearly 600) and a load time of nearly 40 seconds, so something was off. A huge chunk of that ‘something’ was a Facebook widget, which gave me a Google PageSpeed of about 23/100 and added a whopping 20 to 30 seconds to the page load speed. Crazy!

GTmetrix is somewhat more reliable, so I tried that, and it did firmly pointed an accusatory finger at the Facebook calls. As the page include a widget for Facebook I simply deleted it. The requests dropped from over 500 to 139, still high given the average is 88, but it’s a good start. For load time it dropped from 40-odd seconds to 10.8s. Still longer than I’d like, but it is a slow shared server and there’s other tweaks I can do, so it’s a start. Moral here: Widgets can be garbage, Facebook is a sewer.

Leverage browser caching‘ is a miserable 0, but here it’s pointing the finger at Gravatar, on the community widget. Widgets, I tell y’. Another easy fix. Disabled avatars for now. A good chunk of the ‘0’ comes from including Google stuff – like Adsense and analytics. Might rip them out too.

‘Defer parsing of JavaScript’
“1.4MiB of JavaScript is parsed during initial page load. Defer parsing JavaScript to reduce blocking of page rendering.”
Damn, that’s a lot of junk code. When I used to write in just html (and CSS) I used and zero javascript. Ugly, insecure language. Site looks better for all the flashy WordPress code and themes, but I miss just writing clean code!

Upgrading from the free to version of Jetpack might help a little, but I can’t justify the cost. Upgrading the server from a ‘recommended’ shared to a pro, vps or even dedicated would definitely make a difference to the speed, but it goes from £5 a month to several hundred a month, and that’s not happening.

See how it looks for the current changes anyway. Hmm, too soon to register changes, but the site feels a lot faster, so I’ll try next time I remember.


Still slow, and Google’s Pagespeed insights gives the site a miserly 36% rating.

Making a few more fixes, (re)adding CDN support via cloudflare, see how it goes.

~ Ack


Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top
%d bloggers like this: