Google has just released the AJAX Libraries API. Google has created an API that allows developers to access a number of popular javascript API from the Google Cloud.

You can use the Google AJAX Libraries API to reference:

• Prototype
• JQuery
• MooTools
• Scriptalous
• Dojo

Why is this good idea ?

1. Its Fast - its hosted on the Google CDN.
2. The libraries have already been optomised ie. minified, delivered via compression
3. It enables better caching of key libraries from one site to another. ie. Visit site A that uses mootools it downloads the javascript. Visit site b that uses mootools and it fetches it from the cache.

How do I use it ?

Its really easy to use. Either call the scripts directly eg.

<script src=“http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js”></script>

or use the Google API to load them scripts.

<script src=“http://www.google.com/jsapi”></script>

<script>

// Load jQuery

google.load(”jquery”, “1″);

A couple of requests to Google

The AJAX Library API is a fantastic idea, but it could be better. We have a couple of requests .

1. can you host more of the legacy versions of the libraries. (We use an old version of prototype. The recent versions are a little bloat for what we need).
2. It would great if you could provide stats on how many sites in a particular country are using the libraries. Then we can see if there are other sites in that are using the same libraries and then we get the benefit of caching
3. Properly minify the scripts! Thanks for to Eric for pointing it out.
4. Fix the Website. The FAQ and Groups links are going to the wrong place !

What is parallel downloading?

In order to explain what parallel downloading is we first have to illustrate how a webage is rendered by a browser. When you type in the URL and press enter, the browser looks up the DNS for the site, connects to the webserver and requests the base HTML of the site. The browser downloads the file and then starts to parse the HTML. The browser starts to queue up the components of the page it needs to load and then finally begins to render the page.

If the webpage and web server are set-up properly, the browser will seek to download the various components in parallel. ie. it can load multiple components at the same time. Unfortunately, javascript and CSS files can block other components from being downloaded until the files are fully loaded. This blocking behaviour can make a huge impact on a users experience in downloading the page. This blocking behaviour is illustrated below.

Why do want my site to load in parallel ?

The major objective of website optimisation is to minimise the time spent downloading a webpage. One way to achieve this is to load as many components as possible in parallel. (without comprising performance!) The HTTP/1.1 Spec defines that browsers can download two files in parallel from a hostname.

As we move more towards the broadband era, we want to promote more parallel downloading to speed up the delivery of our web content.

Examples:

Below I have included the download profile using IE 6.5 of two New Zealand websites to illustrate why parallel downloading is important.

Good - Parallel downloading

Here you can see the download profile of Trade Me Homepage. You can see that the images load in chunks of 4 at a time. This illustrates how you can much you speed up the loading of your page components.

Bad - Sequential downloading

Here you can see the download profile of Sky City Cinema Homepage. Notice the stepping behaviour of the javascript files loading. The javascript files are loading in single file, one after the other - NOT in parallel. You can see from this behaviour that the loading of the script files is blocking the rest of the content such as images from loading. This explains the delay on the page before the user starts to see the rest of the content.

How did I get my site to load in parallel?

1. Analyse your current downloading pattern. Use Firebug or SiteTimer to show you how your page is loading. Look for what is loading in parallel and what is loading sequentially.
2. Minimise the number of blocking files ie Javascript and CSS. When possible combine and use web compression to speed up loading of the site.
3. Split your page components across multiple domains. ie. One for images, one for ad components. TIP: Create a domain alias for your site eg. for all your images eg. images.blah.com. The browser treats this as a new domain even though its referencing the same webserver.
   Example: For ZoomIn maps - we use 4 domains for the map images, that means for a broadband connection the browser can load upto 8 images at a time.

Note: YSlow research shows that a total of 2-4 domains per page is optimal.

Resources:

• FireBug
• SiteTimer
• YSlow
• Yahoo Performance Blog

I’ve just completed a mini audit of the total size of the frontend vs backend requests of the top 75 NZ homepages

The average backend request size is 27.32K (ie. the size of the base html of page) and that equates to an average of 10.65% of total page size. What this means that is 10.65% of the pages is made up of HTML and the other 89.35% of the page is made up with the other content.

What does this mean and why is it important?

A backend request is the base html of the page. The frontend requests are all subsequent requests to load all css, images, javascript etc of the page. As you can see in the above graphic of the download profile of ZoomIn Homepage , you can see that the base HTML is loaded first and then other components of the page (ie. CSS, javascript and images) are loaded after the base HTML

This behaviour is a really important aspect of web compression as the faster you can load the backend html, the faster the rest of your site will start loading and more importantly the faster your users can start using the site.

Why does web performance matter????

Google has announced that it will start adding page load times into formula for ad ranking. They say that it may have an effect on your keyword score.

Here’s what Google says about why they are making the change.

Why are we doing this?

Two reasons: first, users have the best experience when they don’t have to wait a long time for landing pages to load. Interstitial pages, multiple redirects, excessively slow servers, and other things that can increase load times only keep users from getting what they want: information about your business. Second, users are more likely to abandon landing pages that load slowly, which can hurt your conversion rate.

There is more information at the adwords help center.

This part II of my audit of New Zealand Homepages (Part I looked at the top 75 homepages in New Zealand).

I have conduct an audit of 320 Government websites looking at their web performance. The audit was conducted by using YSlow to analyse the download performance of the homepage of a Government website. The list of government websites was taken from the New Zealand Government website. Full results are available from this Google Spreadsheet. Audit conducted on Tuesday Night 20th May 2008.

Audit Findings

Homepage Size

Graph of NZ Government Home page sizes

(Click on the graph to view values)

• The average homepage size was 216.85K (Compared to 304.5K for top 75 NZ websites) The largest Homepage was staggering 2442K and the smallest homepage was 8.3K,

Web Compression

Graph of Web compression usage on Government webpages

• 84.1% of Government homepages were not compressed, 11.6% are compressing some of the page elements and only 4.4% (14 sites) are fully compressing their pages.
• Some sites are compressing only CSS and JS files but NOT their base HTML
• A lot of sites have compression external javascript eg. Google Analytics (which was discounted as being part of the site) This highlights that all external javascript should be compressed.

Other findings

• The worst site had 151 files for their homepage and the best site 3 files
• The worst offending pages had over 21 Javscript files and the worst offender for the number of CSS files was 40.
• Some sites have duplicate versions of scripts running. One site had 4 Google analytic scripts running.

Tables

Top 10 best Government homepages ranked by YSlow

Top 10 worst Government homepages ranked by YSlow

Top 10 smallest Government homepages by size

Top 10 largest Government homepages by size

I’ve just completed an audit of the 320 government websites as listed in the Government service directory.

The key findings are:

• The Average homepage size for NZ Govt site is 216.85K

• Largest homepage is 2442K
• Smallest homepage is 23.3K
• 84.3% of Govt Site use NO Web compression, 11.5% have some Web compression and only 4.7% use web compression
• Some sites are compressing CSS and Javascript but not the HTML.
• Bad design - one site uses 40 CSS files and another site uses 21 javascript files
• A number of sites have duplicate copies of some javascripts.

I’ll be posting the full report tomorrow.

Related Posts:

• Average NZ homepage size is 304.9K
• Global average pagesize is 312K

My post on NZ Homepage Hall of Shame has shaken things up. I’ve had a number of emails and comments on the blog. A number of sites are now actively looking at improving their page architecture.

Update: A proposal to add web compression to the e-govt webstandard ! Great news.

Kudo’s to New Zealand Herald and Vodafone for taking action and improving their pages. Their numbers now are:

I’ll be doing another audit soon to profile the rest of the sites.