Bundle Size After a CSS Split: Measuring What Actually Changed

Quick answer

Splitting one 6,262-line stylesheet into 19 component files in PostX - a WordPress plugin used by 40,000+ users - was expected to cost bundle size. My first before/after build comparison appeared to confirm that, showing growth on two assets. That comparison was wrong: the commit range I measured across also added new image assets, which inflated the "after" build independently of the CSS work. Isolating those and re-measuring showed the opposite result - a 20-30% reduction on affected assets, alongside the maintainability and developer-experience gains that motivated the work in the first place.

TL;DR

TL;DR summary
What I expected	More files = more per-file overhead = a larger bundle. A cost worth paying for maintainability.
Outcome	A 20-30% reduction on affected assets once the unrelated image additions were excluded
Developer experience	19 independently editable files replaced one shared blast radius - edit a field type without risking the rest
Plugin context	PostX, WordPress Gutenberg plugin, 40,000+ users

The setup

PostX's block settings panels all drew from one shared stylesheet - 6,262 lines, everything in one file. Editing any field type meant opening a file that controlled every other field type. That's a fragile setup, and it was actively slowing feature work down. The fix was to extract each component's styles into its own dedicated partial: one file for toggles, one for color pickers, one for typography controls, and so on - 19 files total under a new editor_styles/ folder. The full technical case study → documents how that extraction worked, commit by commit.

Why I expected the bundle to grow

When SCSS compiles, each @import pulls a partial's contents into the output. With 19 separate partials instead of one file, there's per-file overhead that can compound - repeated media query wrappers, duplicated structural declarations, and other boilerplate that a single file would have kept in one place. That reasoning is sound in the general case. It just wasn't what happened here.

The measurement that was wrong

My first check compared built output at the before and after commit hashes and showed growth on two assets. I documented it as an accepted trade-off and moved on. The problem was the comparison itself. The commit range I measured across didn't contain only the CSS refactor - it also included newly added image assets. Those images landed in the build output and inflated the "after" side, but they had nothing to do with splitting the stylesheet. The measurement was real; the attribution was not. This is the classic confound in a before/after build comparison: two commit hashes differ by everything that happened between them, not just the change you have in mind.

What re-measuring showed

Excluding the unrelated image additions and comparing only the effect of the CSS restructure, the affected assets came in 20-30% smaller than before the split. That direction makes sense once the confound is removed. Extracting each field type into its own partial meant reading every rule in the monolith and deciding where it belonged - which surfaced duplicated declarations and dead rules that had accumulated since 2019 and had been invisible inside a 6,262-line file. The core stylesheet itself dropped from 6,262 lines to 2,529, a 60% reduction. Restructuring didn't just move the CSS around; it removed a meaningful amount of it.

The developer experience gain

The bundle result is the smaller story. The reason the work was proposed was maintainability, and that's where the change is most visible: 1. The blast radius is gone. Editing toggle styles used to mean opening a file that also controlled color pickers, typography controls, dropdowns, and every other field type. Now each component owns its own file. A change to one can't silently break another. 2. Changes are findable. "Where do toggle styles live?" has an obvious answer - editor_styles/toggle.scss - instead of requiring a search through 6,262 lines. 3. Review is scoped. A diff touching one component's styles is legible on its own. Previously every stylesheet diff landed in the same file, so reviewers had to reason about what else might be affected. 4. It stops the growth pattern. The monolith was going to keep accumulating as new field types shipped. The component structure gives each new field type a natural home instead of another few hundred lines in the shared file. Paired with the linting and formatting setup → added just before it, the result is a codebase where the structure guides you toward the right file rather than requiring familiarity with a single large one.

FAQ

Why didn't you assume splitting into components would grow bundle size, when per-file overhead is real?

Because the overhead argument only holds if nothing else changes. In PostX, extracting 19 component partials surfaced duplicated and dead rules that had accumulated in a 6,262-line file, and the affected assets ended up 20-30% smaller once those were gone.

Why measure in an isolated worktree instead of just comparing plugin output directly?

Because the two commits being compared have to differ only by the change being measured. If unrelated assets land in the same range - images, vendor files, new features - the delta describes all of that too, not just the refactor.

Why would the refactor still have been worth it if the bundle had grown?

Because size reduction was never the justification - the monolithic file's regression risk and drag on feature work was. That argument stands on its own regardless of what the bundle-size measurement came back as.

Part of the PostX frontend refactoring case study series →

On this page