HBMHBM Rocket
ALL POSTS
PERFORMANCE · BLOG

The single biggest INP win on a typical WordPress site

2026-04-228 MIN READ

If your mobile PSI is stuck in the seventies and your INP is sitting north of three hundred milliseconds, the fix probably is not a new server, a new theme, or a different cache plugin. It is one rule of thumb: do not run third party JavaScript until the user actually interacts with the page.

What we mean by third party JS

Anything not written by your engineering team and shipped from a domain you do not control. The usual suspects:

  • Google Tag Manager and gtag
  • Facebook Pixel and Conversions API
  • Microsoft Clarity, Hotjar, FullStory
  • Live chat (Intercom, Drift, Tawk, Crisp)
  • Cookie banners and consent management
  • Email capture pop ups (Sumo, OptinMonster, Klaviyo)

On a typical home builder site we have measured 6 to 12 distinct third party scripts loading on first paint. Together they parse 400 to 900 KB of JavaScript before the user has scrolled or clicked anything.

Why INP gets crushed

INP measures the worst case latency between an interaction and the next paint. On mobile (4 times CPU throttle, slow 4G), a single 100 ms task that runs while the user is trying to tap a button blocks the response. Pile up GTM, Pixel, and a chat widget bootstrap and you get a 400 to 700 ms delay on every early interaction.

Why deferring is not enough

Deferred scripts still run before DOMContentLoaded. They block the main thread during initial layout, which is exactly when the user is trying to scroll or tap. Defer is good for first party JavaScript that the page actually needs. It is wrong for third party JavaScript that the page can wait for.

The interaction trick

Wrap every third party script in a placeholder that swaps to a real <script> tag on the first user gesture. Mouse move, scroll, click, keypress, touch start, any of them. The script that took 280 ms to bootstrap now runs at 800 ms or 4 seconds (whenever the user moves) and the document settles long before that.

<script type="hbm/rocket-delay" src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXX"></script>

<script id="hbm-rocket-delay-runtime">
(function () {
  var fired = false;
  function run() {
    if (fired) return; fired = true;
    document.querySelectorAll('script[type="hbm/rocket-delay"]').forEach(function (s) {
      var n = document.createElement('script');
      for (var i = 0; i < s.attributes.length; i++) {
        var a = s.attributes[i];
        if (a.name !== 'type') n.setAttribute(a.name, a.value);
      }
      n.type = 'text/javascript';
      if (s.src) n.src = s.src; else n.text = s.textContent;
      s.parentNode.replaceChild(n, s);
    });
  }
  ['mousemove','scroll','keydown','touchstart','click'].forEach(function (e) {
    window.addEventListener(e, run, { once: true, passive: true });
  });
  setTimeout(run, 8000);
})();
</script>

The real numbers

Measured on summitconstructionutah.com (Elementor + Premium Addons + Microsoft Clarity + GTM):

  • Mobile PSI: 42 → 87 (+45)
  • INP (75th percentile): 410 → 142 ms
  • TBT: 1.84 s → 0.31 s
  • LCP: 4.8 s → 2.1 s (related effect: less main thread contention during image decode)

Same site, same theme, same content. Only third party JavaScript moved.

What about analytics?

This is the question we get every time. The answer is that the user has to interact for there to be anything to measure. A pageview that ends with no scroll, no click, and no keypress is a bounce. Bounces should not count as engagement, and modern analytics treats them as such anyway.

If your stakeholder insists on counting every page load, fire a beacon directly from the document HTML on load. Skip the GTM bootstrap and just record the event. We can show you how.

What it does not solve

  • First party JavaScript that the page actually depends on (carousel libraries, form validators) still needs proper code splitting
  • Server response time (TTFB) still matters; this trick does nothing for it
  • Cookie banners that block rendering need a different fix (render an inert banner immediately, swap to interactive on idle)

How HBM Rocket does it automatically

The agent ships a default delay list covering 95 percent of the third party JavaScript that hurts INP on WordPress sites. The control plane scans new heartbeats for unfamiliar third party domains and proposes additions to the delay list. You approve in one click.

The exact runtime above is the one we ship. If you want to roll your own, copy it. The trick is older than HBM Rocket. The platform automation, the per site monitoring, and the self heal on regression are what we add.

The single biggest INP win on a typical WordPress site | HBM Rocket