Minifying your CSS helps improve your website performance. But as developers, we don’t really talk about minifying CSS anymore. Why?
The TL;DR is that the delivery and optimization of CSS have both been improved with modern tech stacks, making it practically a non-issue. The efficient and performant delivery of CSS is largely solved by HTTP/2 and modern compression algorithms, whilst modern front end frameworks take care of the boring optimization jobs such as code-splitting and minification. Gone are the days when setting up a new front end project involved hours of frustrating manual configuration of Grunt files or Gulp files to compile, minify and post-process CSS files.
Why you should minify your CSS files
Minification in CSS is the process of removing all unnecessary whitespace so that files are smaller in size, but can still be understood by the browser. In short, minifying your CSS helps to optimize your First Contentful Paint (FCP).
FCP is a Core Web Vital that measures the perceived load speed of a web page, and it marks the first point during page load where a user can see anything on the screen. A good FCP score is measured as 1.8 seconds or less and reassures the user that something is loading so that they don’t bounce away. To ensure a good FCP score, your stylesheets or inline CSS should be as small as possible (i.e. minified and compressed) so that they take less time to download and can be processed faster, allowing the browser to paint something on the page sooner. All of the above also contributes to optimizing the critical render path (the steps the browser goes through to convert the HTML, CSS, and JavaScript into pixels on the screen). This is especially important for users who have slower internet speeds.
Additionally, CSS is a render blocking resource, meaning the browser won't show any content until it has downloaded the CSS and constructed the CSSOM (CSS Object Model) in conjunction with the DOM (Document Object Model). This makes sense; most modern web pages won’t function correctly without CSS. Plus, if CSS is loaded and applied after HTML renders on the page, users will experience a Flash of Unstyled Content (FOUC) before the CSS rules are applied. Styling and arranging content after it has loaded will also likely negatively impact your CLS score (we’ve already got enough CLS to worry about with fonts, images and other unexpected issues!). CSS delivered in stylesheets and as inline CSS in the <head> tag of your pages are both render blocking.
CSS minification tools
There are a number of tools available to minify CSS in development or as part of your build pipeline including, but not limited to, cssnano and Vite. If you’re using sass, it’s as straightforward as adding --style=compressed to your sass command. The results you achieve may vary depending on the complexity of your CSS, but you may see numbers similar to this (processed with sass):
| Raw (kB) | Minified (kB) | Saving (kB) |
|---|---|---|
| 78 | 65 | 13 |
What’s interesting, though, is that these numbers pertain to files store on disk. Files delivered from a server will actually be much smaller. And this is where compression comes in.
Modern HTTP compression algorithms
HTTP compression is used by web servers and clients (browsers) to improve the transfer speed of resources, and it also helps to save on bandwidth costs and overheads. There are a number of compression algorithms available, but not all are supported by modern browsers.
Servers may support multiple compression types, and the most common compression types currently used on the web are gzip and Brotli. When making an HTTP request, browsers tell the server which compression methods they are able to decode, at which point the server sends the appropriately compressed file version. Browsers that do not support the available compression methods will receive uncompressed data. While sending and receiving uncompressed data probably isn’t common in 2024, it’s worth bearing in mind for people using older or more niche devices that don’t receive automatic software updates.
You can inspect HTTP request and response headers for network requests in browser dev tools to understand more about what’s described above. Here's an example:
Request headers (sent to the server):
-
Accept-Encodinglists the compression methods the client/browser supports
Response headers (received from the server):
-
Content-Encodingdescribes the compression method used to decode the transferred data -
Content-Lengthprovides the size of the compressed file in bytes
If you’re using Sentry performance to monitor your applications, you can also inspect the response headers for each network request in the associated span.
What’s interesting is that the difference in size between a non-minified compressed file and a minified compressed file isn’t that significant. In the case of the CSS file for my personal website, there was a saving of only 1kB.
| Raw (kB) | Minified (kB) | Saving (kB) | |
|---|---|---|---|
| On disk | 78 | 65 | 13 |
| Compressed | 11 | 10 | 1 |
Whilst 1kB may not seem much, the savings will most definitely benefit both you and your users on a larger scale. As of March 2024 the global median internet speed on mobile is 52.98Mbps. While that equates to being able to download 6625kB per second (calculated here and rounded up to 53Mbps), if you can shave off just 1kB from a total of 100 resources on each page load, you could be making a 15ms improvement on your page speed for those users:
How long does it take to transfer 100kB at 6.625 kB/ms?
6625kB/s transferred
6625 ÷ 1000 = 6.625 kB/ms transferred
100 kB ÷ 6.625 kB/ms = 15ms*
*This is an extremely basic calculation not taking into consideration TCP slow starts or any other network effects that affect data transfer, but it serves as an example nonetheless.
Simultaneously you’ll be saving bandwidth costs as a developer or organisation. While 1kB isn’t much of a saving for a single user, for 1000 users this equates to transferring 1MB less data.
HTTP/2 multiplexing
Another advancement that may mean CSS minification is not-that-important-anymore is HTTP/2. Released in 2015 and adopted over time, HTTP/2 allows the server to use a single connection to deliver multiple requests and responses in parallel (multiplexing). To take advantage of this, front end bundling tools and frameworks provide the ability to “code split” or “chunk” larger CSS files and JavaScript packages in order to ship smaller files simultaneously, whilst the underlying technology pieces those files together in the client for the web page to function correctly.
If a non-minified compressed CSS file is only 10kB, and then split into smaller chunks of, say, 2kB, then minification becomes kind of a non-issue. Additionally, many modern front end frameworks take care of this for us anyway.
CSS minification and code-splitting in front end frameworks
If you’re using a modern front end framework, you’ll usually get CSS minification and/or code splitting out of the box. Frameworks provide their own opinionated, yet sensible default configurations for CSS post-processing, and you can choose to optimize those options further if you wish. Additionally, by serving your websites and applications from modern hosting platforms and CDNs, you’ll benefit from HTTP/2, caching and compression without even having to think about it.
Here’s how just some of the modern JavaScript-based frameworks handle CSS today.
Astro
Astro automatically minifies and combines your CSS into chunks, and further optimizes CSS shared between pages for reuse. Another optimization from Astro is that it “inlines” any CSS chunks that are smaller than 4kB in size (i.e. puts the CSS in a <style> tag in the <head> of the page) to prevent too many network requests for small stylesheets. This provides a “balance between the number of additional requests and the volume of CSS that can be cached between pages.”
Next.js
Next.js comes with a number of pre-configured optimizations for using CSS Modules, Tailwind, Sass and and CSS-in-JS. For example, when using CSS Modules, many smaller files will be automatically bundled into fewer minified code-split CSS files to reduce the number of network requests.
Nuxt
Nuxt comes with postcss and a number of pre-configured CSS minification and optimization plugins including postcss-import, postcss-url, autoprefixer and cssnano.
SvelteKit
SvelteKit uses Vite under the hood to build and bundle projects. This comes with configurable CSS code-splitting and minification.
Where Astro inlines all CSS files smaller than 4kB in size, SvelteKit comes with an inlineStyleThreshold configuration which allows you to explicitly specify the maximum length of a CSS file in UTF-16 code units to be inlined. All CSS needed for the page and smaller than this value are merged and inlined in a <style> block.
Angular
Angular’s build process comes with an --optimization flag which enables CSS minification and inlining of critical CSS. To save even more bytes, you can also choose to use the removeSpecialComments flag during a build to remove comments in CSS and other extraneous characters.
Conclusion
With the luxury of modern web hosting platforms and CDNs caching and delivering files fast to users around the world, powerful compression algorithms and the wide adoption of HTTP/2, I guess we don’t really need to think about CSS minification anymore. It’s generally taken care of for us in modern front end tooling — albeit in opinionated ways. That being said, it is incredibly important for us, as front end developers, to understand how CSS is being delivered to the browser in our applications in order to monitor the impact it has on the performance of our apps in production.
Yes, these modern frameworks are doing a lot for us. But can we do more?
Top comments (5)
Gosh... there are so many new concepts to me in this article! And I'm not even finished yet.
Bundlers like rollup do far more to JS than just physical compression. They rebuild all external ressources into a single file. This is often more important than the the smaller size. I´m not aware of the concepts about CSS, but I suppose they will do it similarly.
One reason to use minification is that it also removes comments. Some CSS can be rather tricky so it makes sense to document what and why it exists. So, since you want those comments away from production CSS it is kind of a good idea to do it via minification. (Also, CSS-in-JS, I'm looking at you: why CSS comments end up to a production JS bundle?!?)
Also I guess technically it is faster to parse minified CSS than non-minified CSS, but we probably talk about very miniscule differences. Although when we consider the lowest end devices then any performance that you can gain you should go for it.
For developers it is way too easy to ignore and not notice the importance of these optimizations with the typical high-end Macs that most devs seem to use. It is not only about what goes through the network, it is also about what is being processed in the end device.
Sustainability is important and we should ensure we don't force people to upgrade devices only because your JS hits 100% CPU utilization for 30 seconds on a low end device on every page load.
So if something can be done with just HTML and CSS instead of a few kB of JS, it is probably worth it to go for the HTML + CSS solution and sprinkle in as little JS as is needed. Mostly it is probably required for accessibility reasons, like, you can implement a pure CSS tooltip, but for best usability you want option to hide it with Ctrl key, thus some JS is needed.
Show me a project where minifying CSS is the performance bottleneck and i'll give you a hundred bucks.
That's why we don't talk about it. It's about as useful to a project as "which font should we use" and "that feature the project lead wants that no one else wants and no one else is ever going to use".
Instead, we talk about resizing and compressing images, making sure our JS scripts are optimized to reduce JS computing time and making sure things render as they should to get those silly page speed insights numbers down. We talk about database query performances and backend code performance.
I get the WANT to see that CSS also performs well, but like you said, your 15kb reduction is literally nothing compared to the other things on the page that need doing.
Also...yup just use cloudflare, they do all the things you mentioned for you.
There's a lot more to look for in modern CSS tooling than simply minification--if it ever really was a limiting factor, to be honest.