Refactoring CSS: Optimizing Size And Performance (Part 3) — Smashing Magazine

Shrinking Stylesheet Payloads

Once a CSS codebase has been refactored for maintainability, the final stylesheet still needs to be tight. Unoptimized CSS means larger downloads, slower rendering, and a poorer experience for users. Several techniques can trim file size without changing what the stylesheet does.

Minification Is The Baseline

CSS minifiers such as cssnano and clean-css have long been standard tools in frontend performance work. They parse the source, transpile it according to configuration options, then strip whitespace, line breaks, and other non-essential formatting. Depending on the config and the browsers you target, they may also drop deprecated vendor prefixes.

The payoff can be significant even for small inputs. A basic rule set might drop from 76 bytes to 55 bytes after optimization — a roughly 23% reduction. Larger codebases and more aggressive configurations can yield even better results. Because the effort is just a few workflow tweaks, minification should be treated as a mandatory step for every stylesheet, not an optional extra.

Merging Duplicate Media Queries

In multi-file setups using preprocessors like Sass or PostCSS, it's common to write the same media query repeatedly — once per component — to keep related rules together for readability. That pattern produces redundant @media expressions in the final output.

Standard minifiers will not consolidate those blocks. The reason is that CSS is order-sensitive: merging two @media (min-width: 768px) blocks would require moving rules, which can change cascade behavior and break styles. Tools like postcss-sort-media-queries do this grouping work, but only safely if the codebase does not depend on rule order.

Before adopting this optimization, check whether the size savings justify the risk. An audit of media query usage will help you decide. If the benefit seems worthwhile, add the tool later in the refactor process and back it with automated regression tests to catch any cascade side-effects.

Why Removing Unused CSS Is Tricky

Refactoring can leave dead legacy rules behind, and new styles sometimes end up unused. Purging them with tools like purgecss sounds appealing, but automated removal is inherently conservative: the tool scans project files and keeps any class that appears anywhere, including classes injected by JavaScript at runtime. This caution prevents accidental deletion of dynamically used selectors.

You can configure purgecss to handle those edge cases, but the setup, testing, and long-term maintenance costs are real. The risk of breaking pages is higher than with other optimizations, so only pursue this route when the file-size payoff clearly outweighs the effort and potential regressions.

Making CSS Non-Blocking

CSS is a render-blocking resource by default: the browser won't paint anything until all linked stylesheets — and their dependencies like fonts — are downloaded and parsed. When a stylesheet is large or pulls from third-party servers, that delay can be significant.

This matters beyond perceived speed. Largest Contentful Paint (LCP) is now both a performance and SEO concern, as better scores lead to better search rankings. Removing render-blocking CSS from the critical path is one of the most direct ways to bring LCP down.

The obvious countermeasure — simply deferring all styles — produces a Flash Of Unstyled Content (FOUC), where content appears before styling lands. That jarring swap can confuse users, so a more surgical approach is needed.

Critical CSS Inlining

Critical CSS limits what the browser must process to render the initial viewport. For a homepage with a header and hero section above the fold, the critical CSS would cover those components, deferring the rest.

This critical subset is placed directly inside a style tag in the HTML head, so it's parsed with the document. That does increase HTML file size slightly (mitigated by minification), but it removes the blocking cost of a separate full stylesheet and makes FOUC largely imperceptible.

<head>
  <style type="text/css"><!-- Minified Critical CSS markup --></style>
</head>

A broad ecosystem of automated tools and NPM packages exists for extracting critical CSS and managing the deferred remainder.

Deferred Stylesheet Loading

There is currently no native HTML attribute for loading stylesheets asynchronously, so JavaScript is required. The standard pattern requests the stylesheet with link rel="preload" as="style" for an asynchronous fetch, then swaps its rel to stylesheet once onload fires.

<!-- Deferred stylesheet -->
<link rel="preload" as="style" href="path/to/stylesheet.css" onload="this.onload=null;this.rel='stylesheet'">

<!-- Fallback -->
<noscript>
  <link rel="stylesheet" href="path/to/stylesheet.css">
</noscript>

Setting onload to null after the swap prevents duplicate execution and unnecessary re-renders. This pattern also needs a noscript fallback so users without JavaScript still receive the fully styled page in the traditional blocking manner.

Smashing Magazine uses exactly this approach: template-specific critical CSS inlined per page type, with a single deferred main.css holding all non-critical styles. The implementation here toggles the media attribute from print (low-priority, deferred) to all after load — an equally viable alternative to switching rel.

<link href="https://www.smashingmagazine.com/css/main.css" media="print" onload="this.media='all'" rel="stylesheet">

Conditional Loading With Media Queries

When a single stylesheet remains too large after other optimizations, splitting it by media query allows conditional loading via the media attribute on the link element.

<link href="print.css" rel="stylesheet" media="print">
<link href="mobile.css" rel="stylesheet" media="all">
<link href="tablet.css" rel="stylesheet" media="screen and (min-width: 768px)">
<link href="desktop.css" rel="stylesheet" media="screen and (min-width: 1366px)">

Following a mobile-first approach, desktop-only styles won’t download on mobile devices under slower network conditions. This tactic is most impactful when stylesheet size is truly suboptimal; for typical, well-optimized cases it adds marginal benefit.

Font Handling And Server Tuning

Deferring Fonts

Font files referenced inside stylesheets add serious weight to initial render. Deferring font stylesheets can improve first paint, but introduces FOUT (Flash Of Unstyled Text) — the page renders with fallback fonts, then swaps. Layout shifts from font swapping can be disruptive. Barry Pollard’s research covers strategies for mitigating FOUT, including the forthcoming size-adjust CSS descriptor for a more native solution. For Google Fonts specifically, Harry Roberts has documented the fastest-known loading strategy, while Zach Leatherman’s comprehensive guide lays out all viable deferral approaches with their trade-offs and is well worth reading in full.

Compression And Caching

Beyond reshaping code, HTTP-level compression (Gzip or Brotli) and effective caching cut time-to-render. Compression reduces downloaded bytes but not parse work, so it complements rather than replaces CSS optimizations.

Server-side caching via the Cache-Control header (configured through .htaccess on Apache, for example) tells the browser how long to keep files locally. Setting max-age alongside public allows both browser and intermediary caches to hold the file.

 Cache-Control: public, max-age=604800

A more aggressive strategy uses immutable, which tells the browser a file will never change in place — any update produces a new filename, a practice called cache-busting.

Cache-Control: public, max-age=604800, immutable

Without a cache-busting strategy, browsers may endlessly serve an outdated CSS file, and new styles silently fail to appear. Two reliable versioning mechanisms exist:

• Appending a query string to the filename, e.g. styles.css?v=1.0.1. Caveat: some CDNs strip query strings, which breaks the strategy entirely.
• Renaming the file with a hash or version, e.g. styles.a1bc2.css or styles.v1.0.1.css. This is the more robust option.

CDNs vs. Self-Hosting

CDNs distribute static assets globally for faster delivery. But Harry Roberts’ deep-dive concludes self-hosting wins for performance: splitting assets across multiple origins adds connection overhead that erodes CDN location benefits.

"There really is very little reason to leave your static assets on anyone else's infrastructure. The perceived benefits are often a myth, and even if they weren't, the trade-offs simply aren't worth it. Loading assets from multiple origins is demonstrably slower."

Self-hosting stylesheets (and font files) by default is the sound baseline, moving to CDN only when specific benefits justify it.

Auditing With Web Vitals

Tools like WebPageTest provide granular insight into file sizes, blocking resources, and load behavior across a spectrum of devices and network conditions.

For the sample site from the first article in this series — the one shipping 2MB of minified CSS — the content breakdown reveals distinct patterns. Images dominate the request count, flagging a clear need for lazy loading. Meanwhile, stylesheets and JavaScript account for the largest share of transfer bytes.

The LCP chart offers a direct view of which resources are actually blocking initial render. In this case, the main stylesheet has the greatest impact, but font stylesheets, JavaScript files, and image references within those stylesheets are all compounding the LCP problem. Each is a target for the deferral and splitting techniques above.

Performance Is Part Of The Refactor

Code health and quality improvements are only half of a successful CSS refactor. A refactored codebase must deliver the same or improved performance compared to what it replaced. Users should not see new lag or longer load times just because the stylesheets have been reorganized. Fortunately, the toolset for keeping CSS fast is well established, ranging from straightforward minification to more advanced techniques like removing render-blocking resources and splitting code by route or component.

Performance auditing tools such as WebPageTest provide a detailed view of load times, render-blocking files, and other bottlenecks. Running these checks early and regularly during the refactor helps catch regressions before they ship and confirms that the cleanup actually pays off in the browser.

Common Optimization Levers

• Minification and compression: Strip whitespace and comments, then serve CSS with efficient compression (e.g., gzip or Brotli).
• Eliminate render-blocking CSS: Inline critical styles for above-the-fold content, defer the rest. Ilya Grigorik’s guide on render-blocking CSS explains the underlying mechanics.
• Defer non-critical styles: Load secondary stylesheets asynchronously with JavaScript or via media attribute tricks. Demian Renzulli’s “Defer Non-Critical CSS” (web.dev) covers practical implementation.
• Code-splitting: Break one large global stylesheet into smaller, feature-specific files loaded only when needed (e.g., per page or component).

Fonts And Assets: Often Overlooked

Web fonts are a frequent hidden performance cost. Zach Leatherman’s comprehensive font-loading guide lays out the trade-offs of modern strategies. Barry Pollard’s article on Smashing Magazine discusses CSS font descriptors as a newer way to reduce layout shift and wait time. Self-hosting static assets—fonts, scripts, images—avoids third-party connection overhead; Harry Roberts explains the rationale in Self-Host Your Static Assets. For further reading on font optimization, Ilya Grigorik’s guide on optimizing webfont loading and rendering is a strong reference.