Optimising My Site for Speed
Date Published: 9th March 2019
This is going to be a quick overview of site speed post-launch, some of the steps I’ve already taken, and what there’s still left to do.
Quick heads up I’m not really bothered about the performance of this website in terms of speed.
By already having a decent host, coding the theme from scratch and barely using images on the site, I’ve pretty much already won the speed battle.
I’m honestly more worried about stuff like passing Google’s Mobile Friendly Test and other Mobile UX/experience tests.
Site Speed
Note: GTmetrix is by no means the be-all and end-all of Site Speed Optimisation – it’s just easy to use and offers good data visualisation.
Post-Launch
Here’s an approximate list of stuff I’ve naturally done as part of the site build:
- Designed a very minimal theme to begin with
- Coded from scratch so no extraneous stuff…there’s one main CSS file and no external JavaScript
- Don’t use featured images and set-up WP thumbnails to auto-resize to my ideal max-width (1000px)
- System safe fonts/a font-stack I stole from Bootstrap
- My Digital Ocean VPS usually delivers a great time to first byte (TTFB)
- Six plugins in total; functions file is bespoke and relatively lean
- WP Fastest Cache Plugin – Does a lot of site speed box ticking in one click e.g. Gzip, minification, combining files etc.
So here’s the homepage score post-live…
GT Metrix recommends the following:
- Leverage Browser Caching – So there’s 7 files where the “expiration isn’t specified”. Fair cop here, I actually removed a lot of these rules from the .htaccess when I was trying to troubleshoot the http to non https redirect. Will re add, although obviously there’s nothing I can do about the two files on external domains for Google Tag Manager and Google Analytics.
- Optimize Images – Fair cop here as well. My homepage uses a massive image of the Turin cityscape and GTmetrix advises that using their version will save 5% which equates to a 43.7 KB reduction which is certainly nothing to be sniffed at. I find tools which do image optimisation to be very inconsistent in their output put that’s a discussion for another day!
Post-Optimisations
So assume I’m going to implement those two recommendations, what else can be done?
Well the answer lies in taking a peak at the Waterfall Chart…
The first thing which stands out is an additional CSS file which I will call “block-library” .Wordpress is automatically enqueuing this as part of Gutenberg.
I did want to use Gutenburg for this website, but after playing around with the block elements it was ultimately easier to just create templates for “unique” parts of the site such as the contact form.
I also found Gutenburg terribly distracting for writing…
Anyway, a quick Google later found this solution on Stack Overflow. So a quick copy into the functions and boom that was one additional request gone.
–
Next up was a similar problem with an automatic Javascript file WordPress was adding to the site “wp-includes/js/wp-embed.min”.
So once again a quick Google for what function to deregister it and we were soon good to go. Here’s the answer I found.
Apparently this was added around WordPress 4.X in order to allow you to embed other people’s WordPress sites into your own. Not sure who would actually use it although embeddable media such as Tweets would make sense.
–
Lastly, I double checked WP Fastest Cache settings and realised I hadn’t actually turned caching on. I must have disabled it when testing the site…
End result:
Basically reducing the requests by 2 and optimising the images had a marginal impact.
Turning on WP Fastest Cache (the actual cache button and not other settings) has has undoubtedly had a massive impact.
Apologies for not saving the same waterfall as the one above but this is the impact:
Combined with I think a bit of natural fluctuation in the servers speed, I think the end result is super positive; especially when you factor in how easy it was to achieve.
Note: Adding expiry headers didn’t appear to be working for me. I did some investigation and I think I actually need to enable this within the httpd.conf file as per Simon Whatley.
Will try and fix this at another time though…
EDIT: This has now been fixed as per 10/3/2019.
Next Steps (optional)
Of course there’s undoubtedly still a few more steps I can probably take but overall I’m not a fan of site speed optimisation for site speed optimisations sake.
Or what I call site speed extremism/inverse dick measuring contests.
Here’s off the top of my head what I could do if I wanted to take thinks a step further on the homepage:
Ditch Font Awesome – So I use 4 Font Awesome icons in the footer but reference the entire stylesheet/.woff file. Now the reality is that most people will have Font Awesome cached before they visit my site, however in terms of vanity metrics there’s a few options.
If I was chasing page size I could maybe just reference 4 x pngs. If I was chasing less requests I could download each icons as svgs and convert them into Base64. Lastly If I was super bored I could download the font, eliminate any used icons and shrink the overall size.
Optimise Homepage Image – I could probably water this down further or add a media-query to serve a different image on mobile. Problem is I am a desktop user and call me crazy but I want my site to look good on my 24 inch monitor. I concede there’s definitely something more I could do though.
Other stuff I will need to look at around the site:
- Gravity Forms – I use this but it enqueues an additional 3 or so additional Javascript files whenever a form is embedded on a page (thankfully not every page). I suspect there’s a quick way of merging these files or limited the requests entirely!
- Lazy Load Images – The more blogs I write which feature images such as this one I will need to find a way to defer the loading of large images so the UX still feels quick.
- Manual Minification – WP Fastest Cache should be taking care of this but it’s always worth double checking.
So this concludes my initial site speed optimisation post-launch. I might review this and write another post if I ever choose to eliminate font-awesome.