Does Hotjar slow down your landing page? Some. Hotjar tells you how to delay it.

What the data shows for Hotjar

The numbers come from third-party-web, an open dataset by Patrick Hulce built from HTTP Archive's Lighthouse runs across millions of pages on mobile settings. How that dataset is made, and the full list of scripts, is in third-party scripts and landing page speed.

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.

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 an answer. Google rates INP good at 200 ms or less and poor above 500 ms. Every millisecond a script spends on the main thread is a millisecond a tap on your call button can wait.

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.

If clicks are coming in but leads aren't, also read why Google Ads clicks don't convert.

Related guides

Frequently asked questions