ProjectX Blog

Introduction

This is the latest installment of the “Home page hall of Shame” which is an independent audit of the state of Web Page Optimisation in New Zealand. This test takes the top 100 New Zealand based websites from Alexa rankings and compares a number of different metrics – Page Size, Download time, optimisation scores and Javascript optimisation.

Summary

• The homepages for 100 of the top NZ based websites was measured using  webpagetest.org.nz on 1.5Mb DSL connection Thanks to aptimize.com.
• The average page size of homepages was 554.6K Up from (359.6K in May 2009 & 305.1K in 2008)
• Fastest home pages load < 2 sec. Top site loads in 1.46 secs ! The average download time was 9 secs using broadband connection. And average 4.6 seconds for a cached reload.
• 62% of websites use  WEB COMPRESSION
• The largest pages were over 2000K. The largest site was 4.6M and had images that were more than 1Mb.
• A lot Advertising javascript still is not being compressed
• Some sites have dozens of Javascript and CSS files, worst offender had 34 javascript files.
• The fastest sites have less total requests. There seems to be a strong co-relation to lower total requests to speed.

Percent of sites that got a passing grade for the basic optimization checks:

Download time distribution

Table 1 – Shows the distribution of download times of the top 100 home pages.

This

What should we do to improve

The Data

Optimisation

What? This table shows the top ranking home pages with highest optimisation scores as ranked by performance ranking tools YSlow and Pagespeed.

How? We used the website www.showslow.com to record the score for the test.

Why is this important? This result shows which sites are best optimised for web performance. The sites  are optimised sites for fastest downloading and reloading of pages.

Top 10 most optimised sites

Top 10 worst optimised sites

Download time

What? This table shows the top ranking home pages with fastest and slowest download times .

How? We used the website webpagetest.org website on 1.5Mb DSL connection Broadband in Wellington NZ to simulate a fair test of all the webpages. The test took page over the weekend 4th and 5th of December. *** (The ird.govt.nz site was re-tested on the 8th of December after they improved their download size from >2Mb)

Why is this important? This result shows which sites are fastest to load for users. The faster the website, the more pages that a user can visit in the allotted time.

Top 10 fastest home page download speed (Broadband)

Top 10 slowest home page download speed (Broadband)

Size

What? This table shows the largest and smallest home pages by total download size .

How? We used YSlow to provide the tool download size of the home page including all the HTML , Javascript, CSS, image and Flash files.

Why is this important? This highlights the total size of some of the home page. Some of these webpages sizes are out of control and webmaster need to think about the time that it takes to load their sites.

Top 10 largest home pages by size

*** 20/10 Public address have optimised their images and now the home page is 806K. Awesome work guys !

Top 10 smallest home pages by size

Cacheability

What? This table shows which sites have the fastest reload time. ie. this is the 2nd loading of a site after an initial load.  This is an indication of effective are the cacheability of the webpage.

How? We used the website webpagetest.org website on 1.5Mb DSL connection Broadband in Wellington NZ to simulate a fair test of all the webpages. The test took page over the weekend 4th and 5th of December.

Why is this important? This test shows which sites will load fastest for regular users. A cacheable site will load quickly as the browser does not have to reload all the content that hasn’t change (static content)

Top 10 fastest cached pages – 2nd reload of a page

Javascript

What? This table shows which sites have most javascript files on the home page.

How? We used YSlow to provide the number of the javascript files used on the web page.

Why is this important? Javascript files can be bad for your website if they are not properly optimised and loaded in the correct way. The scripts can be block the downloading of any other content on the webpage.  The more javascript files on the site can make the page very slow while the user has to wait until the browsers loads all the javascript then continues to render the page.

Top 10 home pages with most javascript files

I’ve been inspired by Pat Meenan’s excellent posts of the State of optimization summary and the state of web performance optimization 2010 , so I thought I’d do another “Homepage hall of shame“. – which is a web performance review of the top 100 NZ based websites. (Top 100 sites is based on Alexa traffic).

I’ll post the full report soon, here are some of the findings…

Summary Findings

• The homepages for 100 of the top NZ based websites was measured using  webpagetest.org.nz on 1.5Mb DSL connection Thanks to aptimize.com.
• The average page size of homepages was 554.6K Up from (359.6K in May 2009 & 305.1K in 2008)
• Fastest home pages load < 2 sec. Top site loads in 1.46 secs ! The average download time was 9 secs using broadband connection. And average 4.6 seconds for a cached reload.
• 62% of websites use  WEB COMPRESSION
• The largest pages were over 2000K. The largest site was 4.6M and had images that were more than 1Mb.
• A lot Advertising javascript still is not being compressed
• Some sites have dozens of Javascript and CSS files, worst offender had 34 javascript files.
• The fastest sites have less total requests. There seems to be a strong co-relation to lower total requests to speed.
• There are two main things that websites should do speed up their sites. 1) Properly Set cache expiry 2) Javascript + CSS bundling.

Percent of sites that got a passing grade for the basic optimization checks:

**Note: I’ve removed the CDN measurement as very few NZ sites use a CDN.

For more web optimisation comparison check out the Home Page drag race.

I’ve created a set of video’s highlighting the page load time differences of a selection of NZ top websites.

side edffects of prednisone

Its a drag race, lets see who can claim bragging rights????

Notes:

• The videos show download times from the US using a “broadband” IE 7.
• The page load times in NZ are faster, but this gives you an idea of which sites are faster.
• Sites are finished loading when they turn gray.
• The latency of connection from the US plays havoc with advertising page components causing some pages to take longer to complete.
• The page rendering of dynamic components also seems to load slowly.
• All the videos are made using the visual comparison on webpagetest.org.

News sites

• Winner: Scoop 13.5 seconds
• First readable page: Stuff 4.3 seconds.
• Slowest page: Stuff 40.5 seconds * Due to javascript delays

Banking

• Winner: ANZ – 12.9 seconds
• First readable page: ASB – 5.0 seconds
• Slowest page: Kiwibank – 30 seconds * Due to flash animation ?

Mobile carriers

• Winner: Telecom – 7.7 seconds
• First readable page: Telecom – 5.0 seconds
• Slowest page: Two Degrees – 21.8 seconds

Auction sites

• Winner: Trade Me – 10.4 seconds
• First readable page: Trade Me – 3.5 seconds
• Slowest page: Sella – 10.5 seconds

I spent a bit of time over the Xmas break using the iPhone for reading webpages. I’m hooked on using Google FastFlip as a way to flick through the top blogs and news sites like Techcrunch, ReadWriteWeb, VentureBeat and BBC News. Unfortunately, I discovered how really sucky browsing webpages from a mobile device is. I’m not sure what the percentage of mobile browsers on visiting site is like for the blog / news site, but I’m sure that its growing audience and the experience is far from ideal at the moment.

I’ve come up with a list of wishes that I would like for see get nailed over this year. (These suggestions are not just for iPhone but for all mobile web devices)

1) Automagic website layout engine for mobile web

A couple weeks ago, I discovered Readability, the page re-formating tool that can dynamically format webpages via a javascript bookmarklet (thanks to Lance Wiggs for the link). It was a revelation. Readability removes the clutter and distractions from the a page to just give you a page designed for reading.

Readability is designed for a normal browser not the iPhone. I did a bit of digging and found that someone has found out how to get it working on iPhone – How to get Readability on iPhone

It requires a little bit of yak shaving to get it working. (I promise only a bit of cut and pasting) So far it’s working on 99% of the pages I’ve looked at it and its a lot nicer to us.

The only downside is that I have to load the original page before switching to the Readability template.

Here’s how it looks on iPhone

Original Page

Original Page with zooming

Page with Readability applied

Readability works so well on iPhone that it got me thinking…. Surely there is a way to create a javascript library that would be able to re-format a webpage to work on a mobile device automatically. And it would be able to take into account more simplified navigational and advertising components. So then anyone with a blog can install the javascript and css on their site and be “mobile” ready. This give the content owners control over how their content is going to be viewed. Otherwise, we’ll move the content until we can see what we want.

Wish 1 – A Plugin for styling webpages for Mobile content – I’m sure that there are some clever jQuery hackers that can take the Readability approach and create a javascript library to detect and mobile device and re-factor the layout automagically.

UPDATE: It looks like Instapaper does a lot of what I want – its a mix of Delicious and Readability in that it allows you to download pages on the iPhone to read them offline and it has a mobile template for reading. Looks interesting.

2) Speed and Page Size for website.

Web pages have to be optimised for mobile devices!

I have “grazing” browser behaviour on phone that means I’m sample small bits from a number of pages. S0 I will leave open pages in the browser and re-open them after switching in and around different apps. What I have noticed is that majority of webpages have to completely reload AGAIN. The iPhone doesn’t cache any web objects (html, css , js and images ) over 15K ! (It used to cache 25K but testing has shown that its only caching 15K objects. )

Blog / news pages are often from 100 – 500K. On 3G, the page loading speed is painful. Webpages need to be optimised for web device. I’m not so worried about wasting bandwidth, more so that if its loads slowly, I’ll switch to something else. The iPhone has allowed me to consume the web in byte sized chunks, I want to quick graze not “queue” up for pages.

Optimisation tools that create packaging of CSS / Javascript and Image Spriting will need to have “mobile” settings to take into account of the mobile cache limitations.

iPhone Browsing tip from iPhone caching article

“Tapping the reload icon in the address bar sends unconditional requests for all components, without the If-Modified-Since header and ignoring the Expires header. So to speed up your browsing, refresh the page by tapping the address bar and then tapping GO, don’t use the refresh icon.
“

Wish 2 – Standards for the webpages for the mobile web. Mobile pages needs to smaller, more focused. The overall page size including ads should only be around 80-100K. Individual components should be less than 15K. Optimisation tools should have output modes – normal and mobile.

3) Merge Fast Flip + Google Reader

Please Google can you integrate Google Reader and Fast Flip. It would make the killer blog reader on iPhone. I use Fast flip all the time. The sheer volume of some of the blogs like techcrunch is far too much for me to handle and as such I normally ignore it. Using fastflip has allowed me to quickly skim over the articles and drill in and read the ones I’m interested in. I’ve found it a great tool for my blog reading, but I have some requests….

• Wish 3.1 Use the FastFlip engine on all my feeds from Google Reader.
• Wish 3.2 Give me the option to only see that pages that I haven’t seen before (not necessarily the one’s that I haven’t read)

UPDATE: Fast Flip is now been integrated into Google News via Fast Company (12/2/10)

The mobile web is getting pretty exciting especially with tools like jQTouch making it easy to make customised UI for mobile sites. We’re going to spend more time on our mobile device, website owners need to optimise our experience to be a joy not a pain in the ass.

Patrick Meenan of AOL has released aggregated data results of a years data of web page testing from webpagetest.org.

Here a quick summary of the results:

Average Load Time: 10.1 seconds
Average Time to First Byte: 1.1 seconds
Average Time to Start Render: 3.8 seconds

Average Page Size: 510 KB
Average Number of Requests: 50
Average Number of Redirects: 1

Comparing that to the web performance audit of the top 100 NZ websites.

Average homepage size: 359.6K
Average download time: 3.85
Average total requests: 57.2

Looks like NZ homepages are starting to get the message.

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.

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.

| View | Upload your own

Here’s another awesome slide deck from the Velocity conference – Image Optimisation, 7 mistakes and how to correct them (PPT) by Stoyan Stefanov.

In his audit he has found 45.6% of the total page download size of the top 10 websites homepages are images. Here is the list of 7 tips for improving image optimisation from the slides.

1. Use PNG’s over GIF’s – The big sites (Yahoo / Google /Blogger / MySpace / Live.com etc) could save 20% image size by using PNG’s over GIF’s.
2. Not crushing PNG’s – Default PNG setting are not the most optimal. Using pngcrush can reduce the size of PNG’s even more.
3. Not stripping JPEG meta data – Jpeg contain lots of meta data including in some cases thumbnails of the image and audio inside the EXIF information. (Remember thumbnails should be 3-4K in size)  Strip out all non critcial exif information using tools like jpegtrans
4. Use Palette PNG’s instead of True colour PNGs.
5. Avoid AlphaImageLoader, try PNG8 or at least _filter
6. Crush generated images – GD and Imagemagick don’t always do the best job in optmising images.
7. Use CSS sprites!

Finally Stoyan says if you optimise your images you can save 10-30% of the download size.

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