Your website is likely hosted on one or two servers in one spot on the Internet. To users physically local to that/those servers yes direct access would be faster, but what about people out of sate? What about those on a completely different continent?
Most of Google's services are hosted in several distinct locations and they use and their DNS setup makes sure that any given user gets sent to the one closest to them.
Even without DNS to help by handing out different IP addresses for the same service depending on the location you are calling from, they have an anycast routing arrangement whereby even when referencing some things by IP address directly you will get a local service of which there are several. For instance if I ping one of their public DNS servers from my home connection (in the UK) I get:
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=30.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=29.2 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=28.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=38.4 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=36.5 ms
and when doing the same from a VM running state-side I get:
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=12.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=12.3 ms
It is simply not possible, unless packets from/to one of those locations are travelling faster than light speed and/or nipping back in time during their journey, for these two locations to have been talking to the same server(s) despite using a specific address not a name.
As well as locality of reference, there is the benefit that your most local Google site is likely to be connected to the backbone by a faster pipe than your hosted servers (particularly for users of large ISPs who have more direct peering arrangements with Google). This comes into effect for any static content, or dynamic content where you can tell Google's checker when the content has not changed so the last version can be used, where the user does not need to wait for your server to respond in full to Google
For truly dynamic content this is going to be slower, but for many sites, especially if you have proper cache control on your dynamic content, I would expect this service to produce a measurable speed-up on average (obviously you'd have to test your specific site to see how much difference it truly makes) and it could save you a fair chunk of bandwidth if the site becomes popular.
This is certainly a service I'll keep my eye on with a view to maybe making use of it for certain projects if they ever get off the ground.
Actually, for truly dynamic content, it will still be faster to serve through the CDN. I do this for my own website, and saw nearly 2x latency improvements from seriously-offsite locations like Qatar.
The reason for this is that the CDN can keep "hot" TCP connections "open" to your backend origin servers.
Normally, when the user connects to your website, best case, he/she will have to send a SYN, receive a SYN/ACK, send their request in their final ACK (hopefully it fits), and then get their response. That's two round trips.
Then, if the file is "large", the TCP window will start out at some horrible default size, and will only get larger over the course of the connection being used, with successful packets being sent back over great distances and latency.
However, with a CDN, it likely already has a connection open, saving an entire round trip to your server. Meanwhile, if your response is somewhat heavy (multiple kilobytes), the old connection will already have a large window (as bandwidth between the CDN node and your origin server is likely high, even if the last mile to the user isn't), so you will get much higher performance and won't get stuck waiting for ACKs.
In fact, once you start thinking at the TCP level, you realize all sorts of things, like: even if you don't have existing reusable connections, the window will still warm up faster for the CDN (due to their connection being slightly lower latency and likely more stable), yielding greater total bandwidth; and, even more hilariously, even if there is no "last mile effect", having a server halfway between two servers will improve their performance due to these same windowing issues.
I'd not thought of persistent connections and window size effects - both good points especially when the receiving end is either far away or unreliable. It could save other resources too: if you deliver the content to the CDN in 0.1ms and it takes them a further 0.5s to get it to the other end, you don't have to care about the 0.4s during which your server might have otherwise been holding a PHP process (or something else similarly heavy) open.
Another thing that will help long distance if you use a large enough well managed CDN is the interconnectedness of the CDN's nodes. Google probably has a much better pipe between there point of presence here and the one nearest Qatar (to use your example), so much so that "my server -> them -> then again through their fat pipe -> user in qatar" may well be faster then "me -> user in qatar via other ISP and international peering arrangements".
Incorrect, mostly.
Your website is likely hosted on one or two servers in one spot on the Internet. To users physically local to that/those servers yes direct access would be faster, but what about people out of sate? What about those on a completely different continent?
Most of Google's services are hosted in several distinct locations and they use and their DNS setup makes sure that any given user gets sent to the one closest to them.
Even without DNS to help by handing out different IP addresses for the same service depending on the location you are calling from, they have an anycast routing arrangement whereby even when referencing some things by IP address directly you will get a local service of which there are several. For instance if I ping one of their public DNS servers from my home connection (in the UK) I get:
and when doing the same from a VM running state-side I get: It is simply not possible, unless packets from/to one of those locations are travelling faster than light speed and/or nipping back in time during their journey, for these two locations to have been talking to the same server(s) despite using a specific address not a name.As well as locality of reference, there is the benefit that your most local Google site is likely to be connected to the backbone by a faster pipe than your hosted servers (particularly for users of large ISPs who have more direct peering arrangements with Google). This comes into effect for any static content, or dynamic content where you can tell Google's checker when the content has not changed so the last version can be used, where the user does not need to wait for your server to respond in full to Google
For truly dynamic content this is going to be slower, but for many sites, especially if you have proper cache control on your dynamic content, I would expect this service to produce a measurable speed-up on average (obviously you'd have to test your specific site to see how much difference it truly makes) and it could save you a fair chunk of bandwidth if the site becomes popular.
This is certainly a service I'll keep my eye on with a view to maybe making use of it for certain projects if they ever get off the ground.