(Finding about and) Joining the 512KB Club

While reading a blog post linked at the orange site, I noticed and followed a funny little banner, and that’s how I got to https://512kb.club/ – a list of “performance-focused” websites under the 512KB threshold (before compression). After reviewing their FAQ, I ran to GTMetrix to scan my website – even if I don’t subscribe to the notion that WordPress is necessarily a broken and bloated mess, a decade of working with it had me expecting that even a very light-weight site would be at least three times that.

Imagine my surprise when I find out that I was just over that at 551KB uncompressed – and this was with a stock Twenty Seventeen theme and a hefty 70KB header image of my dog! Being this close, I decided to dig in and try some optimization.

The oversized header image was not my favorite part of the site anyway, especially wrangling its height across devices, so dropping it was an easy first choice. This didn’t feel like a sufficient change, even though the math is obvious and I should’ve simply performed another test at this point, but instead I also chose to switch back to a slightly older, “more minimal” theme – Twenty Sixteen.

Another surprise – after both of these changes and re-running the test, the site got the same exact 551 KB in uncompressed size, even though the waterfall chart was clearly showing different resources being loaded! I was pretty certain that GTMetrix was broken and had cached the uncompressed size (but nothing else), but I also didn’t care for the sidebar in Twenty Sixteen, so I went back in time again.

Switching to Twenty Fifteen got me to 549 KB, which is still almost a non-improvement over previous results, but at least it put some different numbers on the screen. I liked how the site looked after the change – this theme really has a classic “golden age WordPress” vibe to it – so I decided to stick with it and try some things.

With very low expectations, I tried a popular optimization plugin. One thing such plugins do is try to shave a few KB off by combining and “minifying” the site’s JavaScript and CSS files, but it really did nothing for me. This speaks well for the optimization that’s already built into the stock WP themes, or bad for the benefits of optimization plugins, or both – take your pick.

Going back to the 512KB FAQ, the first tip (of two!) is to “replace custom fonts with a local font stack”, but this isn’t as simple as it sounds with WP themes. I spun a child theme and then spent a couple of minutes trying to override the stock CSS rules with a single declaration, but it didn’t work, so I decided on a different approach – disable the loading of some fonts with a function.

The first thing that I spotted in the waterfall chart was Genericons, which means nothing to me, so I tried disabling that:

// Remove Fonts
function my_dequeue_fonts() {
add_action( 'wp_enqueue_scripts', 'my_dequeue_fonts', 11 );

Doing this did improve the uncompressed size and got me slightly under 512KB, but it also broke some icons used for various actions on the site – ah, that’s what genericons is! – so I reverted the change and looked around for something else to “dequeue”. While reviewing the homepage’s HTML for clues, I noticed “twentyfifteen-fonts” right there under “genericons-css”, so I tried with that instead and suddenly the site was down 150KB, getting me to the magic value of 407KB! What’s even more important in the real world, the 150KB improvement in uncompressed size also translates to virtually the same improvement in compressed size (fonts/images are already compressed, so compression really only works on text-based resources), going down from around 262KB to 102KB! Even though it’s irrelevant for the 512KB Club, in terms of actual page load speed, this is a huge deal.

Anyway, here’s my hard-earned banner:

Final thoughts

Of course, dropping all custom fonts used by a theme can be a big change in terms of a site’s appearance, but not necessarily for the worse. The site still looks fine to me and is perfectly readable, perhaps even more so, but the performance benefits are the real star here. I actually think that disabling custom fonts is such a good idea (for smaller sites, anyway) that it should be included as a core feature of WordPress (it probably is an option in some more advanced themes).

Post-final thoughts

One last “optimization” that I tried while writing this was to enable excerpts on the homepage. This is also not part of WordPress’ core functionality, and while some themes include it, this one does not – so it has to be added with a custom function or a plugin (ugh). This change got me down to 96KB/392KB, which is pretty decent, but far from what I would need in order to move to the next bracket (under 250KB). However, in terms of appearance, this bugs me a lot more than the change in fonts, because excerpts lose all formatting (even basic things such as new lines).

While trying to hack this further, I learned about the “More” block that essentially works as a page break for your blog posts, and only shows that “first page” section on the home or archive page. This is great, as it preserves formatting, and it also allows you to work around different post lengths (you don’t need a 180-character excerpt on a 190-character post, etc). The downside is that you have to manually place it in every one of your posts, but this site only has five or so. I’m really happy with the final results, both in terms of performance and appearance.

Final numbers: 97.4KB/396KB after publishing this post. Seeing 642ms up there is really sweet too!