WordPress Optimization

In a previous post, I wrote about having some reservations about choosing WordPress over leaner or more focused tools and platforms. I made that post because I’m no longer used to having so little control over the output of a tool. Previously, with Jekyll, I was able to tweak every last script, tag and data point. This was great because I could also drop the whole thing into CloudFront and have it entirely served out of a proper CDN.

With WordPress, it’s not so simple. The tool is designed to abstract away a lot of the manual work that static site generators need. Want an image in your post? Easy enough to do in Jekyll… until you want the 2x version or intelligently serve WebP vs JPEG/PNG or if you want to generate thumbnails appropriate for your theme. All of these need to either be pre-computed by the owner, or have to have an asset pipeline setup to process all the different options.

I like WordPress. It’s a versatile tool, though much of it seems more focused on building eCommerce sites, than blogs. Many pre-canned themes have abysmal optimization. Opting to let the user muck with the CSS and JS and leave the optimization to the user. CSS is loaded individually instead of condensed. JS is loaded in the head, and not deferred in the footer and often times the themes rely on absolutely massive 4mb FontAwesome collections for a couple of social icons or other widgets on the page. These then are loaded in a blocking manner, harming the end user experience.

This is understandable. There isn’t any panacea for optimizing. The current best practices are more like… well…

And for good reason. Sometimes the site you’re building needs a specific method to the madness to work at all. While that would be a good place to take a hard look at what your objectives are, it’s certainly understandable with the web being what it is today.

I find myself a little revolted at the new cottage industry that has sprung up around optimization. WordPress should be able to handle this internally. Generally it’s just concatenating files, flattening them by removing excess white-space and then serving up one or two files. Stick the JavaScript at the bottom of the page, defer it if you want and away we go. That’s a large chunk of optimization work taken care of. Media is certainly easy enough to optimize, too, what with WordPress being, ostensibly, the server for all these requests, and PHP (usually) has some form of image processing available via libraries or modules. The last-mile stuff, like content delivery networks, is something that should be left to the user, as it typically costs money to operate. Part of the reason I find it so hard to give up Jetpack is that you get a lot of this stuff for free.

WordPress already has some of this tooling available. In fact, you can enable the confusingly named, wp-config.php constant, CONCATENATE_SCRIPTS to do just that… for the administration screens only. During theme and plugin building, you even enqueue your scripts and CSS files so that WordPress knows what files are needed for building a page. So, I have a hard time with believing that this couldn’t just be dropped in without much fuss and a toggle.

So, what gives, WordPress? I’m more than happy to continue using you. I absolutely love Gutenberg (which says a lot, coming from someone who hates JS-based anything). These seem like such low-hanging fruit, which such a large impact on the often coveted PageSpeed and GTMetrix scores that basically drives the frenzy around optimization. I haven’t been on as much of a deep dive in modern WordPress as I had been with Drupal those many years ago. Therefore I concede that there might be some sort of internal issue as to why this isn’t done, even optionally, in the core platform.

Leaving that behind, I really like this Atomic Blocks theme, even though it seems like more of a showcase for Gutenberg and the Atomic Blocks plugin by WPEngine, than anything else. Though I like it, I think I’m going to keep searching for something a little more smartly constructed. Maybe use the _s ‘base theme’ and build it more smartly, myself. While this makes me less reliant on the tooling, it’s also repetitive and much better suited for a computer to handle.

By Nathan DeGruchy

IT Support extraordinaire. FOSS lover and proud Husband and Father.