Third-Party Scripts, When Most of the Page Is Not Yours
More than half of what a visitor downloads never touches your server. Analytics, an image host, a chat widget, a font, a video embed. Every one of those third-party bytes is counted, and the total is what the report measures.
When the outside hosts supply more than half the page’s total weight, the report raises a finding called third-party scripts dominate page weight. The card names the share, the number of external requests, and the three heaviest hosts by name.
This is the one performance flag that moves the score on its own. Most of the others in that section describe a pattern and leave the score untouched.
The one performance flag that moves the score
The performance score is built from credit the Core Web Vitals earn in a real browser. A page that paints quickly and answers taps collects that credit, and a page that does not simply never adds it.
Two things sit outside that credit and adjust it directly. Modern image formats add four points. This finding works the other way, and when the outside share passes half the page, the score falls by four points.
It reads the worse of your two devices, not the average. A site that measures 95 percent on desktop and 75 percent on mobile is judged on the 95, which is why the desktop and mobile tabs can disagree about the same page.
An expiring certificate is the only other finding that behaves this way. Everything else in the performance and security sections is a missing credit rather than a real reduction. A low score with this flag is a measured weight problem, not a stack of absent headers.
What counts as a third-party host
The measurement is by host, not by file type. Any request that does not come from your own domain or a subdomain of it counts toward the share. That includes images, fonts, video, stylesheets, and scripts alike.
So the finding is titled around scripts but the number is broader than that. A page with barely any JavaScript can still trip it, because the weight is coming from an image delivery host or a font served off somebody else’s domain.
That is why the card names three hosts rather than three files. It is answering a question about where your page’s weight physically lives, not a question about how much code you wrote.
Finding out who is actually on the page
Start with the card. The three hosts it names are already sorted by weight, so the biggest offender is the first one you read. Often one host is carrying most of the problem.
The waterfall in the same report lists every request with its host and size, which is where you go when the top three are not the whole story. Sorting that list by weight shows the long tail of small tags that add up.
A tag manager is usually the single largest source, because one container can inject many tags and the page source rarely shows which tool added what. The container loads, then it decides what else to fetch.
Plugins are the other common source on a WordPress site. Each one can reach out to its own service for updates, fonts, or icons, and deactivating the ones nothing uses is the fastest way to find out which.
Third-party share on one real report, both devices
| Device | Share of bytes from other hosts | External requests | Heaviest three hosts |
|---|---|---|---|
| Desktop | 95.1% | 47 | 821KB, 604KB, 175KB |
| Mobile | 75.4% | 43 | 856KB, 264KB, 194KB |
Those two rows come from the same report on the same day, and they disagree by twenty points. The heavier assets load on the wider screen, the mobile run fetches fewer of them, and the score takes the worse of the two.
Tags that can wait until someone needs them
Mark the non-essential ones async. Analytics and marketing tags do not need to run before the page is readable. Adding async or defer to the script tag lets the browser fetch it in the background instead of stopping for it.
Hold the heavy ones until there is a sign of life. A chat widget, a consent banner, a map, a social embed. None of them is needed in the first second, and all of them can wait for a scroll, a tap, or a mouse move before they load.
Optimisation plugins expose this as a delay JavaScript setting, and LiteSpeed hosts usually expose the same thing inside the cache plugin that ships with the hosting. Switch on one delay at a time and check that the feature still works when it is finally needed.
Delete the tags nobody uses. An old pixel from a campaign that ended, a second analytics install from a previous developer, a heatmap tool nobody has opened in a year. These are pure subtraction, and they cost nothing to remove.
On a WordPress site, the tag was pasted somewhere specific. The theme header, a plugin’s own settings box, or the tag manager container. Finding where it lives is most of the work, and the answer decides who can remove it.
Give the developers the last two routes. Fonts can be served from your own domain instead of a font service, which removes a host and a connection. An edge tag runner can execute third-party tags at the CDN edge rather than in the visitor’s browser.
The guidance on loading third-party JavaScript from the Chrome team goes further into measuring what a tag costs and the ways to load one without holding up the page.
Making the share come down
Run a fresh test once each change is in place. The card prints the new share and the new request count, so the movement shows up in numbers rather than in a hunch.
Watch the share rather than the request count. Twenty small tags can weigh less than one large one, and chasing the count alone can send you after the wrong thing entirely.
If the script pile is the part you want to attack, the guide to reducing the number of script files takes the inventory view, and the page weight guide covers the total. The report-reading walkthrough covers the waterfall columns in detail if those are new to you.
Nobody reaches zero, and nobody needs to. Analytics and a chat widget are legitimate things to run. The aim is a page where the heaviest outside hosts are the ones actually earning their place.
