The browser does one thing at a time
A browser reads your page from the top down. When it meets an ordinary script tag it stops, fetches the file, runs it, and only then carries on reading. Everything below that point, including your product image, waits its turn. That is the whole reason a page with three widgets in the head feels slow while a page with thirty images feels fine.
Deferring a script changes when it runs, not what it does. The browser still fetches the file, but it keeps parsing the page and runs the script once the document is ready. Nothing visible waits for it.
Where the cost actually lands
Largest Contentful Paint measures the moment the biggest thing above the fold has drawn. A blocking script in the head delays it directly. Move the same script to deferred and LCP usually improves by most of what the script was costing, without changing a single line of what the script does.
Total Blocking Time is a separate number and it does not go away. A deferred script that runs for 400 milliseconds still holds the main thread for 400 milliseconds, it simply does it after the page looks finished. Deferring buys you a page that draws early, not a page with less work in it.
Reserving space so nothing jumps
The failure mode of loading late is layout shift. If a block renders into a container with no height, everything below moves down when it fills in, which is how somebody taps the wrong link. Every block should reserve its own height from the start, whether or not it has anything to show yet.
This is worth watching rather than trusting. Throttle the connection to slow 3G in your browser, reload the product page, and keep your eye on the buy button. If it moves at any point, something above it is late and unreserved.
What to ask of an app
Three questions cover it. Does the script load from the Shopify CDN alongside the theme, or from a third party domain. Is it deferred. Does it render anything above the fold that you did not place there yourself.
An app installed as a theme app extension can answer all three, because the block is in the theme editor and you can see exactly where it sits. An app that writes a script tag into your layout cannot, because it loads on every template whether the page uses it or not.
You can check the answers in two minutes without asking anyone. Open the network panel, filter to scripts, and look for anything that started before your hero image and finished after it. That is the queue your product photo was standing in.
Two things deferring will not fix
A deferred script that fetches its data before it can render still leaves a gap. If a block loads content from an external endpoint after the page is ready, the customer sees an empty reserved space until the response arrives, which is honest but not fast. Anything that matters to the buying decision should arrive with the page rather than after two round trips.
Deferring also does nothing about how many separate requests a page makes. Five deferred scripts from five apps are still five connections competing with your images on a phone on mobile data. That is the real argument for running fewer apps, and it holds even when every one of them is written well.
Something on this page no longer true, or a measurement that disagrees with it? Tell us and we will correct it.
