Check Out CSS Cacheer

Shucks Shaun, this is pretty sweet! I can’t wait to take it for a spin. It addresses a number of issues that my friends and I had discussed in passing this year at SXSW, where we theorized on what an object-oriented extension of CSS should look like. We started with simply wanting to declare variables, but pretty soon wanted to extend classes, similar to what “based-on” does.

Pretty slick, Shaun! Can’t wait to have a project to work with :-)

I would like to see more docs, though. That would be useful, I’m sure you do agree, but I also understand you don’t have much time for it anyway.

Really sorry for the double post, I wanted to correct the few mistaking requests I made: the doc is currently available with some minor modifications though, like the new syntax var(variableName) and const(constantName), and not to forget the new additions :-)

Keep up the extremely well work, Shaun, you’re our everyday dev’ hero!

You’re trying to cut down on the amount of queries for static images to Apache by introducing PHP code that runs a bunch of regular expressions, a base 64 encode, and is dependent upon mod_rewrite, one of the most expensive (in CPU time) Apache modules?

Why?

Just by looking at your package, without even looking at your Apache configuration, I can already tell you that you’re developing a solution for people who don’t have Apache configured correctly in the first place.

If you have AllowOverride set to anything but “None”, Apache is going to perform a stat() on .htaccess down the entire path all the way to the directory in question. Let’s assume you have this set up at /var/www/html/csscacheer. For every request for a static image in that directory, Apache will then perform a stat() on /.htaccess to see if it exists, /var/.htaccess, /var/www/.htaccess, /var/www/html/.htaccess and finally /var/www/html/csscacheer/.htaccess. That’s five extra disk operations for every image you serve up.

One single-core Celeron, with Apache correctly configured and tuned, can pump out 45Mbps, easily. If you’re running into issues where you feel the need to reduce the amount of queries going into Apache, you have a lot of tuning that you need to do, especially before trying to cobble together a solution based upon extremely expensive CPU operations such as base64 or a regex.

I should add: this isn’t meant to be disparaging in any way, or take away from your innovation in any way. I’m sure this will be extremely useful for certain situations where clients need to have data urls embedded inside the original html page. (Extremely-timely, dynamic, security/antiphishing issues come to mind, like a bank’s image verification service.)

However, for day-to-day usage, it’s far easier to have Apache deal with serving up static files, something it is very very good at, rather than trying to wrestle with an application-level solution.

You’re doing it wrong!

In all seriousness, though, looking through your code, there are a few places where you’re going to cause a bottleneck.

First:

!file_exists(substr($requested_file, strlen($css_dir) + 1))

Here’s where you perform an extra stat() on the file, even after Apache has already performed that stat() in the original request. This is a relatively expensive operation. If all you’re concerned about is embedding base64 data inside your file, then you should be doing that at file creation, not at runtime. Have whatever CMS you’re using embed the data instead.

Second:

$cached_file = $cssc_cache_dir.preg_replace('#(.+)(.css)$#i', "$1-{$checksum}$2", $relative_file);

Based on this line alone, someone armed with knowledge that you were running this script could perform a denial of service attack on your webserver fairly easily. Just make sure the md5 sum of the GET request changes every time. That’s trivial to do.

(Ed. variables and $_GET-based caching have been disabled as of CSS Cacheer v002)

Third:

$requested_mod_time = filemtime($relative_file);

You’re running another stat() here on the requested file, and the next line runs a stat() on a “cached” file. These may be on the order of microseconds, but they add up as additional overhead that could be better spent streaming data to the client from Apache.

Fourth:

ob_start('ob_gzhandler');

Never never never never do this in PHP, JSP, or any other application you’re writing! Add this:

<IfModule mod_deflate.c>
    AddType text/css .your-cached-file-extension
    AddOutputFilterByType DEFLATE text/html text/css application/x-javascript text/plain text/xml
</IfModule>

…and let Apache take care of the gzip compression for you. Even if you don’t want Apache to do that, at least do the gzip compression the first time you write out the cached file, rather than doing it over and over, again, at runtime.

Last, color me a little skeptical about render time differences vis a vis decoding base64 that’s directly in a stylesheet vs. simply another pipelined request. I don’t even know how you would begin to reliably test that; any speed differences would be extremely small, and could be impacted by some background process on the client running at the wrong time, etc.

Again, Shaun, this is a neat hack, don’t get me wrong. It can be very useful in the right place, I’m sure.

Very cool stuff.

I’m not entirely sold on the base64 encoding of images through. By lumping your images in with the rest of your CSS, won’t the initial page load be significantly longer?

As I understand it, isn’t the downloading & parsing/interpreting of CSS a serial operation by the browser? The rest of the page load has to wait until the CSS rules are finished. And then all of the images for the page can be downloaded in parallel.

Here’s how my site loads, according to FireBug: http://dev.robgoodlatte.com/loadTimes.png

The CSS files “block” the other transfers from happening. Then, once the CSS is finished, images can load in parallel.

If you encode your images into the CSS, won’t that serial CSS operation take much longer?

Nevertheless, really interesting. And I can definitely see advantages in a mobile space.

Do you have any info about how using data urls affects the effectiveness of gzip? Can you achieve better overall served filesize by having it all in one file or by using seperate files and therefore seperate compression schemes?

I’m a total n00b when it comes to this stuff but wondering out loud: Would you accomplish much of what you want to do with cacheer (which is a very cool concept) by using CSS Sprites? You reduce your http requests to a single image request which (as pointed out above) is something Apache does very well.

Move that image out of an “AllowOverride” enabled directory to remove the extra stat() (or many, depending on directory depth) and the time it takes to parse the .htaccess file if one exists and Apache will happily serve like mad. and if httpd is part of the bottleneck, consider “nginx” as an alternative to Apache — It’ll be like your first crush in High School all over again.

What I really don’t know is how that affects render time on the browser level. Perhaps the trade-off is not worth it but if Sprites can be rendered quickly and efficiently, it may be worth considering.

Remember: I’m lame when it comes to CSS and have no idea how to benchmark browser render times in different scenarios outside of Firebug output.

Cacheer still looks like a neat way to burn a few hours tinkering.

Sure Shaun, a wiki would be a great solution for your documentation, letting us do our part of the job aswell as letting you concentrate on making greater things again and again.

That also would be a much better way for users to ask for features or warn you of bugs.

I am looking forward to collaborate on this wiki :)

I think a wiki or setting up a forum would be a great idea to help you collaborate with others and store information on bugs and specific topics.

As for CSS Cacher, do you plan on creating a directory of plug-ins for it?