Why You Should Avoid Adding CSS In The Theme Customizer In WordPress

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:

1. Syntax checking
2. Live preview
3. Explanation of errors
4. Indentation
5. 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!