It is quite similar to a couple of tools that are already out there. JSLint looks for issues in JavaScript code and checks for adherence to a certain set of code standards. PHP_CodeSniffer, a PEAR package, provides similar functionality for PHP files (but is also able to check JavaScript and CSS). Then there is CSSTidy, a parser and optimiser for CSS, which e.g. compresses hex values for color declarations and provides different levels of minification (removing comments, whitespace etc.).

Essentially, what I wanted to achieve with CSS Reviewr is to not only point out issues in the code based on the experiences and the reviews we conducted at work, but also to provide explanatory text for each finding (much like how the W3C Validator does it for HTML). In one or two sentences, I wanted to explain why this is an issue and how it can be resolved. From my perspective, this is ideal for a developer who might not be familiar with a certain best practice or convention. By reading the explanation and maybe following a link to a page that provides more details, it has a certain learning effect to it.

CSS Reviewr, as it is stated on the page, is not a validator. It is encouraged to run your code through the W3C CSS Validator first, before checking it using CSS Reviewr.

Last, but not least, I would like to thank the real brain behind this: Sam Riley. I had the pleasure of working with him on Yahoo! Answers and I was and am still really impressed by his sheer endless knowledge of the ins and outs of CSS. Knowing that I would not be able to just turn to the side and ask him whenever I have a question related to CSS (because I relocated from London to California), I wrote this tool also to store his CSS knowledge somewhere for myself, so I could still use it here in the US So a big thanks to Sam!. Also thanks to Eva-Lotta, who kindly offered to do some visual design work for this in her spare time.

The tool is in beta right now and I have already identified some bugs myself that I need to fix at some point, providing I find time for this. Getting some early feedback from colleagues, I have also received the following feature requests:

• Indentation check (selectable option)
• Check (background) images used in the code are akamized/on a content delivery network (CDN)
• Fonts should not use uppercase characters (e.g “Arial” should be “arial”)
• Limit the amount of errors shown to 50 to prevent browser (FF2) from crashing. Add something like: “More than 50 issues found. Fix the issues above first before checking your code again.”
• Having a ‘Do it!’ button by each issue to make the suggested modification to the code, and then have a textarea at the bottom where you could copy out the fixed version

Suggestions, bug reports and all kinds of feedback welcome. Just leave a comment below. Thanks and happy holidays!

Description

Shrinkr does two things:

1. It reduces the file-size of your CSS and JavaScript files through minification, i.e. stripping out unnecessary content like white-space and comments
2. It then takes those files and concatenates them into one single CSS and one single JavaScript file
3. Those files are then getting stored as css-min-[timestamp].css and js-min-[timestamp].js on your server. The reason for the timestamp is that whenever Shrinkr creates a new file, it is ensured that a user agent doesn’t still use a cached version of the previous files but, because the name of the file has changed, retrieves the latest version from the server

The first measure reduces the file-size by stripping out things from files that are not needed by the browser in order to interpret them. Whitespace and comments are for developers, not for the browser. They can safely be removed, which reduces the file-size and thus the consumption of bandwidth.

In the Yahoo! Exceptional Performance Rules, it says that one should aim to reduce the number of HTTP requests in order to make a page load as fast as possible. Shrinkr does that by concatenating all the files into one single file (one for CSS and one for JS). So instead of having 10 CSS files, you will end up having only one.

Shrinkr also adds an action to wp_head and wp_footer in order to tell WordPress to include those files upon page load in the appropriate section of the page. CSS files should be included in the head of the page, JS at the very bottom as per the Yahoo! Exceptional Performance Rules.

Because of the fact that you will end up having all your CSS and JavaScript in one file and on one line (because all the carriage returns etc. have been stripped out), it makes debugging kind of difficult. For that reason, you should only activate that plugin on the live version of your site and keep the files separated on your development box.

Further details about the plugin can be found on the Shrinkr plugin page. It would be great if you could try it out and give me feedback, either by leaving a comment here or using the contact form. Thanks!

Resources

• Best Practices for Speeding Up Your Web Site
• Yahoo! UI Library: YUI Compressor
• JSMIN, The JavaScript Minifier
• Minify!

Step By Step

I did some digging on the net and some investigation and tried to come up with a concept that makes sense. The steps I was thinking about:

1. On page load, a 10kB image gets requested “in the background” (hidden from the user by CSS)
2. Via JavaScript, the time it takes to load that image gets recorded and the bandwidth gets calculated
3. As soon as this process is done, the image gets removed again from the DOM
4. Some sort of bandwidth cookie gets stored on the client, telling the site which content to serve on subsequent calls to the site

I came up with a prototype that demonstrates the bandwidth measuring using JavaScript. It does not take care of Steps 3 and 4 mentioned in the list above, but I think it conveys the idea behind it.

Some things to note about the JavaScript:

• Line 47: I am using onload as an attribute of the element itself, which is bad practice in general, cause behavior should entirely be controlled using JavaScript and Event Handlers should be added e.g. with YUI Event. To not waste execution time and maybe alter the measure of the bandwidth, I used it in this instance. Because of that, I also had to author this document in HTML 4.01 strict, to make sure it validates.
• Line 52: Also, I am using innerHTML to quickly insert the piece of code that constructs the image element. I could have created the image element using document.createElement, but innerHTML works just fine and occurred to me as just more convenient in this case.

Conclusion

Honestly, after I was finished with the prototype, I was not really sure if that whole thing makes sense at all. Cause what it does is it makes an additional request to the server which would make the page even slower to load for people already suffering from a slow connection speed. Also, thinking about the cookie thing, as people tend to be mobile these days, they might have a slow (WiFi) connection when requesting the site, but have a fast broadband connection at home. But with the cookie already written when they visited the site when they were mobile, they would get the low-bandwidth-experience at home as well – which defeats the purpose, kind of.

So especially after writing this blog post about it, I am not really sure if my idea makes sense. So I am asking you guys, what is your opinion on that?

Resources

• Harvard University Information Systems: Bandwidth Tester
• Upload bandwidth as a bottleneck to busy web pages

With the Dust-Me Selectors Firefox extension provided by SitePoint, there is a way out of this. The extension provides a convenient way of cleaning up your CSS file(s) and identifying selectors which are not used anymore.

After installation, the presence of the application is indicated by an icon in the browser bar showing a spiffy broom. The extension comes with several options. First, you can select that upon visiting a certain web site, it starts recording which CSS selectors from the CSS files loaded get actually used on the site you are on (indicated by an animated broom icon and listing the amount of unused selectors found in how many CSS files). It then creates a list and bit by bit ticking off every selector being used. While you continue browsing the site, that list (hopefully) gets smaller and after you have browsed through samples of significant pages on your site, it will give you a list of CSS selectors which – it thinks – are redundant and can be deleted.

With version 2.0, the clever guys at SitePoint (cause they know what we want) built a spider functionality into Dust-Me. This means that you can provide the extension with a sitemap of your site (either an HTML file with a list of links or a Sitemap XML file) and it will spider the pages provided (and going one level deep from there). From my perspective a more convenient way, if you have a tool that creates a site map like XML-Sitemaps.com Sitemap Generator or GSiteCrawler. There is even a Google (XML) Sitemaps Generator for WordPress.

The “view saved data” option in the plugin will then give you a nice list of used/unused selectors which will give you a sense of which selectors might be save to delete. I say might, because it does not check whether you might use one or the other CSS selector to style markup you insert via JavaScript into the page. This is beyond the scope of the plugin, so with the final output data from Dust-Me at hand, you will need to check whether one or the other applies to markup added using JavaScript — and then don’t delete them, of course

Further reading

• Dust-Me Selectors plugin homepage
• Plugin User Interface
• Plugin Preferences

Analyzing the present state

Equipped with Firebug and Yahoo!’s YSlow, an extension for Firebug, I first had a look at the current performance measures of this site. Firebug reported the following (under the “Net” tab, select “All”):

YSlow measures a web site’s performance against the abovementioned Exceptional Performance Rules. It grades the performance for every category and finally comes up with an overall performance score for the whole website. The scores for this site were as follows:

#	Rule	Score	Reason
Overall Score: F (45)
1	Make fewer HTTP requests	C	I had 13 external JS files, 5 external CSS files and 7 CSS background images
2	Use a CDN	F	Not using a CDN (Content Distribution Network), cause it is just not worth it in my case
3	Add an Expires header	F	No expires header set for CSS, JS and images
4	Gzip components	F	No gzipping of HTML, CSS, JS files
5	Put CSS at the top	F	CSS files were linked with the @import rule, which apparently made them finally load outside of the head
6	Put JS at the bottom	A	All JS gets loaded at the very bottom of the page, close to the closing body tag. Why?
7	Avoid CSS expressions	A	No CSS expressions used
8	Make JS and CSS external	n/a	Not necessary on this website
9	Reduce DNS lookups	A	Sources only provided by two sources (max.)
10	Minify JS	A	geolinkr.js file not minified
11	Avoid redirects	A	No redirects implemented
12	Remove duplicate scripts	A	No JavaScript file gets included twice in one page
13	Configure ETags	F	unconfigured on the Apache server

As stated by Jeff Attwood, Yahoo!’s Problems Are Not Your Problems, you need to be careful when following the guidelines for improving your YSlow scores. Some of them are only useful if you run a website with millions of unique visitors per day. If used wrongly, they can even slow down your site. So I took those results, tried to applied as much common sense to them and then tried to improve them using methods described in the following section.

Taking action

1. Reducing HTTP Requests

Even from a not-so-much technical and geeky perspective, this makes sense. If the browser needs to communicate with the server less often, this will make the web site load fast (“less talk, more action”). For me, I have chose two measures to achieve this:

a. through Minification

To reduce the number of HTTP requests for JS and CSS files, I decided to “minify” them into one file each. This not only reduces the number of HTTP requests, but also shrinks the filesize down by removing unnecessary whitespace, comments etc. The minified JavaScript file gets included as close as possible to the closing body tag, the CSS file gets called as soon as possible in the document.

b. by creating CSS Sprites

Of course I see the point in generating CSS Sprites which then contains all (or at least) many of the background-images you use on the site and then position them using CSS properties. I can certainly see the advantages of using a tool like CSS Sprite Generator (done by my co-workers Ed and Stuart) but I decided no to because of the following reasons:

• YSlow and Firebug are telling me that I am using 7 background images. I think that is not too bad.
• My background images have mixed formats (JPG, GIF and PNG). Now I could make all of them PNGs and create a CSS Sprite. But I think it does not necessarily make sense, cause you use JPGs for certain images (pictures) and GIFs for images with greater areas of solid colours (e.g. comic illustrations). So mixing all of them into one does not make much sense to me.
• Most likely, I am doing some little design changes here and there and I certainly don’t want to recreate my CSS Sprite every time.

So I dropped that measure from my list, even though it might mean my score will not increase that much.

2. Adding an Expires Header

To ensure that elements are cacheable I configured Apache in a way that it sets an Expires header for 3 days in the future. This means that before those 3 days are over, the browser will always use the cached version of the image/CSS/JS/HTML file (if there is one). The requirement for this to work is that the mod_expires module is installed on your Apache webserver. You can check for that by doing a phpinfo(). If that is not the case and you don’t have access to the httpd.conf file, you won’t be able to set the Expires Header through Apache. If you do have access to the httpd.conf file, add the following line to the LoadModule section and restart Apache.

LoadModule expires_module modules/mod_expires.so

Now that the module is available you can add the following lines to your .htaccess file:

<IfModule mod_expires.c>
    # enable expirations
    ExpiresActive On

    # sets the Expires date 3 days out from the time of the request
    ExpiresDefault "access plus 3 days"
</IfModule>

Yahoo! recommends to set the Expires header to +10 years after the time of the request. This might be fine for Yahoo!, but this only seems to be wise if you are dead-serious that this file will never ever gonna change. Cause if you do change it on the server, it won’t force any change on the client side…the user agent will not even bother looking for a new version of that file if it is already in the cache. So unless you rename the file, it will never get picked up by the browser until 2017…I mean, unless you clear the cache, of course.

3. Turning on Gzipping

This can be done using the mod_deflate module, which got introduced in Apache with version 2.0. Again, check if that module is available using phpinfo(). The following line in http.conf will load the module:

LoadModule deflate_module modules/mod_deflate.so

The following additions to your .htaccess file will gzip HTML, CSS and JavaScript files:

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE application/x-javascript
</IfModule>

4. Putting CSS at the top of the document

Due to the fact that I used one basic stylesheet and, from within that one, imported the other stylesheets using the @import rule, for some reason, YSlow tells me that those stylesheet are not located in the HEAD section anymore. Because of the fact that the CSS is now minified, there is now only one single request to the CSS file using:

<link rel="stylesheet" href="[path to minified CSS file]" type="text/css" />

5. Configuring ETags…maybe not

As this website does not receive high traffic – and I therefore do not run a serverfarm – and based on Jeff Attwoods article, I decided not to configure ETags at all on the server side. If, for some reason, you would like to do it, you are free to do so by making another addition to your .htaccess file. The following turns off ETags altogether:

FileETag none

Actions taken, measuring again…

After incorporating these changes, I measured the performance again with the same tools mentioned above. The results are:

Here are the noteworthy changes that occured in the YSlow scores including comments as to which scores/rules got affected:

Conclusion

By following the Exceptional Performance Rules (well, rather treating them as guidelines and using them based on Web Development common sense applied to your site/project) I was able to improve the performance of this site as follows:

As you can see, the overall performance scores improved quite significantly. They could even be improved by further reducing the number of HTTP requests (using CSS Sprites) or trying to further minify CSS and JavaScript files. Generally, I feel that the Exceptional Performance Rules are excellent guidelines if you want to improve the performance of any particular site. As stated above, before blindly trying to follow these rules, one needs to verify how valid each of these rules is for the site he or she is working on. The rules were made with websites in mind who serve several million visitors a day – if you own one of those sites, then certainly follow these rules. If not (which is more likely), try to find out which of these rules really make sense in your case.

Further resources

• Simone Chiaretta was able to find out the weight applied to each YSlow rule in Dissecting YSlow
• Jeff Atwood tells you why Yahoo’s Problems Are Not Your Problems
• Get YSlow for Firebug
• Yahoo!’s Exceptional Performance Team
• Douglas Crockford’s JSMin
• YUI Compressor, another JavaScript minifier
• CSS Tidy, an opensource CSS parser and optimiser
• Website Performance by Ed and Stuart