Similar to “tabs vs spaces” you’ll find WordPress developers who are passionate about their opinions on whether or not plugin and theme styles and scripts should be minified or not.
I personally think that developers should be doing everything possible to make their plugins have the lightest footprint possible on a users website.
Those who argue against it typically argue that minified scripts are difficult and tedious to troubleshoot. That’s absolutely true, but that’s not a reason to not use them in your theme or plugin. At least not if you are doing so responsibly. That’s what this article is about.
There are a few strong reasons to use minified scripts in your plugins and themes.
This to me is the most important reason. When you are shipping code for others to use you want to be as considerate of their website as you can be. This goes along the lines of why you include inline documentation and easy to read function names.
Shipping the smallest files you can to your users tells them that you know their bandwidth and page speed is important to you.
Unfortunately, one downside to concatenation in WordPress is that sometimes scripts or stylesheets don’t concatenate well. This can happen for a wide variety or reasons, but I find overall that is rarely happens if the files have already been minified before concatenation.
If one of your users tries to concatenate their files and finds out that it’s YOUR plugin or theme which is making it difficult to do so, they won’t be so happy with you. This helps avoid that unpleasantness.
PRO TIP: Avoid JS errors with minification plugins by always starting your JS file with a semicolon (;), and prefix all your functions or variable, like “e” which gets used a lot with JS.
This is really something many people don’t think of often enough. Bandwidth is a real resource. It uses processing power which uses electricity. The more bandwidth you use the more electricity you use the more natural resources we all use.
So maybe your un-minified script is 12kb and minified it’s just 6kb. That’s only 6kb, who cares!? Well, think of all the times that extra 6KB is going to be uploaded and downloaded every time your plugin or theme is loaded, updated, downloaded, etc. Even if you just have 100 users, that’s already 600KB extra per page visit. What if ONE of your users gets 1,000 visitors a day ? That’s not a huge amount of traffic for a WordPress site at all. But in extra KB that’s 6MB extra a day, times 356 days in a year that’s 2.13GB of extra bandwidth just from the visits to that one user’s site.
Bandwidth environmentalism matters in my opinion.
There are a lot of ways to minify files. There’s even online tools for it. But doing it responsibly requires using a pre-processor like Node, Gulp, or Grunt. This is because this is the best way to provide both the minified and un-minified versions of your scripts.
I hear you saying: “Wait a minute!? You just preached about bandwidth environmentalism and you’re including BOTH scripts? That’s waseful!”
It’s true that including both scripts affects the download/upload size of your plugin or theme, but what we’re going to do is make sure only one of those versions is loaded on the site. That is where the vast majority of the size difference really matters.
A common technique for including both the un-minified and minified version of a stylesheet, for example, is to have multiple smaller .scss files which are brought together into one “build” file, and then that file is minified and saved in the root of your theme as your main stylesheet.
That is the technique I use in my Beyond 2016 theme. You’ll notice in the assets folder there’s a “source” sub-folder and a “build” sub-folder. In “build” you’ll see main.css. That’s the unminified version. My Gulp script then minifies that and saves it to the root of my theme folder which is what the theme can then enqueue publicly.
I specifically do it this way so that I can ship the unminified version with the theme rather than including all the .scss files. If you wanted to ship all the .scss files with your theme that’s possible as long as you also include sourcemaps so that Dev Tools can point your users to where the CSS comes from originally. Read more on that from Google here.
Now that we have all the files included correctly in our theme, we need to provide the user with a way to troubleshoot with the unminified version.
Any WordPress developer worth their salt knows that to properly troubleshoot a WordPress site you need to enable WP_DEBUG. Since that is already common practice for troubleshooting with WordPress we might as well leverage that for triggering loading the unminified version of your scripts. I mean, afterall, the user enabled WP_DEBUG to do some debugging, we might as well assume that our scripts should be ready for them.
Here’s a rather simple function I use in my Beyond 2016 theme to do just that:
You can see it in action in my Beyond 2016 theme here: https://github.com/mathetos/beyond2016/blob/master/functions.php#L24-L34
Let’s break that down a bit.
Naturally, you could add settings into your plugin or theme to minify/de-minify your scripts and styles instead of relying on WP_DEBUG, but I like avoiding adding more options and automating this action based on the users intent.
Put this all together and it’s relatively simple. Enjoy!
Chrome Dev Tools actually has a little tool that can un-minify CSS and JS for you. See the animation below. The one small caveat with this is that if you are providing support for your theme/plugin and refer to a line-number in the stylesheet, it might not be identical using this tool. Still, it’s awesome-sauce for those times when an un-minified version is not available.