I recently wrote Here’s the thing about “unused CSS” tools, where I tried to enumerate all the challenges any tool would have in finding truly “unused” CSS. The overarching idea is that CSS selectors match elements in the DOM, and those elements in the DOM come from all sorts of places: your static templates, dynamic templates based on server-side state, and of course, JavaScript, which can manipulate the DOM in any way at all, including pull things from APIs and third parties.
With all that at play, how can any tool give us a truly accurate picture of unused CSS, to the point that actually removing that CSS isn’t just as dangerous as leaving it alone?
So, I said:
And yet, I don’t think these tools are useless — they are just…tools. Their use can actually be a positive step toward better code. Their use says OK, I admit it, I’m a little afraid our CSS. You could use this tool to get a broad picture of what your unused CSS might be, then combine that with your own knowledge of your CSS code base to make more informed decisions.
I stand by that, and it’s worth pointing out some successful use cases.
Sarah Dayan just wrote How I dropped 250KB of dead CSS weight with PurgeCSS. She was using Tailwind CSS, an atomic CSS library that a lot of people have had success with.
In my case, not only did I load the entire Tailwind CSS library, but I also added several variants to some modules. That ended up making the final minified CSS file weight 259 KB (before GZip).
It’s a tenth of that when gzipped, but still, that’s a lot of CSS. Tailwind recommends using PurgeCSS, and that’s what Sarah did. PurgeCSS doesn’t handle any of things I mentioned, like state variations and JavaScript and whatnot, but it does look at any static files you’d like it to—both content and CSS—and do analysis from those. Even better, Sarah knew she had some third-party stuff going on, so handled that situation specifically:
PurgeCSS can’t detect that I need to keep selectors such as
.ais-Highlight
, because the components that use it only show up in the DOM at runtime.
So she split off some of that CSS and updated the configuration. Then…
With this new configuration, my final CSS file has gone from 259 KB to…9 KB!
I love it. Using the tool, being super aware of what is happening on your site, and making final choices for a combined win.
Sarah also mentions how this concept of unused CSS is related in spirit to the concept of unused JavaScript. In JavaScript, it’s referred to as tree shaking, and as Jeremy Wagner puts it:
Tree shaking is a form of dead code elimination.
I trust the tooling for tree shaking much more implicitly. These are tools written in JavaScript to look at JavaScript to discover JavaScript that isn’t used. It seems like the intersection of technology isn’t as wide when we’re talking about tree shaking. Still, there could be things like configured third parties that call public functions on your site, or event handlers directly on HTML elements. Those things seem a bit more rare to me these days, but that’s just my own experience bias.
So we tweet this article and the first response is… just use this!
https://uncss-online.com/
That’s very cool that that exists and stuff, but really doesn’t cover the barest of minimum of concerns I’m trying to talk about.
And like I said in my original article:
This week’s one I saw being shared like crazy is this one:
https://unused-css.com/
Get the premium plan for just $756.00 a year.
I’m probably wrong but dropping 250Kb from 259Kb, I can’t stop thinking this css framework wasn’t worth using in the first place.
While I’m not a huge fan of tailwind — I personally just don’t like the ergonomics of atomic-style css — I do feel it’s worth defending in this context.
Tailwind isn’t really designed to be used in its entirety. It’s more like a library which generates classes that you selectively pull from and tree-shake/configure away the rest. In reality, you could configure it to generate 2kb of classes or somewhere way above the 250kb quoted in the article.
It’s actually a rather cool concept for a library and it fits very nicely into this conversation of unused css.
I do think tools like this are handy in some cases but it still doesnt solve the problem in the first place. I feel developers are getting more lazy by the day because all the tools floating around that will “Solve” the problem they created.
A couple of day’s ago i have read an article about the problem with css-in-js and that they had problems with caching, so the solution was to have a gulp tool gather and extract all the css in the js files and create a css file for better caching. Like WTF? and my personal opinion is that tools like this are in the same category. Developers being lazy/using wrong work methodes.
It is true that PurgeCSS does not solve everything. While the accuracy is high, it is not at the moment a tool I would recommend using without knowledge of it being in your projects.
PurgeCSS is still a young project and a work in progress. It has been designed with 100% accuracy in mind and also to work with javascript generated classes.
Once upon a time I used UnCSS (like PurgeCSS) with BackstopJS (Visual Regression Testing).
I set up Backstop first and ran a test of all my templates. Then, I ran UnCSS and another BackstopJS test. BackstopJS notified me if anything had changed. Since the only thing that had changed was adding UnCSS to the pipeline, if anything broke I knew I could pivot to account for those unwanted changes.
I was able to remove unused CSS with a modicum of confidence. The two tools complimented themselves well.