Your developer tuned the images and the hosting, your own code is lean, and PageSpeed still shows a long main-thread timeline full of names you half recognise: a chat widget from a trial that ended, a heat-map tool a former marketer installed, two analytics tags, a social pixel, and a tag manager that loads some more. None of them was a bad decision on its own. Together they are the slowest part of the page.
This guide gives you a one-hour audit you can run without a developer and a decision table you can hand to one. By the end you will have a list of every external script, a measured cost for each, and a keep, defer or remove decision with a named owner. If you are not yet sure that scripts are the problem, start with what to fix first on a slow website and the triage tool.
1. Why third-party scripts cost more than their file size
A third-party script is anything your page loads from a domain you do not control: analytics, advertising pixels, chat, embedded video, fonts, A/B testing, review widgets, consent banners. Google's guidance on loading third-party JavaScript lists the ways they hurt: extra connections to extra servers, JavaScript that keeps the main thread busy, blocking of rendering until they finish, and embeds that pull in whole frameworks more than once.
The main-thread cost is the one owners underestimate. The browser has one thread for parsing, running scripts and responding to taps. As of 2026, the Core Web Vitals threshold for responsiveness, Interaction to Next Paint, is 200 ms or less at the 75th percentile of visits; above 500 ms is poor, per web.dev's INP documentation. A chat widget that runs for 300 ms on a mid-range phone does not just delay its own bubble; it delays the menu tap and the form submit that happen to land in the same window.
Do not assume async or defer makes a script free. Those attributes change when it downloads and runs, not how much work it does once it starts.
2. Build the inventory (20 minutes)
Open your homepage and your most important landing page in Chrome, press F12, choose the Network panel, and reload with the cache disabled. Use the "3rd-party requests" filter or sort by domain. For each external domain, write down the service name, what page types it loads on, and who asked for it. Repeat in a private window so that logged-in extensions do not pollute the list.
Then open your tag manager, if you have one, and export the list of active tags. Tags fire on rules that may not trigger on a single reload, so the container's own inventory is the authoritative source for what can run.
| Column | What to record | Why it matters |
|---|---|---|
| Service | Vendor and product name | Owners recognise names, not hostnames |
| Loaded by | Theme, plugin, tag manager, hard-coded | Determines who can remove it |
| Pages | All, landing only, checkout only | Scope of the cost |
| Owner | Person who reads its output | No owner usually means no value |
| Report it feeds | Dashboard, campaign, support queue | Evidence of use |
| Last reviewed | Date | Trials and expired contracts show up here |
Most audits find at least one script whose owner has left the company and one whose contract has lapsed but whose tag still loads. Those are removals before any measurement.
3. Measure each script's cost (25 minutes)
The web.dev guide documents a direct method: in the Network panel, right-click a request and choose Block Request URL, then reload and compare. Do this per domain, not per file, because one vendor often loads several. Record load time and, in the Performance panel, use the Bottom-up view grouped by product to see how much main-thread time each vendor consumes. Turn on network and CPU throttling first; the guide notes that your visitors rarely have the fast connections and desktop hardware that hide expensive scripts in lab conditions.
PageSpeed Insights gives you two shortcuts without any clicking: the "reduce the impact of third-party code" audit lists vendors by main-thread time, and the field data at the top tells you whether real visitors already exceed the INP threshold. Lab timings vary between runs, so take two or three measurements and use the middle one.
Record for each vendor: bytes transferred, main-thread time, and whether the page's layout or interaction changed when it was blocked. A script that costs 400 ms and whose removal changes nothing visible is the clearest case you will find.
Do not run this measurement only on a desktop with a fibre connection. The ranking of culprits can change entirely on a throttled profile.
4. Decide: keep, defer or remove (15 minutes)
With the inventory and the costs side by side, every script fits one of four rows.
| Decision | Criteria | Typical examples | What the developer does |
|---|---|---|---|
| Remove | No owner, no report, expired trial, duplicate of another tool | Second analytics tag, abandoned heat map, old chat trial | Delete the tag or plugin; confirm nothing else depends on it |
| Replace | Needed function, heavy implementation | Embedded video player on every page, hosted font | Facade or thumbnail that loads the embed on click; self-host the font |
| Defer or load on interaction | Real value but not needed before first interaction | Chat, review widgets, survey tools | Load after the page is interactive or when the visitor scrolls to or clicks the element |
| Keep as is | Named owner, measured value, small cost | Core analytics, consent manager, payment provider script on checkout | Confirm it loads only on the pages that need it |
Two cautions. First, a consent manager, where you use one, often has to run early by design and is not a candidate for deferring; what it governs can still be deferred. Second, a payment or fraud script may be contractually required on checkout; scope it to checkout rather than removing it. Legal and contractual obligations vary by jurisdiction and vendor, so confirm them with whoever signed the agreement before deleting anything that touches personal data or payments.
The case against aggressive removal is that some scripts earn their cost. A chat tool that a support team answers within minutes may convert more than the 200 ms it costs. The audit does not decide that for you; it makes the trade visible so that a person with the numbers can.
5. Apply, re-measure and keep the list alive
- Remove everything in the Remove row first, then re-run PageSpeed on the same pages and record the before and after.
- Scope every remaining script to the page types that need it; most tag managers and plugins support page rules.
- Replace heavy embeds with lightweight placeholders that load the real thing on click.
- Move chat and widgets to load after first interaction or on scroll into view.
- If any vendor still dominates main-thread time, ask them for a lighter integration or a server-side option; many have one.
- Record the final inventory with owners and review dates, and add a line to the site's maintenance checklist: no new third-party script without an owner and a listed report.
Fonts deserve a mention because they are the one third party that is usually easy to bring in-house. Our guide to self-hosting fonts shows the 30-minute version of that move. If the page is slow before any script runs, the problem is upstream; see why a site is slow only on the first visit for the hosting side.
Implementation typically takes a developer 1-4 hours, with a CAD 150-600 allowance as an editorial estimate; the audit itself costs nothing but an hour. Expect to repeat it twice a year, because scripts return the way clutter does: one reasonable request at a time.
— Editorial team. Facts current as of 2026; we revise guides when the ground shifts.
Frequently Asked Questions
How many third-party scripts is too many?
There is no fixed number; the cost depends on what each script does on the main thread, not on the count. A single tag manager that loads eight more tags can cost more than five small ones. Measure the page with each script blocked and judge by the change in load time and responsiveness.
Will removing scripts hurt my marketing?
Only if the script was producing data or revenue someone actually uses. The audit asks each owner to name the report or outcome a script feeds. Scripts with no named owner or no named report are the ones to remove first; the ones with real value stay and get loaded more carefully.
Is a tag manager itself a problem?
A tag manager is a convenient way to add scripts without a developer, which is exactly why sites accumulate them. It is not inherently slow, but it hides the inventory. Export its tag list as part of the audit and apply the same keep, defer or remove test to every tag inside it.