Motta Industries Blog

Your website probably runs code you did not write. Analytics tags, advertising pixels, chat widgets, review badges, social media embeds, video players, heat-mapping tools, consent banners and booking widgets all load from other companies’ servers. Each one promises something useful. Together, they can quietly make your pages slower, less responsive and harder to maintain.

This guide explains what third-party scripts are, why they affect speed and responsiveness, how to find out which ones are costing you the most and how to decide what to keep, delay or remove.

What counts as a third party

A third party is any resource loaded from a company other than your own. The HTTP Archive’s Web Almanac 2024 chapter on third parties, published in November 2024, defines third-party content as content loaded from a different site than the one the visitor originally visited, and notes that web developers use third parties for features such as advertising, analytics, social media integration, payment processing and content delivery.

The chapter found that third parties are nearly universal. More than nine in ten web pages included one or more third parties, often indirectly, meaning one third party loaded another. It also reported that nearly one-third of third parties on all web pages were used for advertising, analytics and consent management, and concluded that including third parties presents privacy, security and performance implications that web developers should consider.

That indirect loading matters. When you add a single tag, it may load several more scripts from other companies, each with its own requests and processing. Many site owners have no idea how many companies’ code actually runs on their pages.

Why third-party scripts slow your site

Third-party code affects performance in several ways.

More network requests. Each script must be downloaded, often from a different server that requires its own connection.

Main thread work. Browsers use a main thread to run JavaScript, calculate layouts and respond to taps and clicks. When scripts run long tasks on that thread, the page cannot respond to the visitor until the work finishes.

Layout shifts. Widgets, ads and embeds that load late can push content around, causing visitors to tap the wrong thing.

Unpredictability. Third-party providers change their code on their own schedule. A script that was lightweight last year may be heavier today.

Failure risk. If a provider’s server is slow or down, a script loaded in the wrong way can delay your whole page.

Responsiveness and Core Web Vitals

Speed is not only about how quickly a page appears. It is also about how quickly it responds when someone interacts with it. Interaction to Next Paint, usually shortened to INP, measures that responsiveness.

In a January 2024 post announcing that Interaction to Next Paint would become a Core Web Vital on March 12, the Chrome team explained that INP would replace First Input Delay as the responsiveness metric. The post noted that Core Web Vitals are scored based on how well pages perform in the field at the 75th percentile of all page loads, and pointed to PageSpeed Insights and the Chrome User Experience Report as ways to see field data. For sites with poor INP, it recommended optimizing long tasks when JavaScript takes up considerable time on the main thread, watching for excessive script evaluation during page load, optimizing input delay and minimizing DOM size.

Google’s Search team had earlier introduced INP to Core Web Vitals in a May 2023 post, later updated to confirm that INP replaced First Input Delay on March 12, 2024. That post highly recommended that site owners achieve good Core Web Vitals for success with Search and a great user experience, while noting that great page experience involves more than Core Web Vitals and that good scores do not guarantee good rankings.

For business owners, the takeaway is practical: third-party scripts are a common cause of main thread work, and main thread work is a common cause of sluggish responsiveness. Visitors feel it as taps that do nothing, menus that lag and forms that freeze.

Take an inventory

You cannot manage what you have not listed. Start by building a simple inventory of every third-party script on your site.

Check your tag manager. If you use one, review every tag and trigger it contains. Tag managers make it easy to add scripts and easy to forget them. Pause any tag you cannot explain.

Review your plugins and theme settings. Many plugins add third-party code. So do some themes and page builders.

Look at the page itself. Browser developer tools show network requests by domain, which reveals scripts loaded indirectly.

Ask your team. Marketing, sales and support staff often add tools for campaigns or tests and never remove them.

For each script, record what it does, who asked for it, which pages it runs on, whether anyone still uses its data and what it costs in money and performance.

Measure the cost

Once you have a list, measure what each script costs.

• Use field data, such as the Chrome User Experience Report through PageSpeed Insights, to see how real visitors experience your pages.
• Use lab tools to identify long tasks and see which scripts cause them.
• Compare performance with and without a script on a test copy of a page.
• Test on a mid-range phone over a typical mobile connection, not only on a fast office computer.
• Check pages that matter most to your business, such as the homepage, top landing pages, product pages and checkout or contact forms.

Decide: keep, delay, replace or remove

With costs and benefits in front of you, sort each script into one of four groups.

Remove. Tools nobody uses, duplicate analytics, expired campaign pixels and abandoned experiments. These are the easiest wins, and removing them carries little risk.

Replace. Heavy embeds can often be swapped for lighter alternatives. A video embed can show a static preview image and load the player only when someone clicks. A social feed can become a simple link. A heavy font service might be replaced by self-hosted fonts.

Delay. Some scripts are needed but not immediately. Chat widgets, feedback tools and some analytics can load after the main content or after the first interaction.

Keep, carefully. Essential tools such as payment processing, consent management and core analytics stay, but load them efficiently, limit them to the pages that need them and review them regularly.

Loading techniques that help

Your developer can apply several techniques to reduce the impact of the scripts you keep:

• Load scripts asynchronously or deferred, so they do not block the page from rendering.
• Load scripts only on the pages that need them, rather than site-wide.
• Use facades, lightweight stand-ins that load the real widget only on interaction.
• Reserve space for embeds and ads so they do not shift content when they appear.
• Set up resource hints to connect early to essential third-party servers.
• Break up long tasks in your own code so the main thread stays free for interactions.

Good hosting helps too. Fast web hosting with caching and modern protocols speeds up your own files, leaving more room for the third-party code you truly need.

Privacy and security are part of the cost

Performance is not the only reason to keep third parties under control. Every script you load can see information about your visitors and their behavior on your pages, and some collect far more than you expect. A compromised or poorly maintained script can also become a security risk, because it runs with the same access as your own code.

Before adding a tool, ask what data it collects, where that data goes and whether your privacy notice describes it. Check that consent tools actually block non-essential scripts until visitors agree. Fewer third parties means fewer companies handling your visitors’ information and fewer places where something can go wrong.

Set a script policy

The best long-term defense is a simple policy that controls what gets added.

• Every new script needs a named owner and a clear business purpose.
• New tools are tested for performance impact before going live.
• Scripts are added through one controlled process, not by whoever has access.
• Every script has a review date, and unused tools are removed.
• Performance budgets set limits on how much script weight and main thread time pages can carry.

A policy like this keeps the inventory from filling up again a few months after a cleanup.

A fictional example

Consider an invented landscaping company whose website felt sluggish on phones. Taps on the quote button sometimes did nothing for a second or two. An inventory found nineteen third-party scripts: two analytics tools collecting the same data, four advertising pixels from campaigns that had ended, a chat widget, a reviews badge, a social feed, a video embed, a heat-mapping tool nobody had checked in a year, and several scripts loaded indirectly by those tools.

The company removed the duplicate analytics tool, the expired pixels and the heat-mapping tool. It replaced the social feed with a link, switched the video embed to a click-to-load preview and delayed the chat widget until visitors had been on a page for a few seconds. It also limited the reviews badge to the pages where it mattered.

In this fictional scenario, the quote button responded immediately on phones, and the company adopted a rule that any new tool must be approved and tested before going live.

Mobile matters most

Third-party costs are felt most on phones, where processors are slower and connections vary. A script that seems harmless on a desktop computer may cause noticeable delays on a mid-range phone. Combining a lean script setup with responsive designs built for mobile visitors gives most of your audience the fastest experience.

When to get help

Some third-party work is simple, such as deleting unused tags. Other changes, like building facades, restructuring loading order or breaking up long tasks, benefit from experienced web development support. A developer can also set up monitoring so you notice when a provider’s update makes a script heavier.

A quick third-party checklist

• Every third-party script is listed with its purpose, owner and pages.
• Unused, duplicate and expired scripts have been removed.
• Heavy embeds use lighter alternatives or click-to-load previews.
• Non-essential scripts are delayed until after the main content.
• Essential scripts load asynchronously and only where needed.
• Embeds and ads have reserved space to prevent layout shifts.
• Field data and Core Web Vitals are reviewed regularly.
• New scripts require approval and performance testing.

The bottom line

Third-party scripts make it easy to add features, but each one carries a cost in speed, responsiveness, privacy and maintenance. Inventory what runs on your site, measure what it costs, remove what you do not need and load the rest carefully. A short policy keeps the clutter from returning. Your visitors will notice the difference every time they tap.