TheLadders.com Developer Blog

Unlike other tools that measure load time to judge page performance. This works much like a static code checker, and finds bad patterns that you should avoid. Because knowing your page takes 1200 milliseconds to load doesn't tell you a whole lot about what you can do to make it faster.

YSlow checks that your HTML follows these 13 Rules. They're kind of a laundry list of best practices for writing fast loading HTML. Running it on a url will point out which rules are not being follow and the areas of the page that violate them.

So back to how our homepage did. YSlow complained that we weren't gzipping our content. Now we've got a fancy ass load balancing NetScaler that does gzip for us. But it turns out we didn't turn on gzip for our akamai served content. A quick config change and we'll be gzipping all our text/html, text/css and application/x-javascript content from Akamai. This should provide a huge reduction in page just from that small quick change.

It takes a day or so for the change to propagate around akamai's network. So I'll have to run YSlow tommorow to see if we can get a passing grade from YSlow.

Some lessons here, I can't preach the value of tools that identify bad patterns enough. Now we all know "gzip your content", but without a nice clear tool to verify this, how many of us are going to start digging into HTTP headers to actually check?

On the Java side, I rely heavily on tools like FindBugs to keep my code free of common pitfalls. How many of you know that DateFormat's are not thread safe? Ever seen weird ArrayIndexOutOfBoundsException's in your server logs that you can't reproduce? I bet you it's cause two threads are parsing dates at once. We had this all over our code. Now the javadoc says it, but my IDE's autocomplete doesn't, so it's nice to have a tool like FindBugs to remind me to keep those DateFormats local.

Looks like YSlow will be a welcome addition to my suite of static code checkers.