Just recently I found myself returning to an old style sheet that I had coded last year. It was vanilla CSS written without the help of a pre-processor.
Locating and rewriting the CSS involved far too much scrolling through 2,000 lines of code for my liking. It stuck me that if the code was divided intelligently between several different files rather than one long one, then maintenance would be a whole lot easier.
Yes, SASS and Apache Ant give the coder the ability to merge several style sheets together, but it should be an inbuilt feature of the CSS browser implementation.
When Google employee and CSS Working Group member Tab Atkins wrote his post 2013 Work Plans, I left a comment underneath suggesting that there should be an alternative to @import which, although allowing you to insert separate style sheets into one, comes at a performance cost.
Is @import the devil?
Using @import is such a taboo that to use it in a production site is almost the equivalent of putting an “I'm an idiot coder” banner on the home page
But why is it so wrong and do these arguments stand up to scrutiny?
@import and download speeds.
Front-page optimization guru Steve Souders had this to say about @import in an article from 2009:
* Using @import within a stylesheet adds one more roundtrip to the overall download time of the page.
* Using @import in IE causes the download order to be altered. This may cause stylesheets to take longer to download, which hinders progress rendering making the page feel slower.
I thought I would test this out with the help of Web Page Test, so changing the code to a finished website still sitting on a development server, I divided the CSS up into five separate files: reset, reusable classes, navigation, content and footer. It is object orientated CSS in its most primitive form. Then I added these five files to the central style sheet using @import.
I tested download times before and after:
| IE 7 | IE 8 | IE 9 | Firefox | Chrome | Nexus Android 2.3 |
|---|---|---|---|---|---|
| Run 1: 2.872s Run 2: 2.198s |
Run 1: 2.042s Run 2: 1.628s |
Run 1: 2.324s Run 2: 1.866s |
Run 1: 2.688s Run 2: 1.962s |
Run 1: 3.423s Run 2: 2.319s |
Run 1: 7.568s Run 2: 3.849s |
| Run 1: 4.63s Run 2: 2.657s |
Run 1: 3.142s Run 2: 1.676s |
Run 1: 2.596s Run 2: 1.865s |
Run 1: 2.228s Run 2: 1.746s |
Run 1: 3.861s Run 2: 2.614s |
Run 1: 7.923s Run 2: 4.529s |
There is a noticeable difference in Internet Explorer 7 and 8, but far less so in IE9, Chrome, Firefox and Android. Perhaps if you are not bothered with IE 7 and 8 (and most of us are), then maybe the 100 milliseconds differences is something you could live with.
@import placed in the footer
The second point made by the prosecution against @import is that it loads the files in the footer, as is written in the Yahoo Performance guide:
One of the previous best practices states that CSS should be at the top in order to allow for progressive rendering.
In IE @import behaves the same as using at the bottom of the page, so it's best not to use it.
Looking at the cascading downloaded resources that Web Page Test details, I can confirm that IE10, Firefox, Chrome and Andriod do load any style sheets added with @import as if they are in the footer, while IE7 to IE9 do not. It's extremely bad practice to place CSS in the footer as it will create a disconcerting page rendering experience for the user.
Conclusion
Avoid using CSS @import. It's not fit for purpose. You're probably thinking, Tell me something I don't know; but it's always good practice to question what your are told rather than accepting it as correct. As some dead guy with a beard once wrote: “We must have merciless criticism of all things existing”.
However, I do hope that browser manufacturers and the CSS Working Group will create an alternative to @import, although I don't see any evidence of demand coming from CSS coders themselves. While many talk about mixins, functions and variables, few seem interested in addressing this problem.