Analytics eccentricities

Back around the start of March, I noticed that pretty much every time I logged in to Google Analytics I was running in to problems with the summary views.

The dashboard would typically load up my list of sites, then freeze without actually fetching any data. Refreshing the page would usually sort this out, before the same thing happened again when I click in to a site’s individual profile.

Still loading..

Occasionally, rather than the page just hanging, there would also be an error message to the effect of “This page has encountered an error which may prevent it from working correctly” which would appear in red at the top of the page. Again, refreshing the page would cause both of these to go away and normal service to resume.

Analytics quirk

We have a(n intermittent) problem

As a refresh would sort these issues out after a brief wait, they were minor annoyances, but never annoying enough to justify time and energy spent hunting the web for a cure – more an itchy finger than a bad foot cramp.

But eventually, that itch has to be scratched, so I looked in to it a little bit more. I eventually came across the following tid-bit on the analytics support forum:

mobpage: try to set your date an time of computer will work after that

My local clock was running a bit fast, so I set it back by 10 minutes or so, and the errors magically disappeared!

So what’s happening here?

Good question. As with all issues relating to google javascript, it’s quite difficult to find out exactly what’s at the root of this. The javascript is compressed and minified, so reverse-engineering it would require substantially more time than would be worth it!
My suspicion is that at some point in the javascript analytics attempts to evaluate the difference between the local clock and the remote server one. This difference can be handy to have when working with date-sensitive info stored remotely, such as the raw analytics data.

My suspicion is that somewhere along the line a bug snuck in, whereby this code allows for there to be 0 difference, or for the server to be ahead of the local machine, but forget the check for the local machine to be ahead of the server.
As such, when the local time is too far ahead, the code gets confused by the difference, hangs, and blocks the subsequent code from loading.

Why does it work fine when you refresh the page?

I’m guessing that this issue doesn’t affect a page reload due to the combination of browser caching and black magic that appears when a js-heavy page is refreshed, namely that the initial checks are mostly cached and thus not capable of blocking the subsequent page load code which was previously prevented from running. As such, the rest of the page can be rendered without issue.

Again, most of the above is pure speculation on my part without any real assessment of the underlying code. However, the important point here is that I no longer get page freezes/red error bars in analytics, and the response time is noticeably faster, all from one clock change!

Leave a Reply