The storefront got slower and nobody on your team shipped any code

Nobody deployed anything and the product page is 600 milliseconds slower than it was a month ago. That combination is not mysterious — it is the signature of a change made outside the release process. Someone installed an app, published a tag, or a vendor pushed a new bundle behind a URL that never changed. All 3 happen without a pull request and none of them appears in your deployment log.

The mistake that follows is measuring the wrong thing. A performance score tells you the page got slower, which you already knew. What you need is the name of the script, and that comes from comparing 2 request waterfalls rather than 2 numbers.

Diff the waterfall, not the score

The capture has to be controlled, because page performance is noisy enough to hide the effect you are hunting. Fix the profile, then change exactly one thing.

1. Pick one product page and one throttled profile — a mid-range mobile CPU multiplier and a constrained network — and use it for every run. A laptop on office wifi cannot see this problem at all.
2. Run the page 5 times and take the median. A single run will move by more than the regression you are chasing.
3. Repeat with every third-party origin blocked at the request level. Most browser developer tools can block by domain pattern; a proxy works too.
4. Diff the 2 waterfalls by request, not by score: which hosts appear, how many requests each made, transferred bytes per host, and where each one sits relative to the largest element.
5. Then unblock origins one at a time and re-run. Bisecting by origin is slower than reading a vendor list and it is the only method that produces a name you can act on.
6. Record main-thread time per script as well as bytes. A 30 KB script that parses JSON on the main thread can cost more than a 200 KB image.

Attribute to a script, not to a category

'Reviews are slow' is not a finding. 'The review widget's loader pulls a second bundle from a different host, and both run before the hero image is requested' is a finding, because it can be fixed 3 ways and only 1 of them involves removing reviews from the page.

• Count hosts, not vendors. One app commonly loads from 2 or 3 domains, and blocking only the obvious one produces a diff that says the app is innocent.
• Watch for chained loads. A loader that fetches a config file that fetches a bundle serialises 3 round trips before any work starts, and each hop is a full network latency on a mobile connection.
• Note whether the script is in the document head and synchronous. That single property usually explains more than the file itself.
• Check whether it writes to the page. A script that injects markup or edits prices is doing rendering work, which is why deferring it changes what the shopper sees rather than only when they see it.

Four ways a storefront slows with nobody shipping

The third row is the one that survives every audit, because there is nothing new to notice. The script URL is identical to the one that was reviewed 6 months ago and the bytes behind it have doubled. The only defence is a recorded history: log transferred size and a content hash per third-party path weekly, and alert on change. That is a small standing job rather than an investigation, which is exactly the kind of thing that belongs in internal tools and operations software instead of a quarterly panic.

A stable URL is not a stable script. The path was reviewed six months ago; the bytes behind it were not.

The governance rule: what may load before the product image

Most of the argument disappears once a storefront has a written answer to one question: what is allowed to execute before the largest element on the page has been requested? Without that rule, every vendor's installation guide says 'paste this in the head', and every one of them is obeyed.

1. Nothing third-party goes in the critical path by default. Every tag is deferred or asynchronous unless it appears on a written exception list with a named owner.
2. The exception list is short and each entry states what breaks if it is deferred. If nobody can say what breaks, it is not an exception.
3. Set a ceiling on third-party JavaScript for the page and enforce it in the build or in monitoring, not in a document. A page-level budget makes the trade explicit — this is the allocation exercise in the performance budget a product page is built against.
4. Every script gets an owner, a business reason and a removal condition at install time. Most storefronts carry tags for tools nobody has used in a year, and the removal condition is the only thing that ever gets them off the page.
5. Review the host list monthly against the previous capture, and treat a new host as a change requiring the same approval as a code change. Doing that during peak trading needs the graded release approach in shipping storefront changes during peak trading.

One measurement caveat is worth stating plainly: the published thresholds for the field metrics people quote — largest contentful paint, interaction latency — are periodically revised, and the definitions themselves have changed more than once. Check the current definition against the source rather than against a number remembered from an article, this one included. What does not change is the ordering: a script that blocks paint is worse than one that does not, at any threshold.

The scripts that genuinely cannot be deferred

An honest audit ends with a short list of things that have to run early, and pretending otherwise produces a fast page with broken features. Four categories recur.

• Consent tooling. It has to run before whatever it gates, so it is early by construction. What you can control is its size and whether it fetches its configuration from a second host.
• Anti-flicker snippets for experimentation. They hide content until the variant is known, which is the entire point. Cap the timeout aggressively and accept that some shoppers see the default.
• Anything that renders content above the fold. A widget that draws the availability badge or a price is a rendering dependency, not a decoration — and deferring it makes the page show a value that is briefly wrong, which is the same class of problem as the in-stock badge that is a cached lie.
• Market and currency resolution. A geo script that redirects or rewrites prices has to settle before the shopper reads the page, and doing it in the browser creates the routing conflicts traced in shoppers landing on the wrong country's storefront.

The last 2 have a better answer than tuning: move the work to the server. Prices that must differ per account can be rendered as an authenticated fragment rather than patched in by a script — the split described in rendering contract pricing without leaking it — and market resolution belongs in routing rather than in JavaScript. Both changes remove a blocking script instead of scheduling it better.

There is a second reason to prefer server-rendered values. Clients that do not execute your scripts — crawlers, feed readers, shopping agents — see only what the server sent, so a price or an availability injected in the browser does not exist for them. That is one route to a store quoting 2 different numbers on 2 different surfaces, alongside the agent-side version examined in the agent's total and your total disagreeing.

None of this is a one-off clean-up. Scripts accumulate because installing one is easy and removing one requires knowing why it is there, which is a storefront architecture governance problem more than a technical one, and it sits alongside the rest of the decisions in retail and e-commerce software.

• performance
• third-party scripts
• storefront architecture
• governance