In October 2016, the guys working at WordPress decided to include a CSS customer in the theme customization options. Previously this functionality was available only to Jetpack users, and it was one of the reasons why I used to recommend Jetpack to everyone.
Before this, users needed to find a 3rd party plugin for their custom CSS code, or make changes directly to the “style.css” file of their theme. It seemed like an elegant solution. Or so I thought at the time. As I started getting interested in optimizing for page speed, I saw something peculiar. Something that the creators of this feature seemed to overlook, and which I will explain below in greater detail.
Adding CSS via the Theme Customizer
As of now, anyone can insert additional CSS via the theme customizer like this:
Once you click that, there’s a separate box into which we can add CSS. It comes with all kinds of useful features like:
- Syntax checking
- Live preview
- Explanation of errors
- Indentation
- Autocomplete
This makes it trivial for anyone to add their own CSS. Great right? The democratization of technology! Unfortunately, the way it’s implemented in the backend is less than ideal.
Referencing the New CSS in HTML
Once you add the CSS, it’s referenced in the final code via a peculiar GET request like this:
Something like:
/?custom-css=xxxxxxx
In other words, it’s not stored as a regular CSS file. There’s no extension, and it’s not a static resource on our server. Rather, it’s stored in the database and is requested with each page load.
Adding a CDN to Speed Things Up
Like any good web owner, I’ve tried using a CDN for my static files like CSS and Javascript. That includes style.css, and (I assumed) any new CSS added with the theme customizer. For the example below, I’m using KeyCDN. I simply enter the pull zone into my CDN plugin like this:
And when I’ve configured it correctly, all my static file URLs are rewritten to come from the CDN instead. Like this:
This seems great! Except that when I checked out the waterfall view of my WordPress site, I see that the GET request for the additional CSS is not rewritten. It’s still this:
This is a huge problem. Not only is it an additional database request, but it’s also not affected by whatever CDN you choose to use! Moreover, this request can’t be cached except perhaps deep in the backend database via Memcache or something. In any case, it’ll always be slower.
Since this feature doesn’t adhere to the basic rules of CSS loading, I recommend that everyone switch off using it.
So What’s the Alternative?
My experiments with page speed have led me to the conclusion that server response times are crucial. So while you can use a 3rd party plugin to store your additional CSS, I suggest that you just bite the bullet and append it directly to your style.css page. Yes, it’s more work. But you only have to do it once. And your CPU won’t have to spend extra cycles processing a plugin to generate the CSS file.
Then simply pass it through a minifier or whatever and have your CDN cache the entire site’s CSS in one fell swoop. This is probably the most efficient solution for custom CSS. In a way, I’ve been moving backward – from extra convenience via the 3rd party plugins, to a more “bare bones” kind of set up. And I’m finding the improvements in page speed really worth it!
I’m a NameHero team member, and an expert on WordPress and web hosting. I’ve been in this industry since 2008. I’ve also developed apps on Android and have written extensive tutorials on managing Linux servers. You can contact me on my website WP-Tweaks.com!
Thanks for this article. It’s too bad because customizer is so convenient and I love the live preview and syntax checker. Maybe WP will figure it out sometime.
Having the css or any other file combined, minified and saved onto the filesystem is actually the job of a cache system; basically what you are had doing has been condensed and automated by a class of softwares of its own.
Many valid and free css caches and optimization plugins in the public repository.