When adding the Hotjar Tracking Code to your site and your visitors load it through their browser, Hotjar initiates certain requests which are needed to track usage:
Scripts (.js files)
hotjar-xxxx.js (where xxxx is the site ID)
This file contains the different settings your site has and updates them as you request new reports and add new items through the Hotjar admin interface (such as new Heatmaps, new Polls, etc.). Once this file is loaded it requests the modules-xxxx.js which is described below. This file is only cached for one minute.
modules-xxxx.js (where xxxx is a hash value)
This is the script file which contains the code and functions required to track your visitors and will also trigger any widgets you set up on your site, such as Survey invites and Polls. This file accounts for about 99% of the script's file size and changes much less frequently, so we cache this for much longer, 365 days or when changed, to reduce needless loading needed by your visitors
XHR requests and Websockets
This POST request is what tracks a page visit from a visitor and includes visit information such as path of URL, browser window dimensions, and the visitor’s Hotjar user ID.
XHR: xxxxx (Where xxxxx is a Poll or Recruiter ID)
This request happens whenever a visitor submits either a Poll or Recruiter widget. For every response/answer sent, a new POST request occurs.
This POST request sends the original HTML the visitor loaded for every page they visited during their stay on the site and is then used to replay back the recording.
The HTML is not sent to Hotjar if a version of the same HTML file already exists on our servers.
This POST request only happens once to a single visitor per Heatmap. It is used by Heatmaps to send the HTML the first visitor Hotjar tracks after a Heatmap loads. This is the HTML used to capture a screenshot of the page and generate the Heatmap on top of it.
This websocket only starts if Visitor Playbacks are enabled or a Heatmap or Form Analysis snapshot is collecting data for the visited page. This connection stays open while the visitor navigates and interacts with the website. Note that websockets appear as PENDING status: 101 ‘switch protocol’ in the Chrome dev console. The pending status is what keeps the connection alive whilst data is being sent.
All XHR requests appear to occur twice. In reality this happens because unlike simple requests, these are "preflighted" requests which first send an HTTP OPTIONS request header to the resource on the other domain in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data.