:format(webp)){kind=small}
Almost every website runs code from other companies: the HTTP Archive's 2025 Web Almanac found third-party resources on at least nine in ten pages. On a typical B2B marketing website, analytics, a tag manager, several ad pixels, a chat widget, a heatmap tool, an A/B testing script, a cookie banner and a few embedded videos and forms can all come from different vendors.
Each one was added for a good reason. Together, they can add a lot of work to every page load. The goal of this guide is not to remove all of them. It is to know what each one costs, keep the ones that earn their place, and load them in a way that doesn't make every visitor pay for them.
Why third-party scripts are expensive
When a page loads a third-party script, the browser has to download it, read it and run it. Three things make this costly:
They compete with your own page. A browser has one main thread for running code and responding to visitors. While a chat widget initializes, a click on your menu waits. That delay is part of what Interaction to Next Paint (INP), one of Google's Core Web Vitals, measures.
They load more than you see. Many tags load further scripts of their own. One pixel can mean several extra requests to several domains.
You don't control them. A vendor can change what its script does or how big it is at any time, without anyone in your team deploying anything.
They can also make the layout jump, for example when a chat bubble, a banner or an embedded form appears late and pushes content around.
The usual suspects on a B2B site
Tool type | Examples | Why it costs | Better way to load it |
|---|---|---|---|
Tag manager and analytics | Google Tag Manager, GA4 | Loads the other tags, so its setup affects all of them | Keep it lean; consider server-side tagging |
Advertising pixels | LinkedIn Insight Tag, Meta Pixel, Google Ads | Usually one script per platform, often on every page | Fire through one tag manager after consent; use server-side or conversion APIs where available |
Chat widgets | HubSpot chat, Intercom, Zendesk | Can load a large script as soon as the page opens | Load on interaction, or only on pages where people actually chat |
Heatmaps and session recording | Hotjar, Microsoft Clarity | Record every click and scroll, which adds steady work while visitors use the page | Run on the pages under study, for a fixed period |
A/B testing tools | VWO, Optimizely and similar | Client-side tools may hide the page until the variant is ready, to avoid flicker | Limit to pages with a live test; consider server-side experiments |
Video embeds | YouTube, Vimeo, Wistia | Each player loads its own app inside an iframe | Show a thumbnail and load the player when clicked |
Embedded forms | HubSpot, Account Engagement (formerly Pardot) | Load the vendor's form script and styles | Load only where the form is, or use your own form sent to the CRM by API |
Cookie banner | CookieYes, Cookiebot, OneTrust | Must load early because it decides what else may load | Keep it, but reserve its space so it doesn't push content |
How to audit your third-party scripts
You don't need to guess. Two free methods will tell you which scripts matter:
PageSpeed Insights. Test one of your key landing pages and open the "3rd parties" insight. It lists the third parties on the page, with how much each one downloads and how long its code keeps the browser busy.
A before-and-after test. In Chrome DevTools, a developer can block a single domain (for example your chat widget's) and reload the page. Comparing the page with and without it shows that tool's real cost on your site.
Then build an inventory. For every script, write down who owns it, what it is for, which pages need it, and when someone last looked at its data. This list is useful on its own: it shows what each tool costs and who to ask before anything is removed.
If nobody has looked at a tool's data in months, it is a candidate for removal.
Loading strategies, from simplest to most involved
Work through these in order. The first two cost almost nothing; the last two are projects for your developers.
1. Remove what nobody uses
Old campaign pixels, a heatmap tool from last year's redesign, two analytics tools measuring the same thing. Removing them usually takes minutes in a tag manager.
2. Load tools only where they are needed
A chat widget may only be worth it on pricing and contact pages. A heatmap only on the pages you are currently studying. An A/B testing script only on pages with a live test, or replaced by server-side assignment, as described in A/B testing for React and headless websites. In a tag manager this is a trigger condition, not a development project. Embedded forms work the same way: load them only on pages with a form, or replace them with your own form, as described in HubSpot forms and lead routing on any website.
3. Load after consent and after the page is ready
In the EU and UK, marketing tags generally shouldn't load before the visitor agrees to them. Beyond that, many tags don't need to run until the page is usable. Delaying them lets your content appear and respond first.
4. Load on interaction
For chat widgets and video players, show a lightweight placeholder that looks like the real thing, and load the actual tool only when someone clicks it. This pattern is called a facade. Google describes it in its guidance on lazy loading third-party resources with facades. Where a vendor offers its own lightweight loading option, prefer it over unofficial workarounds.
5. Move work off the main thread
Tools such as Partytown run third-party scripts in a background thread (a web worker), so they don't compete with clicks and scrolling. Its documentation covers common analytics and tag manager setups, but not every script is compatible, so each tag needs testing.
6. Move tags to the server
With server-side tagging, the browser sends one stream of events to your own tagging server, which forwards them to analytics and ad platforms. Fewer scripts run in the browser, and you control what data leaves your site. It runs on a server you pay for and needs careful setup, so it makes most sense when you feed several analytics and ad platforms. Start steps 5 and 6 only once the simpler steps are done. If you don't have the developer time in-house, moving tags to the server is part of our growth engineering work.
How we load ours
On makersden.io, Google Tag Manager runs through Partytown and sends events to a server-side tagging container, so tag work happens away from the main thread and outside the browser. The cookie banner is the exception: it stays on the main thread on purpose, because it must appear immediately and decides what else is allowed to load. Booking widgets load only on pages that contain a booking section.
The principle behind it is simple: every script is a decision with a cost, not a free addition.