Fast in Japan from Australian Web Hosting

Can Australian servers provide a fast WordPress user experience to Japanese consumers?

The Challenge

We had an interesting challenge recently. We needed to deploy a website to serve Japanese market consumers from Australian servers. The challenge was to provide a Hilenium Fast experience to Japanese users without provisioning hosting in Japan. The website in question was a WordPress informational business to business website for the construction industry that would support both the Japanese and English languages. If you’re wondering why speed is important read our post why a fast website matters.

Get it Fast in Australia

The first step in any optimisation is to ensure the website is fast in the web server’s local market, in this case Australia. Incidentally, we recently published the The Definitive Website Speed Guide which goes into more detail on how to achieve website speed. 

We set about optimising the website including:

• Minification of CSS and Javascript files
• Enabling GZip compression on the web server
• Compressing images
• Enabling page caching
• Utilising Litespeed cache
• Deploying a CDN – more on that later

 We then verified it with our trusty website performance measuring tool GTmetrix:

As illustrated by the above image, after completing Hilenium Fast & Found optimisations, the website is achieving A+ in both Google PageSpeed and Yahoo YSlow. 

Fast Australian website

Before we could begin the campaign to be fast, we need to determine a benchmark for the site in Australia.  We were only after a rough indication of speed in this test so we reloaded the page at least ten times to ensure the site is primed for action. The priming performs two functions:

1. Ensuring the base HTML document is cached by the WordPress CMS and also the LiteSpeed cache. LiteSpeed is the web server software we are using to serve the website. Most servers use Apache as standard.
2. Ensuring the site assets including images, CSS, JS & fonts are cached at the nearest AWS CloudFront Content delivery POP.

The data we are showing in this posts are typically in the top 20% of results. It should be noted there is can be a high variation (over 100%) in speeds between individual repeated requests. We are showing standard prompt responses.

The baseline results:

• HTML Doc: 23ms
• Website: 941ms

Fast In Japan

Whilst we couldn’t move the server location, we could move the content. To do this we deployed Amazon’s AWS Cloudfront CDN (Content Delivery Network). The AWS CDN cached the website images, CSS, Javascript and Font files at locations around the world. CloudFront uses a global Network of over 100 POPS (Points of Presence)  spread over 51 cities in 23 countries.

Fortunately there are POPS in both Tokyo and Osaka – Japan’s largest and third largest cities. Yokohama, Japan’s second largest city is only 30 km from Tokyo. Nagoya, Japan’s 4th largest city is 130 km from Osaka. It seems most of Japan will be served well by CloudFront provided the internet connection is fast.      

The advantage a CDN offers is that it can cache the majority of your content locally to your viewers. Only the base HTML document will be loaded from the origin server in Australia whilst everything else is cached (a copy of the file) on a POP close to the end user. Except for this first request, there should be little to no speed difference in the subsequent asset request between an Australian and a Japanese hosted website.

Japanese Internet

Incurring a minor speed penalty on the first request will only be acceptable if the Japanese internet network is high speed and low latency for the majority of users. According to fastmetrics as of early 2017, Japan had an average speed of 20.2 Mbps placing it in the top 10 countries globally. Over 90% of Japanese internet user achieve speeds greater than 4 Mbps. Australia, by comparison, has an average speed of 8.2 Mbps with 72.9% of users over 4 Mbps. As Japan’s speed had increased by 11% over the previous year it demonstrates network investment that we believe would server as a proxy for low latency. The Japanese network looked up to the task.

Testing From Japan

It was time time to test our theories. To do this we would need to have access to a machine in Japan. Due to language concerns we didn’t think it viable to access a real user’s machine for random tests. We turned to Microsoft Azure for a virtual machine. We chose Osaka and spun up a Windows 10 virtual with an average spec GPU and RAM configuration. We would use Google Chrome as our inspection tool.    

After priming caches a typical fast baseline Osaka result is:

• HTML Doc: 136ms
• Website: 1,220ms [ 1.22 seconds ]

Like For Like

One issue with our test was that the Australian test was from our Brisbane office with its stable, fast, but not blazingly fast, 18 Mbps line – interestingly that’s a comparable speed to the average Japanese internet user. Meanwhile the Japanese test was from the Microsoft Azure Osaka data centre. The Japanese test would not encounter the ‘last mile’ conditions that typically slow packet delivery. To balance this test we deployed another Windows 10 machine to Azure in Sydney, Australia. Sydney is 733 km from Brisbane, 922 km by road transport. In internet distance its roughly an extra 10ms ping from our office over a server in a Brisbane data centre. 

After priming caches a typical fast baseline Sydney results:

• HTML Doc: 28ms
• Website: 1,050ms [ 1.05 seconds ]

Third Party Web Page Speed Test

We though it would be pertinent also to see what independent free speed testing site WebPagesTest.org  had to say about our speed test arrangement. WebPageTest is an open source project supported by Google that started life as an AOL internal project back in 2008. The project code is up on GitHub and the server infrastructure is donated by third parties who receive advertising of their logo in return.

Sydney

WebPageTest results for Sydney AWS EC2

Tokyo EC2

WebPageTest results for Tokyo AWS EC2

WebPageTest Results

We ran test from the several Australian locations and also from the single Japanese location. We settled on comparing Sydney EC2 with Tokyo EC2 to keep it ‘like for like’. We did notice the reported response times are faster for both Sydney and Tokyo than we achieve across all our test machines, both in our office and within the Azure data centres. The WebPageTest machines we used are hosted on AWS EC2 in Sydney & Tokyo whereas the CDN’s are AWS CloudFront in Sydney & Osaka. We should expect lightening fast load times for inter-data center traffic in Sydney. Also, you would hardly expect slow speeds between AWS Osaka & AWS Tokyo.

For more detail on AWS Inter-Region Latency visit cloudping.co which publishes daily and weekly rolling average packet latency between the different Amazon Web Services Regions. There is no data published between Tokyo and Osaka. The closest AWS region to Tokyo (ap-northeast-1) is Seoul (ap-northeast-2) which has a daily rolling average of approximately 40 ms. Latency between Tokyo (ap-northeast-1) and Sydney (ap-southeast-2) for the last 24 hours averaged 113.40 ms. This matches our observed delay of 105 ms for loading the website’s 31.6 KB HTML Doc. 

The overall WebPageTest results for both locations is the five green ‘A’ and a tick for CDN usage. These are results from the Google PageSpeed module that we also see measured in the GTmetrix results at the top of this article. As expected, time to first byte is slower in Tokyo than Sydney. What is fascinating is how fast the CDN content is loading. Typical image load speeds on WebPageTest are less than 10% – 20% of what we observe from our Azure VM’s.

For a range of images that typically take 500ms on Azure VM’s are taking between 50ms to 100ms on WebPageTest. We set the internet connection on WebPageTest to ‘native’ so there is no artificial throttling of content to simulate the end-user ‘last mile’ experience. This throttling is typically added by default to compensate for the test being run from a data centre. We disabled it as we are mostly interested in a comparison between transport to Australia and Japan.

Google Speed Recommendations

Traditionally, Google has been notoriously vague when it comes to giving hard numbers that effect it search rankings. One ray of light on this subject was cast by this tweet last year from Google’s John Mu.   

So, according to John Mu, if we aim for a website load time of less than three seconds we should not experience adverse effects from Google’s Search algorithm. Fortunately another Googler has provided a more definitive insight into the importance of loading time.

In February 2017, Daniel An, Global Product Lead, Mobile Web at Google published Find out how you stack up to new industry benchmarks for mobile page speed. The article was published on thinkwithgoogle.com which is a Google information website specifically for disseminating Google Concepts to the Industry or to paraphrase their words ‘Think with Google is our way to share … as your resource for everything from high-level insights to deck-ready stats to useful tools … the data we’re exploring and the trends we’re tracking along with forward-looking perspectives.’ It is just the kind of insider rule-of-thumb on the importance of speed that we need to verify our Japan – Australia Web Hosting challenge.

As this website is for a construction industry product, mobile performance will be very important. Anyone who has construction industry experience can verfiy that the smart phone has become the defacto onsite office.

Google tells us that ‘53% of visits are abandoned if a mobile site takes longer than three seconds to load’.  According to Google ‘… We did an analysis of 900,000 mobile landing pages spanning 126 countries. … They trained a deep neural network. …. The neural net, which had a 90% prediction accuracy, found that as page load time goes from one second to seven seconds, the probability of a mobile site visitor bouncing increases 113%’. You can see a summary of Google’s results in the in their info-graphic below: 

Summary

We would be the first to admit this test is not definitive. To achieve that we would need to do the following:

1. Use an automated version of Google Chrome to perform a large number of tests at different times of the day [ we have this in the pipeline ].
2. Generate artificial website load to report if any traffic surges impact performance [we are working on this ].
3. Account for the ‘last mile’ user experience in Japan. Our Windows 10 virtual machines are sitting in data centers and will generally show much lower latency. 

Our typical ‘fast’ results listed below:

What was consistently observed was a 100ms penalty for loading the HTML document in Japan. That’s 0.1 second which is at the edge of perception for user experience. While Brisbane achieved consistently the fastest website load time its CDN assets were quite a lot slower than Sydney and Osaka. This is for two very obvious reasons:

1. AWS Cloudfront has CDN POPs in both Osaka and Sydney but not in Brisbane.
2. Osaka & Sydney virtual machines are data centre based so the content delivery does not encounter the ‘last mile’ delays a typical user experiences.

Brisbane achieved the fastest consistent HTML document load time. That is not surprising considering the web server is down the road in the Brisbane. The Sydney HTML document load was around 5ms slower than Brisbane. That is 5ms less than the typical 10ms delay to the Sydney machine and no doubt due to it being data centre based.

We have reservations about whether the Osaka Azure would be a good proxy for the typical Japanese user. If we compare the typical Australian user we see that the data centre result is actually slower than the ‘last mile’ ie. the Brisbane office. No doubt that is Australia’s vast ‘tyranny of distance’ at work. As Japan is geographically compact and has a quality high speed internet network, I expect local distance and ‘last mile’ delays to be less than half of the Australian experience.   

Overall I think our rudimentary test at this stage suggests that a Japanese market website can be served from Australia provided:

1. The website and its servers are highly optimised to be fast.
2. The websites assets are edge cached close to the end user on a performant CDN.

We look forward to doing automated batch testing. That will produce large data sets at different time of the day. Then we may give a more scientific answer to the Japan hosting challenge.