A lot of new stuff is released by Google these days. The Google I/O conference typically means a bunch of new products and API’s and this year are no different. In regards to performance optimization, I was very happy to discover a new Page API earlier today. That’s right, folks! A new and shiny API, making the Page Speed rules open for everyone to integrate into their products. Actually, I requested this feature last year (http://code.google.com/p/page-speed/issues/detail?id=279), why I’m even happier to see it implemented.

I’m really looking forward to see exciting new products, using the Page Speed API. In fact, I’m working on a product myself, which will definitely be using the Page Speed API. Stay tuned for more info soon.

You can check out the Page Speed API at Google Code.

Last week I blogged about Google making Page Speed available for Chrome users. This week Google surprises me again, by doing Page Speed Online. Page Speed Online is pretty much just an online edition of Page Speed for Firefox and Chrome. The funny thing is, that I just a couple of posts ago votes against Google in the YSlow – Page Speed battle. Now I think that Yahoo actually needs to deliver something new to keep up with Google.

Update: I just realized, that there’s a Chrome YSlow extension as well. I’m really looking forward to see, which new tools this competition between Yahoo and Google will bring us.

This week I’m taking a little detour from the YSlow rule series. Earlier today, Google announced Page Speed for Chrome. As mentioned in a previous post, Chrome users have been limited to Google Speed Tracer, but now they also have the possibility of using Page Speed inside Chrome.

I’ve tried out the new plugin, and besides a better-looking UI, the plugin works pretty much like the Firefox equivalent. What surprised me a bit was the score, which sums differently in Chrome and Firefox. I can’t really figure out why the scores are different, but it looks like the rules in the two versions are a bit different.

(Proofread by inWrite)

In this post I will try to explain to you the idea behind a content delivery network or CDN. I think that the Yahoo documentation on this rule is a bit confusing. So here’s my attempt to explain YSlow rule #2: use a content delivery network.

To explain the rule, we need to start by looking at the problem. As discussed in the two previous blog posts, the browser typically needs to do a lot of requests to render a page. The YSlow documentation mentions that around 80-90 percent of the time of showing a page is used up by requesting resources from the server. That’s why we need to optimize this part before looking into other stuff like your SQL or other serverlike stuff. We can do this in two ways: (1) by limiting the number of requests, as explained in the previous two posts, and (2) by speeding up the existing requests. The use of a CDN focuses on speeding up your existing requests or even avoids making them.

So what’s a CDN? According to the YSlow documentation, a CDN is a number of web servers distributed across multiple locations. The idea behind this is to be able to serve different users as fast as possible, making the response times optimized for each particular client’s location. Even though this may be the official definition of a CDN, I typically don’t use a CDN for location-based stuff. As opposed to Yahoo, most of us develop smaller websites, targeting single countries or even regions. These sites typically don’t have the need for a CDN, because the web server(s) can be placed near the users.

Why do we need to focus on this rule then? Well, a few years back we did not need to. In the meantime Google, Microsoft, and other large companies have opened up their internal CDNs for us to use. This is best illustrated by an example. You most likely use some sort of JavaScript framework like jQuery or Google Maps. On the needed pages you add a script import like this:


<script src="/scripts/jquery.js"></script>

As mentioned in the two previous posts, we could combine this script with other required scripts on our server. I usually use this approach a lot, but never when referencing scripts like jQuery. As I mentioned, Google (as well as others) made a CDN for us to use for common scripts like jQuery. Google’s solution is called Google Libraries API and serves a lot of frequently used scripts. Instead of referencing jQuery like in the example above, you should reference it like this:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js"></script>

Why is this a good idea? There are  several reasons:

1. The browser is more likely to have the response of this URL cached, because a lot of sites now use this approach.

2. Response times on Google’s servers pretty much kick everybody else’s asses.

3. You don’t need to worry about minimizing JavaScript yourself.

4. You don’t need to use disk space for common scripts.

5. Updating to a new version is as simple as changing a URL. No new download from the jQuery website required.

Start by using everybody else’s content delivery networks and build your own only if the gig requires you to.

(Proofread by inWrite)