JavaScript performance is how quickly a page’s scripts load and run, and how long they block the browser’s main thread. On eCommerce sites, poor performance shows up as laggy filters, slow Add to Cart taps and failing Interaction to Next Paint (INP) scores. Much of that script is third-party.
What is JavaScript performance?
The phrase means two different things. For a developer writing a library, it is about how fast code executes: loop choices, data structures, memory. For an eCommerce team, it is about what all the JavaScript on a page does to the shopper’s experience.
Browsers run JavaScript on the main thread. That same thread handles taps, clicks, scrolling and painting the screen. While a script runs, nothing else on that thread can. Any task over 50 milliseconds counts as a long task, and the shopper feels it as a page that ignores them (web.dev).
So on a storefront, the real question is how many scripts compete for one thread, and when.
Why is JavaScript the bottleneck on eCommerce sites?
The web is running more JavaScript every year, and the lab data shows it. The HTTP Archive Web Almanac 2025 (published January 15, 2026) found median mobile Total Blocking Time rose to 1,916 milliseconds, up 58% from 1,209 milliseconds in 2024. At the 90th percentile, mobile pages carry more than 7.5 seconds of blocking time.
Field responsiveness improved over the same period, which looks like a contradiction. The Almanac’s read is that faster phones are masking heavier code, and that sites are tuning the interactions INP measures while background work keeps growing.
eCommerce pages sit on the wrong side of this. The Almanac found that 69% of mobile secondary pages have good INP, against 80% of home pages, and points to filters, carousels and third-party widgets as the reason. Product and category pages are secondary pages.
Third parties are a large share of the load. Yottaa’s data puts 44% of eCommerce load time on third-party apps: reviews, personalization, BNPL messaging, chat, analytics and tag managers. Every one of them wants the main thread.
The business cost is measurable. In its April 27, 2026 analysis, Shopify found that for every 32 milliseconds slower a store responds to interactions, conversion tends to drop by about 1.5%. Shopify notes this is a correlation and that the INP signal is noisier than load time, but the direction held after controlling for other metrics.
How do you measure JavaScript performance?
Use lab data to find the cause and field data to confirm the effect.
- Lab: Total Blocking Time. Lighthouse and PageSpeed Insights report TBT, the sum of every long task’s time over 50 milliseconds after first contentful paint. It is the best lab proxy for responsiveness.
- Lab: the Performance panel. Record a page load and a few interactions in Chrome DevTools. Long tasks are flagged, and each one traces back to a script URL, which tells you whether it is your code or a vendor’s.
- Lab: the Coverage tab. It shows how much of each downloaded script never runs on that page. High unused percentages on product pages usually point to site-wide tags that only matter on one template.
- Field: INP from real users. Lab tests run one emulated device. INP from real sessions tells you what shoppers on mid-range phones actually felt, on the pages they actually used.
Measure by template, not by site. A homepage score says little about the product detail page where a reviews widget, a size guide and a BNPL message all load at once.
What is a good Total Blocking Time?
A good Total Blocking Time is under 200 milliseconds. The median mobile page is near 1,916 milliseconds, roughly ten times that target (Web Almanac 2025).
TBT is a lab metric and not a Core Web Vital. The Almanac notes that lab TBT and field INP are correlated, so a falling TBT usually predicts better INP. Good INP means 200 milliseconds or less for at least 75% of sessions. Track TBT in your build pipeline and INP in production.
How do you improve JavaScript performance without removing features?
Cutting tools is the easy recommendation and the hard sell. Marketing added each one for a reason. These steps keep the features and give the main thread back.
- Inventory every script and its owner. List what loads on each key template, who requested it, and whether it is still in use. Uninstalled apps often leave code behind.
- Rank scripts by cost on revenue pages. Score each script by the long tasks it causes on product, category and cart pages. Fix the top five first.
- Change when scripts load. Chat can wait for the first interaction. Reviews can load when the shopper scrolls to them. Retargeting pixels can fire after onload. Most third parties do not need to compete with the first tap.
- Break up your own long tasks. For first-party code, split heavy work into smaller chunks and yield to the main thread between them. Minification shrinks file size, but it does little for the time a script spends executing.
- Verify each change with real users. Ship one change at a time, compare INP before and after on the affected template, and keep the field data as proof. A lab score that improves on one run is not proof.
How Yottaa helps
Yottaa’s Rapid platform automates the steps above. It inventories every third party on your site and rates each one with a Performance Index Rating built from 1,000+ characterized applications. RUM Plus correlates browser, edge and origin data so you can trace a slowdown to the vendor script, CDN edge or origin behind it. Application Sequencing then controls when each script loads, with rules like after first interaction, lazy load and after onload, without code changes. Split tests let you prove the impact on a share of traffic before rolling out.
If your product pages are failing INP and nobody can say which script is responsible, talk to Yottaa about a third-party performance review.
FAQ
Does minifying JavaScript improve performance? A little. Minification reduces download and parse size. It does not reduce the work a script does once it runs, which is what blocks the main thread.
What is a good Total Blocking Time? Under 200 milliseconds in a lab test. The median mobile page measured 1,916 milliseconds in the Web Almanac 2025.
Is Total Blocking Time a Core Web Vital? No. The Core Web Vitals are LCP, INP and CLS. TBT is a lab proxy that correlates with INP.
How do you measure JavaScript performance on a live store? Use TBT and the DevTools Performance panel to find long tasks, then confirm with INP from real-user monitoring on each page template.
Subscribe to our blog
Performant Experimentation – A Guide to A/B Testing
Every A/B test you run is a purchase. You’re buying information—an answer to a hypothesis—and you’re paying for it in degraded performance and lost conversion during the test window.
Download eBook
