So, when Automattic set me up with a shiny new .blog TLD, I got to thinking: as long as I had a couple of instances running locally anyway, I might as well get something public-facing together. Not because anyone needs to read any more of my particular brand of nonsense, but so I can tinker with and document some of the WordPress-focused performance approaches we’ve been using for ourselves and our clients, out here in the open. I’ve been a little reclusive lately, in terms of Open Source work, so I’m easing back into it by distilling a lot of work we’ve been doing for clients into a performance-focused WordPress theme that anybody can pick up and use.
Admittedly, there’s not a whole lot to see here so far. I’ve taken kind of an “MVB[log]” approach to getting this theme up and running—no comments, no search, not much of anything, really. Just an index and individual posts. Naturally, the plan is to re-add all the features and options that any public-facing theme ought to have, and release it into the wilds of the WP ecosystem. Luckily, I have WordPress and Bocoup’s own KAdam White to keep me honest about doing things The WordPress Way, and talk me down from—just as a purely hypothetical example—tearing
wp_head out of my templates altogether. Speaking of which, maybe don’t “view source” too hard just yet.
Overzealous as I might get from time to time, the “tear it down to build it back up” approach appeals to me given our goals for the theme. In any performance-focused project, WordPress or otherwise, we aim to start as simply as possible and layer in enhancements in the most unobtrusive possible way.
“Unobtrusive,” here, means two things:
“Layer in enhancements in the most unobtrusive possible way” is just a slightly longer way of saying “progressive enhancement,” when we’re talking about user-facing features: if a performance enhancement should fail, or break down, or meet with dicey browser support, it needs to do so in a way that works with the medium—the way the web works. If a font loading method intended to shave precious milliseconds off a page’s initial load time has a potential failure path that could end with a user seeing a blank page, it can’t be considered viable—the risks outweigh the benefits. If the worst case scenario ends with the user seeing plain ol’ non-
@font-face’d type—that’s okay. That’s how the web works.
At the same time, “unobtrusive” also means that these features need to stay out of a developer’s way—to have a positive impact on the end result, without adding overhead for the maintainers. For example, if implementing a CriticalCSS approach would require “just remembering to” copy the contents of a file, that isn’t a viable implementation either. No matter how elegant the user-facing solution might end up being—no matter how great the performance improvement—the potential for error will outweigh the potential benefit. These features have to be as seamless for maintainers as they are for users.
So, my goal for this new theme is the same: to get all the tricky behind-the-scenes wiring for a fast website in place, unobtrusively—for users and theme developers alike—and documented in an approachable way.
Like it or not, we have a rich tradition of pun-based project names here at Bocoup—and, truth be told, front-end performance often means dealing in particularly strange and arcane magicks; generated files and cookies and in-line styles and whatnot. The metaphor is a bit of a reach, but we’ve taken to calling this base theme Bouillabaisse: the component parts may not be too pretty on their own, but they add up to a deceptively elegant dish.
Whether or not that name sticks: we’ll have a repo up and running for you soon. Stay tuned.