A website can look simple from the outside and still be carrying a small crowd of vendors under the hood.

Analytics. Ads. Heatmaps. Chat widgets. Review badges. Embedded video. CRM tracking. Retargeting pixels. Cookie banners. A tag manager that loads more tags.

Most of those tools were added for a reason. The problem is that almost nobody owns the full stack after launch. Marketing adds a script. Sales adds a chat tool. A contractor adds a tracking pixel for one campaign. Three years later, the site is slower, harder to secure, harder to audit, and nobody is quite sure which tags are still needed.

That makes third-party scripts a perfect linkable topic for web teams and business owners. The risks are measurable, the fixes are practical, and the numbers are strong enough to make a cleanup project easy to defend.

Use these 41 third-party script statistics when you’re building a website audit, writing a business case for performance work, or deciding whether that extra vendor tag is worth the cost.

What counts as a third-party script?

A third party is content loaded from a domain different from the site the visitor originally requested, according to the HTTP Archive Web Almanac definition. If someone visits example.com and the page loads a script from an analytics, ad, chat, video, font, or social media provider, that external provider is a third party.

That definition matters because the risk is not just file size. A third-party script can make its own requests, set cookies, delay rendering, inject other scripts, collect consent signals, or fail in ways your team doesn’t fully control. Google’s web.dev guidance says third-party JavaScript can affect performance, privacy, security, and page behavior.

For a small business website, that turns a technical detail into an ownership question: who is responsible for everything your visitors’ browsers are asked to run?

The short version: what the data says

  1. At least 90% of web pages use one or more third parties. HTTP Archive’s 2025 Web Almanac found that pages with at least one third party remain at or above 90%, even after a slight decrease from the previous year. (HTTP Archive)

  2. The top 1,000 websites load a median of 129 third-party requests on desktop and 106 on mobile. That is before a visitor clicks, scrolls deeply, or interacts with lazy-loaded components that might trigger more vendors. (HTTP Archive)

  3. Across all sites, the median page loads 83 third-party requests on desktop and 79 on mobile. This is the everyday web, not just media giants and ad-heavy publishers. (HTTP Archive)

  4. Third-party requests increased year over year across all ranks. HTTP Archive reports that the top 1,000 sites added 15 third-party requests on desktop and 15 on mobile compared with 2024, while the broader dataset added five requests on each device type. (HTTP Archive)

  5. The top third-party categories are ads, analytics, and CDNs. That lines up with what most web audits find first: measurement, monetization, and shared infrastructure. (HTTP Archive)

  6. Script, image, and “other” resources make up more than half of all third-party request content types. In plain English, the vendor load is not one neat JavaScript file. It’s scripts, pixels, images, iframes, JSON, and other resources working together. (HTTP Archive)

  7. Google-owned services dominate the top 10 third-party domains by page prevalence. HTTP Archive lists fonts.googleapis.com, googletagmanager.com, google-analytics.com, accounts.google.com, and adservice.google.com among the top domains, with facebook.com as the only non-Google domain in the top 10. (HTTP Archive)

  8. Facebook.com appears on 21% of pages. That makes Meta’s domain the only non-Google domain in the 2025 top 10 third-party list. (HTTP Archive)

  9. The median third-party inclusion chain depth is 3. HTTP Archive explains that this means most third parties include at least one additional third party on a page. (HTTP Archive)

  10. The deepest third-party inclusion chain observed was 2,285. You don’t need to hit an extreme number like that to have a problem. The point is that one vendor can quietly become many. (HTTP Archive)

Performance statistics: the JavaScript tax is real

Third-party scripts are not just downloaded. The browser has to parse, compile, execute, and coordinate them with everything else on the page. That cost is worse on cheap phones, weak connections, and overloaded pages.

  1. The median mobile page shipped 558 KB of JavaScript in 2024. The median desktop page shipped 613 KB. (HTTP Archive)

  2. Median JavaScript payload increased 14% in 2024. HTTP Archive called the trend concerning because larger JavaScript bundles place more strain on device resources, especially for older or less powerful hardware. (HTTP Archive)

  3. The median mobile page made 22 JavaScript requests in 2024. At the 90th percentile, mobile pages made 68 JavaScript requests. (HTTP Archive)

  4. The median desktop page made 23 JavaScript requests in 2024. At the 90th percentile, desktop pages made 70 JavaScript requests. (HTTP Archive)

  5. About 44% of JavaScript bytes delivered on the median mobile page were unused during page load. HTTP Archive reported 206 KB of unused JavaScript at the median on mobile. (HTTP Archive)

  6. At the 90th percentile, third-party JavaScript requests grew from 34 in 2022 to 36 in 2024. HTTP Archive described the rise in third-party scripts as concerning because of performance, security, and privacy risk. (HTTP Archive)

  7. Google Lighthouse flags third-party code when it blocks the main thread for 250 milliseconds or longer. That threshold is useful for audits because it turns “too many tags” into a measurable failure. (Chrome for Developers)

  8. A third-party server problem can block rendering until the request times out, sometimes for 10 to 80 seconds. Google’s web.dev guidance calls out this single-point-of-failure problem for third-party JavaScript. (web.dev)

  9. The median 2025 desktop home page weighed 2.86 MB. The median 2025 mobile home page weighed 2.56 MB. (HTTP Archive)

  10. The median 2025 desktop home page included 697 KB of JavaScript. The median 2025 mobile home page included 632 KB of JavaScript. (HTTP Archive)

  11. Median mobile home page weight increased 202.8% between July 2015 and July 2025. Over the same period, the median desktop home page saw a 110.2% increase. (HTTP Archive)

  12. The median home page size grew 7.8% year over year to 2.7 MB in 2025. Mobile home pages grew 8.4% from 2024, while desktop pages grew 7.3%. (HTTP Archive)

  13. The median mobile home page used 632 KB of JavaScript and 911 KB of images in 2025. That mix matters because images are heavy to transfer, while JavaScript is expensive to process. (HTTP Archive)

If a third-party script can identify a user, set a cookie, receive a consent string, or pass data to another provider, it’s not just a front-end choice. It’s a privacy and compliance choice.

  1. Roughly 60% of cookies on top websites are third-party cookies. HTTP Archive found that, on both desktop and mobile, about 40% of cookies are first-party and about 60% are third-party. (HTTP Archive)

  2. On the top 1,000 websites, 78% of cookies are third-party. HTTP Archive says the most popular websites set proportionally more third-party cookies, likely because they include more third-party content and scripts. (HTTP Archive)

  3. The median desktop website sets 9 cookies overall. That includes a median of 7 first-party cookies and 7 third-party cookies on pages where those cookie types appear. (HTTP Archive)

  4. At the 90th percentile, desktop pages set 44 cookies overall and 40 third-party cookies. For a business owner, that is a lot of data behavior to explain in a privacy policy. (HTTP Archive)

  5. At the 99th percentile, desktop pages set 399 third-party cookies. That is not a normal small business target, but it shows how far tag sprawl can go when nobody cleans house. (HTTP Archive)

  6. Nearly 100% of third-party cookies use SameSite=None. HTTP Archive explains that this setting allows cookies to be sent on cross-site requests, which can enable cross-site tracking. (HTTP Archive)

  7. Only 8.6% of third-party cookies on mobile pages were partitioned in July 2025. Partitioned cookies are meant to limit cross-site tracking by storing third-party cookies per top-level site. (HTTP Archive)

  8. TCF is the dominant third-party consent standard in HTTP Archive’s 2025 data. It reaches 36% among low-ranked sites and 18% across all sites. (HTTP Archive)

  9. USP consent standard adoption ranges from 9% to 17% across ranks. HTTP Archive identifies it as the second most prevalent consent standard in the 2025 third-party dataset. (HTTP Archive)

  10. GPP adoption remains low at 3% to 6% across ranks. That is notable because GPP was designed to unify consent frameworks across jurisdictions. (HTTP Archive)

  11. Pubmatic.com receives the highest volume of consent signals among top-ranked websites, with adservice.google.com in second place. HTTP Archive notes that the top consent receivers are mostly advertising and ad tech vendors. (HTTP Archive)

Security statistics: every outside script is a trust decision

A third-party script runs in your customer’s browser as part of your website experience. If that script is compromised, misconfigured, or abused, the visitor will not blame the vendor first. They’ll blame the site they visited.

  1. The 2025 Web Almanac reported that the Shai-Hulud 2.0 npm supply chain attack compromised more than 1,000 packages and infected more than 27,000 GitHub repositories. That example is about the software supply chain, but the lesson applies to vendor scripts too: dependencies can become risk multipliers. (HTTP Archive)

  2. Content Security Policy adoption rose from 18.5% in 2024 to 21.9% in 2025. CSP helps websites control which content can load and can reduce the impact of cross-site scripting attacks. (HTTP Archive)

  3. CSP adoption increased by about 18% year over year. HTTP Archive said adoption has now risen above 20%, continuing a steady upward trend. (HTTP Archive)

  4. The HSTS header appears on 36% of mobile pages. HSTS tells browsers to use HTTPS for a domain, reducing downgrade and first-visit risks. (HTTP Archive)

  5. 97.3% of mobile homepages are served over HTTPS. That is good baseline progress, but secure transport does not automatically make third-party scripts safe. (HTTP Archive)

  6. 98.8% of mobile requests use HTTPS. The web is increasingly encrypted in transit, but third-party governance still matters because the browser is executing code from outside domains. (HTTP Archive)

  7. Chrome, Firefox, and Safari all push HTTPS-first behavior in modern browsing. HTTP Archive cites browser vendor HTTPS-first moves as one reason HTTPS adoption keeps climbing. (HTTP Archive)

A practical third-party script audit framework

Stats are useful, but the real value is knowing what to do Monday morning. Here’s the framework we use when a site has tag bloat.

1. Inventory everything

Start with a simple spreadsheet. List every script, pixel, iframe, tag manager container, embedded widget, font provider, and CDN-hosted library that loads on your homepage, top landing pages, contact page, checkout or quote page, and highest-traffic blog posts.

For each item, capture the vendor name, domain, owner inside the business, purpose, pages loaded, last confirmed use, data collected, and whether it is required before consent.

If nobody can name the owner or purpose, that script is a removal candidate.

2. Sort by business value

Don’t remove tools blindly. A call-tracking script that proves ad spend may be worth its cost. An old heatmap tag from an agency you stopped using two years ago probably isn’t.

Put each vendor in one of four buckets:

  • Required for revenue or operations
  • Useful, but not required
  • Unknown owner or unknown value
  • Duplicate, expired, or unsafe

The third and fourth buckets are where cleanup usually pays off fastest.

3. Measure speed before and after

Run Lighthouse, PageSpeed Insights, WebPageTest, or your preferred monitoring tool before removing anything. Then test again after each cleanup round. Google’s Lighthouse third-party audit uses a 250 millisecond main-thread blocking threshold, which gives you a useful line in the sand.

Pay special attention to mobile. HTTP Archive’s 2025 page weight chapter shows that the median mobile home page already ships 632 KB of JavaScript, and lower-end phones feel that cost first.

Look at which scripts fire before consent, which cookies appear before consent, and which vendors receive consent strings. HTTP Archive’s 2025 third-party chapter found that consent signal handling is now measurable across vendor categories, with TCF, USP, and GPP all appearing in third-party request data.

If your privacy policy says one thing and the browser does another, fix the browser behavior first. The policy should describe reality, not wishes.

5. Put tags under change control

The goal is not a one-time purge. The goal is to stop the mess from coming back.

Create a lightweight rule: no new third-party script goes live without an owner, purpose, expiry date, privacy review, and performance check. If a vendor is only needed for a campaign, set a removal date when the campaign starts.

This is boring work. It also prevents a lot of expensive surprises.

What should a small business actually remove?

Start with duplicates. Two analytics platforms, two heatmap tools, two chat tools, two popup tools, and two tag managers are rarely helping you twice as much. They’re usually making the site slower and the data harder to trust.

Then remove abandoned campaign pixels. If an ad campaign ended last quarter, its pixel should not live forever.

After that, review widgets that appear on every page. Chat, reviews, maps, social embeds, scheduling widgets, and video players can be useful, but they don’t always need to load globally. Put them where they help the visitor make a decision.

Finally, look at tag manager permissions. A tag manager is convenient, but it can become a back door for website changes that bypass normal QA. The larger the business, the more important approvals become.

FAQ

Are third-party scripts always bad?

No. Analytics, payment tools, scheduling widgets, accessibility tools, CDNs, and support chat can all be legitimate. The problem is unmanaged accumulation. Google’s web.dev guidance recommends choosing third-party resources carefully, avoiding duplicate vendors, using performance budgets, and routinely cleaning out redundant scripts. (web.dev)

How often should we audit third-party scripts?

For most small businesses, quarterly is enough. Audit sooner after a redesign, analytics migration, agency handoff, ad campaign launch, CRM change, or privacy policy update.

What’s the fastest win?

Remove duplicate and abandoned tags first. They’re usually low-risk because nobody is using the data, and they often reduce requests, cookies, and main-thread work immediately.

Should we self-host third-party scripts?

Sometimes, but don’t treat self-hosting as a magic fix. HTTP Archive counts content served directly from a first-party domain as first-party content, but that can hide the original vendor relationship in client-side measurements. (HTTP Archive) You still need to know what the code does, who maintains it, and whether updates are safe.

Want a cleaner, faster website stack?

If your website has years of tags, trackers, plugins, and mystery scripts piled on top of each other, we can help you sort it out.

Your Web Team builds and maintains small business websites with performance, ownership, and lead generation in mind. If you want a practical audit and a clear cleanup plan, get started here.