--- title: "Third-Party Script Performance and Tag Managers | Evaluat" description: "How third-party scripts and tag managers slow a page, what happens when a vendor is down, and how to measure and cut what each script costs your shoppers." url: "https://www.evaluat.com/blog/third-party-scripts-performance" last_modified: "2026-10-29" --- [Blog](https://www.evaluat.com/blog) [Guides](https://www.evaluat.com/blog/category/guides) # Third-party scripts and tag managers: the slowdown you did not write Nine in ten web pages run code from another company's servers, such as analytics, ads, chat and consent banners. Each one downloads, runs on the main thread beside your own code, and can hold the page up when its server is slow. A tag manager makes them easy to add. Measuring what each one costs tells you which to keep. Written by: [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · 29 October 2026 [Beginner's guide](https://www.evaluat.com/blog/beginners-guide) Part 18How a web page loads ![The browser's main thread drawn as one bar shared by several owners. The site's own code takes the first part. Tag manager tags, a chat widget, a video embed and ads, all code from other companies, take the rest. A shopper's tap has to wait until the thread is free. You wrote some of the page; your shoppers wait for all of it.](https://www.evaluat.com/blog/third-party-scripts-performance-cover.svg) Summary A third-party script is code your page loads from another company's server, such as analytics, advertising, chat, reviews, A/B testing or a consent banner. Nine in ten web pages load at least one. They slow a page in four ways. They add downloads from extra servers, each needing its own connection. They run on the browser's main thread, the same thread that responds when a shopper taps a button. Some stop the page being drawn until they arrive. And some move content around after it appears. A tag manager such as Google Tag Manager is small on its own. The cost is in the tags you put inside it, and in how early they fire. When a vendor's server is slow or down, a script loaded the old-fashioned way can leave shoppers looking at a blank page, while one loaded asynchronously lets the page draw but still holds up anything waiting for the page to finish loading. To find what each script costs, block it in the browser's developer tools, reload, and compare. Then remove what nobody uses, load the rest later, and give every tag an owner. A real-browser load test runs every tag your shoppers get, so its results include their cost. Listen to this article · 1:24 [Download the audio summary (MP3)](https://www.evaluat.com/blog/audio/third-party-scripts-performance.mp3) Key takeaways - A third-party script is code loaded from another company's server; at least 90% of pages load one or more third parties. - They cost extra connections, main-thread time, sometimes a blocked page, and sometimes layout shifts. - Google Tag Manager is small on its own; the cost is the tags inside it and how early they fire. - A slow vendor blanks a page only when its script blocks rendering; async scripts still delay the load event. - Measure each script by blocking it, reloading and comparing, then remove, delay or replace the expensive ones. ## What is a third-party script? A third-party script is JavaScript that your page loads from another company’s server: analytics, advertising, chat, product reviews, A/B testing, personalisation, consent banners and payment widgets. You choose to add it, but another company writes it, hosts it and can change it. It runs inside your page with the same access as your own code. The HTTP Archive’s 2025 Web Almanac defines it simply: [a third party is an entity different from the site owner](https://almanac.httparchive.org/en/2025/third-parties). The same chapter found that [the percentage of pages with one or more third parties remains greater or equal to 90%](https://almanac.httparchive.org/en/2025/third-parties), and that the median number of third-party requests per page is [83 on desktop and 79 on mobile](https://almanac.httparchive.org/en/2025/third-parties). Scripts are the largest share of those requests, at [24.8%](https://almanac.httparchive.org/en/2025/third-parties). By size, other companies often ship more JavaScript than the site itself. The 2024 Almanac’s JavaScript chapter found that the median mobile page downloads 168 KB of JavaScript from its own host [and 375 KB from third-party hosts](https://almanac.httparchive.org/en/2024/javascript). Think of a restaurant that lets several suppliers send their own staff into the kitchen during service. Each brings useful things. Each also needs space at the same hob, and if one is late, whatever they were making waits. [Part 8 of this guide](https://www.evaluat.com/blog/how-a-web-page-loads) walked through the seven waits in a page load; third-party scripts add to almost all of them. ## How do third-party scripts slow a page down? In four ways. They add downloads from extra servers, each needing its own connection. They run on the browser’s main thread, competing with your own code and with the shopper’s taps. Some stop the page being drawn until they arrive. And some insert or move content after the page appears, which shifts the layout. ### More servers to connect to Every new server means a new DNS lookup, connection and secure handshake before the first byte of the script arrives. Scripts also load other scripts: the Almanac found that [the median depth of the inclusion chain is 3](https://almanac.httparchive.org/en/2025/third-parties), so one tag you added can pull in a second company’s code, which pulls in a third. ### Time on the main thread A browser does most of its work on one main thread: running JavaScript, laying out the page and responding to taps and clicks. While a script runs, a shopper’s tap waits. Lighthouse, Google’s page audit tool, used to [flag pages that have third-party code that blocks the main thread for 250 ms or longer](https://developer.chrome.com/docs/lighthouse/performance/third-party-summary), in the audit its newer versions have replaced. The cost varies enormously by script. The open third-party-web project, which analyses Lighthouse runs from the HTTP Archive’s mobile crawl, gives an average main-thread execution time per page for each provider. In its March 2026 data, scripts served from Google Tag Manager’s domain averaged [1,066 ms across 15 million pages](https://github.com/patrickhulce/third-party-web), YouTube’s 6,297 ms and Google Analytics 108 ms. These are averages from lab runs on an emulated phone, pulled up by heavy pages, so treat them as a ranking, not a prediction for your site. This is the cost that shows up in [Interaction to Next Paint (INP)](https://www.evaluat.com/blog/interaction-to-next-paint), the Core Web Vital that measures how quickly a page responds to input. Google’s guidance on tags notes [a correlation between the size of tag managers and poorer INP scores](https://web.dev/articles/tag-best-practices). ### Blocking the page A plain script tag in the page head, without `async` or `defer`, is [fetched and executed immediately before the browser continues to parse the page](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script), in MDN’s words. Nothing below it is built until it has arrived and run. Paul Calvano, writing for the Web Performance Calendar, found in December 2025 that [67.7% (of 15.78 million websites) request at least one render-blocking third party](https://calendar.perfplanet.com/2025/third-parties-and-single-points-of-failure/), a figure that includes stylesheets such as web fonts as well as scripts. Some A/B testing tools block the page on purpose, to stop visitors seeing the original version flicker into the variant. Adobe Target’s anti-flicker snippet, for example, [pre-hides the whole HTML BODY](https://experienceleague.adobe.com/en/docs/target-dev/developer/client-side/at-js-implementation/at-js/manage-flicker-with-atjs) by default, with a three-second timeout. ### Moving things after the page appears Banners, chat buttons, review widgets and ads that are inserted after the first paint push content down unless space was reserved for them. That shows up as [Cumulative Layout Shift](https://www.evaluat.com/blog/how-to-improve-cls), and as shoppers tapping the wrong thing. ## Which third-party scripts cost the most? Video embeds, advertising and chat widgets usually cost the most, because they load large amounts of code and often their own iframes. Analytics tags are usually lighter. But how a script is loaded and when it runs matter as much as which vendor wrote it, so the categories below are a starting point for measuring, not a verdict. | Type | Examples of what it does | Where the cost usually lands | First fix to try | | ------------------------------- | --------------------------- | --------------------------------------------- | ---------------------------------------------------- | | Video embeds | Product and brand videos | Large downloads and main-thread time | A placeholder image that loads the player on click | | Advertising and retargeting | Ad slots, pixels | Main-thread time, more servers, layout shifts | Load after the page; reserve space for ad slots | | Chat and support widgets | Live chat, help buttons | Main-thread time on every page | Load on interaction or after a delay | | A/B testing and personalisation | Variant switching | Blocked or hidden page | Server-side testing, or a short anti-flicker timeout | | Analytics and tag managers | Measurement, event tracking | Main-thread time as tags fire | Fewer tags, fired after load | | Consent banners | Cookie choices | Early main-thread time and layout shifts | Load early but reserve its space | | Reviews and social proof | Star ratings, review lists | Layout shifts below the fold | Reserve space, or render reviews on the server | ## Does Google Tag Manager slow down your site? Not much on its own. Google Tag Manager loads asynchronously and its library is small; the cost comes from the tags inside it and from how early they fire. A container full of custom HTML tags firing on page load can cost a lot. The same container with a few tags firing after the page has loaded costs little. Google’s own guidance puts the library at around 33 KB compressed and the median site’s container at around 50 KB, and describes the relationship well: [the tag manager provides a vessel, but what you fill it with and how you use it is mostly up to you](https://web.dev/articles/tag-best-practices). Julius Fedorovicius of Analytics Mania tested it directly, and in an article updated in September 2026 reported that [an empty GTM container had a minimal impact on page speed](https://analyticsmania.com/post/google-tag-manager-impact-on-page-speed-and-how-to-improve). His summary is blunt: [it’s not GTM itself. It’s what you put inside of it.](https://analyticsmania.com/post/google-tag-manager-impact-on-page-speed-and-how-to-improve) It matters because tag managers are everywhere. W3Techs reports that [Google Tag Manager is used by 44.8% of all the websites](https://w3techs.com/technologies/overview/tag_manager) it monitors. Two details trip people up. First, [most tools attribute the performance impact of a Custom HTML tag to the tag manager that injected it](https://web.dev/articles/tag-best-practices), so a report that blames Google Tag Manager may really be blaming one of your tags. Second, timing: Google’s guidance is to [fire non-essential tags after Window Loaded](https://web.dev/articles/tag-best-practices), because the earlier a tag fires, the more it competes with the page. The real reason tag managers let costs pile up is that adding a tag no longer needs a release. Shopify’s developer guide describes the pattern exactly: [marketing adds a tracking pixel, a developer adds analytics, a merchant installs an app](https://shopify.dev/docs/storefronts/themes/best-practices/performance/audit-remove-third-party-scripts), and later [the feature becomes unneeded, but the code still executes](https://shopify.dev/docs/storefronts/themes/best-practices/performance/audit-remove-third-party-scripts). ## What happens when a third-party server is slow or down? It depends on how the script is loaded. A script that blocks rendering can leave shoppers looking at a blank or half-built page until the request times out. An asynchronous script lets the page draw, but the browser still waits for it before declaring the page loaded. Either way, someone else’s bad day becomes yours. - **Blocking scripts.** Calvano puts it plainly: [the user would essentially see a blank screen until the third party request times out](https://calendar.perfplanet.com/2025/third-parties-and-single-points-of-failure/). - **Asynchronous scripts.** The page draws, but MDN notes that the load event fires only when the whole page has loaded, [including all dependent resources such as stylesheets, scripts (including async, deferred, and module scripts)](https://developer.mozilla.org/en-US/docs/Web/API/Window/load_event). Anything set to wait for load, including tags set to fire on Window Loaded, waits with it. - **Pre-hiding snippets.** The page stays hidden until the script arrives or the snippet’s own timeout runs out. There is also a quieter failure: the script changes. In February 2024 the polyfill.io domain, used by many sites to patch older browsers, was bought by a new owner, and by June its script was serving malicious code. Even after the attack was exposed, Censys [still detects 384,773 hosts embedding a polyfill JS script linking to the malicious domain](https://censys.com/july-2-polyfill-io-supply-chain-attack-digging-into-the-web-of-compromised-domains) on 2 July 2024. A third-party script runs with your page’s permissions, so its owner matters as much as its speed. ## How do you measure what a third-party script costs? Compare the page with and without it. List the third parties a page loads, see how much main-thread time each one takes, then block them one at a time, reload, and compare the results over several runs. The difference is what that script costs your shoppers on that page. 1. **List them.** Run Lighthouse or PageSpeed Insights and read the third-parties insight, which replaced the older third-party summary in [Lighthouse 13](https://developer.chrome.com/blog/lighthouse-13-0) and groups the page’s requests by provider. 2. **See where the time goes.** In the Chrome DevTools Performance panel, the 3rd parties insight [categorizes resources and CPU activity by first and third-party entities](https://developer.chrome.com/blog/devtools-insights-sidebar). 3. **Block and compare.** In the Network panel, [right-click a request and select Block request](https://developer.chrome.com/docs/devtools/request-conditions), then reload. Shopify’s version of the same advice is to [block a domain, reload, and compare transfer sizes and scripting time](https://shopify.dev/docs/storefronts/themes/best-practices/performance/audit-remove-third-party-scripts). Run each case several times, because single loads vary. 4. **Rehearse a slow vendor.** The same DevTools drawer can throttle one request with a custom network profile, so you can see what your page does when one vendor takes ten seconds. 5. **Check checkout, not just the homepage.** Payment, fraud and address-lookup scripts often load only there. ## How do you reduce the impact of third-party scripts? Remove what nobody uses, delay what is not needed for the first view, and replace heavy embeds with something lighter until a shopper asks for them. Then give every tag an owner and an end date, so the list does not grow back. Each fix trades something away, so make the trade knowingly. - **Remove.** Shopify calls auditing and removing third-party scripts [the highest-impact optimization for improving responsiveness and overall performance](https://shopify.dev/docs/storefronts/themes/best-practices/performance/audit-remove-third-party-scripts). Old campaign pixels and trial tools are the usual finds. - **Load later.** Use `async` or `defer` on script tags, and fire tag-manager tags after the page has loaded. The trade is a little lost data from visitors who leave in the first seconds. - **Use placeholders for heavy embeds.** Show a still image of the video or the chat button, and load the real thing on click. - **Connect early to the vendors you keep.** A `preconnect` hint lets the browser open the connection to a critical third party before it is needed. - **Move work off the page.** Server-side tagging and web-worker tools such as Partytown can take some scripts off the main thread, though Partytown’s own documentation notes [it may not be the best fit for every single script out there](https://partytown.qwik.dev/trade-offs/). - **Freeze tags before peak.** A tag added the week before a sale has never been tested at peak. [Part 11 of this guide](https://www.evaluat.com/blog/black-friday-code-freeze) explains why a code freeze should cover tags. ## Common mistakes with third-party scripts Most come from treating tags as marketing’s business and speed as engineering’s, when both teams own the result. - **Blaming the tag manager.** The container is rarely the problem; the tags in it are. - **Testing a lighter page than shoppers get.** A lab test with an ad blocker, or one that never accepts the consent banner, skips every tag behind it. - **Treating async as free.** It removes the blank-page risk, not the main-thread cost. - **Keeping tags forever.** Every tag needs an owner and a date to review it. - **Only measuring the homepage.** The scripts on product, basket and checkout pages are often different. ## How Evaluat shows what your tags cost Every virtual user is a real browser, so each one loads and runs every tag, pixel and embed your shoppers get, and a scenario can accept the consent banner so the tags behind it fire. Core Web Vitals for every session include their cost. What users see, not what scripts pretend. The network log for each session lists every request with its timing and size, first-party and third-party alike, and the report’s network view groups requests by URL with a percentile of their duration across all sessions, filterable to scripts. That separates a slow page caused by your servers under load from one held up by a vendor. Console logs show the errors a third-party script throws, and the session video shows the banner that pushed the page down. The boundaries are worth stating. Evaluat’s browsers run as desktop browsers on cloud machines, without slowing the processor to match a phone, so a script’s main-thread cost on a mid-range phone will be higher than the test shows; use field data from real visitors for that. And test sessions reach your analytics and ad platforms like any other visit, so decide beforehand how you will filter them out. Third-party scripts are part of the page your shoppers get, whether you wrote them or not. Count them, measure what each one costs, and keep the ones that pay their way. Test in real browsers. Debug in real sessions. [Book a demo](https://www.evaluat.com/demo?intent=performance) to see what your tags cost at peak. [Previous · Part 17What is a virtual waiting room?](https://www.evaluat.com/blog/product-drop-queues-waiting-rooms) [Next partNew parts every Wednesday and Thursday. See the guide index.](https://www.evaluat.com/blog/beginners-guide) ![Ahmad Farzan, Founder at Evaluat](https://www.evaluat.com/authors/ahmad-farzan.jpg) About the author [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · Founder at Evaluat Founder of Evaluat. Has spent years building and load-testing Adobe Commerce and Magento storefronts, and built Evaluat to test sites the way real browsers actually hit them. [Ahmad Farzan on LinkedIn](https://www.linkedin.com/in/ahmadfarzan/) [Ahmad Farzan on GitHub](https://github.com/farzanahmad) [More from Ahmad](https://www.evaluat.com/authors/ahmad-farzan) Common questions ## FAQ ### What are third-party scripts? Third-party scripts are JavaScript files a web page loads from another company's servers, such as analytics, advertising, chat, reviews, A/B testing and consent banners. The site owner adds them but does not write or host them. At least 90% of web pages load one or more third parties. ### Do third-party scripts slow down a website? Yes, by adding downloads from extra servers, using time on the browser's main thread, sometimes blocking the page from being drawn, and sometimes shifting content after it appears. How much depends on the script and how it is loaded. A small analytics tag costs little; a video embed or ad stack can cost seconds of processing. ### Does Google Tag Manager slow down your site? The Google Tag Manager library itself is small and loads asynchronously, so an empty container has little effect. The cost comes from the tags inside it, especially custom HTML tags and tags that fire early in the page load. Fire non-essential tags after the page has loaded. ### What happens if a third-party script fails to load? It depends on how the script is loaded. A script in the page head without async or defer can leave visitors looking at a blank or half-built page until the request times out. An async script lets the page draw, but the browser's load event still waits for it, so anything set to run after load waits too. ### What is the difference between async and defer? Both download the script without stopping the page being built. An async script runs as soon as it arrives, in no fixed order. A deferred script runs after the HTML has been parsed, in the order the scripts appear on the page. ### How do I find which third-party script is slowing my site? Run Lighthouse or PageSpeed Insights and read its third-parties insight, or use the 3rd parties view in the Chrome DevTools Performance panel. Then block one script at a time in the DevTools Network panel, reload, and compare load times and main-thread time over several runs. ### Should you remove third-party scripts? Remove the ones nobody uses, and keep the ones that earn their cost. Many sites carry tags for campaigns and tools that ended long ago. For the rest, load them later, replace heavy embeds with a placeholder until a visitor clicks, and give every tag an owner who decides when it goes. Related reading ## More from the blog [![A page load drawn as a waterfall of seven waits in order: DNS lookup, TCP connection, TLS handshake, the server thinking until the first byte, the HTML download, fetching CSS, scripts and images, then layout and paint. The first byte arrives after the fourth wait and the largest paint after the seventh. The server wait is highlighted because it is the one that grows when the site is busy.](https://www.evaluat.com/blog/how-a-web-page-loads-cover.svg)](https://www.evaluat.com/blog/how-a-web-page-loads) ### [What happens when a web page loads: DNS, TLS, TTFB and render](https://www.evaluat.com/blog/how-a-web-page-loads) [Between the tap and the paint there are seven waits, and most speed problems live in exactly one of them. The browser looks up the address, opens a connection, secures it, waits for the server, downloads the page, fetches everything the page asks for, and paints. Learn the order and you can find the slow one.](https://www.evaluat.com/blog/how-a-web-page-loads) [Ahmad Farzan · 24 September 2026](https://www.evaluat.com/blog/how-a-web-page-loads) [![Two Interaction to Next Paint timelines compared. Before optimization a long task creates a large input delay and INP is 520 milliseconds, rated poor. After breaking up the task and yielding to the main thread the input delay nearly disappears and INP drops to 180 milliseconds, under the 200 millisecond good threshold.](https://www.evaluat.com/blog/how-to-improve-inp-cover.svg)](https://www.evaluat.com/blog/how-to-improve-inp) ### [How to improve INP: a step-by-step optimization guide](https://www.evaluat.com/blog/how-to-improve-inp) [Most teams trying to improve INP optimize the click handler, and most of the time the handler is not the problem. A long task was already running on the main thread when the user clicked, so the interaction had to wait. This guide is the practical playbook: the fixes in priority order, the code for each, the modern API most sites have not adopted yet, and how to confirm the number actually moved for real users under load.](https://www.evaluat.com/blog/how-to-improve-inp) [Ahmad Farzan · 18 June 2026](https://www.evaluat.com/blog/how-to-improve-inp) [![Interaction to Next Paint: a visit's interactions drawn as stacked bars of input delay, processing, and presentation time. Most stay under Google's 200ms good threshold while one slow interaction passes 500ms and sets the page's INP.](https://www.evaluat.com/blog/interaction-to-next-paint-cover.svg)](https://www.evaluat.com/blog/interaction-to-next-paint) ### [Interaction to Next Paint (INP), explained for engineers](https://www.evaluat.com/blog/interaction-to-next-paint) [A page can pass every functional test and still feel slow on the second tap. Interaction to Next Paint is the Core Web Vital that catches it: the latency of your slowest interaction across a visit, timed from the click to the next frame painted. Here is what INP captures, what drags it past 200ms, and how to test it under load.](https://www.evaluat.com/blog/interaction-to-next-paint) [Ahmad Farzan · 30 May 2026](https://www.evaluat.com/blog/interaction-to-next-paint) See it on your site Test in real browsers.\ Debug in real sessions. ## Want to see this measured on your app? 30 minutes. We build a scenario on your real customer journey, run a small test, and walk you through the report. [Book a demo](https://www.evaluat.com/demo?intent=performance) [How it works](https://www.evaluat.com/how-it-works)