Most website bloat does not come from one bad decision.
It comes from 40 small decisions nobody owns anymore.
A chat widget gets added during a sales push. A retargeting pixel gets installed for a campaign that ended nine months ago. A heatmap tool stays live after the trial expires. A tag manager container collects old experiments, duplicate analytics events, affiliate scripts, consent tools, social embeds, form plugins, and mystery vendors with names nobody recognizes.
Each one looked harmless on the day it was added. Together, they can slow the site, leak data, break consent rules, create accessibility problems, and make the business dependent on outside code running inside the customer’s browser.
This guide pulls together current third-party script statistics from HTTP Archive’s 2025 Web Almanac, HTTP Archive’s 2025 security chapter, HTTP Archive’s 2025 page weight chapter, WebAIM’s 2026 Million report, Baymard Institute, Portent, and Sonatype’s Polyfill.io analysis. Use it as a cleanup plan for your next website audit.
Third-Party Script Statistics at a Glance
| Area | Current benchmark | Why it matters |
|---|---|---|
| Pages using third parties | At least 90% of pages use one or more third parties, according to HTTP Archive | Third-party code is normal now, which means it needs management, not guesswork. |
| Third-party requests | Across all sites, the median page has 83 third-party requests on desktop and 79 on mobile, according to HTTP Archive | Request count can hurt performance even when each individual file looks small. |
| Top site pressure | The top 1,000 sites have a median of 129 third-party requests on desktop and 106 on mobile, according to HTTP Archive | Larger sites tend to collect more vendor code, not less. |
| Request growth | Third-party requests increased year over year by five requests across all sites and 15 requests among the top 1,000, according to HTTP Archive | Tag cleanup is not a one-time project. It needs a recurring owner. |
| Inclusion chains | The median third-party inclusion chain depth is 3, and the maximum observed depth is 2,285, according to HTTP Archive | One script can call another script, then another, until your team has no clear map. |
| Page weight | The median mobile home page grew from 845 KB in July 2015 to 2,362 KB in July 2025, according to HTTP Archive | The modern web has gotten heavier, and scripts are part of that weight. |
| CSP adoption | Content Security Policy adoption rose from 18.5% to 21.9%, according to HTTP Archive | Most sites still do not use one of the main browser controls for script sources. |
| SRI adoption | Median pages protect only 2.82% of scripts with Subresource Integrity, according to HTTP Archive | Many external scripts can change without the browser checking a known hash. |
| Accessibility failures | 95.9% of the top one million home pages had detectable WCAG failures in WebAIM’s 2026 report | Widgets and overlays do not automatically make a site usable. |
| Cart abandonment | Average ecommerce cart abandonment is 70.22%, according to Baymard Institute | Checkout is already fragile. Extra scripts can add more ways to lose the sale. |
What Counts as a Third-Party Script?
A third party is code, content, or a request served from a domain the visitor did not originally choose to visit. HTTP Archive defines third-party content as content loaded from a different site than the one visited by the user, and its analysis only counts third parties that appear on at least five unique pages in the dataset.
For a business website, the usual suspects are familiar:
- Analytics, ad pixels, tag managers, chat widgets, review widgets, heatmaps, A/B testing tools, embedded video players, payment tools, social embeds, cookie banners, fonts, CDNs, affiliate tools, call tracking, form tools, and customer support platforms.
The problem is not that these tools exist. Many are useful. HTTP Archive lists common third-party categories including ads, analytics, CDNs, customer success, marketing, social, tag managers, utilities, video, and consent providers, which matches what most small business sites accumulate over time.
The problem is ownership. If nobody can answer what a script does, who approved it, what data it collects, what pages it belongs on, and when it should be removed, the tool has become website debt.
The Web Runs on Third Parties Now
Third-party code is not rare. It is the default.
HTTP Archive found that the percentage of pages with one or more third parties remains greater than or equal to 90%. That means the average business owner should not ask, “Do we have third-party scripts?” The safer question is, “Which ones do we have, and are they still worth it?”
Request volume is where the mess starts to show. HTTP Archive reported a median of 83 third-party requests on desktop and 79 on mobile across all sites. Among the top 1,000 sites, the median rises to 129 third-party requests on desktop and 106 on mobile.
HTTP Archive measures third-party requests, not just visible marketing tags. Fonts, images, analytics calls, iframes, and scripts can all count. Still, the pattern is clear: outside dependencies are everywhere.
The year-over-year trend matters too. HTTP Archive found that third-party requests increased across all ranks, with the broader dataset adding five requests on desktop and five on mobile compared with 2024. For the top 1,000 sites, the increase was 15 requests on desktop and 15 on mobile.
That is how a tag manager turns into a junk drawer. It does not explode in one afternoon. It fills up slowly.
Scripts Create Performance Cost Even When They Are Small
A 20 KB script does not sound scary. The browser does not care how harmless it sounds.
HTTP Archive’s page weight chapter explains that JavaScript is expensive because the browser has to parse, compile, and execute it. It also explains that many small files can feel slower than one larger file because each request adds network work and round trips.
That matters because the page itself keeps getting heavier. The median mobile home page grew from 845 KB in July 2015 to 2,362 KB in July 2025, a 202.8% increase. HTTP Archive also reported that median home page size grew 7.8% year over year to 2.7 MB.
Third-party code is not the only reason pages are heavier. Images, video, fonts, CSS, and application code all contribute. But third-party scripts are uniquely slippery because they often sit outside normal development review. The marketing team can add a pixel. A vendor can update code. A tag manager can fire scripts on every page even when only one landing page needs them.
For lead generation sites, speed is not a vanity metric. Portent found that ecommerce sites loading in 1 second converted 2.5x higher than sites loading in 5 seconds, and B2B sites loading in 1 second converted 3x higher than sites loading in 5 seconds. If a chat widget, A/B test, review badge, and three ad pixels slow the first interaction, the business may read the symptom as “bad traffic” when the real problem is a heavy page.
Tag Managers Help, but They Also Hide the Mess
A tag manager is useful when it has rules, naming, version history, and someone responsible for cleanup.
It is dangerous when it becomes the place every department drops code because opening the website repo takes too long.
HTTP Archive lists tag managers as a third-party category and notes that tag manager scripts tend to load many other scripts and initiate many tasks. That is exactly why they need governance. The container may look like one script in the HTML, but it can fan out into analytics, ads, conversion pixels, form listeners, scroll tracking, remarketing, consent signals, and testing tools.
The hidden-chain problem is real. HTTP Archive found that the median depth of third-party inclusion chains is 3. It also observed a maximum inclusion-chain depth of 2,285. You do not need to be anywhere near that worst case for governance to break down. If your tag manager loads a vendor, and that vendor loads another vendor, your team may not see the full picture from the CMS or page builder.
A plain rule works better than a fancy policy: every tag needs an owner, a purpose, a page scope, a data scope, and an expiration date.
Privacy and Consent Are Now Part of Script Management
Third-party scripts are not just a speed issue. They are also a data-flow issue.
HTTP Archive’s 2025 third-party chapter added analysis of how user consent choices are propagated among third parties. It found that the TCF standard is the dominant consent standard and reaches 36% among low-ranked sites compared with 18% across all sites. It also found that the USP standard ranges from 9% to 17% across ranks, while GPP adoption remains minimal at 3% to 6%.
Consent plumbing is not proof of good privacy practice. It is proof that modern websites are complicated enough to need plumbing. HTTP Archive notes that ad tech vendors receive many of the top consent signals, which makes sense because advertising and analytics vendors often require consent before processing user data.
For small businesses, the practical question is simple: can you show which scripts fire before consent, after consent, and only on specific user action?
If the answer is no, the site needs a script audit before another pixel gets added.
Security Risk Comes From Trusting Code You Do Not Control
A third-party script runs in your visitor’s browser on your page. That gives it serious power.
HTTP Archive’s security chapter says content inclusion introduces risk because sites place significant trust in third-party resources, and a compromised resource can lead to supply chain attacks. The business owner version is even simpler: if someone else’s script changes, your site can change with it.
The Polyfill.io incident made that risk hard to ignore. Sonatype reported in 2024 that more than 100,000 websites using Polyfill.io were compromised in a supply chain attack. That was not a tiny edge case on one forgotten site. It was a reminder that popular shared scripts can become a shared blast radius.
Browser defenses exist, but adoption is uneven. HTTP Archive reported that Content Security Policy adoption increased from 18.5% in 2024 to 21.9% in 2025. That is progress, but it still means most pages do not use CSP. The same chapter says CSP can help control which sources are allowed to load and can reduce the impact of cross-site scripting attacks.
Subresource Integrity is also underused. HTTP Archive’s 2025 security results show median pages protect only 2.82% of scripts with SRI. SRI lets the browser verify that a fetched script matches the expected cryptographic hash. It is not a cure for every third-party risk, especially when vendors update scripts often, but low adoption shows how many sites rely on trust without verification.
Accessibility Widgets Are Not a Shortcut
Third-party code can also affect accessibility.
WebAIM’s 2026 Million report found 56,114,377 distinct accessibility errors across one million home pages, an average of 56.1 errors per page. It also found that 95.9% of home pages had detectable WCAG failures.
A widget does not fix that by magic. In fact, complexity often travels with errors. WebAIM reported that home page complexity increased to 1,437 elements per page in February 2026, a 22.5% increase in one year. It also found that 82.7% of home pages used ARIA and pages with ARIA had more detected errors on average than pages without ARIA.
That does not mean ARIA is bad. It means bolt-on interface code needs care. Chat windows, cookie banners, modal popups, review sliders, sticky buttons, lead forms, and overlays can all create focus traps, missing labels, poor contrast, keyboard problems, or screen reader noise if nobody tests them.
The Third-Party Script Cleanup Framework
Here is the practical way to clean this up without turning the website into a committee project.
1. Inventory every domain and script
Start with a real browser, not just the CMS. Use Chrome DevTools, WebPageTest, PageSpeed Insights, your tag manager export, your CMP report, and your hosting logs if available. HTTP Archive warns that client-side measurements can undercount third parties because CNAME cloaking and server-side tracking can reduce visibility, so treat your first list as a starting point.
Record the vendor, domain, owner, purpose, pages affected, consent category, data collected, load timing, and business value.
2. Sort scripts by business value and risk
Keep tools that clearly make money, reduce support cost, protect the business, or measure something you actively use. Challenge everything else.
A lead form spam tool may be worth its cost if it protects sales staff from junk. A retargeting pixel for an ad account nobody has opened in a year is not. A heatmap tool used during a redesign might not need to stay on every page forever. A chat widget that creates qualified leads may deserve budget, but it should not load on pages where it adds no value.
3. Restrict where and when scripts load
Most scripts do not need to run everywhere. Fire conversion pixels on conversion pages. Load chat only after the core page is usable or only on high-intent pages. Keep checkout scripts limited to checkout. Delay noncritical marketing tags until after consent and after key content loads.
You do not need a full rebuild to stop old code from running on every template.
4. Add guardrails before adding new tags
Require a ticket, owner, purpose, expiry date, data classification, consent category, and rollback plan for every new script. Add CSP where practical. Use SRI when external static assets are stable. Review the tag manager monthly if campaigns change often and quarterly if the marketing stack is steady.
The key is preventing the junk drawer from filling back up.
A Simple Script Audit Scorecard
Use this scorecard when deciding what stays:
| Question | Keep | Fix | Remove |
|---|---|---|---|
| Does someone own it? | Named owner | Shared or unclear owner | Nobody knows |
| Does it make or save money? | Clear business value | Possible value, no recent proof | No current value |
| Does it run only where needed? | Page scoped | Too broad | Sitewide for no reason |
| Does it respect consent? | Clear consent behavior | Needs testing | Fires before approval |
| Does it hurt performance? | Low cost | Delay or limit | Heavy and low value |
| Does it create security risk? | Reviewed source | Needs CSP/SRI/vendor review | Unknown or abandoned vendor |
| Does it affect accessibility? | Tested | Needs keyboard/screen reader QA | Blocks use or creates barriers |
If a script lands in “remove” on two or more rows, it should probably go.
What to Audit First
Do not start with the least important page on the site. Start where money changes hands or trust is won.
Audit these pages first:
- Homepage, top landing pages, contact page, quote request form, booking flow, cart, checkout, pricing page, service pages, thank-you pages, and any page used in paid campaigns.
- Then audit the tag manager container, consent banner, analytics setup, call tracking, form plugins, chat widget, A/B testing tools, heatmaps, retargeting pixels, review widgets, and embedded videos.
- Finally, review every vendor that can inject code, collect user data, or load another vendor inside your page.
This order protects the business outcome first. Baymard’s 70.22% average cart abandonment benchmark shows how easy it already is to lose ecommerce buyers.
FAQ
How many third-party scripts is too many?
There is no universal safe number. HTTP Archive reports median third-party request counts of 83 on desktop and 79 on mobile across all sites, but request count alone does not prove harm. A better test is whether each script has an owner, a purpose, a page scope, acceptable performance cost, and clear consent behavior.
Should small businesses remove all third-party scripts?
No. Analytics, payments, forms, spam protection, maps, reviews, chat, and call tracking can all be useful. The goal is not zero third-party code. The goal is no unmanaged third-party code.
Are tag managers bad for performance?
A tag manager is not automatically bad. HTTP Archive notes that tag manager scripts tend to load many other scripts and initiate many tasks, so the container needs cleanup rules. A disciplined tag manager can be cleaner than random scripts pasted across templates.
What is the fastest cleanup win?
Export your tag manager, sort tags by last used date and owner, then remove or pause anything with no owner, no current campaign, and no clear conversion value. After that, restrict high-cost scripts to the pages where they actually matter.
Need a Cleaner, Safer Website Stack?
If your site has years of old pixels, mystery plugins, duplicate analytics tags, or vendor scripts nobody wants to touch, we can help you sort it out.
YourWebTeam audits the scripts, fixes the loading strategy, cleans up tracking, and builds a website stack your team can actually understand. Start here: /get-started/.
