Websites are getting heavier and heavier. This is a fact, regularly highlighted by numerical reports and illustrated by those from Web Almanac. In 10 years, the weight of a page's resources has multiplied by 4 on Desktop, and by almost 10 on mobile.
For nearly 10 years, this constant increase in page weight was mainly linked to images, which were getting larger despite the widespread adoption of responsive features and progressive enhancement/graceful degradation (picture element, srcset attribute...). JavaScript, on the other hand, changed little, and you could find jQuery + a few plugins and Google Analytics almost everywhere. Period.
Why is third-party JavaScript weighing more and more?
Because the nature of page weight has changed. For ten years, the increase came from images; it now comes from JavaScript, and mainly from third-party JavaScript: marketing tools, analytics, A/B tests, chat, consent management. These scripts are added without ever being removed, as each team's needs evolve.
In the minds of many (developers, web agencies, publishers...), it was estimated as early as 2015 that JavaScript was THE solution to take websites to the next level in terms of User Experience. JS frameworks have become widespread, SPAs (for "Single Page Apps") using React and Angular have become THE new must-have, PWAs have been featured on web marketing blogs... In short, JavaScript has become essential for any self-respecting website publisher.
In parallel, we started using Tag Managers to add advanced website features for traffic monitoring (Google Analytics…), advertising/social retargeting (Facebook…), Voice of Customer (Zendesk…), A/B testing (AB Tasty…), behavioral analysis (Hotjar…), accessibility improvement (AccessiBe), anti-bot Captcha (Recaptcha…). And that was without counting on the arrival of CMP platforms (for “Consent Management Platform”), made essential by the GDPR and also built 95% on a JavaScript base to interact with cookies (see our CMP comparison).
Is your site as fast as your visitors expect?
What is the impact of third-party scripts on performance?
Their cost far exceeds their weight. A third-party script must be downloaded, parsed, compiled, and then executed on the main thread, the very thread that displays the page and responds to clicks. It is the execution time that degrades the INP, much more than the kilobytes transferred.
This proliferation of third-party JS is also often associated with a poor understanding/management of the issues. Very often, our clients load 2 or even 3 GoogleTagManagers or Google Analytics to access data internally while allowing their service providers (web or SEO agency) to view the data. However, a simple GTM configuration allows sending data to multiple Google Analytics accounts.
Other pitfalls are unfortunately just as common:
- Poor CMP configuration, with third-party scripts loading even without user consent (making it useless);
- Presence of an A/B testing script while no test is running, which heavily penalizes loading times for no reason;
- Presence of Facebook, TikTok, or other retargeting scripts while no advertising campaign is running;
- Poor loading prioritization, with third-party scripts sometimes loading before scripts necessary for the site's functionality.
How to reduce the impact of third-party scripts?
Three actions in order: remove what is no longer needed, defer what is not necessary for the first screen, and load on interaction what is only useful after an action. The first action is by far the most profitable, and it's the one we almost always skip.
JavaScript is evil! This statement, intentionally a bit exaggerated, at least puts priorities into perspective: the more third-party JavaScript on a site, the worse the User Experience will be. Why? Because these scripts generate “Blocking Time,” which makes interfaces less responsive and usable (lags, freezes, inability to interact…). This experience is materialized by TBT (for “Total Blocking Time”) in performance analysis tools like Lighthouse and PageSpeed Insights, and under the acronym INP (for “Interaction to Next Paint”) within Google’s Core Web Vitals.
Too much JavaScript, therefore, penalizes not only your visitors but also your "Page Experience" as Google perceives and takes it into account. Knowing that this data is now an integral part of Google's ranking algorithm on mobile AND desktop, it seems wise to pay the utmost attention to it: if you want to maximize your chances of being visible in Google's search results pages (the famous SERPs), this is a project to undertake!
How to measure the real cost of a third-party script?
Three figures are enough to qualify a script: its transferred weight, its execution time on the main thread, and the number of additional connections it opens. The second is the most determining and the least observed, even though it can be read directly in the Performance tab of the developer tools.
The method takes a few minutes. Open the Performance panel, record a load, then sort activity by origin: each third-party domain appears with its cumulative parsing and execution time. A 40 KB script can cost more than a much heavier script, depending on what it does once loaded.
The decisive test remains the comparison with and without. Block the script's domain in the developer tools, reload, and note the difference in LCP and total blocking time. The resulting figure is the one to present to the team that requested the tool, as it transforms a debate of opinion into a documented arbitration.
Should all third-party scripts be removed?
No, and asking the question that way leads to a dead end. An audience analysis tool, a payment system, or an internal search engine provide a service that the site cannot produce on its own. The useful question is about the value-to-cost ratio, script by script, not about their wholesale removal.
Three cases are clearly distinguished. Scripts essential for operation are kept and optimized; those whose value is real but deferrable are loaded after the first screen or on interaction; those whose data is no longer requested are removed. The third case often represents a third of the scripts present on an old site.
The inventory is the prerequisite that is almost always missing. Listing the third-party domains called by the homepage takes ten minutes and systematically produces surprises: tools from a completed campaign, measurement duplicates, scripts from a provider whose contract has ended. Each continues to run for all your visitors.
How to govern third-party scripts over time?
By treating each addition as an expense subject to arbitration: who requests it, for what purpose, for how long, and who verifies that it is still useful. Without a named owner, a script is never removed, because no one takes the risk of disabling what they did not install.
At Agence Web Performance, we deal with these third-party script management issues daily. As part of our audits and optimizations, re-prioritizing the loading of these resources is always a crucial step (if they cannot simply be removed). Fortunately, there are indeed techniques to reduce their impact on user experience, notably through the HTML attributes "async", "defer", but not only. It may also be relevant to delay the execution of these scripts, whose loading is transparent to the user, until the first interaction (hover, scroll, click...).
If you are experiencing these types of issues on your site (unresponsive interfaces, high bounce rates…), do not hesitate to contact us. We master techniques for improving the performance of your pages, on the JavaScript side of course, but much more! Carrying out this type of project on an existing site can multiply the PageSpeed Insights score by 2.5 on average, and the difference is all the more appreciable the slower the site was initially. If this is your case, do not lose hope: take action 😉
