Many websites are never “finished”. They get completely re-designed from time to time, but they get tinkered with much more often. A shift of text size here, an improvement to content structure there. Every now and again, a new layout element is added to a pre-existing set of features.
Modifying a large website can be a heck of a job when everything is interwoven. Changing a few layout definitions on a site with several hundred or even several thousand pages can create a huge knock-on effect. Every page which might be affected by the change has to be checked individually.
Historic front-end coding principles dictate that CSS and JavaScript should be merged into a single file, so that the browser doesn’t have to make as many individual requests. The introduction of compilation processes like Sass means that you can automate the compilation: linking several individual Sass files together to compile them into a single compressed CSS file.
The difficulty comes when CSS rules for a part of the site need to be changed. Re-writing the code is fine, but re-compiling the individual Sass files to create the master CSS file can be dangerous. This is especially true if you’re basing your code on a framework or library, which may have changed since the Sass code was last compiled. In a large installation, it’s difficult to be 100% sure that re-compiling your CSS hasn’t introduced an obscure problem in a separate set of rules.
The more maintainable solution is to structure your Sass files in such a way that they are individually compiled. By building a structure of individual files – perhaps in the way suggested by SMACSS, with base, layout and modular rules – you can organise your code in such a way that you can edit the CSS for the page navigation, whilst leaving the CSS for the content section untouched. You can then re-publish the changes individually, without running the risk that other page sections will suddenly break.
In CMS like TYPO3, you can also optionally concatenate the compiled CSS files into a single resource. The advantage here is that the CMS will concatenate the new CSS file with the other unchanged files on the server. This is less dangerous than re-compiling and concatenating all of the CSS locally, when you only need to revise a single file.
The reason for concatenating your CSS into a single file at all is tied to HTTP/1. Browsers using this transport method to get files from the server to the client run into trouble when there are many files to be loaded concurrently. A page with a couple of dozen individual CSS files will be loaded slightly more slowly than a page with a single CSS file, as each file request needs its own request.
The arrival of HTTP/2 does away with this issue: multiple files can be loaded concurrently with no problem at all, because the connection is “multiplexed”. (Multiple files can be transferred in a single request.) So if you’re able to run your website via HTTP/2, then you can move away from a single, concatenated CSS file.
Leave a Reply