Interesting that National Bank and ANZ are both owned by the same parent company ANZ National and yet their page load times vary so dramatically.
Why would they host ANZ in Australia and National Bank in NZ? Don't economies of scale factor in the equation, surely 1 main hosting provider would result in reduced hosting costs?
gmball: Interesting that National Bank and ANZ are both owned by the same parent company ANZ National and yet their page load times vary so dramatically.
Why would they host ANZ in Australia and National Bank in NZ? Don't economies of scale factor in the equation, surely 1 main hosting provider would result in reduced hosting costs?
Not only is ANZ hosted in Australia - but it's hosted in Melbourne, which has higher pings to NZ.
TBH, web sites hosted in Sydney tend to not be much slower (if at all) than ones hosted in New Zealand.
That said I don't really like the idea of using a bank or email hosted overseas myself, but lots of people seem to be happy to use hosted exchange in Singapore/Hong Kong, Xtra email in Australia, Gmail in Australia/Japan/US.
mercutio: You'd still expect the average to give some kind of meaningful result. In my testing, I've never found a normal web site that loads in 0.1 seconds. nzcouriers.co.nz seems to be the highest performing web site I've tested over time, giving minimum load times of 0.320 seconds. (trademe at 0.355)
0.320 seconds for nzcouriers.co.nz? You're lucky, I consistently get 3.7s. Also, we're not talking about loading time, so the amount of time taken to render the page isn't accounted for, we're talking about the amount of time to download all the files required for the page to be rendered. Just testing now I've been getting in the range of 0.1 - 0.3 for tsb.co.nz.
Averages over lots of connections don't really tell me what "typical" performance is like. They'd include both low and high sync rates, full interleaved, low interleaved, no interleaved connections. connections in Auckland, Dunedin etc where performance could change significantly etc etc.
Agreed, but if the results are broken down by all those variables there is far too much information to be able to process. We do periodically play with breaking the data down by different variables to see how it looks.
Obtaining some of that information for every probe (like interleaved) would be impossible.
mercutio: You'd still expect the average to give some kind of meaningful result. In my testing, I've never found a normal web site that loads in 0.1 seconds. nzcouriers.co.nz seems to be the highest performing web site I've tested over time, giving minimum load times of 0.320 seconds. (trademe at 0.355)
0.320 seconds for nzcouriers.co.nz? You're lucky, I consistently get 3.7s. Also, we're not talking about loading time, so the amount of time taken to render the page isn't accounted for, we're talking about the amount of time to download all the files required for the page to be rendered. Just testing now I've been getting in the range of 0.1 - 0.3 for tsb.co.nz.
Averages over lots of connections don't really tell me what "typical" performance is like. They'd include both low and high sync rates, full interleaved, low interleaved, no interleaved connections. connections in Auckland, Dunedin etc where performance could change significantly etc etc.
Agreed, but if the results are broken down by all those variables there is far too much information to be able to process. We do periodically play with breaking the data down by different variables to see how it looks.
Obtaining some of that information for every probe (like interleaved) would be impossible.
from dsl connection: wget -p --delete-after -O /tmp/curl http://www.tsb.co.nz/
..
FINISHED --2012-04-02 12:48:22-- Total wall clock time: 0.9s Downloaded: 18 files, 178K in 0.3s (629 KB/s)
from uk vps: FINISHED --2012-04-02 12:52:07-- Total wall clock time: 12s Downloaded: 18 files, 178K in 6.2s (28.4 KB/s)
from nz vps: FINISHED --2012-04-02 12:51:49-- Total wall clock time: 0.3s Downloaded: 18 files, 178K in 0.04s (4.09 MB/s)
it still doesn't seem very representitive. it was easily seen from the uk server that the initial page loaded very slowly, and nothing was done until it had finished loading.
so there's an increased latency bias.
from dsl connection: wget -p --delete-after -O /tmp/curl http://www.nzcouriers.co.nz/
FINISHED --2012-04-02 12:57:58-- Total wall clock time: 1.4s Downloaded: 34 files, 194K in 0.3s (665 KB/s)
So are you taking the number that it says after Downloaded?
To me it seems the wall clock time is longer than a page takes to load. And if it really takes 6.2 seconds to load TSB from the UK then they have something wrong with their international bandwidth, or the test is flawed.
from dsl connection: wget -p --delete-after -O /tmp/curl http://www.tsb.co.nz/
..
FINISHED --2012-04-02 12:48:22-- Total wall clock time: 0.9s Downloaded: 18 files, 178K in 0.3s (629 KB/s)
Which ISP?
it still doesn't seem very representitive. it was easily seen from the uk server that the initial page loaded very slowly, and nothing was done until it had finished loading.
so there's an increased latency bias.
Well, yes, I'd expect to see that a request from the UK would be slower due to latency.
from dsl connection: wget -p --delete-after -O /tmp/curl http://www.nzcouriers.co.nz/
FINISHED --2012-04-02 12:57:58-- Total wall clock time: 1.4s Downloaded: 34 files, 194K in 0.3s (665 KB/s)
So are you taking the number that it says after Downloaded?
Yes. We're looking at the overall download time.
To me it seems the wall clock time is longer than a page takes to load. And if it really takes 6.2 seconds to load TSB from the UK then they have something wrong with their international bandwidth, or the test is flawed.
A well designed page will start to render as soon as the main html file is downloaded and then plonk in the received media as it comes down. Not everyone designs their pages well!
It is possible that TSB don't have enough international bandwidth, I'm not in a position to state either way.
FINISHED --2012-04-02 13:03:12-- Total wall clock time: 1.1s Downloaded: 10 files, 364K in 0.4s (815 KB/s)
It just comparing the downloaded times, I can't see how asb is such a slow site in your results?
Correct, ASB is HTTPS only now, which is why they're excluded from this set of tests. I suspect you're referring to ANZ which another poster has said is hosted in Australia.
Bank websites are all very well, but is it that much of a big deal for me if my bank takes 2 seconds to download the page instead of 0.1 seconds (plus rendering time)? Not really. I check my bank *maybe* once a day, and click thorugh 2-3 pages, if that, so the impact is very minimal.
With that in mind, is there any view to testing access to sites where speed does matter a lot more? e.g. Youtube, iSky, TVNZ OnDemand, Quickflix, Facebook Photo album viewing. Etc etc.
NonprayingMantis: Bank websites are all very well, but is it that much of a big deal for me if my bank takes 2 seconds to download the page instead of 0.1 seconds (plus rendering time)? Not really. I check my bank *maybe* once a day, and click thorugh 2-3 pages, if that, so the impact is very minimal.
With that in mind, is there any view to testing access to sites where speed does matter a lot more? e.g. Youtube, iSky, TVNZ OnDemand, Quickflix, Facebook Photo album viewing. Etc etc.
Interesting that NB and ANZ are at different ends of the scale, especially as ANZ owns NB, and the NB brand is likely to become ANZ. So we may only end up with the ANZ website.
mattwnz: Interesting that NB and ANZ are at different ends of the scale, especially as ANZ owns NB, and the NB brand is likely to become ANZ. So we may only end up with the ANZ website.
Our trial test in December had NB at the ANZ end of the scale
NonprayingMantis: Bank websites are all very well, but is it that much of a big deal for me if my bank takes 2 seconds to download the page instead of 0.1 seconds (plus rendering time)? Not really. I check my bank *maybe* once a day, and click thorugh 2-3 pages, if that, so the impact is very minimal.
I've actually experienced occasionally terrible performance with Westpac, on more than one different ISP and connection. As well as that it seems terrible on 3g. I bet it's even worse on a capped connection.
I've also noticed occasionally that the site appears up but won't let you login saying that it's under maintenance or something. I dunno if this is typical for banks, or just an issue with Westpac. I do all my banking online, including things like checking how much money I have in my accounts. And often I'm in single focused mode while doing such, and not loading a web page in the background, so to me banking performance does matter a little.
One of the caveats with Kiwibank I've noticed from other people using it is that they seem to have a slow/complicated login process. This is just as bad to me. I dunno if it's adjustable.
With that in mind, is there any view to testing access to sites where speed does matter a lot more? e.g. Youtube, iSky, TVNZ OnDemand, Quickflix, Facebook Photo album viewing. Etc etc.
There are inherent problems in benchmarking things like youtube, facebook photos etc.
Like - if you're on one isp, and you view a friends facebook photos, then someone from that isp views the photos they're likely to get faster results than you.
If a benchmark tests the same photo again and again, you're going to get the faster results the vast majority of the time.
It's because it's hosted overseas, on Akamai with local caches.
So even if they do benchmarking, unless they force the content to be local some of the time, and remote other parts of the time, and give both results then benchmarks could be misleading compared to experienced performance
The same problem exists for Youtube.
I dunno what isky does, but tvnz ondemand's content is terribly low quality, and should work over any connection.
I really want to see testing with parallel connections to overseas common web sites. But even something like facebook is hard to benchmark - most connections now days are secure, and different people have different information on their feeds. And benchmarking the login page does very little to show real performance. And at the same time facebook performance can very by user due to their clustering of users.
Although I don't think it's likely to happen, it'd be much better to have passive monitoring looking at actual page load times, and data content transferred while users are using the net as they use it.
Like I've noticed that if you use a program like youtube-dl ( http://rg3.github.com/youtube-dl/ ) that speed will vary by just running it multiple times, and results can cycle through multiple destination servers in different countries.
from dsl connection: wget -p --delete-after -O /tmp/curl http://www.tsb.co.nz/
..
FINISHED --2012-04-02 12:48:22-- Total wall clock time: 0.9s Downloaded: 18 files, 178K in 0.3s (629 KB/s)
Which ISP?
I think this is the wrong attitude to have. As if ISP is what makes the most significant difference to national traffic.
It's like how fast does your car get from 0-60 on Caltex, Gull, or Mobil fuel. When really it depends on the incline of the road, bends, traffic on the road, the kind of car etc etc.
The access can and does make a difference. ADSL versus Cable versus UFB versus Ethernet/Direct Fibre versus Dialup.
International can still have some difference with routing, peering policies etc.
I have 10 megabit sync rate, low interleaving in Auckland, with ~20 msec pings to sites hosted in Auckland.
it still doesn't seem very representitive. it was easily seen from the uk server that the initial page loaded very slowly, and nothing was done until it had finished loading.
so there's an increased latency bias.
Well, yes, I'd expect to see that a request from the UK would be slower due to latency.
Well yes I expect to see it slower too - but by how much.
from dsl connection: wget -p --delete-after -O /tmp/curl http://www.nzcouriers.co.nz/
FINISHED --2012-04-02 12:57:58-- Total wall clock time: 1.4s Downloaded: 34 files, 194K in 0.3s (665 KB/s)
So are you taking the number that it says after Downloaded?
Yes. We're looking at the overall download time.
Again latency bias - here's a DSL connection with 7 msec ping non-interleaved, but again around 10 megabit sync rate.
FINISHED --2012-04-02 15:41:53-- Downloaded: 34 files, 194K in 0.2s (963 KB/s) Because of the lack of parallel connections the average download speed goes way up.
I wouldn't say it's 40% faster though.
To me it seems the wall clock time is longer than a page takes to load. And if it really takes 6.2 seconds to load TSB from the UK then they have something wrong with their international bandwidth, or the test is flawed.
A well designed page will start to render as soon as the main html file is downloaded and then plonk in the received media as it comes down. Not everyone designs their pages well!
I'd say that it's more significant that a well designed page includes external references within the initial TCP/IP window. Which is up to 5840 bytes (but sometimes less)
From there a well designed web browser will start making external connections straight away before the initial page has been downloaded in full.
A lot of web pages use external CSS these days, which does speed up page load times, especially when shared between pages, but testing like this will make it seem slower.
It is possible that TSB don't have enough international bandwidth, I'm not in a position to state either way.
FINISHED --2012-04-02 13:03:12-- Total wall clock time: 1.1s Downloaded: 10 files, 364K in 0.4s (815 KB/s)
It just comparing the downloaded times, I can't see how asb is such a slow site in your results?
Correct, ASB is HTTPS only now, which is why they're excluded from this set of tests. I suspect you're referring to ANZ which another poster has said is hosted in Australia.
Oops - all these three letter acronyms get confusing. With wget I get close to 1.7 seconds downloaded time (426k/sec average), which I think was on the slow side of your scale. With chrome it definitely loads faster than that though.
NonprayingMantis: Bank websites are all very well, but is it that much of a big deal for me if my bank takes 2 seconds to download the page instead of 0.1 seconds (plus rendering time)? Not really. I check my bank *maybe* once a day, and click thorugh 2-3 pages, if that, so the impact is very minimal.
With that in mind, is there any view to testing access to sites where speed does matter a lot more? e.g. Youtube, iSky, TVNZ OnDemand, Quickflix, Facebook Photo album viewing. Etc etc.
Yes :-)
Any other great ideas welcome
How about including 3g networks? 3g is often cheaper and easier to get connected to than DSL for light users now days.
I think this is the wrong attitude to have. As if ISP is what makes the most significant difference to national traffic.
It's like how fast does your car get from 0-60 on Caltex, Gull, or Mobil fuel. When really it depends on the incline of the road, bends, traffic on the road, the kind of car etc etc.
The access can and does make a difference. ADSL versus Cable versus UFB versus Ethernet/Direct Fibre versus Dialup.
International can still have some difference with routing, peering policies etc.
I have 10 megabit sync rate, low interleaving in Auckland, with ~20 msec pings to sites hosted in Auckland.
I wanted to check and see what results we saw for your ISP in particular. And the ISP can make a difference. Every you listed are factors. As is the peering agreements for the ISP, where they route their traffic (some ISPs route all national traffic via Auckland), and a bunch of other variables.
I'd say that it's more significant that a well designed page includes external references within the initial TCP/IP window. Which is up to 5840 bytes (but sometimes less)
From there a well designed web browser will start making external connections straight away before the initial page has been downloaded in full.
A lot of web pages use external CSS these days, which does speed up page load times, especially when shared between pages, but testing like this will make it seem slower.
Without getting into the ends and outs of designing a page efficiently, I think we can agree that there are lots of pages out there which aren't!
Oops - all these three letter acronyms get confusing. With wget I get close to 1.7 seconds downloaded time (426k/sec average), which I think was on the slow side of your scale. With chrome it definitely loads faster than that though.
Cool. So chrome is just starting to render the page before all the content is received.
Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly
to your computer or smartphone by using a feed reader.
Trusted
