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 🙂

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]

Recently, we released the cycling and walking journeyplanner for our clients the Greater Wellington Regional Council. The journeyplanner website is an advanced map mash-up show advanced directions from different parts of the  region. What makes this site special is that we have combined a lot more data from the councils to include walkways, cycleways, tracks and extra information from all over the regional.

There are a number of unique features:

• Custom routing and directions of walking tracks over the entire region eg.  walking around the Botanical gardens

Routing through the Botanical Gardens

• Suggested journeys from all over the region to highlight some of more scenic walks around the region.

• Draggable routing over all streets, tracks and walkways around the region. We build our own custom routing engine with draggable routing front-end over google maps.

Routes are fully drag-able

Simply select and hold the line, drag to where you would like

Then let go. The route and description will automatically update.

• Elevation graph with live feedback on the map. See the little icon travel across the map as move across the elevation graph.

• Points of interest showing locations of variety of points for both walkers and cyclists such as landmarks, pedestrian crossings, traffic lights, bike shops, bike racks, street lighting and toilets.

• Calorie counter to figure out how much energy you could burn.

This has been one of the bigger projects for ProjectX and we’ve got a number of people and partners to thank.

Jill, Simon and Ian from GW. Thanks for your belief in the project and the patience to see it through to end, from wireframes to through all eight iterations until the final release. Thanks to Michael for being our physical location guru who helped connect the physical world to the data files.

Big thanks to the ProjectX team for the work on their hard work on project – Thong, Tim, Gaetan, Stephen, Cameron, Boris, Felix, Raja and Nahum. Dr Geof Leyland from Incremental for the providing our routing algorithm and advice on making it super-fast.

Our design team via Lushai user experience team- Lulu for her interaction design, and wireframes Amiria for the lead graphics, Brent and Chika for supplementary graphics.

Xlinks is a collection of interesting links as discovered by the ProjectX team.

Streetview arrives in NZ
Added on 12/02/2008 at 08:04AM
How Google’s ear hears
Added on 12/01/2008 at 07:04PM
Super happy dev house is on this week
Added on 12/01/2008 at 06:54PM

Life magzine photo archive on Google
Added on 12/01/2008 at 06:47PM

A more useful 404
Added on 12/01/2008 at 06:42PM

The size of Africa
Added on 12/01/2008 at 06:42PM

The commoditisation of massive data analysis
Added on 12/01/2008 at 06:40PM

Splitting up founders pie
Added on 12/01/2008 at 06:35PM

Tech crunchs new search engine powered by Yahoo Boss
Added on 12/01/2008 at 06:32PM

Warren Buffet – 10 ways to get rich
Added on 12/01/2008 at 06:30PM

NY Times visualisation lab
Added on 12/01/2008 at 06:28PM

Mapping the worlds supercomputers
Added on 12/01/2008 at 06:25PM

Easing the path from design to development
Added on 12/01/2008 at 06:24PM

Amazon’s cloudfront – global load balancing
Added on 12/01/2008 at 06:23PM

Silicon Welly HQ
Added on 11/29/2008 at 04:12PM

Meer Meer – Cross browser testing through one browser
Added on 11/26/2008 at 08:36AM

Billionaire lessons from Malcolm Gladwell
Added on 11/20/2008 at 09:05AM

The Food Miles Mistake – Saving the planet by eating New Zealand apples
Added on 11/20/2008 at 09:00AM

Web Sequence Diagrams – basic UML: Awesome – Hat tip to David Preece
Added on 11/18/2008 at 02:52PM

WPA-TKIP broken almost
Added on 11/15/2008 at 11:39PM

iPhone top phone in US 3rd quarter 2008
Added on 11/12/2008 at 12:25AM

We’ve been going through some big changes at ProjectX. We’re in the process of changing our business model and to be honest we’re getting pretty excited about our new future.

One of our goals at ProjectX is to build the best online mapping applications on the web. We started with ZoomIn Maps site which was the first maps site to cover all of New Zealand and offer user friendly predictive search and urls. We did it tough as had to build our own API’s and maps from scratch (with the help of some opensource).

Fast foward a couple of years, now there several map apis covering the NZ. We’ve had a change in our commercial arrangement with our data supplier and that presented us a chance to look at our existing product offerings and refocus at what we’re good at. So the first decision was to move up the value chain and move away from basic mapping API’s. It was a hard decision to make as the Map API’s were the products that we started the business on. Its time for us to move on and focus more on providing value-added applications and services.

Here’s an outline of our new focus at ProjectX:

• Independent consulting on online map tools and frameworks. We’re used most frameworks and know intimate details of the pro’s and con’s of different data and mapping frameworks. We’re data neutral ie. we build web applications on any data. We’ve got experience building web services using GIS data from around the world – New Zealand (LINZ, Terralink, NZ Post), Australia (PSMA), USA (TeleAtlas). We’re framework neutral ie. we can build maps using any framework – Google, MapQuest, Virtual Earth, GeoSmart, OpenLayers, ModestMaps or even the ZoomIn engine.
• Bespoke development – We build smart online map applications and widgets for a wide range of clients – Trade Me, SSC, GWRC, LTNZ and ARTA.
• Software as a Service – We’ll be releasing soon some new API’s tools and widgets that will work on _any_ map.
• Products – We build local search sites like ZoomIn and more coming soon ….

We’re excited about our future, as we now will be able to showcase our abilities on an international stage.