Utility-first CSS is often accused of bloat because elements carry long lists of tiny classes. Compare how the shipped CSS actually scales in a utility-first codebase versus one built from semantic component classes, and say where each really pays its cost.

## Two different growth curves The bloat accusation compares the wrong things. Look at what each model's output is a function of. **Component-class CSS is a function of component count.** Every new component adds a new block of rules. A product with 400 UI components has 400 blocks, plus modifier rules for their variants. This curve does not flatten, because component 400 needs its own padding, border and colour rules just as component 1 did — even when those declarations are identical to ones already in the file. Duplication is invisible: `padding: 1rem` may appear 180 times across the stylesheet under 180 different selectors. **Utility CSS is a function of distinct-utility count.** `.p-4` exists once no matter how many components need 1rem of padding. So the size depends on how much of the vocabulary the product touches, and that number saturates: by the time you have built thirty screens, the thirty-first mostly reuses spacings, colours and layout utilities that already exist. New output appears only when a screen needs something genuinely new. In practice this produces a curve that rises quickly and then flattens. ```css /* component model: the same declaration, re-expressed per component */ .card { padding: 1rem; } .panel { padding: 1rem; } .dialog { padding: 1rem; } /* utility model: expressed once, referenced from markup N times */ .p-4 { padding: 1rem; } ``` ## Why the component stylesheet ratchets upward The deeper problem is not growth but **irreversibility**. Deleting `.card` safely requires knowing that no template, no content-managed page, and no piece of markup generated anywhere still carries the class. That is hard to prove, and getting it wrong breaks a page in production. So the rational individual choice is always to add rather than to edit, and the file becomes append-only. Over years, a meaningful fraction of a large stylesheet is rules that nothing renders any more. Utility CSS does not have this problem in the same shape, because a utility is not owned by any component. If the last usage of `.gap-2` disappears, the class becomes unused but harmless, and the generated output shrinks by one rule the next time it is built. There is no equivalent of an orphaned 60-line component block that nobody dares touch. ## Where utility-first pays The cost moves to markup. An element carrying twelve classes carries them on every instance, so a table with 200 rows repeats the cell's class string 200 times. Two things soften this: - **Compression.** HTTP responses are compressed, and the repeated identical strings that make utility markup look bloated are precisely what compression algorithms collapse best. The wire cost is far smaller than the raw byte count suggests. - **Componentized markup.** If the class string is written once inside a template and rendered many times, the *source* is not duplicated at all — only the output is. But it does not vanish. On a very large server-rendered document, per-instance class strings are real transferred bytes, and unlike a stylesheet they are not cached across pages — a stylesheet is fetched once and reused, whereas markup ships with every response. That is the sharpest form of the criticism and it is worth conceding. ## The caching asymmetry, both ways A component stylesheet is cached, but any change to it invalidates the whole file for every returning user. A utility stylesheet changes only when the *vocabulary* changes, which is rare after the system settles — routine feature work edits markup instead. So utility-first tends to produce a more stable, longer-lived cached stylesheet at the price of larger, per-request markup, while the component model produces smaller markup and a stylesheet that churns. ## Being honest about the numbers Do not claim utility-first is unconditionally smaller. It usually wins on a large application with many repeating patterns, where declaration reuse is high. It can easily lose on a tiny site: three pages of bespoke design do not amortise a vocabulary, and hand-written CSS for three components is smaller than any generated utility set. The general rule is that utility-first's advantage is a *scaling* advantage — it shows up as the codebase grows, and is invisible or negative at small size. A good answer also notes that stylesheet bytes are rarely the thing that hurts most; a stylesheet you are afraid to edit costs more engineering time than a few extra kilobytes cost users. Frame it as maintainability first, size second.