Hotjar's script, like most scripts and other tracking solutions, will only have a marginal (almost negligible) effect on your site's speed and performance. In Hotjar's case, we take all the necessary steps in ensuring fast deliverability of our service on your sites with as little impact as possible. Here is how:
1) The script is loaded asynchronously.
This means that the Hotjar script does not stop your site from loading its own assets. This ensures your visitor's experience is not jeopardized.
2) The script is served through a Content Distribution Network (CDN).
In a nutshell, this means that our script is served to your visitors from a system of strategically positioned servers around the globe, not just from a single location. This allows the script to be loaded faster by your visitors while offering much better availability. We currently average 130 - 200ms globally.
3) The script makes proper use of browser cache.
Although the script loads asynchronously, it is still important to get the script loaded and running as fast as possible when tracking visitors. We do this by making the best use of browser cache by loading two separate files which are reloaded by browsers at different intervals or when changed. These files, together with all other requests we do, are explained here.
Regarding usage tracking, Hotjar primarily does two separate things:
- At regular short intervals (every 100ms or 10 times per second), the cursor position and scroll position are recorded. Clicks are recorded when they happen, capturing the position of the cursor relative to the element being clicked - these are functions which in no way hinder experience as they are by nature very simple - capture the location of the pointer when a click happened or every 100ms. The events are sent to our servers through frames within the WebSocket we set up which is far more efficient than sending XHR requests at regular intervals.
- When it comes to recordings, changes to the page are captured using the MutationObserver API which is built-in into every modern browser. This makes it efficient since the change itself is already happening on the page and the in-built browser MutationObserver API allows us to record this change which we then parse and also send through the WebSocket.
Unfortunately, these types of measuring tools don't always give an accurate picture when tracking scripts like Hotjar.
The Hotjar script loads asynchronously, meaning it doesn't prevent the rest of your site from loading while it downloads. It loads in two parts, with the initial part containing the settings of your site, and the second part containing the modules that allows us to track data.
Then, depending upon the specific Hotjar tools you have setup and which pages are being targeted, it opens up a WebSocket and begins sending information back to our servers. Your site has usually has finished loading while this process is happening in the background.
When these tools measure a site with Hotjar installed, it usually includes the time that Hotjar takes to request the full batch of modules from our servers, as well the time we start to send data back. But this ends up giving you an inaccurate picture, because your site has finished loading and now it is just Hotjar sending back analytics data.
We take site performance very seriously and do everything in our power to optimize everything in the process.