Among 52 SaaS homepages, the 13 that transferred the least JavaScript recorded a median Total Blocking Time of 49.5 milliseconds. For the 13 that transferred the most, it was 725.5 milliseconds.
That gap makes JavaScript worth investigating when a page feels slow. For a growth leader deciding whether to fund the work, the next question is more specific: what is keeping the browser busy on a page that already matters to the business?
Merge Rocks’ 2026 SaaS website performance and accessibility benchmark examined 60 selected B2B SaaS public marketing homepages in October 2026. The main lab comparison used 52 sites, with a median for each metric from five valid mobile Lighthouse runs per site. The other eight were reported separately because of collection warnings or browser-method exceptions. These were public homepages, not an assessment of the logged-in products or a representative survey of all SaaS websites.
| JavaScript-transfer group | Sites | Median JavaScript transferred | Median Total Blocking Time |
|---|---|---|---|
| Lowest quarter | 13 | 0.28 MB | 49.5 ms |
| Highest quarter | 13 | 3.08 MB | 725.5 ms |
The pattern held beyond the two largest downloads
Pages transferring more JavaScript generally had higher Total Blocking Time. Across the primary 52 sites, the analysis compared how the pages ranked on both measures. The Spearman rank correlation was 0.727.
Leaving out the two sites with the largest JavaScript transfers brought the correlation to 0.722 across the remaining 50. The relationship barely changed. The wider group still showed the pattern, giving teams a reason to examine what happens after the code arrives.
These were different pages, whose content, integrations and implementation could vary. The correlation cannot tell a team how many milliseconds removing code would save. Nor does the lower quarter’s 0.28 MB median establish a download budget for another website.
What the browser does after the download matters
After downloading JavaScript, the browser may still need to read, prepare and run the code. That work can occupy time it also needs to display the page and respond to a visitor.
Google’s Total Blocking Time metric adds up the time beyond 50 milliseconds for each long task during the measured load. Those tasks can include running scripts and rendering the page, so the whole total cannot be attributed to JavaScript.
The 725.5-millisecond group median is an accumulated total, rather than one continuous wait. TBT comes from lab tests. Field Interaction to Next Paint captures responsiveness during real visits.
A performance trace is a recording of what the browser was doing and when. It helps an engineer connect blocking with the work behind it. That could mean examining an essential control, a feature starting before it is needed or code that makes rendering take longer. Removing code, changing when it runs and changing how the page renders address different problems. A download total does not show which of those changes would help.
Commenting on how teams should use the findings, Ihor Ostin, Head of Growth at Merge Rocks, says:
“A large JavaScript download would make me ask for a trace, not approve a rebuild. I want to know which work is delaying the page and whether changing it helps visitors on a page that already brings us business.”
One landing-page experiment made the decision measurable
Ostin describes an earlier project in which he and a founder debated whether performance optimization deserved development time. He led an A/B test of two versions of one landing page, handling the hypothesis, experiment setup and analysis. Developers made the technical changes.
The versions looked and functioned the same. In the optimized version, the developers moved a widget’s rendering to the server, server-rendered critical HTML and improved image loading. The team could evaluate performance work while retaining the existing visible interface.
In that A/B test, the optimized version generated 6% more sales than the baseline, with LCP improving by 26%.
The figures belong to that landing-page experiment. They are not a predicted return from fixing TBT in the 52-site comparison, and the test does not isolate JavaScript removal as the reason for the sales difference.
The business decision followed the result: extend optimization across the site, starting with pages attracting the most traffic and those already generating sales.
A team commissioning front-end development work can bring that level of specificity to its brief: what should change in rendering or loading, and what must stay intact. An engineer can assess those requirements against the existing codebase before estimating the job. The earlier experiment shows why a new visual design need not be part of that scope.
Choose where the next development hour belongs
The largest lab number should not automatically get the first development hour. A team has to weigh the page’s audience and commercial role alongside the technical finding. That is the prioritization judgment a benchmark cannot make for it.
On the selected page, the proposal should identify the browser work being changed and the behavior that must keep working. Before extending the work, check whether the improvement holds across repeated measurements under equivalent conditions and whether the required interactions still work. Assess sales or enquiries separately if a business outcome is part of the hypothesis.
The next investment can then follow a specific result: a change worth testing on another page, or a diagnosis that needs revising before the team commits more time.