Start a personal dev blog on your domain for free with Hashnode and grow your readership.
Get Started

Considerations for bundling/serving CSS

  • Avoid using @import in CSS at all costs, it blocks parsing the rest of your styles while it goes off to make more network requests for the imported files.

  • The browser doesn't really care about the number of stylesheets used, after CSS is parsed the browser it treats all CSS like one giant stylesheet anyway. Feel free to use as many stylesheets as you want. CSS has performance limitations in other areas, but the number of stylesheets isn't one of them.

  • Individual CSS files can be cached by the browser, where inline styles cannot be cached. A cached stylesheet loads much faster than one that has to be transferred over a network each time.

  • The best way to add a stylesheet to HTML is via the <link> tag.

  • CSS can also be embedded in a <style> tag inside HTML, but it's a tradeoff: you save a network request for the stylesheet, but forfeit the chance for the browser to cache that stylesheet.

  • You can add styles to HTML with Javascript via the CSSOM, or with <link> or <style> tags in the DOM, or by setting the style property. Adding CSS with JavaScript is the least desirable option, so a good rule of thumb here is to do anything in CSS that can be done in CSS.

  • Depending on whether you have HTTP/2 enabled on your server, it may be more efficient to send many small files versus sending one large file. Bundling multiple files into one might not be the most efficient way your server is configured to send files. The answer will depend on your server configuration, and the number and size of the files you are serving.

  • If you want to bundle multiple files into one CSS file, you don't really need a special bundling tool. Adding the contents of the stylesheet files together into one file (concatenating the files), paying attention to the order they are loaded in (to respect the cascade) is all that's required. It could be as simple as this command:

$ cat *.css > bundle.css
  • If you want to reduce bandwidth, enable GZIP compression on your server. Repeated parts of files compress well, so the more consistent your code formatting, usually the better the compression.

  • If you want to reduce filesize, the CSS minifier I recommend is CSSnano, but whether you minify your CSS or not—keep in mind that the savings here are tiny so don't stress over it, and don't waste too much time if it doesn't work. Failing to optimize just 1 image on your site might wipe out any benefit you can get by squeezing all the extra space out of your CSS.

Start a personal dev blog on your domain for free and grow your readership.

3.4K+ developers have started their personal blogs on Hashnode in the last one month.

Write in Markdown · Publish articles on custom domain · Gain readership on day zero · Automatic GitHub backup and more

Jason Knight's photo

Part of why I say use a monolithic stylesheet for the ENTIRE site. That means only one LINK per media target (assuming you don't go full re-re by omitting media="" or derping it to "all") so less handshaking, minimal blocking, and of course better leveraging of caching models since you can pre-cache the appearance of subpages.

But then I stand by my statement that 90%+ of all websites have ZERO legitimate excuse for using more than 48k of CSS in one file per media target apart from -- here come those words again -- ignorance and incompetence.

Though I also say that there is ZERO legitimate reason for the <style> tag to even exist and 99% of the time people use the style="" attribute they're doing something wrong. The former is just creating code bloat and slowing down pageloads, the latter

Of course the worries about hanging the load time are nonsense too, or would be -- as I've said repeatedly -- if people stopped using 40-200k of HTML to do 16k's job, half a megabyte in a dozen files of CSS to do 32k in one file's job, or vomiting up megabytes of JavaScritp spanning dozen[b]S[/b] of files on pages that don't even warrant the presence of JavaScript, or if they do 64k or less would do the job. Not counting external's like social media or discussion plugins.

But with most 'experienced' developers not even knowing that <style> and <link> are invalid inside <body>, what can you expect?

Steven Ventimiglia's photo

I use, which leads you in the right direction in term of compressing and delivering what's needed for certain pages, no matter how you intend to go about it.

I dislike <style> and style="..." - however, I've learned that throwing minified CSS into the head using <style>, for 'above-the-fold' content, is acceptable and needed to bring that score up to 100. This does help your ranking in the SERPs, so it can be valuable for important content such as the site's homepage being indexed properly. (Ironically, adding Google Analytics causes the page to fetch something remote, lowering that score by a few points.)

There should only be a single <link> (and <script>) tag, imo. "Run on Save" add-ons for editors like Atom and VSCode, as well as Grunt/Gulp pipelines, help to avoid cluttering your HTML with calls to 999+ different files by concatenating them. Using randomly generated or specific versions on each (ex. style.css?v=127c8127), then helps with browser caching and issue tracking.

Also, @import should never be used within a CSS file, but it's vital for Sass partials - which will also concatenate all the partials, minifying the final .css file it creates. That process happens rather quickly, too, since I never had to delay live reloading several browsers for more than 2 seconds on large sites.

Unlike existing libraries, that always has stuff you'll never need to use, this is the best way I've found to keep my CSS unbloated and DRY (beware of @extend.)

Show +3 replies
Jason Knight's photo

Oh, and what I just said is particularly true given that your HTML can and should support MANY different layouts, more so if you have that separation of presentation from content that allows full multi-skinning without even touching the markup. Part of why I consider html/css frameworks to be such utter mental-huffing-midgetry; they inherently put layout into the markup in the form of classes preventing one of the ENTIRE reasons to use CSS in the first huffing place!

Remember a decade and a half ago when people were showing off how to write HTML once and then do dozens of different layouts off that single unified markup? Yeah, those days are dead and buried.

Steven Ventimiglia's photo

In terms of layout, when I speak to developers, it’s basically the structure of the markup or how components are being handled.

However, even Sass has it’s own type of structured layout that should be applied to keep things organized - but, sometimes a conversation about this is confusing to some since it’s CSS, which creates the visual layout of their site/app.

Much like the word “scope”, it can be overused and underthought.

The company I’ve been building for the last few years is slowly becoming known as the “Anti-Agency” - which I love, despite the naysayers. We go against the grain, proving that libraries such as Bootstrap and piles of dung known as JS frameworks are not what they need to use for long term growth and sustainability.