When Is Enough CSS Enough?

One of the major pushes in web development today is to try to do as much of the styling of a website as is possible from within the CSS of the site. The idea behind this is that when you do so, you remove styling responsibilities from your JavaScript and HTML content, resulting in a much better separation of concerns. The other aspect of this is that CSS styling is typically handled in a more native fashion in the browser as compared to what you can accomplish via Javascript.

This idea is one that has many merits and very few detractors. However, I believe there is at least one wrong way to handle this. As an example, Internet Explorer 9 and before has a limit on the number of CSS selectors that it can apply per stylesheet of 4095. After that, any CSS that appears in the stylesheet is completely ignored by the browser. While this seems like a lot, I know of quite a few sites that have had to specificaly split single stylesheets into multiples to simply get around this limitation.

Recently, I was tasked with taking a website that had been abandoned in mid-development and preparing it for launch as fast as possible. Once I had the basic functionality tested and working properly, I started looking into the details of the styling of the frontend of the site. When I found the main CSS file, I quickly scrolled to the bottom of the file to see how big it was, and was completely shocked. This single CSS file was over 13,000 lines of CSS. Amazingly, this was only one of the several CSS files that were compbined into a single piece of CSS that is delivered to the browser.

Once all of the CSS files have been combined, they nearly reach half a megabyte in size, more than 50 times the HTML payload of the homepage of the site. You might think that some of the space is taken up by some data-uri images, but there are no data-uri resources in that giant CSS file.

Any time your global CSS file is 50x the size of your HTML, you are doing things very wrong.

Related Posts

Mar 11, 2015
One minute

Firefox 36 Has A Massive Memory Leak

While looking through our TrackJS logs the other day, I ran across a peculiar error message coming from Firefox 36 on Windows 7. The error message was simply out of memory. It seemed that the pesky local storage issue had reappeared mysteriously. However, with a quick check of the codebase, I verified that no one had accidentally reverted those fixes.

With that possible cause ruled out, I turned to a developer’s best friend, Google, for solutions. Well, it appears that Firefox 36.0.0 has quite the memory leak issue. When looking into the detail of the issue, it became highly probably that this issue was the cause of the errors in our monitoring tools. Apparently, this bug rears its ugly head when you are doing 2D rendering on your page, and the site uses a 2D charting library to present information.

Oct 7, 2014
2 minutes

LocalStorage and Safari Weirdness

One of the technologies that has been intriguing to me for a while has been LocalStorage on the web browser. One of my first adventures into using persistent storage other than cookies on a web browser was the short-lived HTML 5 standard of the webSQL database. It turns out that it was simply a SQL Lite database that was accessible via JavaScript in all the WebKit browsers as well as Firefox. However, Internet Explorer did not implement this functionality, and the webSQL standard was soon dropped from the HTML 5 standard itself, leaving only the LocalStorage key/value storage mechanism.

Jan 9, 2015
3 minutes

Authorize.Net Directpost is Overly Complex

One of the necessary evils that every ecommerce website that wants to accept credit card transactions must deal with is some sort of payment processing company. It just so happens that Authorize.net is one of the largest payment processors around, and they allow you to choose from a few different ways to integrate their payment processing functionality into your website. One of their ways is via DirectPost, which allows an eCommerce website to process a credit card transaction without the credit card information ever being sent through the website’s servers.