Skip to content
Imagine if you only measured users that don’t make mistakes, it would present a more cheery picture of reality right? The problem is with slower code, that’s what happens.
If every user is patient, fully loads the page, doesn’t click away fast, nor swaps tabs, or loses connectivity. Then they would all be counted by analytics.
However in the real world, over a population of users these issues are commonplace. And in these scenarios, analytics code may not load. Providing a smaller (and therefore faster) payload, ensures more of these scenarios are captured. This means more accurate data for more users.
The inverse is also true, if you only count the visitors which are most engaged, analytics will end up over reporting the true performance.
Thus speed is vital for accuracy. Slower analytics can have as big a difference as 10-15% discrepancies.
To examine how Nudge performed relative to other analytics systems. We used Lighthouse, to load the scripts, in real world environments. Then documented their payload.
What happens when you load analytics:
1. Your browser sends a request to download the script.
2. The server sends the script to your browser.
3. Your browser loads the script and executes it.
The larger the payload, the longer the initialization, time to transfer, and then time to execute code on your device. In mobile environments, this is particularly important.
Other speed considerations
Analytics systems use CDN’s (content distribution networks) so that visitors can download the code closer to them. And to use optimized networks, to deliver the code faster, with less latency. Latency is the delay between when the script is asked for and it is received.
Caching is also used, to avoid repeat loading of the script. Caching is where a prior loaded copy of the script can be used instead of requesting a new one. For example, downloading once you visit the homepage, but not needing to on subsequent pages.
|
|---|
