Way down the list of YSlow rules, we’ve reached rule number 11, which is important and a no-brainer to implement. The rule is titled “Minify JavaScript and CSS.” So what is minification, and why do we need it?

Both JavaScript and CSS files are packed with unnessecary characters like spaces, comments, tabs, etc. Minification is the process of identifying which characters can be cut out. One part of minification can also be done by obfuscating the code, as we know it from obfuscators for Java and C#. In short, obfuscation is the process of shortening everything that can be shortened: method names, variable names, etc. These different methods combined lead to a more compressed output file, which leads us to question number 2: why do we need it? Fetching not only JavaScript but also CSS is a time-consuming task in the browser. The render thread blocks every time the browser loads a script, which can cause the user experience to regenerate. Speeding up the load time for JavaScripts and style sheets causes the browser to render the page quicker.

Minifying your JavaScripts and style sheets is easy. You can use one of the various minification tools online like thisthis, or this. If you want to use this approach, Google for “JavaScript minify” and use the tool you think is the best.

There’s a downside to minification as well. When you want to debug your JavaScript, the minified source code looks pretty messy and is hard to read. Luckily there’s a better way than hardcoding your minified source: minifying on the fly. I’ve previously talked about Mads Kristensen’s WebOptimizer, which contains nice HTTP modules for both JavaScripts and style sheets. I usually go with SquishIt, which I wrote about in my blog post “Combining your scripts and style sheets with SquishIt.” SquishIt combines your scripts and style sheets into a single file, which reduces the amount of HTTP requests done by the browser. In addition, SquishIt also minifies the generated file. What’s really genius about the minification in SquishIt is its ability to avoid merging and minification when working on a localhost. Here you will have the ability to work with individual files as well as not-minified scripts, which helps you debug.

(Proofread by inWrite)

We all know it: zipping is a great way to compress the size of a file. This rule also applies on the web. Zipping responses from a server is natively implemented in the HTTP version 1.1 standard, which is why you don’t have any excuse left not to zip all your responses. I won’t go into a lot of detail on how zipping over HTTP works, but here is a short brushup.

When doing a request on a web server, the client can set the Accept-Encoding request header. If set to one of the valid values like “gzip,” the client tells the server that it is capable of handling a zipped response. If the server chooses to zip the response, it must set the Content-Encoding response header to a valid value like “gzip” or “deflate.” The browser checks for this header and unzips the response if necessary. This sounds a bit technical, but actually all of the above are handled by the browser. This means that all you have to do is tell your server to gzip encode your content. Pretty neat, right?

There are different ways to gzip encode web server responses. I typically use ASP.NET MVC for my projects, which does not have anything build in. I’ve seen different implementations in HTTP handlers and modules as well as custom action filters. I typically use WebOptimizer.NET by a fellow Danish developer, Mads Kristensen. It has a pretty simple HTTP module, which produces standard gzip/deflate by adding the WebOptimizer dll to your dependencies and pasting the following XML to your web.config:

<system.webServer>
  <modules>
    ...
    <add name="CompressionModule" type="WebOptimizer.Modules.CompressionModule, WebOptimizer"/>
    ...
  </modules>
</system.webServer>

It doesn’t get any simpler than this! The downside is that WebOptimizer doesn’t really evolve (last commit in 2009). If you have any proposals for a better and more recent implementation, please provide me with a link.

If you have access to configure the IIS, compression is natively supported. Scott Hanselman just wrote a great blog post on the subject.

(Proofread by inWrite)