The Average Website Now Loads 375 KB of Third-Party JavaScript

Across the millions of pages the HTTP Archive crawls, the median mobile page loads about 375 KB of third-party JavaScript. This is the 2024 figure from the Web Almanac's JavaScript chapter, and it represents the 50th percentile: half of all pages ship more than this and half ship less.

For comparison, the same median page ships only 168 KB of first-party JavaScript, the code a site's own developers actually wrote. On a typical website today, external scripts outweigh the site's own JavaScript by more than two to one.

The gap widens sharply at the heavier end of the web. At the 75th percentile, third-party JavaScript reaches about 766 KB. At the 90th percentile it climbs to roughly 1,292 KB, which is more than a full megabyte of code from other companies on a single page.

At every percentile, third-party scripts outweigh first-party scripts. The heavier the page, the larger the share of weight that belongs to someone other than the site owner.

A single year's figure is a snapshot. The HTTP Archive has measured the same thing repeatedly, and the direction never changes.

From 2020 to 2024, third-party JavaScript on the median page rose by roughly 47 percent. From 2022 to 2024 alone it grew about 28 percent. Across the entire window, the scripts a site borrows have consistently weighed more than the scripts it builds. In 2020, the median site already served slightly more third-party scripts than first-party ones by request count. By byte weight, the imbalance has only grown since.

The first-party line tells its own story. It dipped from 134 KB in 2020 to 109 KB in 2022 before climbing again to 168 KB in 2024. Even in the year first-party weight fell, third-party weight rose.

This matters because the conversation about web performance grew louder over the same period. Google made Core Web Vitals a ranking signal, build tools improved, and "performance" became a standard line item in redesigns. Despite all of that, the amount of external JavaScript on the typical page kept rising.

The most useful way to read this data is as an inversion. There was a time when most of a page's JavaScript was the site's own application code, with a handful of external scripts bolted on. That relationship has flipped. The median page is now mostly other people's code, with the site's own work as the minority share.

This happens gradually. A marketing team adds an analytics platform. A growth team adds a heatmap tool and an A/B testing script. Sales adds a live chat widget. Finance adds a fraud-detection service. Legal adds a consent management platform. Each one is justified on its own. None of them are weighed against the others, because no single person owns the cumulative total.

The 2024 request data makes the same point from a different angle. At the median, a mobile page makes about 11 first-party JavaScript requests and 10 third-party ones. By the 90th percentile, that becomes 45 first-party and 36 third-party. The counts are close, but the byte weight is not, because individual third-party scripts tend to be larger and are far less likely to be trimmed, code-split, or tree-shaken the way a modern first-party build would be.

Not all page weight is equal. An image is heavy to download, but once it arrives the browser simply paints it. JavaScript is different. Every kilobyte has to be downloaded, then parsed, then compiled, then executed, and most of that work happens on the main thread, the same single thread the browser uses to respond to taps, clicks, and scrolls.

So 375 KB of third-party JavaScript is far more than 375 KB of transfer time. It is processing work that competes directly with the things a visitor is trying to do. While a tag manager is busy loading and running other scripts, the page can look ready while ignoring taps. That delay shows up in Interaction to Next Paint, one of Google's Core Web Vitals, and it is felt most acutely on the mid-range phones and ordinary mobile connections that make up a large share of real traffic. Our companion mobile vs desktop speed gap study puts the mobile INP median at 188 ms versus 76 ms on desktop, and JavaScript weight is the biggest reason for that split.

The cost is also uneven across devices. A flagship phone on fast Wi-Fi chews through a megabyte of script without much complaint. A three-year-old mid-tier Android handset on a congested mobile network does not.

There is one more reason third-party JavaScript is uniquely expensive: you do not control it. Your own code ships when you decide and changes when you change it. A third-party script can update itself on the vendor's schedule, pull in new dependencies you never reviewed, and grow heavier between one week and the next without any change on your side.

The link between speed and revenue is one of the most studied effects in digital commerce. Research compiled by Portent shows conversion rates collapsing as load time grows.

Bounce behavior follows the same curve. Google's research found that as a page's load time goes from one second to three, the probability that a visitor bounces rises by 32 percent. From one second to six, it rises by 106 percent, and Think with Google reports bounce probability increasing as much as 123 percent at the ten-second mark. Separately, Google has reported that 53 percent of mobile visitors abandon a page that takes longer than three seconds to load.

In the Google and Deloitte study Milliseconds Make Millions, a mere 0.1 second improvement in mobile load time raised retail conversions by 8.4 percent and lifted average order value by 9.2 percent.

External JavaScript is not random. The 2025 Third Parties chapter of the Web Almanac breaks the web's third parties into a small set of categories, and the three largest by usage are advertising, analytics, and content delivery networks. After those come tag managers, customer-support and chat tools, marketing pop-ups, and social embeds. Tag managers deserve special attention, because their entire job is to load other scripts.

The web's third-party layer is also remarkably concentrated. The most common third-party domains across the web are almost entirely Google properties: Google Fonts, Google Tag Manager, Google Analytics, and Google's advertising services. Meta's Facebook is the only non-Google domain in the top tier, appearing on about 21 percent of pages. More than 90 percent of all pages load at least one third party.

Third parties bring friends. The 2025 data measured the typical inclusion chain, meaning how many layers deep third-party loading goes. The median depth is three, which means most third parties on a page will themselves load other third parties. The maximum chain observed reached 2,285 levels deep.

One finding in the 2025 data looks, at first, like good news. The median number of distinct third-party domains on a page went down compared to the prior year.

The weight did not follow. Over the same period, the number of third-party requests per page went up across every ranking band. Among the top 1,000 sites, third-party requests rose by about 15 on both desktop and mobile, and the broader set of sites rose by about five each. The most popular sites now make a median of 129 third-party requests on desktop and 106 on mobile, against 83 and 79 across all sites.

There are fewer vendors on the page, but the ones that remain are doing more work, making more requests, and sending more code. A smaller number of larger players now account for a growing share of every page's activity.

The HTTP Archive figures are also a floor, not a ceiling. Techniques like CNAME cloaking and server-side tagging route third-party activity through a site's own domain, which makes those third parties invisible to a client-side crawler. The Web Almanac authors are explicit that their numbers represent a lower bound. The real amount of third-party code reaching the average visitor is very likely higher than 375 KB.

The goal is not zero third parties. Analytics, payments, and consent tools exist for good reasons. The goal is intentional third parties, where every script on the page is there because someone decided it should be and confirmed it still belongs.

Measure what is actually loading before you change anything. Run your site through PageSpeed Insights or WebPageTest and look specifically at third-party script weight and main-thread time. Most teams discover scripts still firing from a campaign that ended years ago.

Treat your tag manager as a budget, not a storage closet. Every container entry has a cost in both download and execution. Remove dormant tags, and require a named owner and a reason for each one that stays. If nobody can say why a tag is there, that is the answer.

Defer everything that does not need to run immediately. Chat widgets, testing tools, and social embeds rarely need to execute before a page is usable. Loading them after the page becomes interactive removes their weight from the moment that decides whether a visitor stays. On WordPress specifically, our guide to how to defer render-blocking scripts in WordPress walks through the exact plugin and code-level steps.

Remove duplicate tooling. It is common to find two analytics platforms, several heatmap or session-recording tools, and more than one consent script running together. Consolidating to a single tool per job is often the fastest single reduction available.

Set a third-party budget and monitor it over time. Because third-party JavaScript tends to grow on its own, a one-time cleanup degrades. Pick a ceiling, watch it, and treat a breach the way you would treat overspending on ads.

If you want to know how your own site compares to the 375 KB median, the measurement is straightforward. PageSpeed Insights and WebPageTest both report third-party script weight and the main-thread time it consumes, and the Chrome User Experience Report shows how real visitors experience Core Web Vitals rather than how a lab test does. A site shipping noticeably more than 375 KB of third-party JavaScript is carrying more external weight than half the web.

The figure to watch is not only the total. It is the trend on your own domain. The web's median rose 47 percent in four years because individual sites kept adding without subtracting. The same drift happens on any single site that is not actively managed.

The headline figures in this study come from the HTTP Archive and its annual Web Almanac, which analyze millions of real-world web pages using Google's Lighthouse and WebPageTest infrastructure on a throttled mobile profile that approximates a typical device and connection.

A third party is defined as any resource served from a domain other than the page's own registrable domain, following the eTLD+1 definition the Web Almanac uses. All headline byte figures are medians, the 50th percentile, for mobile pages, taken from the JavaScript chapters of the 2020, 2022, and 2024 Web Almanac editions. Prevalence, category, request-count, domain-concentration, and inclusion-chain figures come from the 2025 Third Parties chapter.

Because techniques such as CNAME cloaking and server-side tagging route third-party activity through a site's own domain, some third parties are invisible to a client-side crawler. The Web Almanac authors state plainly that their measurements represent a lower bound.

The conversion and bounce figures are drawn from Google and Deloitte's Milliseconds Make Millions report, Google's mobile bounce-rate research published through Think with Google, and site-speed conversion research compiled by Portent.

• JavaScript, 2024 Web Almanac (HTTP Archive): median mobile third-party JavaScript of 375 KB versus 168 KB first-party, and the full percentile distribution.
• JavaScript, 2022 Web Almanac (HTTP Archive): median mobile third-party JavaScript of 292 KB.
• JavaScript, 2020 Web Almanac (HTTP Archive): median mobile third-party JavaScript of 255 KB and per-script request counts.
• Third Parties, 2025 Web Almanac (HTTP Archive): prevalence above 90 percent, category breakdown, Google domain concentration, request growth, and inclusion-chain depth.
• Milliseconds Make Millions, Google and Deloitte: a 0.1 second speed improvement lifting retail conversions 8.4 percent and average order value 9.2 percent.
• Mobile bounce-rate statistics, Think with Google: bounce probability rising 32 percent from one to three seconds and up to 123 percent by ten seconds.
• Research on how site speed hurts revenue, Portent: conversion rates by load time, from 3.05 percent at one second to 0.41 percent at five.