The problem with CSS

21 December 2004   1 comment   Web development

Powered by Fusion×

CSS and web standards is a great tool for producing good web pages. It allows you to separate out content from presentation. The CSS file should be given a lot of responsibility and be very powerful in terms of what it can control.

The problem is that the CSS file can grow very big resulting in slow download times for the web surfer and heavy load on web servers. Usually it grows because you either:

A typical thing to do (in the design phase) is to add some HTML/content feature, then you add the CSS to go with it; six months later you uninstall that HTML/content feature but fears to remove the CSS because some other HTML/content feature might be dependent on the CSS that you just don't know by heart any more.

So what to do? I don't know. Of course we can be saints and preach not to get in to the pickle in the first place but that doesn't solve existing problems.

Are there any tools on the market that can analyse a webpage for redundant CSS? I've been thinking of creating one but have yet to discover a way to cover all webpages and not just the home page. Some pages might be password protected and some CSS might only apply when an error message appears.

As an example, Dabs's stylesheet is 19395 bytes big. Ebuyer's total is 25070 bytes big. That's about 18% of the total download size of their webpage! To contrast that, of my total webpage content 4% is CSS and my webpage doen't even use tables for the layout.

I've written about web optimization before here and here. It's all about stripping all unnecessary whitespace to decrease download times. It's not a bad pattern but sometimes it just doesn't work and that is when the stuff your optimizing is stinkingly too big.

One potential solution that I was thinking about is a profiler that loads a CSS file and a list of URLs within a homepage. As soon as any CSS is matched with the HTML, you remove that CSS from the CSS file. As you test more and more pages the CSS file will consequently shrink. Eventually the CSS file will be much smaller and it will then become manageable to inspect the final possible modifications manually. The would however require a serious analyser that could handle not-so-straight-forward CSS like this:

#nav ul li a:hover {text-decoration:none;}


Thinking out loud...

You can't just grep the files server-side. Some of the HTML might be generated at runtime, or stored in a database. There's also the false-positive problem.

You can't wget the site, and grep it post-spidering. As you said there's password-protection, and all the other problems associated with generated content (eg we have styles associated with the day of the week - mondayContent, tuesdayContent, etc).

I think you need some kind of reference counting scheme. But how to implement it without doing all the work by hand... not a clue. Possibly you could lash something up if your only IDE was Visual Studio. But I don't think any programmatic solution is going to "get":

$style = date('D') . 'content';

You could bind the CSS files tighter to the content - instead of a site-wide stylesheet, each directory has it's own stylesheet. That's more managable, but it's just working around the problem rather than solving it, removes a lot of the advantages of CSS and introduces redundancy.

How about using javascript to report back which styles have been used in rendering the page? If 3 months have gone by and you haven't had a report that mondayContent has been used, it's probably safe to remove it. The problems with this are obvious, and it's a total hack besides.

When you get into weird cases like "Site A depends on the stylesheet from site B", I think there's basically no chance.
Thank you for posting a comment

Your email will never ever be published

Related posts

__call__ folderish Zope objects 19 December 2004
Merry Christmas 22 December 2004
CSS Bloat Comparison 03 June 2016
How to no-mincss links with django-pipeline 03 February 2016
mozjpeg installation and sample 10 October 2015
django-semanticui-form 14 September 2015
Examples of mozjpeg savings 01 September 2015
Introducing optisorl 18 August 2015 08 July 2015
Python slow-down of exception handling or condition checking 14 May 2015
AJAX or not 22 December 2014
Gzip rules the world of optimization, often 09 August 2014