Considerations for bundling/serving CSS
@importin 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
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.
<style>tags in the DOM, or by setting the
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.
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
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
But with most 'experienced' developers not even knowing that <style> and <link> are invalid inside <body>, what can you expect?
I use https://developers.google.com/speed/pagespeed/insights, 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.
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
<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.
@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
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.
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.