Most of my coding life is spent in the web development world, and as such, I get to generate a substantial amount of CSS on a daily basis. Things get added, while others removed, and some get updated multiple times in order to achieve just the right look. So slowly this pool of classes, id, selectors and pseudo-selectors grows by the week.
A typical file can look something like the following:
Potentially thousands of lines per CSS file that I am working with. The above is from this very same blog that you are reading, and it is only 1 particular file out of the dozen or so.
And if that sounds like alot to you, it isn't. Almost every project that I've had the pleasure of working on has involved thousands upon thousands of lines of CSS.
Sometimes this involved many different files (better) while other times they involved singular files that could barely open in any given text editor due to the sheer requirements of opening up 30,000 line files and expecting the OS to not choke at some point as that buffer fills up.
Why does it matter you ask? We have super powerful computers these days and even more powerful smartphones (somehow), and 5G is here. So why does it really matter if we spend a few extra kilobytes here or there?
Let's dive into why it matters and why we should maybe start to pay more attention.
Digital cost
Data isn't free. And I don't mean that in a financial sense, although there is some financial value associated with it as well. I mean more so in a resource management sense. An extra 100kb might seem trivial to you. But now multiply that by let's say 100,000 (estimated number of monthly page views). Those extra 100kb of bandwidth have all of sudden, through the magic of time, turned into 10,000,000KB of data.
That equates to about 1GB of data per those 100,000 page views. Again, in this day and age, a GB of data is probably worth just a few cents from a server hosting perspective. That number can only go up as the popularity of any website increases.
If we were to multiply that across all websites with 100,000 or more page views (monthly, yearly, etc), then we will start to get into some real numbers.
I'll say this, we don't really know just how many websites exist currently. Some estimates show that in 2014 we were at 1.4 billion and claim we are still there now, which makes little to no sense. The world may never know.
But if we were to assume just a few million websites even, the number of bytes transferred daily that weren't being used would still be surprisingly high.
The causes
Why does CSS go unused? That is the question to ask and the answer, probably won't surprise you. There's a few reasons actually, which I'll break down below.
Websites tend to change frequently. More frequently than you would expect. If you were to look at any websites that's been around for over 5 years (waybackmachine.com), you would see revision after revision after revision.
Revisions, or redesigns as they are more professionally referred to, are difficult to implement. Fundamental logic on a website must remain almost exactly the same, while elements shift positions, become modal, vanish (display:none) or get moved from page to page.
Which means that a developer will do their best to maintain what is currently there, while morphing it in the process to fit the new mold. Most redesigns happen in steps to add to the challenge. There is no final approved version 2.0 before work begins. There are potential version 2.1's, 2.2's, etc that are usually implemented until a final agreed upon version is discovered and approved.
In getting to that stable version, there will be alot of CSS that is sacrificed in the process. And by sacrificed I mean ignored and not used and probably left behind on line 456 of some file.
Frameworks
Probably one of the biggest culprits when it comes to unused CSS comes from the use of 3rd party pre-built frameworks. Some of these libraries are fully packed with anything and everything that you would ever need. They are very convenient and avoid you having to maintain dependencies across multiple packages, but as mentioned, they can be heavy.
There is a high likelihood that 90% or more of the CSS in a library will go unused on any one project. Let's take a look at Bootstrap as an example. It is one of the more popular JS/CSS frameworks that have been around for some time.
The raw bootstrap.css file clocks in at around 195kb, as of the latest version. Which isn't an overly large size mind you. But there is a chance that much of it will go unused as mentioned above. Just how often are you going to use .text-dark really?
You will more than likely be working with multiple frameworks as well, not including your own custom CSS that will inevitably be added and you can start to see that the generous 100kb that I mentioned above is probably on the low end.
So there are 2 problems, or challenges, at hand when it comes to efficiently producing CSS in a non-wasteful manner. On the one hand, you have developers under tight deadlines attempting to create multiple designs without breaking any current functionality leading to unused CSS elements. And on the other end you have the kitchen sink approach, in which pre-built libraries will include everything into one file.
We want to aim to be somewhere in the middle.
The underlying problem
But there lies the problem. There is no form of modularization built into the CSS standard currently as it stands. It is true that CSS is becoming more feature rich by the year, with new elements popping into existence that make use of the latest hardware. But the underlying architecture has not really changed since its inception.
It is still a class/id/selector based method that isn't really held accountable by the parsers. By that I mean, that if a class isn't used anywhere in a project, there is no warning or error given to the developer and it is technically ignored because it isn't really a problem.
It's essentially a double-edge sword. Developers have the freedom to create and structure CSS to their own liking, at the expense of any type of optimization or standardization.
So what's a developer to do you may ask? Well, there's a few things actually. We have to take it into our hands. Down below I've outlined a few possible techniques that can help alleviate the bandwidth burden that we are placing on our networks.
Per page approach
I follow the practice of having 1 CSS file per page on my websites. My about page for example, would have its own about.css file and similarly the contact page would include contact.css. Which makes sense, as any design choices related to your about page probably aren't very relevant in your contact page.
This makes updates a much simpler process as you don't have to navigate around one giant file looking for an element, but it comes at the expense of having to manage multiple files per page. The solution to that would very much depend on the programming language and framework that you are using and how you choose to link to your resource files.
Any shared styling rules can go into one primary and central CSS file that you would include on every single page. I've been using this approach for years, and it definitely has reduced my overall page loading times and development times as well.
It hasn't completely solved the issue, but it has helped to alleviate it a bit.
Audits
There are various tools that you can use that will audit your websites and attempt to find unused style rules. Chrome developer tools for example has such a tool built-in, however it doesn't fix the problem for you technically, it just points it out.
It is up to you at that point to make the right adjustments and deletions. If you do this frequently enough however, it is definitely a very buyable approach to CSS maintenance. The trick being to not let it get out of hand for months on end and then spending hours going line by line looking for issues, as I once did.
I am not aware of any other CSS auditing tools currently that can generate clean CSS automatically, but if you know of any, comment down below.
Mindful of updates
The simplest way to keep your CSS low-weight and less wasteful is to really be mindful of it. Which sounds corny, but its true. Just being more aware of when you are making changes and the type of changes that you are making is a life changer.
Changes will happen, that is inevitable. And staying on top of those changes and responding accordingly will save those sweet KB's of data. And that's true with anything and everything folks, not just our CSS. So what does responding accordingly mean? That really depends on your personal approach to code maintenance and is subjective on many factors.
To me, it means adding any potentially unused CSS into a queue for deletion before anything else. And once my updates are completed, to perform a final audit to ensure that indeed those elements can be removed safely. And then the hardest part, actually deleting the code.
We live in the age of source control however, so nothing ever really dies, it just goes into stasis. Although more than likely never to be looked at again.
On the surface, saving a few kb's of data might seem like a trivial and also comical thing. But let's remember that most of the world isn't as connected as we are (me writing this and you reading it). There might be some parts of the world where a single 1 GB of data transfer could equate to hundreds of families communicating for a year and to kids downloading information from the web.
Now if only there were a way to donate that data somehow ?? .
We can definitely do better when it comes to our digital architecture and infrastructure, and we should. Let's start today by saving just a few kilobytes on our web apps and see where that takes us.