A reference for cleaning up an existing site’s CSS that’s grown “held together with string and sellotape” — usually the result of a framework being shipped wholesale years ago, with real site styling bolted on top rather than integrated.
Step 1 — Diagnose what you’re actually dealing with
Before cutting anything, figure out the shape of the problem. A common pattern on older sites: the stylesheet turns out to be an entire CSS framework (e.g. Foundation, Bootstrap) shipped untouched, with the site’s own custom classes bolted on at the very end rather than the framework being trimmed to what’s needed.
Signs of this pattern:
- The file is large relative to how visually simple the site actually looks (e.g. 150KB+ for a site with no complex UI)
- You can spot a framework’s naming conventions (grid classes, component prefixes) throughout most of the file
- Your own site-specific classes are a small fraction of the total, usually clustered at the end
Step 2 — Inventory what the site actually uses
Go through the real pages and note every distinct UI pattern in use — nav, hero/slider, forms, content lists, footer, and so on. Then compare that list against everything the stylesheet defines. Frameworks bundle dozens of components “just in case” that many sites never touch — a real example list of unused components found this way: joyride tours, a lightbox gallery, range sliders, toggle switches, pricing tables, tooltips, modals, split buttons, side-nav, sub-nav, tabs, and accordions.
Caveat worth being upfront about: if you’re checking this from rendered page content rather than raw HTML with class names, you’re working from what’s visible on the pages you checked, not a guaranteed complete picture. A page you didn’t check could still be leaning on a component you’re about to remove.
Step 3 — Keep only what’s actually load-bearing
Prune the stylesheet down to just the components genuinely in use. In the real example this guide is based on, the kept list was:
- Grid system (rows/columns/block-grid)
- Buttons
- Forms (needed for a contact page)
- The homepage hero slider component
- Top bar + off-canvas mobile navigation
- Basic typography, tables, text alignment
- All of the site’s own custom-prefixed classes, left untouched
Everything else — the unused framework components identified in Step 2 — gets cut. In that real case, this took the file from 155KB / 7,260 lines down to 91KB / 4,354 lines, roughly a 40% reduction, without changing how any page actually looked or behaved.
Step 4 — Leave a paper trail
Add a comment block at the top of the pruned file listing exactly what was removed and why. This matters practically: if a page turns out to rely on something that got cut (missed in the Step 2 audit), it’s easy to go back to the original, unpruned file and pull just that one component back out — rather than having to redo the whole audit or restore the entire bloated file.
Step 5 — Verify braces/syntax integrity
After manually removing large blocks from a minified or semi-structured CSS file, do a basic sanity check that braces are still balanced and the file parses cleanly before treating it as final — easy to accidentally leave a dangling { or } when cutting blocks out by hand or with find-and-replace.
Step 6 — Test on staging before going live
Don’t push a pruned stylesheet straight to production. Test it on a staging copy of the site first, specifically checking any pages that weren’t part of the original audit — this is the safety net for the caveat in Step 2, where “no accordions/tabs/galleries anywhere I could see” is only as reliable as the pages actually checked.
The underlying principle
This isn’t really about CSS syntax — it’s an auditing exercise. The core move is always the same: compare what’s shipped against what’s actually used, keep the overlap, cut the rest, and document the cut so it’s reversible if the audit missed something. The same approach applies whether you’re pruning a legacy Foundation/Bootstrap stylesheet, an old jQuery plugin bundle, or any other “we shipped the whole toolkit years ago and never looked back” situation.