The cost of third parties

Twelve tags on the tea of the week

Meera looks after Leaf and Kettle's marketing. Over the past year, she has added tags to the shop's pages. A tag is a small piece of code from another company. One counts visits. One tells an ad network who came. Each took her a minute to add. She adds them through a tag manager, a script that puts tags on the page for her. It now holds twelve of them.

On Monday, Asha sends the shop a message. The home page is slow on her phone. Ravi opens the page and reads its head. Next to his own code, he finds scripts from four other companies. And one of them adds two more. So Ravi asks a simple question. Which of these costs Asha the most?

Each of those companies is a third party. Its code or files come from its own site, not the shop's. Leaf and Kettle is the first party: it owns the page and its address.

The course didn't load any real analytics, ad or chat service. They would track the course's browser, and they change from day to day. So it built six stand-ins. Each one lives on its own made-up site, like tags.example. Each keeps the phone busy for about as long as a well-known service of its kind does, on average. Their file sizes are the course's own choice. You'll meet the list those averages come from later on.

Then it loaded the page on "Asha's phone", the stand-in from lesson 22.1. That's Chrome 157 on a phone's screen, DevTools' Slow 4G network, and a CPU 4 times slower. It loaded the page with no third parties, and with all of them, three times each. Here is what Asha saw:

In the top row, the words came first, then the photo. Both were on screen within 1.3 seconds. In the bottom row, the screen stayed white until 2.9 seconds. Then the whole page came at once, with a banner across the bottom asking about cookies. The chat bubble came at 4.4 seconds.

Here are the numbers behind those screens:

1// Asha's phone: the median of three loads of each page.2const withoutTags = { photo: 1273, blocking: 0, bytes: 13216 };3const withTags = { photo: 2920, blocking: 1135, bytes: 346544 };4const kb = (bytes) => (bytes / 1024).toFixed(1);5 6console.log(`Photo on screen: ${withoutTags.photo} ms, then ${withTags.photo} ms`);7console.log(`Blocking time: ${withoutTags.blocking} ms, then ${withTags.blocking} ms`);8console.log(`Downloaded: ${kb(withoutTags.bytes)} KB, then ${kb(withTags.bytes)} KB`);

• Line 1 is a comment. Each number is a median of three loads: the middle one, once they're sorted.
• Line 2 holds the page without the tags. photo is when the photo appeared, in milliseconds (ms). It was the page's largest contentful paint. blocking is the page's blocking time. It adds up how long the phone was too busy to answer a tap, after the first paint. bytes is everything the page downloaded.
• Line 3 holds the same page with the tags. Line 4 turns bytes into kilobytes (KB).
• Lines 6 to 8 print Photo on screen: 1273 ms, then 2920 ms, Blocking time: 0 ms, then 1135 ms and Downloaded: 12.9 KB, then 338.4 KB.

The tags more than doubled Asha's wait for the photo. They added over a second of blocking time. And they made her phone download 26 times as many bytes. Why it matters: Asha can't see or use the shop until other companies' code is done with her phone.

The main thread is the one line of work where the browser runs scripts and draws the page. Only one thing happens on it at a time.

The system design lesson Third-party scripts and supply chain covers what this code can do to your page and your visitors' data. It also covers how to keep it safe. This lesson measures what it costs in speed. Lesson 19.2 already measured three embeds. Lesson 23.1 showed how a script tag decides when a file runs. Here, you'll answer four questions:

• What kinds of third parties are there? Analytics, ads, tag managers and widgets.
• How do you measure each one? Measuring each third party's cost.
• How can you know before you add one? The Third Party Web dataset.
• What if one of them is down? Single points of failure.

Analytics, ads, tag managers and widgets

Third parties are on almost every page. The Web Almanac studies millions of pages from the HTTP Archive. Its 2025 chapter on third parties found them on more than nine in ten pages. The median mobile page made 79 requests to them.

Most fall into a few kinds. Here are the kinds on Meera's page:

• Analytics counts visits, and what visitors do. Meera's analytics tag sends a small report for each event, like "the tea of the week was seen".
• Ads show ads, or tell an ad network who visited. Then it can show them ads on other sites. Meera's ad script does the second.
• A tag manager is a script that loads other scripts. Meera picks tags in its dashboard, and it adds them to the page. Nobody has to change the shop's code.
• Widgets put something on the page. Meera has a chat widget, with a bubble in the corner.
• A consent banner asks Asha which cookies she allows. It runs early on every page.
• An A/B test shows half the visitors one version of a page, and half another. Then Meera can see which one sells more.

Here is the top of the page, with each company's snippet pasted as its instructions said:

1<head>2  <style>.ab-hide { opacity: 0 !important; }</style>3  <script>4    document.documentElement.classList.add("ab-hide");5    setTimeout(() => document.documentElement.classList.remove("ab-hide"), 4000);6  </script>7  <script src="https://abtest.example/experiment.js" async></script>8  <script src="https://consent.example/banner.js"></script>9  <script src="https://tags.example/container.js?id=LK-12" async></script>10  <script src="shop.js" defer></script>11</head>12<!-- ...the photo, the words and the button... -->13<script src="https://chat.example/widget.js" async></script>

• Lines 2 to 7 are the A/B test's snippet. Line 2 makes a class that hides the whole page. Line 4 puts it on the page. Line 5 is a safety net. It shows the page anyway after 4 seconds. Line 7 loads the test itself, experiment.js.
• Line 8 loads the consent banner as a plain script: no async, no defer.
• Line 9 loads the tag manager's container. That's its file with Meera's twelve tags in it.
• Line 10 is Ravi's own script. Line 13, at the end of the body, loads the chat widget.

Lesson 23.1 showed what a plain script does. The browser stops reading the HTML until the script has arrived and run. Remember line 8. It comes back at the end of the lesson.

A script that adds scripts

The HTML names four third parties. But the page talked to six. The tag manager added the other two. Here is its container, shortened:

1// container.js, shortened: 2 of its 12 tags.2const TAGS = [3  { name: "Analytics: base tag", kind: "script", when: "start", src: "https://stats.example/analytics.js" },4  { name: "Ads: landing page", kind: "pixel", when: "start", src: "https://ads.example/pixel?tag=landing" },5];6const run = (tag) => {7  busy(16); // the tag's own code8  if (tag.kind === "script") {9    const script = document.createElement("script");10    script.src = tag.src;11    document.head.append(script);12  } else new Image().src = tag.src;13};14const fire = (when) => TAGS.filter((tag) => tag.when === when).forEach(run);

• Lines 2 to 5 list the tags. Each has a name, a kind, a trigger and an address. The real container lists twelve.
• Lines 6 to 13 run one tag. Line 7 is the tag's own work. busy(16) is how the course's stand-ins work: it keeps the main thread busy for 16 ms.
• Lines 8 to 11 add a script tag to the page. Only now does Chrome ask for that file.
• Line 12 sends a pixel. That's a request for a tiny image, made only to report something. The report rides in the address.
• Line 14 runs every tag whose trigger has come. A start tag runs at once. A ready tag waits for DOMContentLoaded, and a load tag for the load event.

Here is who asked for what, and when Chrome asked:

Chrome asked for the container at 618 ms. It arrived at 2,550 ms. Only then could it run, and add analytics.js and ads.js. Those two then sent pixels of their own. So one line of HTML brought in two more sites, and 16 requests in all.

This is normal. The Almanac found that "the majority of the third parties include at least another third party". Why it matters: the HTML doesn't show every third party. Look at the requests the page really makes.

Measuring each third party's cost

Back to Ravi's question. In the flat, there were two ways to find the costly plug: a meter on each one, or a switch. The same two ways work on a page. Start with the meters: split the cost by site.

Bytes and requests, by site

Each third party answers from its own site. So group the page's requests by the site they went to. In DevTools' Network panel, More filters › 3rd-party requests keeps only requests to other sites. Here is what each site sent on the page with every tag:

1// What each site sent, on the page with every tag: bytes and requests.2const sites = [3  ["shop.example", 13376, 3],4  ["abtest.example", 27417, 1],5  ["consent.example", 30716, 1],6  ["tags.example", 71276, 1],7  ["stats.example", 45864, 7],8  ["ads.example", 60953, 8],9  ["chat.example", 96942, 2],10];11for (const [site, bytes, requests] of sites) {12  const word = requests === 1 ? "request" : "requests";13  console.log(`${site}: ${(bytes / 1024).toFixed(1)} KB in ${requests} ${word}`);14}

• Lines 3 to 9 hold one site per row: its name, the bytes it sent, and how many requests it answered.
• Line 12 picks the word "request" or "requests".
• Line 13 prints one line per site. It starts with shop.example: 13.1 KB in 3 requests and ends with chat.example: 94.7 KB in 2 requests.

The chat widget sent the most: 94.7 KB, nearly all of it one script. The tag manager's container came next, at 69.6 KB. The shop's own page, photo included, was 13.1 KB. So Asha's phone downloaded about 25 times more from other companies than from the shop. Why it matters: on a slow network, those bytes share the line with the shop's photo.

Main-thread time, by third party

Bytes are only part of the cost. Each script also runs on the main thread. DevTools can split that time three ways:

• In the Performance panel, the 3rd parties insight lists each third party. It gives each one's transfer size and main thread time.
• With nothing selected, the Summary tab shows a 1st / 3rd party table. The page's own site carries a 1st party badge.
• The Bottom-up tab has a grouping menu. Pick Group by 3rd parties.

Lighthouse shows the same table, in its own 3rd parties insight. Both use DevTools' trace engine. It gives each bit of work to the script file it ran from. Then it gives each file to its third party. The course ran that engine on its trace of the page:

The ad script ran the longest: 681 ms. The consent banner came next, at 567 ms. The shop's own code ran for just 10 ms. In all, other companies' code ran for 2,561 ms. So the chat widget sent the most bytes, but the ad script held the phone the longest. Why it matters: the biggest file isn't always the biggest cost.

Take one away, and compare

The meters split the cost. They don't tell you what would change without one. For that, use the switch. Block one third party, load the page again, and compare. In the Network panel, right-click a request and open Block requests. Then pick Block request URL or Block request domain. The Request conditions drawer lists what's blocked. Load the page three or more times each way, and compare the medians. One load can mislead you.

The course did this for each third party, three loads each. Read each row across: what was taken out, then how four numbers moved. Each is compared with the page with every tag.

Three findings stand out:

• The tag manager cost the most blocking time. Without it, blocking time fell by 791 ms. The page downloaded 173.9 KB less. Yet its own code ran for only 292 ms. The rest came from the tags it added. So count what a tag manager adds as part of its cost.
• The A/B test cost the most time to the photo. Without it, the photo came 939 ms sooner. Yet its own code ran for 468 ms, less than the ad script or the banner. Its snippet hid the page until that code had run. No main-thread table shows a hidden page.
• The consent banner held the photo back too, by 711 ms. Its plain script stopped the browser reading the HTML.

Two surprises

First, look at the blocking time without the A/B test. It went up, by 216 ms. Blocking time only counts long tasks after the first paint. A long task holds the main thread for more than 50 ms. With the page hidden, the first paint came late. So the early long tasks weren't counted, though they still kept Asha's phone busy. Why it matters: a lower blocking time isn't always a better page. Check when the first paint came.

Second, without the ad tags or the analytics tags, the photo came about 140 ms later. The smaller container arrived sooner: at 2,415 ms instead of 2,550. That was just before the browser had read all the HTML. So the container's 161 ms long task ran first, and the page waited behind it. Why it matters: taking one script away can move another's work in front of your page. Measure. Don't guess.

Watch each page fill in. Move the slider:

Now block one third party at a time, and watch the numbers move:

The Third Party Web dataset

Measuring needs the tag on your page. But Meera wants to know before she adds the next one. For that, there's a public list.

Third Party Web is an open dataset by Patrick Hulce. Each month, the HTTP Archive loads millions of sites with Lighthouse, as a phone. Lighthouse adds up how long each script ran on the main thread. Third Party Web adds those times up for each origin: the scheme, host and port a script came from. Then it gives each origin to the company behind it. That company is an entity: one name, like Google Analytics, for all the origins it serves from.

For each entity, it gives an Average Impact. That's the main-thread time of all its scripts, divided by the number of pages that use it. So it says how long that service runs on a typical page. The README sorts the entities into categories, from the lightest to the heaviest. For example, the most used tag manager, Google Tag Manager, averages 1,066 ms.

The course sized its stand-ins from this dataset. Each keeps the main thread busy for about the Average Impact of one well-known service of its kind. Read each row across: the stand-in, its kind, the dataset row it copies, that row's Average Impact, and what DevTools measured on Asha's phone.

The last two columns match within 10 ms, because each stand-in works for a fixed time. Real services vary from page to page. That's why the dataset gives an average.

The same list names the third parties in your tools. DevTools' docs say its 3rd parties insight groups requests "based on the Third Party Web open source dataset". Lighthouse uses the same package. A site the list doesn't know is named after its domain. That's why the course's stand-ins show up as ads.example and chat.example.

Keep two limits in mind. The dataset only counts main-thread time. It knows nothing about the A/B test's hidden page, or a plain script that stops the HTML. And its numbers come from other people's pages, not yours. Use it to compare before you choose. Then measure on your own page.

Single points of failure

So far, every third party answered. What if one doesn't? In 2010, Steve Souders named this a frontend single point of failure. It's one file that can take down the whole page if it never arrives. His example was a script from another site, in the head. If that site is overloaded, he wrote, "the entire page is blank".

Pat Meenan showed how to test for it. When a third party fails, he wrote, "the servers usually become unreachable and requests time out." So a server that says "no" at once isn't a fair test. You need one that never answers. He set up a blackhole server: a server that drops everything sent to it.

The course made its own. It made the consent banner's server take each connection, then say nothing at all. Then it loaded Meera's page with the banner's tag written two ways:

<script src="https://consent.example/banner.js"></script>        <!-- 1. plain, as pasted -->
<script src="https://consent.example/banner.js" async></script>  <!-- 2. with async -->

• Line 1 is the tag as Ravi pasted it: a plain script.
• Line 2 is the same tag with async. Nothing else on the page changed.

With the plain script, Asha's screen stayed white for half a minute. With async, the page came at 2,192 ms. That's even sooner than on a normal day, when it came at 2,920 ms. There was no banner code to run. Here are the times:

1// The banner's server never answered. Times in ms after Asha opened the page.2const plain = { waited: 30012, photo: 30705 };3const withAsync = { waited: 30007, photo: 2192, loadEvent: 30627 };4 5console.log(`Plain script: Chrome waited ${plain.waited} ms for banner.js. The photo came at ${plain.photo} ms.`);6console.log(`With async: Chrome waited ${withAsync.waited} ms for banner.js. The photo came at ${withAsync.photo} ms.`);7console.log(`With async: the load event came at ${withAsync.loadEvent} ms.`);

• Line 2 holds the plain page: how long Chrome waited for banner.js, and when the photo came. Line 3 holds the page with async, and when its load event came.
• Lines 5 and 6 print Plain script: Chrome waited 30012 ms for banner.js. The photo came at 30705 ms. and With async: Chrome waited 30007 ms for banner.js. The photo came at 2192 ms.
• Line 7 prints With async: the load event came at 30627 ms.

On the plain page, the async scripts below the banner waited too. The preload scanner reads ahead in the HTML, so Chrome fetched the tag manager's container early. It arrived at 2,376 ms. But a script can only run once the parser has reached its tag. So the container ran after the banner failed, and asked for analytics.js at 30,785 ms. One plain script held back every script under it.

Both pages waited about 30 seconds. That number comes from Chrome's own code. Every new HTTPS connection starts with a short exchange that sets up its encryption, called the TLS handshake. Chrome gives it 30 seconds, then gives up. The course's server took the connection, but never did its part of the handshake.

A real blackhole is worse. It never even takes the connection. Then Chrome waits for the operating system to give up. Chromium's code says that takes "anywhere from 20 seconds to 190 seconds", and it stops waiting at 4 minutes. web.dev says the wait "can be anywhere from 10 to 80 seconds".

With async, the page didn't wait. But one thing still did: the load event. It came at 30,627 ms. The HTML standard makes the load event wait for every async script still on its way. So anything that waits for load waited half a minute too. Here, that was four of Meera's tags. Why it matters: async keeps the page on screen, but it doesn't make a dead server free.

Move through both pages, second by second:

Which way answers which question?

Each question below needs one of the three ways of measuring. Sort each one into the way that answers it:

Common mix-ups

• "A third party costs as much as its file weighs." No. The chat widget sent the most bytes. But the ad script ran the longest, and the A/B test held back the photo the most.
• "A tag manager is light. It only loads other tags." No. Its own code ran for 292 ms. With the tags it added, taking it out cut 791 ms of blocking time.
• "async makes a third party free." No. The ad script was added like an async script, and still ran for 681 ms. And the load event waits for every async script.
• "If a third party is down, its script just fails fast." No. A server that never answers made Chrome wait 30 seconds. One that drops every packet can take minutes.
• "Lower blocking time means a faster page." No. Hiding the page lowered the blocking time, because it pushed the first paint later.
• "DevTools knows every third party by name." No. It names the ones in Third Party Web. Any other site is named after its domain, like tags.example.

Practice exercises

Answer each one first. Then open the hints if you need them.

// Another shop's "3rd parties" insight: main-thread time (ms) and bytes.
const parties = [
  { name: "reviews.example", ms: 320, bytes: 180000 },
  { name: "pixel.example", ms: 40, bytes: 900 },
  { name: "survey.example", ms: 510, bytes: 42000 },
];
const byTime = [...parties].sort((a, b) => b.ms - a.ms);
const byBytes = [...parties].sort((a, b) => b.bytes - a.bytes);
console.log(byTime[0].name);
console.log(byBytes[0].name);

// Blocking time counts the part of each long task past 50 ms, from the first paint on.
const tasks = [{ start: 1000, duration: 300 }, { start: 2500, duration: 200 }];
const blockingTime = (firstPaint) =>
  tasks.reduce((sum, task) => {
    const from = Math.max(task.start, firstPaint);
    const to = task.start + task.duration;
    return to - from > 50 ? sum + (to - from - 50) : sum;
  }, 0);
console.log(blockingTime(900));
console.log(blockingTime(2000));

Check your understanding

For each question, ask which cost it's about: bytes, main-thread time, or risk.

Key takeaways

• Third parties are code and files from other companies' sites. More than nine in ten pages have them.
• Each one costs bytes, main-thread time and risk. The page's total doesn't say which one costs most.
• Split the cost by site: the Network panel's 3rd-party filter, and the Performance panel's 3rd parties insight.
• Then take one away and compare. On Meera's page, the tag manager cost the most blocking time. The A/B test cost the most time to the photo.
• A tag manager's cost includes every tag it adds. The HTML doesn't show them.
• Third Party Web gives each service's Average Impact, so you can compare before you add one.
• A plain script from a server that never answers kept Asha's screen white for 30 seconds. With async, only the load event waited.

Sources

The facts on this page come from these docs, datasets and source code:

• Third Parties, Web Almanac 2025, HTTP Archive.
• Third-party JavaScript performance, web.dev.
• Network features reference: show only third-party requests, Chrome for Developers.
• NetworkLogView.ts: the 3rd-party filter and Block request domain (Chrome 157), DevTools source.
• Performance features reference: distinguish between first- and third-party events, Chrome for Developers.
• TimelineTreeView.ts: Group by 3rd parties (Chrome 157), DevTools source.
• 3rd parties insight, Chrome for Developers.
• ThirdParties.ts: the 3rd parties insight (Chrome 157), DevTools source.
• third-parties-insight.js (Lighthouse v13.6.0), Lighthouse source.
• Network request blocking: the Request conditions drawer, Chrome for Developers.
• Identify slow third-party JavaScript, web.dev.
• Third Party Web: README, Patrick Hulce.
• Third Party Web: entity scripting data, Patrick Hulce.
• package.json: Lighthouse depends on third-party-web (v13.6.0), Lighthouse source.
• Frontend SPOF, Steve Souders.
• Testing for Frontend SPOF, Patrick Meenan.
• ssl_connect_job.cc: the 30-second TLS handshake limit (Chromium 157.0.8103.52), Chromium source.
• transport_connect_job.cc: the 4-minute connection limit (Chromium 157.0.8103.52), Chromium source.
• HTML Standard: the end of parsing, and the load event, WHATWG.
• The script element: async, MDN.

Coming next: Loading third parties well. You've measured what each tag costs. Next, how to load them so they cost less, or don't load in the browser at all.