ProjectX Technology

I decided to have a look at “The NZ homepage hall of shame” , 1 year on. ( Part of the speeding up NZ Internet series, I’ve just finished retesting the web performance of top 75 NZ homepages and added another 25 websites to cover the departure of a few sites) .

This time around, I’ve added a couple new metrics, including website download time. I’ve used Webpagetest.org.nz to calculate download time. The webpagetest service is equivalent download speed to a fast office connection. (ie. they have 15Mb Down 1Mb Up connection !)

The bragging rights for NZ’s fastest webpage does not belong to Trade Me but to Land Transport at #1 and Canterbury University at #2. (Although Trade Me dominate the Top 10).

The key takeaway from this audit is the effect of too many page elements will kill download speed. Reducing the number of page elements will speed up the site!

Summary Findings

• The average page size of homepages was 359.6K. ( Up from 305.1K)
• Fastest sites load < 1 sec. Top site loads in 0.246 secs ! The average download time was 3.85 secs
• 33% of websites use NO WEB COMPRESSION (Down from 52% – Great improvement)
• The largest pages were over 1000K
• A lot Advertising javascript still is not being compressed
• Some sites have dozens of Javascript and CSS files, worst offender had 35 javascript files
• The fastest sites have less total requests. There seems to be a strong co-relation to lower total requests to speed.

Here are the summary results: (The raw results are found here - http://spreadsheets.google.com/pub?key=p94gU-OKvrDhp7ggKO8iiBw )

Here is a graph of the distribution of homepage download time.

Steve Sounders has put up the test for his stanford class on website optimisation.

There are some really challenging questions in there.

Why were ETags introduced in HTTP/1.1?
What are four techniques for reducing cookie weight?
List five techniques for making selector matching faster.
Why do ETags (with the default Apache and IIS syntax) degrade performance with regard
to proxy caching?

Kudos to Steve for pushing the boundaries of our field. Its time that optimisation was baked in by default and every web developer knew the fundamentals! That starts by teaching the students of the future.

The RPO team have released the AOL Webpagetest for New Zealand. Finally, we have a local content test frame work for testing the speed of a page.

Webpage Test is Awesome as it creates pageload waterfalls and average load times over a number of test iterations.

No there is no excuse for slow pages. Get to work NZ, we have a lot of internet to speed up !

A big day in the web optimisation space tool, we have a second new tool to help web developers in the quest for faster web pages. Mr YSlow Steve Sounders has just released a new tool – Hammerhead.

Here is Steve’s explanation behind the rational for the tool

* real user data – I love real user metrics. JavaScript frameworks like Jiffy measure page load times from real traffic. When your site is used by a large, diverse audience, data from real page views is ground-truth.
* bucket testing – When you’re getting ready to push a new release, if you’re lucky you can do bucket testing to gather performance metrics. You release the new code to a subset of users while maintaining another set of users on the old code (the “control”). If you sample your user population correctly and gather enough data, comparing the before and after timing information gives you a preview of the latency impact of your next release.
* synthetic or simulated testing – In some situations, it’s not possible to gather real user data. You might not have the infrastructure to do bucket testing and real user instrumentation. Your new build isn’t ready for release, but you still want to gauge where you are with regard to performance. Or perhaps you’re measuring your competitors’ performance. In these situations, the typical solution is to do scripted testing on some machine in your computer lab, or perhaps through a service like Keynote or Gomez.
* dev box – The first place performance testing happens (or should happen) is on the developer’s box. As she finishes her code changes, the developer can see if she made things better or worse. What was the impact of that JavaScript rewrite? What happens if I add another stylesheet, or split my images across two domains?

I’ve done a quick test of ZoomIn from our crimped broadband at home. And I can already see that we have some work to sort out page load time.





I’ve been after a tool that will measure page loadtime and exports out to a data file. A big thanks to Steve for the tool.

Stoyan Stefanov and Nicole Sullivan of the Yahoo exceptional performance team have built a image optimisation tool. Its amazingly easy to run.

1 Install the firefox plugin and press on the little face on the bottom of the browser.

2 Smushit will open a new tab and run the optimisation  process on the fly.

3 Download the optimised images in a zip file!

Here’s the result summary

And here’s the image optimisation report





A quick review of some of the tops NZ sites.

Trade Me could save 8K
TV3 could save 9k
Stuff could save 49K

Now there’s no excuse for having bloated images. Every web developer should have this plugin installed !