Ograniczanie nieużywanego CSS

Large frameworks and accumulated styles often ship rules no page uses. Unused CSS inflates download size and parse time, and because CSS is render-blocking, it directly delays first paint.

The DevTools Coverage tab records which CSS bytes actually apply during a session. A high unused percentage signals an opportunity to trim.

Utility and component frameworks include thousands of classes for flexibility. If you use a small subset, the rest is pure dead weight unless removed at build time.

Tools like PurgeCSS scan your templates for class names and strip any selector not referenced, often cutting stylesheets by 90% or more.

Utility frameworks like Tailwind scan your content files and generate only the classes you actually use, producing a tiny production stylesheet automatically.

Purgers work by string matching. Class names built dynamically can be wrongly removed. Use a safelist or full static strings to protect them.

Splitting styles by route means each page loads only its own CSS instead of one global blob. Many bundlers and frameworks do this automatically with CSS code splitting.

Scoped styles via CSS Modules or single-file-component styles keep CSS tied to the component that uses it, making unused styles easier to spot and remove.

After purging, run a CSS minifier (cssnano, esbuild, lightningcss) to strip whitespace, comments, and redundant rules, and compress with Brotli or gzip in transport.

Re-run Coverage and Lighthouse after trimming. Lighthouse explicitly reports Reduce unused CSS with the estimated savings, confirming the improvement.

• Measure with the Coverage tab.
• Purge unused selectors at build.
• Safelist dynamic classes.
• Split CSS per route, then minify.

You learned to cut render-blocking CSS by measuring coverage, purging unused selectors, scoping styles per component and route, and minifying. Watch for dynamically built class names and safelist them so purging stays safe.