How much does server location really matter

A bit of background

Sonassi is a Magento hosting provider, that specialises wholly in high performance Magento hosting using the highly regarded MageStack Operating System. We have Magento developers and Magento consultants on staff to support hosting customers; we eat, sleep and breath Magento.

A question that we are (extremely) often asked is whether we have servers installed in [country X]. More often than not, the question is posed from US merchants, looking to use our hosting services (as of writing this article, the majority of our infrastructure is in the UK). So I find myself in a situation where I've got two challenges to overcome,

  1. To educate the customer on the technical relevance (and irrelevance) of location
  2. To change the feeling-driven decision into a pragmatic one

This prompted a little bit of a sarcastic response, in an email to an existing customer looking to refer another. Tongue-in-cheek pitches aren't exactly the recommended path for converting a sale, but in this case, I felt a little humor might help convey the technical aspect better.

Clearly amused with my own email, I felt it deserved sharing with the world, so a tweet followed with a screenshot of the email. It stirred up a few comments ...

So in the context of the email response, hosting a US store, from the UK - I want to add a few of my own thoughts.


Server location has far less importance that you might believe. Speed and reliability are absolutely important - but neither correlate with location, they aren't mutually exclusive. Your store could be significantly faster hosted with Sonassi in the UK, than in your domestic market.

Take the time to read this article and see why.

The facts

There are a lot of reasons why hosting your Magento store outside of your domestic region might seem like a bad idea, after all,

  • Latency - Data crossing the Atlantic Ocean will incur additional latency
  • GeoLocation - The IP address will be graphically tagged with the wrong region
  • Connectivity - Connectivity between the two regions is a point of failure
  • SEO - SERPs will be impacted by the location of the server
  • Speed - The store would be slower if it wasn't hosted in the US

I certainly can't argue with the above, they seem like fair, rational statements that should put anyone off using international hosting providers, right?


Latency UK to US

Using a few tools from a number of major global ISPs, we are able to determine what the latency is going to be between the locations.

If we compare New York City in the US, to both Manchester in the UK and San Francisco in the US, we can see a rounded impression of what it would mean if our NYC targeted website was hosted in the US (from a west-coast DC) to the UK.

NYC to NYC   ~10ms
NYC to SFO   ~75ms
NYC to UK    ~75ms

From a latency perspective, its equidistant between the US-West and UK, despite all the water between us, it isn't changing the statistics too dramatically. To add perspective to these numbers, the time it takes the human eye to blink is between 300 and 400 milliseconds. So even in the worst possible scenario (customers in San Francisco, server in UK), the data can have made it to the UK and back twice, in a blink of an eye.

Tests conducted using Cogent's Looking Glass and L3's Looking Glass.

How relevant is latency

[~]$ curl -w "@curl.txt" -o /dev/null -s ""
    time_namelookup:  0.035
       time_connect:  0.079
    time_appconnect:  0.000
   time_pretransfer:  0.079
      time_redirect:  0.000
 time_starttransfer:  0.360
         time_total:  0.566

That's a good question. Latency dictates the absolute baseline for performance, you can't load a request faster than the latency between the locations is going to permit, but in the grand scheme of a full HTTP request, what does latency actually account for? I've picked a recently showcased (and arguably quick) Magento store to test on.

So, there's a number of measurements, the one we're most interested in is time_connect - the time it took the server to acknowledge our request. In this case the connect time (of which latency will be the major contributory factor) was responsible for 0.079s of the total 0.566s load time, ~13% (or a quarter of the time it takes you to blink).

So in the big picture, what does latency actually account for - in terms of the total page load time (measured as time to first byte TTFB)? I took a sample of a number of stores we host and averaged out the results. The test was run from a standard DSL connection (as a customer would have) to the respective web sites, measuring a request from a UK customer, to a UK server (ie. the server in the same domestic region)

Latency Chart

The answer: It depends on fast your store is to begin with.

  • If you've got a lighting fast site - latency accounted for a whopping 30% of page load time (that's 1/10th of an eye blink ~0.03ms). In this case, there is definitely a reason to consider latency, there's no question.
  • If you've got an average site - latency is far less relevant, only 3% of the total TTFB was made up of the latency
  • If you've got a "snails pace" site - latency is entirely irrelevant, barely 1.5% of the total TTFB was incurred by latency
Location Latency (ms) Server Render Time (ms) Total Load Time (ms)
US 75 2000 2075ms
UK 150 500 650ms

The most important thing to note is not what latency a hosting provider's location will add, but how much they can reduce your page load time by. If you've got 2 second page load times with a US host, and Sonassi can (and regularly do) deliver 0.5 second page load times - then even in the worst possible case, adding 150ms from US-West to the UK, the total page load time, from the UK will still only be 0.65s - over 3x faster than the US host.

The interesting thing to note here is that whilst your (and our) focus has been wholly on hosting provider latency, what we've glossed over is an equally as important statistic for the lightning fast sites - DNS resolution. Pick a slow DNS provider and you can easily see your low-latency, high speed site be reduced to that of the snails pace site.


IP Location

There is a widely believed (and incorrectly) held opinion that IP addresses have a location tied to them; that there is such a thing as a UK IP, or a Spanish IP, or US IP. Sorry to burst your bubble, but there isn't - there is no 1:1 correlation between IP address and location.

The popular GeoIP database by MaxMind keeps a "rough" idea of what IPs belong to what region, but this service relies on human input to manually update the DB, it requires the IP owner to contact MaxMind to ensure the records are correct.

Sonassi own a number of IP blocks, you can see a few of our publicly visible blocks via our autonomous system (AS199542). What you'll also notice (if you visit this link) is that somehow, we've managed to posses UK and US IPs - despite the fact, all these IPs originate from the UK.

Yeah, but what about tracing the IP?

DNS Root Servers

Good point. The information held in the GeoIP DB isn't going to have a bearing on where the actual IP is, so if Google (or anyone else) really wanted to see where an IP address was, they could just traceroute it back to its real location.

This will work perfectly well in a unicast network, where a single IP is announced at a single location; it does not apply to anycast networks, where the same IP is announced at multiple locations. A great example of this are the root servers that make up what is the entire internet's DNS resolution. The seemingly small (13) different IPs are actually announced in over 130 different locations, across hundreds of devices.

With services like CloudFlare and Incapsula becoming more popular, more and more websites "lose" their geographic identity, as their "geographic" IP is replaced by that of the service's anycast IPs - announced simultaneously all over the world.

Ultimately, there isn't any definitive way of knowing where an IP actually resides as IPs have no fixed or determinable location.



It makes sense that the further you are away from something, or in networking terms, the more devices your traffic has to pass through - the more likely the potential for failure. After all, if your traffic has to transit 2 devices, versus 20 devices, there is 10x less risk of failure. So the logic would be that hosting in your domestic region is naturally going to be more reliable, because there are less parts involved. Well, that's almost true.

The location of a provider will have some bearing on path that your customer's traffic will take to reach your web server, but simply having "less hops" between the two by no means makes it less likely to fail, or any more reliable.

Take the example to the right. Sonassi has multiple connections to the internet, via Tier 1 internet providers (the companies that effectively are the internet), and our (fictional) US hosting company has only one. Now under non-fault conditions, the US hosting company is going to have us beat on latency, we've established that. But what happens if their (single) connection to the internet fails, there is no fallback - the server would immediately be inaccessible to the world. However, Sonassi, with its multi-homed connectivity has at least 3 other paths still available.

The crux here is that location has no bearing on reliability, what will drive reliability is the quality and quantity of the hosting provider's transit connections to the internet.


Speed Matters

I'm no SEO, so take my response with a pinch of salt.

There's numerous videos out there from Matt Cutt's, from way back in 2009, where he makes reference to location being a (very) minor ranking factor - but equally, that merely tagging the location for the respective domain in Google Webmaster Tools or having a CC TLD would achieve the same thing; it tells Google where your site markets to, but where it physically is, isn't relevant. There's also some good reading from Google here.

A far more effective means of improving your local (geographic) listing is simply opting into Google Maps local business listing service. You'll receive a physical postcard (who doesn't love snail mail!) to claim that you are in fact said business, and that you are based exactly where you say you are (unlike an IP). It ties your website to your geographic location.

Speed matters, location doesn't imply speed

What has become more important is that new (and important) ranking factors in SEO are that of speed, how fast, in total your site is. You are more likely to rank poorly with a slow Magento store, than you would if it were quick. As we established earlier, if a UK hosting provider can load the site faster than a US provider (even with the added latency), its an obvious choice - you will rank better with the faster provider, not the "closest".


My intentions with this (extended stream of consciousness)/article, wasn't to prove anyone wrong - its not to convince people that location somehow has no bearing on baseline latency, because it does. A site will only ever be as fast as the latency incurred reaching it. That means if you host your US store from the UK, the fastest it will ever be is 75ms.

But what I am trying to drive home is that if you don't have a store that loads in 75ms (and not many do), and its closer to the 500-1500ms mark, then you could well see a marked improvement in using a hosting provider that can deliver faster speeds and more reliable performance; and whether that hosting provider is in the US or the UK, if the total page load time is lower than what you started with, then you have proved that location wasn't as relevant as you thought it might be.

But there may be hope yet, MageStack Edge

MageStack Edge solves all the problems outlined above; by bringing your SSL termination, your static content delivery, your dynamic content delivery (and a whole host of native MageStack features like DOS filtering, WAF, log aggregation etc.) straight to a point of presence in your domestic region.

As it is fully integrated into MageStack, nothing is required to leverage the functionality, just turn it on, and enjoy the benefits. Now location, really doesn't matter, with MageStack Edge, your store is everywhere.

  • Kalen Jordan

    Hey there - the mystery customer who sent the initial email that sparked this madness here 🙂

    So couple of thoughts. I'm glad you took the time to document all of this - it shows how thorough you are in looking into issues and the depth of knowledge that you have about how hosting infrastructure actually works behind the scenes, which has always impressed me.

    The short answer is that yes, the 75ms matters, and will continue to matter increasingly over time as standards continue to increase around page load time. As I test the site from time to time, I usually see somewhere between 250ms to 500ms TTFB. You've done a great job of breaking down the actual figures and I'm sure that your numbers are more accurate than the ones that I'm pulling from my chrome network tab.

    But that's my experience. Whereas with my site that's hosted on a digital ocean droplet in SF, I see 30ms to 50ms TTFB. I know that's kind of cheating because I'm very close physically to SF, and people in NY will see a much higher response time, which is kind of one of the main points of your post. But even if one of the coasts could have that fast of a response and the other coast was 2X that, that would be a lot better.

    The other point of yours that I agree with is that if you're already at 900ms TTFB on some other Non-Optimal US Host, then the 75ms to 150ms of additional time that you will see in the UK is kind of irrelevant, particularly when you factor in that you will be working with basically the best magento hosting company in the world.

    So I agree with that and it's the reason why I continue to recommend Sonassi even to people in the US.

    But - I do *get it* when they say that they want US hosting, and I feel the same way myself. The benefits outweigh the downsides for us though b/c you guys are awesome. But it is something that matters to me. If there was a Sonassi in the US - all things being equal - we'd switch to them in a heartbeat. And we'd probably (maybe) even switch if the price were slightly higher.

    Another factor that I think of from time to time is support. You guys always reply to support tickets probably faster than any other vendor that we work with, even outside of your regular working hours - but I kinda feel bad about it. I feel bad about filing a support ticket at 3pm Pacific time on a Friday b/c I know it's the middle of the night on a weekend for you. And again you always reply very fast, but I feel kinda bad about it, and it would be nice to have someone with regular US hours so that I didn't have to feel bad about it.

    That's a very minor issue but I suppose worth mentioning in the context of this question.

    Another kind of minor thing is just the lag time in working with SSH. I know that you're probably going to feel like that's such a minor thing and a nitpicky thing, but when I work with my digital ocean site over SSH and feel that snappiness of the 50ms network latency, it just feels a *lot* better. And when working over ssh, sometimes a single mistyped character could cause Very Bad Things to happen. That never has caused a problem for me but it does cause a little extra level of anxiety when working over SSH. Again fairly minor but worth mentioning.

  • That was a mind blowingly informative post.

    Reading your content on here, and seeing the contributions made on r/magento makes me wish I could turn back the clock and go with you guys for hosting over Rackspace when I was in charge of a Magento site. Nothing against Rackspace at all - very competent support - but you guys REALLLLY know your stuff.

  • nawfal

    Thank you, good article.