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

Your email address will not be published. Required fields are marked *

For security, use of Google’s reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

This site uses Akismet to reduce spam. Learn how your comment data is processed.