Google using ISPs to cache Google Analytics endpoint

I don't really know if this is happening users using different ISP's but starting from today I've noticed that all my requests to www.google-analytics.com were being served from a not usual but familiar IP address range, and the response time was just 9ms. Hey just a great improvement from the 42ms of average I'm usually getting from Google Analytics servers.

[email protected]:~$ ping www.google-analytics.comPING www-google-analytics.l.google.com ( 56(84) bytes of data.64 bytes from cache.google.com ( icmp_seq=1 ttl=59 time=8.80 ms64 bytes from cache.google.com ( icmp_seq=2 ttl=59 time=9.12 ms64 bytes from cache.google.com ( icmp_seq=3 ttl=59 time=8.66 ms64 bytes from cache.google.com ( icmp_seq=4 ttl=59 time=8.19 ms--- www-google-analytics.l.google.com ping statistics ---4 packets transmitted, 4 received, 0% packet loss, time 3004msrtt min/avg/max/mdev = 8.190/8.698/9.129/0.344 ms

That's is, Google Analytics files are hits are being server locally from my ISP. It doesn't seems to be a problem with my ISP, since it's the Google Nameservers who are delegating that dns response:

[email protected]:~$ dig +trace www.google-analytics.com; <<>> DiG 9.9.5-3-Ubuntu <<>> +trace www.google-analytics.com;; global options: +cmd. 443274 IN NS b.root-servers.net.. 443274 IN NS j.root-servers.net.. 443274 IN NS e.root-servers.net.. 443274 IN NS a.root-servers.net.. 443274 IN NS m.root-servers.net.. 443274 IN NS h.root-servers.net.. 443274 IN NS i.root-servers.net.. 443274 IN NS c.root-servers.net.. 443274 IN NS d.root-servers.net.. 443274 IN NS k.root-servers.net.. 443274 IN NS l.root-servers.net.. 443274 IN NS g.root-servers.net.. 443274 IN NS f.root-servers.net.;; Received 531 bytes from in 295 mscom. 172800 IN NS m.gtld-servers.net.com. 172800 IN NS l.gtld-servers.net.com. 172800 IN NS k.gtld-servers.net.com. 172800 IN NS j.gtld-servers.net.com. 172800 IN NS i.gtld-servers.net.com. 172800 IN NS h.gtld-servers.net.com. 172800 IN NS g.gtld-servers.net.com. 172800 IN NS f.gtld-servers.net.com. 172800 IN NS e.gtld-servers.net.com. 172800 IN NS d.gtld-servers.net.com. 172800 IN NS c.gtld-servers.net.com. 172800 IN NS b.gtld-servers.net.com. 172800 IN NS a.gtld-servers.net.com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766com. 86400 IN RRSIG DS 8 1 86400 20141130170000 20141123160000 22603 . KcH1dZuKA0dS9oDK2Wy8Iq/axbkR1/Dd0OnU3zgAUI88ym4rezyeHIJQ z6f7T2Ym2Ese+4ma1n0/9Q8iMvvTw8LAv+0ICzCuBtGQuCY3LhJ8uaRG AHoCVwv772zkalcRQuq07cxfllZmNykMyUgPcp/ViyQZtWcB/3eGFwJj mII=;; Received 748 bytes from in 915 msgoogle-analytics.com. 172800 IN NS ns2.google.com.google-analytics.com. 172800 IN NS ns1.google.com.google-analytics.com. 172800 IN NS ns3.google.com.google-analytics.com. 172800 IN NS ns4.google.com.CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0QFMDQRCSRU0651QLVA1JQB21IF7UR NS SOA RRSIG DNSKEY NSEC3PARAMCK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20141129055344 20141122044344 48758 com. mKMCjqttB9SBFDa9+UYTil3/baYuVXdwSsrBjWybi05WCkGUvVBe14yF HrrQUMAue5E8qBwbESuqqhwgEdspaybxel8gCwFHFCAAl12Ok5VGtMCK gYlu3/nXwfFtN46WYMPU3k83n1j/UhSypjE6OajPWV/nKVzcKfHwYQ39 NM4=PMC1T49FLPALQ6HR7VPE0GQRFGSM38PS.com. 86400 IN NSEC3 1 1 0 - PMCAVG0VD8T2G2NPG5K6HV9F6T4VRMVT NS DS RRSIGPMC1T49FLPALQ6HR7VPE0GQRFGSM38PS.com. 86400 IN RRSIG NSEC3 8 2 86400 20141128052656 20141121041656 48758 com. cPUz3qVmzylXFxkLa870sFXMxAjAodtPcK3Nkoric83FKdaegulpxd9c eoY5zs3q5fKDNz8MjSkp4GO6MXsrbU2zOi9mueWmhVbb5OPAW7Od0DNg C6g+fSCRbIaOzsFHStWry9i7Rj9ZKPW8tayKQWuP2+p7FyTfATeg5IBA Jto=;; Received 681 bytes from in 297 mswww.google-analytics.com. 86400 IN CNAME www-google-analytics.l.google.com.www-google-analytics.l.google.com. 300 IN A 300 IN A 300 IN A 300 IN A 300 IN A 300 IN A 300 IN A 300 IN A 300 IN A 300 IN A 300 IN A 300 IN A 300 IN A 300 IN A 300 IN A 300 IN A;; Received 342 bytes from in 42 ms

So it seems that's not really my isp who's acting by it's own serving me the ga.js/analytics.js and receiving my hits to the Google Analytics endpoint in some of their caching servers.


Actually even if a 304 Not Modified response code is being returned, hits are being registered in Google Analytics, so that shouldn't be something about I should care about at the moment. I must add that ssl.google-analytics.com is not being cached for me at the moment:

[email protected]:~$ host ssl.google-analytics.comssl.google-analytics.com is an alias for ssl-google-analytics.l.google.com.ssl-google-analytics.l.google.com has address has IPv6 address 2a00:1450:4003:807::101e

I must say that this looks like a good thing for our Google Analytics implementations as hits will be sent faster by our user's browsers, but in any case if you have any server-side implemention on Google Analytics using the Measurement Protocol, I'd add the "z" parameter to avoid any kind of malfunction on those cache servers preventing the hits being sent to real Google Analytics endpoint , even if that parameter is not obligatory ( it just needs to be a randomly generated number ).

As I said I noticed this today, I'm not sure since when it has been up, or if Google is doing the same with any other ISPs . I think that they have some agreements with some isp's to caché YouTube content too, saving bandwidth to Google and the ISP's and giving to users a better experience while viewing videos.

I tried with different browsers, different computers, different Operating systems and I'm experiencing the same behaviour for all of them, so I'm discarding some kind of configuration by me.