Reviewed November 9, 2026

Third-Party Scripts Ranked by LCP Cost: The Audit Order That Finds the Worst Offender First

Open the network waterfall, sort third-party scripts by the time they block the main thread before the largest contentful paint, and start with the worst. On most stores one or two scripts, a chat widget, a review widget, a tracking pixel, account for most of the delay. Remove or defer the worst first, and measure LCP again before touching the next one.

The store's LCP is 4.2 seconds. The team compresses images, minifies CSS, and the LCP moves to 4.0. The images were never the problem. The problem is a chat widget that loads before the hero image, a review widget that blocks the main thread for 800 milliseconds, and a tracking pixel that fires three more scripts. The waterfall shows all of it, and nobody looked at it.

Third-party scripts are the largest hidden cost on most storefronts, because they are added one at a time, by different people, for different reasons, and nobody ever removes one. Each script is small. Together they are the page. The audit that finds the worst offender first is the audit that actually moves LCP.

Reading the waterfall

Open the browser's developer tools, load the page with the network tab open, and sort by the time each request blocks rendering. The waterfall shows what loads, in what order, and how long each request holds the main thread. The scripts that load before the largest contentful paint are the ones that matter. The scripts that load after it are not free, but they are not the LCP problem.

The metric to watch is not the script's file size. It is the time the script spends on the main thread: parsing, executing, and the work it triggers, like rendering a widget or fetching more data. A 50 kilobyte script that executes in 50 milliseconds is cheap. A 50 kilobyte script that triggers a widget render and three more network requests is expensive, and the file size will not tell you that.

Rank the third-party scripts by their total blocking time before LCP, worst first. On most stores the list is short: one or two scripts account for most of the delay, and the rest are noise. The chat widget is the usual winner, because it loads early, renders a visible widget, and often pulls in its own fonts and styles. The review widget is second, for the same reasons.

Removing, deferring, or delaying

Removing is the best fix and the one teams resist. A script that no one can name the owner of, that was installed for a campaign that ended months ago, is dead weight. Remove it, measure LCP, and if nothing breaks, it stays removed. The store that audits its scripts quarterly has fewer of them, and the ones it has are the ones someone is responsible for.

Deferring is the second fix. A script with the defer attribute loads after the HTML is parsed, so it does not block rendering. A script with async loads in parallel and executes when ready. For scripts that do not need to run before the page renders, which is most of them, defer is free performance. The chat widget does not need to be interactive before the hero image paints. Defer it.

Delaying is the third fix, for scripts that are needed but not immediately. Load the chat widget after the user scrolls, or after three seconds, or on first interaction. The widget still works. It just stops competing with the hero image for the main thread. The user who needs chat will wait three seconds. The user who does not need chat never pays for it.

The measurement loop

Measure LCP before and after each change, one change at a time. Removing three scripts at once and watching LCP improve tells you nothing about which one mattered, and the next store that copies the fix will remove the wrong one. One change, one measurement, one decision. The loop is slow and it is the only version that produces knowledge instead of luck.

Measure on a real device, or at least a throttled connection. A script that costs 200 milliseconds on a fast office connection costs a second on a mid-range phone on a 4G connection, and the phone is where most shopping happens. The waterfall on a fast connection hides the problem. The waterfall on a slow connection shows it.

Set a budget and enforce it. A total third-party budget, say 500 milliseconds of main thread time before LCP, turns the audit from a one-off project into a rule. A new script that pushes the store over budget needs a justification, not just an install. The budget is what keeps the store fast after the audit ends.

Frequently asked questions

What is the largest contentful paint and why does it matter?

Largest contentful paint, LCP, measures when the largest visible element, usually the hero image or the main heading, finishes rendering. It is the moment the page feels loaded to the user. Google treats an LCP under 2.5 seconds as good, and over 4 seconds as poor. Third-party scripts that run before LCP delay it directly.

How do I find which third-party script is slowing my store?

Open the browser developer tools, load the page with the network tab open, and sort third-party scripts by the time they block the main thread before LCP. Rank them worst first. On most stores one or two scripts account for most of the delay, and the rest are noise.

Should I remove a script if I am not sure what it does?

Find out what it does first. Ask the team, check the install date, and look at what breaks when it is disabled in a staging theme. A script no one can name the owner of, installed for a campaign that ended months ago, is usually safe to remove. Test in staging before removing from the live store.

Is deferring a script the same as removing it?

No. Deferring loads the script after the HTML is parsed, so it does not block rendering, but the script still runs and still costs main thread time. Removing eliminates the cost entirely. Defer the scripts you need, remove the ones you do not, and delay the ones that can wait for user interaction.