Does Hotjar Slow Down WordPress? Performance Impact Tested

Hotjar is one of the most popular behavior analytics tools for WordPress. Heatmaps, session recordings, feedback polls — it gives you visibility into how users actually interact with your site. But every third-party script has a cost, and Hotjar is no exception.

Here’s what Hotjar actually loads, how much it impacts performance, and what you can do about it.

What Hotjar Loads on Your Pages

When you install the Hotjar tracking snippet, your pages gain the following:

• Bootstrap loader — 15KB uncompressed (~6KB gzipped) from static.hotjar.com, with a surprisingly short 60-second cache TTL
• Main module bundle — dynamically loaded from script.hotjar.com, typically 80-120KB compressed
• Session recording module — additional JS for capturing DOM mutations, mouse movements, scroll events, and form interactions
• Analytics beacon — requests to metrics.hotjar.io for event tracking
• Feedback widgets — if you use polls or surveys, additional UI code from voc.hotjar.com

In total, you’re looking at 100-150KB compressed JavaScript across multiple domains, plus a WebSocket connection that persists throughout the session. The 60-second cache TTL on the bootstrap script means repeat visitors re-download it on nearly every visit — unusual for third-party scripts that typically cache for days.

Actual Performance Impact: The Numbers

I ran Lighthouse (mobile, simulated throttling) against makewpfast.com — a production WordPress site on a Mikrus VPS running GeneratePress. Three runs, averaged.

Baseline Without Hotjar (Measured)

Metric	Average (3 runs)
Performance Score	99
First Contentful Paint	985ms
Largest Contentful Paint	1,983ms
Total Blocking Time	0ms
Cumulative Layout Shift	0
Total Transfer Size	~100KB

Projected Impact With Hotjar

Hotjar adds 100-150KB of compressed JavaScript across 3+ new origins. Based on the script analysis (not a live install test), the expected impact:

• Transfer size — roughly doubles, from ~100KB to ~200-250KB
• TBT — the biggest concern. Parsing and executing ~400KB of uncompressed JS on the main thread adds significant blocking time, especially on mobile CPUs
• LCP — minimal impact since Hotjar loads asynchronously
• Score — expect a drop from 99 to somewhere in the low 90s on a lean site like this

Important: these projections are based on script size analysis, not a direct before/after Lighthouse test with Hotjar installed. Your actual impact depends on which Hotjar features are active, your baseline score, and your visitors’ devices. Always measure on your own site.

How to Measure Hotjar’s Impact on Your Site

Don’t trust generic benchmarks — measure on your own site. Here’s how:

Method 1: Lighthouse Before/After

# Run from Chrome DevTools or CLI
# First: disable Hotjar (deactivate plugin or remove snippet)
lighthouse https://yoursite.com --output=json --output-path=./without-hotjar.json

# Re-enable Hotjar, clear caches
lighthouse https://yoursite.com --output=json --output-path=./with-hotjar.json

Run each test 3-5 times and average the results. Single Lighthouse runs have too much variance to be reliable.

Method 2: WebPageTest with Script Blocking

WebPageTest lets you block specific domains. Run two tests:

1. Normal test with Hotjar active
2. Same test with static.hotjar.com and script.hotjar.com added to the block list

Compare the filmstrip view and waterfall charts. This is the most accurate method because it isolates Hotjar’s network impact without changing anything else on your site.

Method 3: Chrome DevTools Performance Tab

Record a performance trace with Hotjar enabled. Filter the flame chart for “hotjar” to see exactly how much main thread time it consumes. Look for long tasks (>50ms) that Hotjar contributes to.

Mitigation Strategies

You don’t have to choose between Hotjar and performance. These strategies let you keep the insights while reducing the cost.

1. Load Hotjar Only on Specific Pages

Most sites don’t need heatmaps on every single page. Load Hotjar only where you actually analyze user behavior:

// In your theme's functions.php or a custom plugin
add_action('wp_head', function() {
    // Only load Hotjar on landing pages and checkout
    if (!is_page(['pricing', 'signup', 'checkout'])) {
        return;
    }
    ?>
    <script>
    (function(h,o,t,j,a,r){
        h.hj=h.hj||function(){(h.hj.q=h.hj.q||[]).push(arguments)};
        h._hjSettings={hjid:YOUR_ID,hjsv:6};
        a=o.getElementsByTagName('head')[0];
        r=o.createElement('script');r.async=1;
        r.src=t+h._hjSettings.hjid+j+h._hjSettings.hjsv;
        a.appendChild(r);
    })(window,document,'https://static.hotjar.com/c/hotjar-','.js?sv=');
    </script>
    <?php
}, 99);

This alone can eliminate Hotjar’s impact on 90%+ of your page views.

2. Defer Loading Until After User Interaction

Delay Hotjar until the user actually interacts with the page. This eliminates any impact on initial load metrics:

<script>
function loadHotjar() {
    if (window.hjLoaded) return;
    window.hjLoaded = true;

    (function(h,o,t,j,a,r){
        h.hj=h.hj||function(){(h.hj.q=h.hj.q||[]).push(arguments)};
        h._hjSettings={hjid:YOUR_ID,hjsv:6};
        a=o.getElementsByTagName('head')[0];
        r=o.createElement('script');r.async=1;
        r.src=t+h._hjSettings.hjid+j+h._hjSettings.hjsv;
        a.appendChild(r);
    })(window,document,'https://static.hotjar.com/c/hotjar-','.js?sv=');
}

['scroll', 'click', 'mousemove', 'touchstart'].forEach(function(evt) {
    window.addEventListener(evt, loadHotjar, {once: true, passive: true});
});
</script>

Tradeoff: you’ll miss data from users who bounce without interacting. For most analytics purposes, that’s acceptable — you’re primarily interested in engaged users anyway.

3. Use Google Tag Manager for Conditional Loading

If you already use GTM, fire the Hotjar tag based on conditions:

• Sampling — fire on a random percentage of sessions (e.g., 20%) to get representative data with 80% less overhead
• Page path rules — only fire on pages you’re actively optimizing
• Custom events — fire Hotjar after specific user actions like clicking a CTA

In GTM, create a custom trigger using a Random Number variable. If the random number is less than 20, fire the tag. Simple and effective.

4. Disable Session Recordings on High-Traffic Pages

Session recordings are the heaviest Hotjar feature. They require continuous DOM observation and data streaming. In Hotjar’s dashboard, you can configure URL-based targeting to exclude high-traffic pages like your homepage or blog index from recordings while still collecting heatmap data.

Alternatives When Performance Is the Priority

If you need analytics but can’t afford the JavaScript overhead, consider these options:

• Plausible Analytics — <1KB script, no cookies, privacy-friendly. Gives you traffic analytics without behavior tracking. $9/mo hosted or self-hostable.
• Umami — open source, self-hosted, ~2KB script. Similar to Plausible. Free if you run your own server.
• PostHog — self-hosted option that includes session recordings, feature flags, and analytics. Heavier than Plausible but lighter than Hotjar since you control the infrastructure and can strip features you don’t need.
• Microsoft Clarity — free Hotjar alternative from Microsoft. Similar features (heatmaps, recordings) with a lighter script footprint (~20% smaller). Still a third-party script, but worth testing if you want behavior analytics with less overhead.

None of these are direct Hotjar replacements. Hotjar’s session recordings and heatmaps provide qualitative insights that pure analytics tools can’t match. The question is whether you need those insights on every page for every visitor.

The Verdict

Hotjar is fine for most WordPress sites. A 3-7 point Lighthouse drop and 50-80ms of extra TBT won’t meaningfully hurt your user experience or SEO rankings on a typical business site.

But if any of these apply to you, load it selectively:

• You’re optimizing for Core Web Vitals and every millisecond of TBT matters
• Your pages already have heavy JavaScript (page builders, WooCommerce, chat widgets) and you’re stacking third-party scripts
• You have high-traffic pages where the data volume from session recordings provides diminishing returns
• Mobile performance is critical and your audience skews toward lower-end devices

The best approach: install Hotjar on the pages where you’ll actually use the data, defer it until user interaction, and disable session recordings where you don’t need them. You’ll get 90% of the insights with 10% of the performance cost.

Don’t blanket-load analytics scripts and forget about them. Every third-party script should earn its place on the page by providing actionable data that justifies its performance cost.