Third-Party Scripts and INP: GTM, Chat Widgets and Cookie Banners

Which third-party scripts hurt INP most?

Third party scripts INP problems rarely come from one large file alone. They come from work that competes for the main thread at exactly the moment a visitor tries to click, tap, type or scroll, and from extra scripts that those first scripts then pull in. If the browser is busy parsing, compiling, executing or hydrating third-party code, it cannot respond promptly, and that delay is what visitors feel as a slow interaction.

A useful rule is to judge a script by when it runs and what it blocks, not only by its size. A small script that runs on every page, hooks into every click or forces layout work can hurt more than a larger script that loads quietly after the interaction has finished.

How to measure the cost of each script. Start with a repeatable test, not a single lab run. In Chrome DevTools, record a Performance trace on a representative page, then interact with the page in the same way a visitor would: open the menu, scroll, start a form, open the chat panel if one is present, and use the consent banner. Repeat the trace with the suspect script removed or blocked, and compare what changed in the interaction, not only what changed in the headline score.

In the trace, look for long tasks, which are chunks of main-thread work that can delay a response to input. Expand a long task and look at its call stack and the script that owns it. The file name, domain and initiating script usually point to the responsible third party, even when the work is triggered by your own tag manager or by a script that another script loaded. If you cannot name the owner from the trace, do not guess: block or delay that one source at a time on staging and retest, so the change you credit is the change you actually made.

The worst offenders in practice. Tag managers are often first because they are not one script: they are a loader for many others, and each tag can add its own work, network requests and event listeners. A slow Google Tag Manager setup on WordPress is therefore usually a slow collection of tags, triggers and third-party pixels, not only the container itself.

• Chat widgets: they load early, stay resident, and can attach handlers and polling work long before anyone asks for help. A chat widget slow WordPress problem often shows up as a delayed first click, because the widget is still waking up when the visitor tries to use it.
• Cookie banners: a banner that blocks the page, shifts layout or runs heavy consent logic on every visit can hurt both the first interaction and later ones. Cookie banner INP problems are especially common when the banner script, its styling and its consent checks all compete with the interaction that dismisses it.
• Review, heatmap and session-recording scripts: these watch clicks, scrolls and mouse movement, so by design they do work during interactions. If they record too much, too early, or send data too often, they add work to the exact moments INP measures.
• Social embeds, video players and comment systems: these often load large players, iframes and their own scripts before the visitor needs them. They are also easy to defer or load on click, which is why they should rarely be allowed to run unconditionally on every page.

Before removing anything, keep a short inventory: what each script does, who owns it, where it loads, and what breaks if it is delayed. That inventory makes the later choices defensible, and it stops a performance fix from quietly breaking measurement, support or consent.

How to load GTM later

Loading Google Tag Manager later is not the same as removing it. The goal is to move its work out of the first interaction, while keeping the measurement you actually need. Start by auditing the container: remove tags that are no longer used, pause tags that fire on every page but are only needed on one page type, and check triggers that fire on clicks or scrolls, because those can add work at the moment INP measures.

Load on interaction. A common safe pattern is to load GTM only after a genuine interaction, such as a first scroll, click or key press, or after the page has become interactive and the browser has had a chance to settle. That keeps the first click from competing with tag loading, but it means early visits that bounce without interacting will not be counted in the same way. Decide that trade-off explicitly with the site owner, rather than treating it as a free win.

Delay until after the page is interactive. Another pattern is to hold GTM until the main content is usable, then load it in the background. This is gentler than interaction-only loading, but it still changes timing: tags that expect to run at page load may fire later, and some conversion or session data may look different. Test on staging with real journeys, including form submissions and checkout, and compare the resulting events before you deploy.

Server-side tagging is an option, with trade-offs. Moving tags to a server container can reduce browser work and give you more control over what data leaves the browser, but it adds infrastructure, maintenance and cost, and it does not automatically make every tag faster. It is worth considering when the browser container is large, when privacy controls matter, or when many tags duplicate the same data, but it is not a simple switch and it still needs the same staging tests.

Why a delayed payment or consent script must be tested. Never delay a payment script, a consent script or a script that gates checkout until you have tested the full journey. If the first click is the click that wakes the script, the visitor may need a second click, see a missing payment field, or be asked for consent after data has already been sent. Keep those scripts out of any aggressive delay, or test them so thoroughly on staging that the risk is explicit and accepted. For a related delay approach, see the guide to delaying JavaScript execution in WordPress, which explains the same staging-first, one-change-at-a-time discipline.

Safe alternatives

The safest alternative is often the simplest: do not load the script at all until it is needed. That is a design choice, not just a performance trick. If a widget is only useful on a contact page, load it there. If a video is only useful when played, show a lightweight preview and load the player on click. If a review widget is only useful near the bottom of a product page, do not let it compete with the first interaction at the top.

Native and lightweight replacements. Before adding a third-party widget, ask what the site already does natively. WordPress, the theme and a form plugin can often handle a simple contact form, a basic consent notice or a static testimonial without a resident script. A lightweight, self-hosted replacement that does one job well will usually cost less main-thread time than a general widget that loads a full framework to do the same job.

Loading on click. For chat, video and social embeds, a click-to-load pattern is usually the best compromise: the visitor sees a clear button or preview, and the heavy script loads only after that click. The first interaction is then cheap, and the later interaction is expected to take a moment because the visitor asked for it. Keep the preview itself light, and do not let the preview script do the heavy work in advance.

Partytown as an option, with limits. Partytown WordPress setups move some third-party scripts off the main thread into a web worker, which can help when a script is mainly doing background work. It is not a guaranteed fix, and it does not work for every script: scripts that need direct access to the page, that expect to run in a specific order, or that interact closely with checkout, consent or payment flows may not behave correctly in a worker. Treat Partytown as a tested experiment for suitable scripts, not as a blanket solution for third party JavaScript WordPress sites.

What to do first. A practical order is: remove what is unused, move what can wait to interaction or click, replace what can be native, and only then consider a worker or server-side approach for what remains. On builder and shop pages, check the same inventory against the specific guidance for fixing INP in Elementor and for fixing slow add-to-cart interactions in WooCommerce, because those pages add their own interaction work on top of the third-party cost.

• Chat widgets: replace an always-on widget with a contact button that loads chat on click, unless live support is the main purpose of the page.
• Cookie banners: use a light consent banner that does not block the page or run heavy logic on every visit, and test the dismiss interaction specifically for cookie banner INP problems.
• Analytics and pixels: keep only the tags that are actually read and acted on, and review tag manager performance regularly, because a container that grows quietly will cost more than the day it was first installed.

Common Questions

Frequently Asked Questions

Clear, honest answers about third-party scripts, GTM, chat widgets, and cookie banners.