1 - Google uses a CDN (their own, but a still CDN) which puts servers around the world close to users so visitors in Japan connect to a server in Japan. You can do the same with a commercial CDN (Cloudflare, Akamai, Fastly, etc).
2 - Google’s TLS handshake is tuned so it only needs one round trip. Yours looks like it may be using 2. A CDN will likely already be tuned but if you want to optimize your server’s negotiation, start at https://istlsfastyet.com
You can run dynamic requests through a CDN as well. The CDN doesn’t actually cache the response if it isn’t cacheable and it makes the request back to the origin but the browser <-> CDN connection setup is much faster (and the CDN can maintain persistent connections back to the origin if it makes sense. These days the best architecture is to serve all of the dynamic and static content over the same domain, terminated at a CDN. That way HTTP/2 can provide the most benefit.
(that said, the Google analytics js is static and cached at the edge so it is actually served from the CDN).
Hi - pmeenan is right.
All of those providers terminate as close as possible to the end users. They use dynamic DNS to allow the browser to connect to a datacenter as close as possible to them.
SSL handshakes can take a few packets back and forth. So take a normal ping from A<->B and multiply that by a few and your getting closer to your 500ms.
Possible options that you have:
cloudflare - there service will terminate your SSL much closer to the end user and then fetch the content from your origin server(s)
cloudfront (+ ELB) - you can now server dynamic content over AWS’s cloudfront which can connect out to external or internal origins - I haven’t done this yet -so I’m not sure if an ELB is also required.