The Hidden Weight of Stylesheets
CSS remains one of the most essential technologies on the web, capable of everything from subtle layout tweaks to hue-rotate() image manipulation. Yet its very nature makes it a performance liability. Stylesheets sit squarely in the critical rendering path, blocking paint and sometimes even delaying JavaScript execution. The solution isn't to abandon CSS—it's to ship less of it.
The problem is often more straightforward than hunting down unused selectors within a single file. Many sites, particularly WordPress installations, load entire stylesheets that serve no purpose at all. Plugins and blocks frequently come bundled with CSS, regardless of whether you're actively using their features. On this very site, there are a few such files loading right now—small, but entirely unnecessary.
Exposing Rogue Stylesheets
Stoyan's new bookmarklet, CSS Me Not, offers a quick solution to this problem. It scans the current page and lists every stylesheet that's been loaded, making it easy to spot files that never should have been requested in the first place. The convenience factor is genuinely helpful, but the bookmarklet has a more compelling feature attached: the ability to disable any of those stylesheets on the spot for testing.
Running it here reveals four WordPress-generated stylesheets tied to settings and plugins that aren't actually needed. Seeing them all in one place makes cleanup feel far less daunting.

If you'd rather avoid installing anything, the same outcome is achievable through DevTools. Filter network requests by CSS, locate the offending file, right-click to block it, and reload. The process is manual and slightly slower, but equally effective for verifying whether a given stylesheet can be safely removed.

Beyond Whole-File Removal
Eliminating an entire stylesheet is the obvious low-hanging fruit. The trickier work begins when you need to strip unused CSS from files that contain a mix of used and dead rules. Tools like UnCSS can help in theory, but they only give you a laboratory view—what happens on a test render may not match the reality of production usage.
For sites with real traffic, a more reliable method exists. One approach is to instrument every CSS declaration at build time: attach a transparent 1×1 pixel background-image to each selector. Then, instead of guessing which rules matter, you check the server logs after a week of production traffic to discover which image requests were actually made. The ones that never appear correspond to selectors you're safe to discard.



