Websites often start to feel slow not after changing servers, but after small features are added one by one: customer service chat, analytics, ad pixels, social media widgets, promotional pop-ups, or video embeds. Each seems lightweight when viewed individually. The problem is, the browser has to load and execute everything almost simultaneously.
Third-party JavaScript is code that comes from services or domains outside of our website. This code can help businesses, but it can also increase network requests, CPU usage, parsing time, and work on the main thread—the main path for the browser to process rendering and interactions. As a result, the page may appear to have loaded, but buttons may not be responsive, or users may have to wait before they can scroll comfortably. ([web.dev](https://web.dev/articles/optimizing-content-efficiency-loading-third-party-javascript?hl=en&utm_source=openai))
Why is Third-Party JavaScript Often Overlooked?
Because this code usually does not reside in the website's main repository. The marketing team may install it through Google Tag Manager, plugins may add it automatically, or vendors may request a snippet of code to be placed in the <head> section. After that, the feature is considered complete because it displays correctly.
However, “displaying” is not the same as “being cheap for performance.” A script can call several other domains, download additional files, create new elements, run tracking, or wait for responses from external servers. If one of the services is slow, the impact can be felt on the user experience, even if the main website server is functioning normally.
Google includes LCP, INP, and CLS as Core Web Vitals. LCP measures how quickly the main content appears, INP measures the page's responsiveness to interactions, while CLS measures unexpected layout shifts. Heavy scripts are particularly at risk of worsening INP because long JavaScript tasks can prevent the browser from responding to clicks or taps. ([web.dev](https://web.dev/articles/defining-core-web-vitals-thresholds?hl=en&utm_source=openai))
Start the Audit from a List, Not Assumptions
The first step is not to immediately upgrade the server specifications. Create a list of all external services used by the page, then ask about the function of each.
- Analytics and conversion tracking.
- Chat, chatbots, or ticket systems.
- Ad pixels and remarketing.
- Embedded videos, maps, reviews, or social media.
- A/B testing and personalization tools.
- Fonts, icons, or JavaScript libraries from external CDNs.
For each item, note three things: who owns it, which page needs it, and what the consequences would be if the script were not loaded. Often, scripts that are installed globally are actually only needed on one page, such as a payment script that is loaded on article pages.
Use DevTools to See the Real Costs
Open Chrome DevTools, go to the Network tab, and then reload the page with the cache disabled. Use the JS filter to view JavaScript files, then check the originating domain, transfer size, and loading time.
After that, open the Performance tab and record the process as the page loads. Look for sections that indicate long tasks or long tasks. If there is long-running JavaScript work on the main thread, try to identify whether the source is from the website's main code or from third-party domains.
Lighthouse and PageSpeed Insights can also help identify external scripts that take time. However, lab test results are not representative of all users. Cheap devices, unstable mobile networks, and browsers with slower CPUs may feel a greater impact. Therefore, compare lab results with real user data if available. ([web.dev](https://web.dev/articles/optimizing-content-efficiency-loading-third-party-javascript?hl=en&utm_source=openai))
Four Ways to Reduce the Impact
1. Remove Scripts That Are No Longer Valuable
This is often the most effective optimization. Check installed scripts for old campaigns, unused widgets, or services that are only retained because “who knows, it might still be needed.” Every script has maintenance costs, privacy risks, and potential disruptions.
Don’t just ask, “Does this feature look good?” Also ask, “Does this feature provide measurable value?” If there is no clear benefit, removing it is better than continuing to try to work around it.
2. Don’t Load All Scripts on All Pages
A chat script may be important on product pages, but it may not be necessary on documentation pages. Video embeds should only be loaded on articles that display them. Certain pixels can also be limited to relevant campaign pages.
This separation can be done through templates, tag manager rules, or conditions on the server side. The goal is simple: users only pay the performance cost for features they actually use.
3. Use async and defer for the Right Reasons
The async attribute allows scripts to be downloaded without blocking HTML parsing, but the scripts will run as soon as they finish downloading. The execution order is not guaranteed.
Meanwhile, defer also downloads scripts in parallel but waits until HTML parsing is complete and maintains the execution order. For scripts that are not needed for the initial content to display, defer is often the more predictable choice. Google recommends using async or defer for third-party scripts unless they are indeed on the critical rendering path. ([web.dev](https://web.dev/articles/efficiently-load-third-party-javascript?utm_source=openai))
<script src="https://example-vendor.com/widget.js" defer></script>However, adding these attributes is not an automatic guarantee. Scripts that run after the page appears can still consume CPU and disrupt interactions. Measure again after changes.
4. Delay Heavy Features Until They Are Really Needed
For chat, video, or maps, consider a facade pattern: display a lightweight image or button first, then load the actual service after the user clicks it. This approach reduces initial workload without eliminating the feature.
For services that are far down the screen, lazy loading can also help. But ensure that the element's space is defined from the start so that loading does not cause layout shifts. Third-party embeds without fixed sizes can worsen CLS. ([web.dev](https://web.dev/articles/embed-best-practices?hl=en&utm_source=openai))
What Does This Mean for Us?
Performance is not just a developer or hosting issue. Business decisions—such as adding marketing tools, pop-ups, conversion trackers, and external widgets—also determine how fast a website feels to visitors.
Therefore, every feature request should have a “performance budget.” Before installation, determine which pages need it, when the script is loaded, what metrics are monitored, and when the service will be re-evaluated.
What You Can Do Now
- Create an inventory of all external scripts and embeds.
- Remove services that do not have measurable functions.
- Limit scripts to only the pages that need them.
- Test the use of
async,defer, or loading after interaction. - Compare INP, LCP, and response times before and after changes.
- Test with realistic devices and networks, not just developer computers.
A fast website does not mean it lacks features. The principle is to load features at the right time, on the right pages, and with justifiable costs.
Sources & Further Reading
- Efficiently load third-party JavaScript
- Load Third-Party JavaScript
- Optimize Interaction to Next Paint
- How the Core Web Vitals metrics thresholds were defined
- Best practices for using third-party embeds
– Rio Yotto @rioyotto