What the data shows for Hotjar
The numbers here come from third-party-web, an open dataset by Patrick Hulce. It is built from HTTP Archive, which tests millions of pages with Google Lighthouse on mobile settings. Lighthouse records how long each script keeps the browser's main thread busy. The dataset adds that up for each company and divides by the number of pages that use it.
We used third-party-web version 0.30.0, published in September 2026, with the HTTP Archive crawl from March 1, 2026. For Hotjar it reports:
- Average script execution time: 732 ms per page.
- Usage: 504,590 pages in the crawl.
For context, the same crawl shows Microsoft Clarity, another heatmap tool, at 405 ms and Google Analytics at 108 ms. See the full list in third-party scripts and landing page speed.
Hotjar's side of the story
Hotjar makes a fair point in its help center. It says speed tests like Google's count the time Hotjar spends fetching its modules and sending data back, after your page has already loaded. Hotjar calls that an inaccurate picture of your site's speed.
That is partly true. Much of Hotjar's work happens after the page looks ready. But a visitor can try to scroll or tap during that window too. Script execution time still counts when it lands right as a person reaches for the call button.
What script execution time means for a phone visitor
A phone browser does most of its work in one lane, called the main thread. That lane builds the page, runs scripts, and answers taps. Only one job runs there at a time.
Google's Lighthouse docs say that when the main thread is busy, the page can't respond to user input. Google's Interaction to Next Paint (INP), a Core Web Vital, measures how long a tap waits for the screen to react. Google rates INP good at 200 ms or less and poor above 500 ms.
A homeowner on a phone does not know what Hotjar is. They know the page felt stuck when they tapped. That is the cost to weigh against what the heatmap teaches you.
How to load Hotjar the smart way
Heatmaps and recordings are worth having on an ad page. They show where people stop scrolling, what they tap that isn't a link, and whether they ever see your form. The trick is to get that without paying for it on every visit.
1. Delay it, the way Hotjar suggests
Hotjar's help center lists three ways to reduce its impact on speed:
- A timer in Google Tag Manager. Fire the Hotjar tag a few seconds after the page loads.
- After the visitor interacts. Load Hotjar only once someone clicks or scrolls.
- After DOM Interactive. Load Hotjar once the page's main code has had its turn.
Any of these lets the page get usable first. The trade is that you may miss people who leave in the first second or two. For most ad pages, that is a fair deal.
2. Run it during a study, not forever
You do not need recordings of every visit, every week, for a year. Turn Hotjar on for the ad page while you are testing a change. Collect enough sessions to learn something. Then turn it off until the next test.
Heatmaps are most useful right after you change the page, like a new headline, a shorter form, or a bigger call button. That is when you want to see what visitors do differently. Between tests, the data piles up and nobody reads it.
3. Keep one tool per job
Two heatmap tools on one page means two scripts doing the same work. If you run Hotjar and another session recorder, pick one.
Check the page before and after
The dataset shows averages across many sites, not your page. Scan before you change anything, make the change, and scan again.
ClickMend checks the page your Google Ad sends people to. It gives a 0 to 100 score that blends Google PageSpeed Insights performance (40%), Core Web Vitals (25%), SEO basics (20%), best practices (10%), and accessibility (5%). It names unused JavaScript and other slow parts, so you can see which scripts weigh the page down. It also checks that your Google Ads conversion tag is on the page and loaded.
Scan the landing page free, 2 scans a week, no card. If clicks are coming in but leads aren't, also read why Google Ads clicks don't convert.
Frequently asked questions
Does Hotjar say it slows down sites?
Hotjar says its script loads asynchronously and is designed for minimal impact. It also says it cannot guarantee your site will not be affected, since every piece of JavaScript can affect a site.
How does Hotjar suggest reducing its impact?
Hotjar's help center suggests delaying when Hotjar loads, using a Google Tag Manager timer, loading it after the visitor clicks or scrolls, or loading it after the DOM Interactive event.
Will delaying Hotjar lose data?
It can miss visitors who leave before the delay ends. For an ad page that is often a fair trade, but decide based on what you are studying.
Where does the 732 ms number come from?
From third-party-web version 0.30.0 by Patrick Hulce, built on the HTTP Archive crawl of March 1, 2026, across 504,590 pages that load Hotjar.