OPTIMIZE YOUR WEBSITE FOR SPEED
While this phenomenon isn’t disconcerting at first glance, the impact it has on performance and maintainability is awful. Add in aging devices, bandwidth restrictions, or slow speeds in general and we have a much bigger problem.
Thankfully, we have control over not only our file sizes, but also how our pages are rendered in the browser. This sort of control gives web developers like ourselves a chance to help ease this problem, and optimize our code for better performance in the process.
THINKING MODULAR IS THE FIRST STEP
Modular code typically adds bloat in the form of more options. Here, we want to think modular in terms of combining as many common pieces of our code as possible. If we can combine two CSS classes into one and use less code to provide the same result, we should.
WHY BOTHER?
There are also quite a few SEO and UX benefits to be had by taking the time to look at our code. Not to mention, decreasing file sizes by optimizing our code for better performance has the added bonus of decreasing our bandwidth costs as hosts, and decreases bandwidth usage (think ISP/cellular data caps) on the user level as well.
WRITE SMARTER, MORE READABLE CODE
Sometimes the very code we’re writing is the slowest link in the chain. Inefficient CSS or bloated JavaScript can hurt loading times more than you may think. This Mozilla post goes into great detail about the importance of writing lean CSS selectors and explaining how browsers render them. In short, writing the exact path down a chain of selectors is much less efficient than simply using the smallest uniquely identifiable selector instead. They both direct the styling to the same element, the latter simply gets the job done much, much faster.
KEEP HTML VERY SIMPLE
In keeping with our goal to write leaner CSS selectors and keep bloat to a minimum, writing efficient HTML should also be a priority.
CSS resets often target all common elements and enforce resetting styling on them. So even if you aren’t targeting that extra div, it’s likely still slowing things down by having to have its padding and margin reset at a minimum. Typically, an extra div or two wen’t really hurt anything though. Only when you start ending up with dozens of them do things get crazy. With the introduction of more elements into the HTML5 spec, we also have much more flexibility in this area as well.
CONCLUSION
When optimizing our code, we have to not only think about file sizes but also consider how it will be read; either by browsers or even other humans. Mobile use should also be taken into consideration, with many service providers enforcing very constraining data caps these days.