Update: Since the original publication of this post, we have been doing some more in-depth research about the possible causes of the speed difference. We have edited the ‘Why is this happening’ section with our new findings.
Over the last few months, many folk have noticed that the Google Analytics interface seems to be running more slowly than it used to.
Some people have blamed this on the user interface and menus, some have blamed it on big data sets, some have blamed it on Users Everywhere and -- probably -- someone out there has blamed it on Trump / Brexit / shrinking chocolate bars / Kanye West.
Whatever the problem, it certainly seems to be a problem, and while the Google engineering team are understood to be looking at implementing a fix and solution, we found a pretty neat solution kind of by accident.
(Trivia buffs: Balkan was trying the VM for something else, Nick noticed it was observably hella faster than how the interface behaves locally, I got excited, then Balkan did the testing, I got excited again, then Balkan and I wrote this up.)
It turns out that if you set up a Virtual Machine on Google Cloud Platform, and load the Google Analytics interface on the Virtual Machine, the interface loads more quickly. Much more quickly: in our own testing, we found that the Google Analytics reporting interface loads up to 77% faster.
Here's What We Did
We spun up a virtual machine on Google Compute Engine, running the Ubuntu 16.04 operating system and using the Gnome desktop environment (for the graphical user interface).
Many thanks to Google’s Francesc Campoy on outlining the steps to do this. The whole process shouldn't take too long; we reckon you're looking at about a 15-30 minute setup time.
Here's How We Tested It
We ran several tests to process the same data on both the virtual machine based Chrome browser and the Chrome browser on the local machine.
We used Chrome's internal network request monitoring capabilities, and we had to log in to each with a different account, as Google Analytics’ caching capabilities foiled our test results otherwise.
(Yep, we know there's more intelligent and robust ways of testing it, and we might return to that at some point in the future. What we wanted to establish is whether we could find any measurable verification of what looked like quick loading, and this kind of does the job.)
We started with a pretty big data set, and threw a three-month date range, with a user-based segment. This is the sort of process that we'd expect to trigger slow loading in the Google Analytics reporting interface under normal circumstances.
When we ran the Frequency & Recency report, with the Returning Users segment, here's what we found:
On the local machine, Google Analytics took 12.64 seconds to load. Which sounds like a long time (but we all pretty much felt like it was normal when we experienced that load time first-hand.) The virtual machine took 6.68 seconds -- better, but still longer than we'd like (this was for a GA360 account.)
Next, we ran the User Explorer report with the segment Single Session Users for the same date range:
It's a bit more of a noticeable difference here -- 14.75(!) seconds for the local machine, and 3.36 seconds for the virtual machine.
Finally, we ran the Geo Location report with the Single Session Users segment for the date range:
The local machine was 18.6 seconds (a crazy long time on the web) and the Virtual machine was 5.2 seconds -- much more acceptable.
Why is this happening?
It beats us. Overall, the web interface on the virtual machine was significantly quicker to load in all trials.
Edit: This might be because the virtual machine on Google Cloud Platform sits on the same petabit network that Google’s core services utilise. It stands to reason that Google’s software-defined network is configured to prioritise traffic between its own set of IP addresses. Whereas when we access Google Analytics in our office, our traffic to and from Google is routed through our ISP and multiple hops, which introduces several sources of latency. This all assumes, of course, that there's some sort of limitation in place and there's no official word on whether this is the case (and if it was, it surely wouldn't be the case for GA360 as well as GA Standard users).
It’s also highly probable that GA uses Google Cloud Bigtable (thank you Graham Polley for your sleuthing!). This also means that if the GA user interface is accessed while on the Google network (i.e. on a GCP VM), the API calls to Bigtable, and the responses, would travel speedily across Google’s network.
We did consider that it might be a local limitation. Australia does have crappy internet, but we're on a 400/400 dedicated fibre, and we've anecdotally seen the same behaviour when we've been using the Google Analytics interface at home. And countries aside, there have been reports from all over the world of slow interface load times. So it's not just 'straya.
How to get set up
If you would like to set this up to take advantage of faster Google Analytics load times, these instructions will get you there. Allow 15-30 minutes and you should be set up.
Unfortunately, these instructions omit one crucial part of the set up process which will result in seeing a blank grey screen when you connect to the VM with the VNC viewer. To fix this problem, you will need to amend the /.vnc/xstartup file as described in the the following link: https://www.linode.com/docs/applications/remote-desktop/install-vnc-on-ubuntu-16-04/#configure-vnc-for-a-full-desktop
One thing we would recommend is to increase the screen resolution and quality of the virtual machine connection (using VNC viewer.) This can be done by selecting the ‘High’ option in the ‘Picture quality’ dropdown of the ‘Options’ tab, when first configuring connection details to the virtual machine.