The real cost of Hotjar on your page speed (and how to fix it)
Hotjar is one of the most useful tools in your stack and one of the worst for performance. Here is how to keep it without it being the largest TBT contributor on every page.
Hotjar is the heatmap and session replay tool most teams reach for. It's also the largest TBT contributor on the average B2B site we measure. The good news: most of the cost is unnecessary.
Why Hotjar is heavy
Hotjar records every user interaction in real time. To do that, it has to hook every event listener, mutation observer, and scroll event on the page. The initial bootstrap is around 80-120ms of main-thread work on a mid-tier mobile device. That happens during the LCP window.
The fix is not to remove it
Removing Hotjar means losing your heatmaps and replays. The fix is to defer it past the interaction window. Set Hotjar's trigger to idle in Quickload's per-script overrides on the Discovered Scripts page. The recording starts when the main thread has time; you lose the first ~1-2 seconds of session data, but for marketing sites the early seconds are mostly bounce traffic anyway.
What we measured
A fixture site with Hotjar's default (eager) trigger: TBT 1.2s, INP p75 540ms. Same site with Hotjar deferred to idle: TBT 280ms, INP p75 220ms. Hotjar still works, recordings still happen, the heatmap data is still useful.