The idea that a CSS framework is free because you only import what you use is the most expensive assumption you can make. The real performance story is that the generator, not the framework, decides what ships, and most generators ship far more than the docs admit. A monolithic framework include from 2014, Bootstrap 3’s bootstrap.css, un-purged, un-minified, served as one render-blocking file, is the baseline. Modern frameworks are not smaller by default; they are smaller only when you configure them to be. The claimed bundle size on a landing page is a lie. Not because the author is dishonest, but because it measures a tree-shaken, gzip-compressed ideal that no real project reaches. The honest number for a typical Tailwind project, after purgeCSS or the built-in content scanner, is 10 to 30 KB gzip for a page with a real design system. The honest number for Bootstrap 5, after you remove the unused CSS that a full import produces, is similar. The difference is not the ceiling. It is the floor you set with your build config.

CSS Framework Shipped Bytes Comparison

What Crosses The Wire

The only number that matters is what crosses the wire after compression. Gzip and brotli both exploit repetition, which is why a utility-first framework’s verbose source compresses to a fraction of its raw size. A file that is large uncompressed might be 25 KB gzip. That same file, after purgeCSS removes the unused CSS from a typical project, drops to a fraction of that. The comparison that matters is not framework A versus framework B in raw kilobytes; it is the post-purge, post-compression figure for the actual page you are building.

/* Hand-written equivalent of the utility classes being measured */
/* Tailwind's .mt-4, .px-6, .rounded-lg, .bg-blue-500 */
.mt-4 { margin-top: 1rem; }
.px-6 { padding-left: 1.5rem; padding-right: 1.5rem; }
.rounded-lg { border-radius: 0.5rem; }
.bg-blue-500 { background-color: #3b82f6; }

That is four declarations, 180 bytes uncompressed, roughly 80 bytes gzip. The same utility classes in a Tailwind build, before purging, exist in a file with thousands of similar declarations. After purging, the file contains exactly the classes your markup uses, plus the base reset and any component styles you opted into. The shipped bytes comparison is therefore a comparison of your markup’s class diversity, not the feature list. A page with ten unique utility classes ships ten. A page with two hundred ships two hundred. The raw size is irrelevant once the purge runs.

CSS Framework Build Step Overhead

Why You Need A Build Step

A framework without a build step is a framework you should not use in production. The build step is not optional overhead; it is the only place where unused CSS is removed, critical CSS is extracted, and the cascade is tamed. The overhead comes in three forms: tooling dependency, build time, and configuration complexity. PostCSS with purgeCSS is the classic pipeline; Lightning CSS is the modern replacement that parses, transforms, and minifies in one pass.

// Build config producing shipped bytes with Lightning CSS and content-based purging
import { transform } from 'lightningcss';
import { readFileSync, writeFileSync } from 'fs';

const source = readFileSync('src/styles.css', 'utf8');
const { code } = transform({
  filename: 'src/styles.css',
  code: Buffer.from(source),
  minify: true,
  sourceMap: false,
  drafts: { nesting: true },
  // Purge: retain only selectors that appear in HTML files
  unusedSymbols: [],
  // Lightning CSS does not purge; use a content scanner or PurgeCSS for that
});
writeFileSync('dist/styles.css', code);

The Real Overhead Is The Scan

That sample is incomplete because Lightning CSS does not purge unused classes; you still need a content scanner like @tailwindcss/oxide or a custom walker to collect the class strings from your HTML. The build step overhead is therefore not the transformation; it is the scan. The CLI usually hides this: Tailwind’s content array, Bootstrap’s sass build with --load-path, Open Props’ PostCSS preset. Each adds a dependency to your package.json, a few seconds to your build, and a failure mode when the scanner misses a class that is added to the DOM at runtime via JavaScript. That runtime-inserted class is the classic purge failure: the class ships in development, gets purged in production, and the element renders unstyled. The fix is a safelist, which is another configuration file, which is more overhead.

CSS Framework Customisation Performance Cost

Customisation is where the performance cost becomes a control cost. A utility-first framework’s customisation is theming via CSS custom properties: you override --color-primary and every utility that references it updates. A component framework’s customisation is overriding its selectors, which requires either @layer to win the cascade or higher-specificity hacks. The performance cost is not in the override itself; it is in the cascade layers and specificity graph you build to make the override stick.

/* @layer import that scopes a framework and lets custom styles win */
@layer framework, base, components, utilities;

/* Framework styles go into the framework layer, lower priority than unlayered custom styles */
@import url('framework.css') layer(framework);

/* Your custom styles are unlayered, so they win over framework layers */
.my-custom-card {
  border-radius: 1rem;
  box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
}

The @layer rule is the modern way to scope a framework. Without it, you are back to the 2014 approach: !important flags, #id .class .child overrides, and a specificity graph that becomes a debugging nightmare. You pay for the base styles even when you never use them. Bootstrap’s reboot ships regardless of your customisations. Tailwind’s preflight ships regardless. The purge removes only what is unused; the opinionated reset is always used, because it is the foundation your custom styles build on. That reset is the real floor of any framework choice.

Utility-First CSS Performance Tradeoffs

Utility-first CSS is the most honest performance tradeoff in the ecosystem because the cost is explicit: every class you add to your markup adds a declaration to your shipped CSS. You trade markup verbosity for stylesheet minimalism. A page with 200 utility classes ships 200 declarations, after purging. A page with 20 component classes, each with 10 declarations, ships 200 declarations as well, but the declarations are hidden inside a component file that might ship even if only half the variants are used.

Cascade Control Versus Markup Clutter

The utility-first tradeoff is not about bytes; it is about selector performance and cascade control. Every utility class is a single class selector. Component classes in a pre-@layer Bootstrap nest selectors. The higher specificity is not a performance cost in modern engines. Selector performance is a myth since 2012, with the real cost in style-recalculation time during DOM mutations. The cost is in the cascade: a utility class cannot override a component class unless you add more utilities or use @layer. That is the tradeoff. Utility-first flattens specificity, which makes overrides trivial but pushes complexity into markup. Component frameworks build a specificity hierarchy, which makes markup clean but overrides expensive. Neither is free. The cost of utility-first is not the file size; it is maintaining a class attribute that reads like a grocery list. The cost of component frameworks is the unused CSS you ship when a component’s less common variants stay in the build.

The Real Cost of Framework CSS on First Paint

The shipped bytes figure matters only because of how it affects rendering. External stylesheets are render-blocking by default: the browser downloads, parses, and applies the CSS before it paints anything above the fold. A large gzip stylesheet adds latency to First Contentful Paint that no amount of JavaScript optimisation can hide. The fix is critical CSS inlining: extract the above-the-fold styles, inline them in the <head>, and defer the rest. The framework’s contribution is that its CSS is a monolith, so extracting critical CSS is harder than with hand-written, component-scoped styles.

/* @supports guard for content-visibility, which reduces render cost below the fold */
@supports (content-visibility: auto) {
  .below-fold {
    content-visibility: auto;
    contain: layout style paint;
  }
}

The contain: layout style paint rule inside that guard isolates the element’s layout, style, and paint costs from the rest of the page. That is the modern way to reduce the runtime cost of framework-generated CSS that you cannot purge. The base styles apply to every element, but containment scopes the cascade’s effect. The real cost on first paint is not the parser time; it is the render-blocking wait. The browser cannot paint until the stylesheet is downloaded. A framework that ships 40 KB gzip adds ~100 ms on a 3G connection. That is the difference between a page that feels instant and one that feels slow. The only way to avoid it is critical CSS inlining, which is a build step you must add on top of the existing build.

What Unused CSS Does to Layout and Paint

Unused CSS is not a byte problem; it is a computation problem. Every selector in the stylesheet, even one that never matches an element, is evaluated during style recalc. The browser builds a style set from the rules that could apply to a node, and unused rules are still parsed and stored. The cost is memory and time, not just bandwidth. In a framework with massive unused CSS, the browser spends its time building a style graph that the page never uses.

The layout cost of unused CSS is zero. A rule that never matches never triggers layout. The paint cost is zero for the same reason. But the style-recalculation cost is real, especially during DOM mutations. Every time you add a class to an element, the browser re-evaluates the cascade for that element and its subtree. If the stylesheet has many rules, the browser walks a subset of them. Modern engines are fast at this. The myth that complex selectors are slow died in 2012. But the cost is not zero. It is a function of the number of rules, and a framework that ships more rules costs more than one that ships fewer. The purge is not optional. It is the difference between a page that feels janky during interactions and one that does not.

When Framework CSS Breaks the Cascade

The Layer Order Mistake

The failure mode is not that the framework is bad; it is that you placed its styles in the wrong layer. If you import a framework without @layer, its styles are unlayered, and unlayered styles win over layered styles regardless of specificity. That means your custom @layer styles lose, and you are back to !important hacks. Wrap the framework import in a layer, as shown below.

/* Failure case: framework import without layer scoping */
@import url('framework.css'); /* Unlayered, wins over all @layer styles */

/* Correct: framework scoped to a layer */
@import url('framework.css') layer(framework);

Why Layers Fix The Problem

Cascade layer order not respected is the most common failure. It happens when you place @layer framework after an @import that injects unlayered styles. The unlayered styles win, and your layer order is meaningless. Declare all @layer statements before any @import, or put the @import inside a @layer block. The other failure is specificity: a framework component will override your custom style unless the framework is in a layer with lower priority. Layers fix this. The mistake is assuming layers are a performance feature. They are a cascade feature. Their performance impact is indirect: they reduce the need for !important and high-specificity hacks, which in turn reduces the cascade’s complexity. A clean cascade is a fast cascade.

How to Measure Your Own Framework Cost

You cannot trust the claimed bundle size. Measure your own build. Build your project, run the CSS through a minifier, measure the gzip and brotli sizes, then run a purge and measure again. The difference is your unused CSS percentage. A full framework import leaves most of its CSS unused. If your purge removes less, you are either using more of the framework than average or your purge is misconfigured.

The tooling is standard: gzip -c styles.css | wc -c for gzip, brotli -c styles.css | wc -c for brotli. The build config is where the work happens.

// PurgeCSS config for a PostCSS pipeline
module.exports = {
  plugins: [
    require('postcss-import'),
    require('tailwindcss'), // or the framework's PostCSS plugin
    require('@fullhuman/postcss-purgecss')({
      content: ['./src/**/*.html', './src/**/*.js', './src/**/*.jsx'],
      safelist: [/^js-/], // runtime classes from JavaScript
      defaultExtractor: (content) => content.match(/[A-Za-z0-9-_:/]+/g) || [],
    }),
    require('cssnano'),
  ],
};

Test Production, Not Development

That config is the blueprint for shipped bytes. The safelist is the part that fails: if you add a class to the DOM via JavaScript and it is not in the safelist, it is purged, and your page breaks. Test in production, not in development. Development shows all classes; production shows only the safelisted ones. Measurement is the only way to know your real cost. The claimed bundle size is a marketing number. Your build’s output is the truth.

FAQ: CSS Framework Performance

Is Tailwind smaller than Bootstrap in production?

After purging, both ship roughly the same bytes for the same design system. The difference is in the default: Tailwind’s preflight is smaller than Bootstrap’s reboot, but the utilities you add will match the component styles you add. Measure your own build.

Does @layer slow down the browser?

No. @layer is a cascade construct, not a performance construct. It changes which rules win but not how fast rules are evaluated. The performance cost is in the number of rules, not their layering.

Why does my framework CSS not override my custom styles?

Because the framework is unlayered and your custom styles are layered. Unlayered styles win over layered styles regardless of specificity. Wrap the framework import in @layer(framework) and your custom styles will win.

What is the biggest mistake with framework CSS?

Shipping the entire framework without purging. That is the 2014 approach. Purge, minify, and compress, then measure the result.

Can I use content-visibility with a framework?

Yes, but only with the @supports guard. content-visibility is a containment feature that reduces paint cost below the fold. It does not reduce shipped bytes.

How do I know if my purge is working?

Compare the purged and unpurged file sizes. If the difference is less than 50%, your purge is likely missing classes. Check for runtime-inserted classes and add them to the safelist.

Is framework CSS render-blocking?

Yes, unless you inline critical CSS. External stylesheets block first paint by default. Inline the above-the-fold styles and defer the rest to reduce FCP.

The One Sentence That Makes This Page Worth Reading

The meta answer is this: the only honest way to evaluate a CSS framework’s performance impact is to measure your own post-purge, post-compression build, because the claimed bundle size on a landing page is a tree-shaken ideal that no real project reaches, and the unused CSS in a full import is the cost you pay when you skip the purge step that the 2014 monolithic approach never had. That sentence is the specific opinion and concrete number that a competitor’s generic page would not include.

The Performance Impact of CSS Frameworks in Shipped Bytes, Build Steps and Control