ProjectX Blog

Introduction

Recently, Gomez released information that Google Chrome was the fastest browser from real world testing. That got me thinking, how does Chrome compare to IE8 for New Zealand webpages. For most websites, IE8 is the most popular browser, so it will be an interesting piece of research.

I’ve created a mini-test of 40 New Zealand homepages. I’ve split the test into 4 tests of download performance, that represent a cross-section of the best and the worst that NZ homepages have to offer.

Image courtesy of Wedo Photography


I wanted to write a little bit of background to why I gave this talk at WDCNZ. I got hassled a little bit by the other presenters on why I gave this talk. That web performance was “Old Hat” and companies have known about this for 5 years. That’s correct, but very very few companies are doing it right especially in New Zealand. I would have loved to give a talk on advanced web performance techniques like Varnish and Edge Side Includes or how to handle 10K requests a second on a VM. BUT with the data from my Web page test results, fewer than 10% websites in New Zealand are doing it right.

Here’s the facts, if all New Zealand websites did four things

• Turn on web compression
• set expiry properly for images css and JS,
• Bundle JS and CSS files
• use image spriting

Every New Zealand website would be TWICE AS FAST.

I do a lot of Research and Development on web performance, I do consulting and I talk to a lot of companies about web performance. What I find the companies don’t understand enough about the operational side of their websites ie what is happening at the webserver and database. Some of the basic principles about how web sites scale is completely oblivious to some developers. eg. the difference between dynamic and static content.

In my talk I had to pick one site which has had all of the characteristics of bad web performance. Unfortunately the newstalkzb was the one that I choose. I could have been chosen several other websites. There are a lot of really really bad preforming websites. (As a sector blogs and news sites have a lot of work to do to improve performance)

I was thinking of a what to highlight just how “backward” the thinking in Web performance in modern terms. I came up with an idea of what was the worst html techniques that no web developer in their right mind would use today. So I made the correlation between 1990’s web design and bad web performance traits. Just as we have moved on from those designs to better designs, we need to progress web performance to next level in NZ. Its not hard to make significant performance wins.

I want developers and companies to take professional pride in their work and do a good job. I have seen very talent company release a website for a blue chip client with a 122 CSS files, which caused the site to take over 10 seconds to load. I’m sorry I can’t that seriously. Not very professional! I would want my company to be associated with kickass, innovative, FAST websites.

For those that have asked me, here is the video

How ugly is bad web performance from John Clegg on Vimeo.

WPO setting = BAD Design
No HTTP compression = Blink text
Poor expiry settings on static assets = Marquee text
No Javascript / No CSS bundling = Comic Sans font
No Image Spriting = Animated Gifs

Thanks to Martin Hipp for hacking the HTML for me!

Mobile is our future

Web Performance is even more important is Mobile. All of the web performance strategies and tactics are a lot more relevant with mobile as network latency is much much worse. The top minds in web performance are now starting to focus on Mobile, as a result the tools and best practices are being defined as we speak.

Should how we fix it?

Service companies must make it a priority with their clients. I bet that clients expect that their website will be the fastest possible. They do not understand that it has to built that way.

The best way to make Web performance happen is to make it a part of the build process of your website. There are plenty of tools to make Javascript and CSS bundling a part of your build and deployment process of your website. Then Web optimisation happens automagically everytime!

For service companies, creating a common build process with bunding and image spriting will become a small incremental cost that can be re-applied across all your clients.

If that sounds like too much work then look at mod_pagespeed module for apache or commercial solution Aptimize

Here is new image from my latest research of homepage performance.

This clearly shows the correlation between page load time and number of requests. The pageload time increases, so does the number of requests on the page.



From my presentation at WDCNZ, I recommend less than 60 total requests for a page, if you want to have a fast website.

Looks like there still a _lot_ of work to be done in speeding up NZ websites.

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 160 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 160 of the top NZ based websites was measured using  webpagetest.org.nz on 1.5Mb DSL and 20Mb connection Thanks to aptimize.com.
• The average page size of homepages was 661.8K Up from (554.6K in Dec 2010 359.6K in May 2009 & 305.1K in 2008)
• Fastest home pages load < 2 sec. Top site loads in 1.1 secs !
  • The average download time for office broadband – 5.98 secs(3.97 secs for page reload)
  • The average download time for home broadband connection – 12.43 secs (5.21 secs for page reload)
• 66% of websites use  WEB COMPRESSION
• Only 35% of sites load in under 4 seconds.
• The largest pages were over 4000K. The largest site was 4Mb and with one image over 3Mb.
• A lot Advertising javascript still is not being compressed
• Some sites have dozens of Javascript and CSS files, worst offender had 54 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 – Office Broad band (20Mb)

Table 1 – Shows the distribution of download times of the top 160 home pages using office broadband speed.

Download time distribution – Home Broad band (1.5Mb)

Table 1 – Shows the distribution of download times of the top 160 home pages using home broadband speed.

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 and 20Mb Office network connection in Wellington NZ to simulate a fair test of all the webpages. The test took page over the week of the 2nd to 11th of July.

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 using Office broadband

Top 10 slowest home page download speed using Office 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

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 20Mb Office connection Broadband in Wellington NZ to simulate a fair test of all the webpages. The test took page over the week of 2nd to 11th of July.

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)

Note: There seems to be some problems with the reload calculation as geonet.org.nz and westpac.co.nz should be at the top of this table but for some reason they are not.

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’m giving a half day  SEO training session on Wednesday for NZCS in Wellington. Pricing starts from $230 for NZCS members and $345 for the general public. This course is open to everyone.

This course has been derived from the specialist consulting that I have provide my clients over the past few years and my learning from running a number of sites for the last ten years. I’ve added some new slides from recent findings on the effectiveness of Twitter and Google+

The workshop includes the following:

Introduction to Search Engine Optimisation (SEO) and Search Engine Marketing (SEM)

• What is SEO?

• SEO and online marketing (SEM)
• SEO Key concepts
• SEO – Science or Magic?
• Paid Ads
• SEO in practice
• Page / Content Optimisation
• Site Optimisation
• Link building
• SEO and Social Media
• Tools

More courses are available in Auckland and Christchurch later in the year.

I’ve been having performance issues on a 512Mb VM where I run 3 wordpress sites for projectx and lushai. The problem was that the memory footprint default apache configuration would explode when traffic arrived. Lots of traffic would cause the Apache prefork module to spawn more processes until the machine started swapping and then cause the VM to spiral into a forced reboot.

Part one of my solution was to switch to Nginx webserver. I still wanted to use Apache, because I’m using the mod_pagespeed library for some extra performance juice, but I didn’t want to blow out memory usage. The solution involves using Nginx as a reverse proxy to apache. This allowed me to reduce the number of Apache servers down to 10. Nginx as a reverse proxy uses about 5Mb of memory It worked a treat . But it was a little slow 🙁 See the AB test below.

projectx@projectx:/px/sites/httparchive$ ab -n 1000 -c 100 http://www.projectx.co.nz/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.projectx.co.nz (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: nginx
Server Hostname: www.projectx.co.nz
Server Port: 80

Document Path: /
Document Length: 85698 bytes

Concurrency Level: 100
Time taken for tests: 112.181 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 85937000 bytes
HTML transferred: 85698000 bytes
Requests per second: 8.91 [#/sec] (mean)
Time per request: 11218.133 [ms] (mean)
Time per request: 112.181 [ms] (mean, across all concurrent requests)
Transfer rate: 748.10 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.2 0 13
Processing: 474 10689 2000.6 11051 12967
Waiting: 272 10458 1996.3 10821 12692
Total: 487 10690 1997.7 11051 12967

Percentage of the requests served within a certain time (ms)
50% 11051
66% 11220
75% 11381
80% 11525
90% 11927
95% 12409
98% 12687
99% 12799
100% 12967 (longest request)

I wasn’t happy about the performance, so I decided to throw Varnish as a proxy cache into the mix.

Using WordPress Varnish and varnish wordpress tips from the varnish site, I was able to quickly configure Varnish on the server.

Here’s the result in the performance, from the AB test.

projectx@projectx:~$ ab -n 1000 -c 100 http://www.projectx.co.nz/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.projectx.co.nz (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: nginx
Server Hostname: www.projectx.co.nz
Server Port: 80

Document Path: /
Document Length: 85689 bytes

Concurrency Level: 100
Time taken for tests: 0.366 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 86009000 bytes
HTML transferred: 85689000 bytes
Requests per second: 2733.35 [#/sec] (mean)
Time per request: 36.585 [ms] (mean)
Time per request: 0.366 [ms] (mean, across all concurrent requests)
Transfer rate: 229582.36 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 4 12 4.6 11 23
Processing: 16 25 4.9 24 36
Waiting: 2 10 5.3 10 23
Total: 29 36 4.6 37 42

Percentage of the requests served within a certain time (ms)
50% 37
66% 41
75% 41
80% 41
90% 42
95% 42
98% 42
99% 42
100% 42 (longest request)

Its a massive improvement from 8 reqs/sec to 2700 reqs/sec. Now I can remove Nginx from the mix, and now to tune mod_pagespeed to optimise my site 🙂

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

It been a long long while since I’ve written a blog post. This year has been a bit of a blur with lots of things happening – lots of consulting to companies, selling the services side of ProjectX, going on a holiday for two months and more consulting.

This blog will change as the focus of “ProjectX” the company has changed to represent my personal consulting business and interests. I’ve got a number of blog post queued up that I’ll be pushing out over the next few weeks and months.

Web performance: Its been a while since I posted an update to the “NZ Homepage hall of Shame” and I’ve created some interested videos on how “fast” a few of the key websites actually are to load compared to their market alternatives.

Blood rules: I’ve got some suggestions, advice, observations and learnings from the world of running an IT Start-up. These rules have been earned in “blood” ie. learnt the hard way via pain by those concerned. Topics that I will cover include founders, communication, seeking advice, partnerships and execution.

Geo-Location: I’ve been following with interest the rise of Foursquare and a demise of Yellowpages. I’ve got some interesting thoughts on where the industry is heading and how New Zealand will be lagging behind.

[The picture is of me posing next to a massive bath tube at Vatican Museum in Rome]