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.
thyngster@hq:~$ ping www.google-analytics.com PING www-google-analytics.l.google.com (212.142.160.238) 56(84) bytes of data. 64 bytes from cache.google.com (212.142.160.238): icmp_seq=1 ttl=59 time=8.80 ms 64 bytes from cache.google.com (212.142.160.238): icmp_seq=2 ttl=59 time=9.12 ms 64 bytes from cache.google.com (212.142.160.238): icmp_seq=3 ttl=59 time=8.66 ms 64 bytes from cache.google.com (212.142.160.238): 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 3004ms rtt 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:
thyngster@hq:~$ 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 212.142.144.66#53(212.142.144.66) in 295 ms com. 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 C41A5766 com. 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 198.41.0.4#53(a.root-servers.net) in 915 ms google-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 NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.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 RRSIG PMC1T49FLPALQ6HR7VPE0GQRFGSM38PS.com. 86400 IN RRSIG NSEC3 8 2 86400 20141128052656 20141121041656 48758 com. cPUz3qVmzylXFxkLa870sFXMxAjAodtPcK3Nkoric83FKdaegulpxd9c eoY5zs3q5fKDNz8MjSkp4GO6MXsrbU2zOi9mueWmhVbb5OPAW7Od0DNg C6g+fSCRbIaOzsFHStWry9i7Rj9ZKPW8tayKQWuP2+p7FyTfATeg5IBA Jto= ;; Received 681 bytes from 192.41.162.30#53(l.gtld-servers.net) in 297 ms www.google-analytics.com. 86400 IN CNAME www-google-analytics.l.google.com. www-google-analytics.l.google.com. 300 IN A 212.142.160.238 www-google-analytics.l.google.com. 300 IN A 212.142.160.223 www-google-analytics.l.google.com. 300 IN A 212.142.160.240 www-google-analytics.l.google.com. 300 IN A 212.142.160.229 www-google-analytics.l.google.com. 300 IN A 212.142.160.234 www-google-analytics.l.google.com. 300 IN A 212.142.160.230 www-google-analytics.l.google.com. 300 IN A 212.142.160.251 www-google-analytics.l.google.com. 300 IN A 212.142.160.212 www-google-analytics.l.google.com. 300 IN A 212.142.160.218 www-google-analytics.l.google.com. 300 IN A 212.142.160.216 www-google-analytics.l.google.com. 300 IN A 212.142.160.208 www-google-analytics.l.google.com. 300 IN A 212.142.160.249 www-google-analytics.l.google.com. 300 IN A 212.142.160.241 www-google-analytics.l.google.com. 300 IN A 212.142.160.227 www-google-analytics.l.google.com. 300 IN A 212.142.160.245 www-google-analytics.l.google.com. 300 IN A 212.142.160.219 ;; Received 342 bytes from 216.239.32.10#53(ns1.google.com) 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:
thyngster@hq:~$ host ssl.google-analytics.com ssl.google-analytics.com is an alias for ssl-google-analytics.l.google.com. ssl-google-analytics.l.google.com has address 74.125.230.62 ssl-google-analytics.l.google.com 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.