Introduction
Third-Party Scripts and Core Web Vitals are closely connected because external code can consume processing time, delay important resources, and introduce unexpected layout changes. Analytics tools, advertising scripts, chat widgets, tag managers, video embeds, and social media integrations can affect Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) in different ways. Auditing script behavior, removing unnecessary integrations, and loading essential resources strategically can reduce their performance impact without sacrificing important functionality. A website can have optimized images, efficient CSS, a fast server, and carefully written JavaScript—and still perform poorly.
One reason is code that the website does not actually own.
Analytics platforms, advertising systems, chat widgets, social embeds, tag managers, A/B testing tools, video players, consent platforms, and marketing services can all add resources to a page.
Each service may seem small on its own.
Together, they can create a surprisingly large performance cost.
Third-party code can increase network activity, consume CPU time, compete for bandwidth, delay important resources, and sometimes change the page after it has already started rendering.
That can affect Core Web Vitals.
The solution is not to remove every external service. Many third-party tools serve legitimate business, measurement, accessibility, advertising, or functionality requirements.
The better question is:
Does this third-party resource need to load, when does it need to load, and how much work does it make the browser perform?
Quick Answer
Third-party scripts can affect Core Web Vitals by:
- Competing with important resources for network bandwidth
- Delaying discovery or loading of critical content
- Consuming main-thread time
- Triggering layout changes
- Adding JavaScript execution during interactions
- Loading additional resources after the initial request
- Increasing page weight and request count
To reduce their impact:
- Inventory every third-party resource.
- Remove services the site no longer needs.
- Avoid loading third-party code globally when only a few pages require it.
- Delay non-critical scripts where practical.
- Load functionality only after the user needs it when appropriate.
- Reduce unnecessary tags inside tag managers.
- Optimize advertising and embed loading.
- Review chat and customer-support widgets.
- Be careful with excessive preloading.
- Test both lab performance and real-user Core Web Vitals.
The objective is not zero third-party scripts.
It is to prevent optional external code from competing with the resources and processing needed for the user’s primary experience.
What Counts as a Third-Party Script?
A third-party resource is generally a resource that comes from a different origin than the website itself and is controlled by another provider.
Examples include:
- Analytics
- Advertising
- Tag-management systems
- Chat widgets
- Social media widgets
- Video players
- Maps
- A/B testing platforms
- Heatmaps
- Customer-support tools
- Marketing automation
- Consent-management platforms
- Payment services
- Recommendation engines
Some third-party services load JavaScript directly.
Others load a small initial script that then requests additional scripts, images, stylesheets, or data.
That second category can make the real cost harder to see.
A script that appears to be only a few kilobytes in the HTML may ultimately trigger a much larger chain of activity.
Why Third-Party Code Is Different
You have much less control over external code.
With first-party JavaScript, your development team can usually:
- Remove unnecessary code
- Change the implementation
- Split bundles
- Reduce execution
- Change loading behavior
With a third-party service, you may only control:
- Whether it loads
- Where it loads
- When it loads
- Which pages use it
- Which features are enabled
The provider controls much of what happens after the script is requested.
That makes resource selection and loading strategy especially important.
How Third-Party Scripts Affect LCP
Largest Contentful Paint measures how quickly the largest visible content element is rendered.
Third-party code can interfere with this process in several ways.
Competing for bandwidth
Imagine the browser is trying to download the main image for an article.
At the same time, several third-party scripts request JavaScript and other resources.
The network connection is shared.
The more unnecessary resources competing for bandwidth, the less efficiently important resources may be delivered.
This does not mean every third-party request automatically delays LCP.
The effect depends on resource priority, connection conditions, timing, and what the page’s LCP element actually is.
Competing for main-thread time
Even after a script downloads, it may need to be parsed and executed.
If it performs substantial work while the page is trying to render, it can consume CPU time that could otherwise be used for rendering.
Triggering additional requests
A third-party script may load other resources after initialization.
The result can be a chain like:
Page
↓
Third-party loader
↓
Additional JavaScript
↓
Configuration request
↓
Tracking request
↓
Additional resources
The network waterfall may therefore look very different from the handful of script tags visible in the page source.
How Third-Party Scripts Affect INP
INP is particularly sensitive to main-thread availability.
Suppose a visitor clicks a navigation button while a third-party script is executing an expensive task.
The browser may not be able to process the interaction immediately.
The visitor sees a delayed response even though the navigation code itself is lightweight.
This is one reason third-party JavaScript deserves attention when investigating poor INP.
Potential sources include:
- Analytics processing
- Advertising scripts
- Tag-management code
- Chat interfaces
- A/B testing
- Heatmaps
- Social widgets
The issue is not simply that these services use JavaScript.
The problem is when and how much work they perform.
How Third-Party Code Can Affect CLS
Third-party content can also cause layout instability.
For example, an external component might insert content after the initial layout has been established.
Potential examples include:
- Advertising slots
- Embedded social posts
- Recommendation widgets
- Chat interfaces
- Video players
- Promotional banners
- Consent interfaces
If content appears without adequate space being reserved, surrounding content may move.
That movement can contribute to CLS.
The solution is often to reserve the expected space or use a layout strategy that prevents late-arriving content from unexpectedly pushing existing content around.
Not every dynamic change causes a CLS problem. User-initiated changes are treated differently from unexpected layout shifts.
Advertising and Core Web Vitals
Advertising deserves separate attention because ad systems can involve multiple resources and dynamic content.
An advertising request may involve:
- Ad scripts
- Auction or selection processes
- Network requests
- Creative assets
- Tracking
- Measurement
- Dynamic rendering
The performance impact depends heavily on the implementation.
Reserve space for ads
If an ad slot changes the page’s layout after content has already appeared, it can contribute to visual instability.
Defining an appropriate slot size can help prevent unexpected movement.
Avoid loading unnecessary ad functionality
Not every page necessarily needs identical advertising behavior.
Review whether ads are being requested:
- On every page
- In locations users never reach
- At sizes that do not fit the layout
- Before critical content
- Multiple times when fewer placements would be sufficient
The goal is not simply fewer ads.
It is a more efficient relationship between monetization and page performance.
Analytics: Necessary Does Not Mean Free
Analytics is often treated as harmless because the scripts are relatively small.
But analytics systems still consume resources.
Depending on the implementation, they can:
- Download JavaScript
- Execute code
- Listen for events
- Collect information
- Send network requests
- Trigger additional tags
A useful analytics setup should measure what the business actually needs.
If multiple analytics systems are collecting the same information, reconsider whether all of them are necessary.
The question should be:
What information do we need, and what is the smallest reasonable implementation that gives us it?
Tag Managers Can Multiply Third-Party Cost
A tag manager can make it easy to add marketing and analytics services without changing the site’s core code.
That convenience can create another problem.
Over time, a tag container can accumulate:
- Old analytics tags
- Duplicate tracking
- Advertising tags
- Heatmap tools
- Marketing pixels
- Testing tools
- Tags belonging to campaigns that ended months ago
The website may continue loading code nobody remembers adding.
Audit tag-manager configurations regularly.
For each tag, ask:
- Is it still needed?
- Who owns it?
- What data does it collect?
- On which pages does it need to run?
- Does it need to run immediately?
- Can it be triggered later?
- Is another tag already providing the same function?
Removing an obsolete tag can be a better optimization than trying to make the tag load 20% faster.
Chat Widgets Can Be Expensive
Live-chat and customer-support tools can be useful, but they may load:
- JavaScript
- Styles
- Fonts
- Icons
- Network connections
- Additional application code
If the chat widget is not needed immediately, consider whether it can initialize later.
For example, a business might not need chat functionality before the visitor has had an opportunity to read the page.
Possible strategies include:
- Delayed initialization
- Loading after user interaction
- Loading only on relevant pages
- Showing a lightweight launcher before initializing the full application
The correct strategy depends on the business requirement.
If immediate chat availability is essential, delaying it may not be appropriate.
Social Embeds and Video
Social posts, maps, and video embeds can introduce substantial external resources.
A common example is a video embed that loads an entire external player before the user has pressed play.
A lighter strategy may be to show a preview image and load the full player only when the visitor interacts.
This is sometimes called a facade approach.
Conceptually:
Initial page
↓
Lightweight preview
↓
User clicks
↓
Full third-party player loads
This can prevent a large external application from becoming part of the initial page load when the user may never use it.
The same principle can apply to some maps and other interactive embeds.
Load Third-Party Scripts Only Where They Are Needed
One of the simplest improvements is often overlooked.
A service that is needed on one page does not necessarily belong on every page.
For example:
- Chat might be needed only on sales pages.
- A booking widget might be needed only on a contact page.
- A video player might be needed only on selected articles.
- A review widget might be needed only on product pages.
Loading these globally increases the cost of pages that never use the functionality.
Page-specific loading can reduce unnecessary requests and execution.
Delay Non-Critical Third-Party Code
Some third-party functionality does not need to run before the main content becomes usable.
Depending on the service, possible triggers include:
- After initial rendering
- After the page becomes idle
- After user interaction
- When the feature enters the viewport
- After consent is granted
- Only when a relevant component is used
There is no universal “delay everything by five seconds” rule.
An arbitrary delay can introduce other problems.
The loading strategy should match the purpose of the service.
For example, delaying an analytics event too aggressively may affect measurement. Delaying a payment component until after the user needs it may be perfectly reasonable.
Do Not Use async as a Universal Fix
Third-party scripts are often changed from normal loading to async.
That can prevent parser blocking, but it does not make the script free.
The browser still has to:
- Download it
- Parse it
- Execute it
- Perform whatever work it contains
A third-party script loaded asynchronously can still consume substantial main-thread time.
So the question should not stop at:
“Is this script async?”
Ask:
“Does this script need to run during the initial experience at all?”
Sometimes removing or delaying a script is more effective than simply changing its loading attribute.
Be Careful With defer
defer can be useful for suitable first-party scripts and some third-party resources, but it does not automatically solve third-party performance problems.
A deferred script still executes after parsing.
If it performs expensive work immediately after parsing, the browser can still experience substantial main-thread activity.
Loading later is helpful only when “later” is actually acceptable for the functionality.
Preconnect: Useful but Easy to Overuse
If a critical third-party origin must be contacted early, connection hints such as preconnect can sometimes reduce connection setup time.
For example:
<link rel=”preconnect” href=”https://example-third-party.com”>
But adding preconnect hints for every external domain is not a performance strategy.
Each connection has costs.
Prioritize origins that are genuinely important to the initial page experience.
If a third-party resource can safely load much later, establishing a connection to it early may accomplish little.
Third-Party Scripts and Mobile Performance
Third-party code can be particularly noticeable on mobile devices.
The problem is not just network speed.
Mobile devices may have less processing capacity available for JavaScript execution.
A script that seems harmless on a fast desktop can become much more noticeable on a lower-powered phone.
When testing third-party performance, consider:
- Mobile CPU
- Mobile network conditions
- Number of third-party requests
- JavaScript execution time
- Main-thread blocking
- Interaction responsiveness
Do not judge performance exclusively from a high-end desktop.
How to Audit Third-Party Scripts
Start with the actual page.
Open Chrome DevTools and inspect the Network panel.
Group or filter requests by domain.
You may discover that a page you thought used five external services actually contacts fifteen different domains.
Create an inventory.
| Third-party service | Purpose | Pages needed | Initial load required? | Action |
| Analytics | Measurement | Most pages | Maybe | Review |
| Chat | Support | Selected pages | Usually not | Delay |
| Video | Content | Selected pages | No | Facade |
| Ads | Monetization | Content pages | Depends | Optimize |
| Heatmap | UX analysis | Selected pages | Usually not | Review |
| Social embed | Content | Selected pages | No | Lazy load |
The exact decisions depend on your site.
The table is a decision framework, not a universal configuration.
Use the Performance Panel for INP Investigation
The Network panel tells you what was downloaded.
The Performance panel helps you understand what happened after those resources arrived.
Record the page and perform the interaction that feels slow.
Then look for:
- Long JavaScript tasks
- Third-party script execution
- Event handlers
- Style recalculation
- Layout
- Rendering
- Other work occurring around the interaction
If a third-party script occupies the main thread at the same time as the user’s interaction, you have a much stronger lead than simply seeing the script listed in a PageSpeed report.
What PageSpeed Insights Can and Cannot Tell You
PageSpeed Insights can identify third-party resources and provide performance diagnostics.
But a report does not automatically tell you:
“Delete this script.”
A third-party resource might be necessary.
Another might be delaying an important resource.
Another might have negligible impact.
Another may be responsible for substantial main-thread work.
The report should therefore be treated as evidence for investigation.
Use the audit to identify candidates, then inspect the page and its business requirements before changing the implementation.
Lab Data vs Real-User Data
Third-party scripts can behave differently across testing environments.
A lab test provides a controlled environment that is useful for diagnosing resource loading and execution.
Field data shows how real users experience the page across different:
- Devices
- Networks
- Locations
- Browsers
- Connection conditions
A third-party service may have a small impact in one lab test and a much larger effect for certain real-user groups.
This is why Core Web Vitals should be evaluated using both laboratory diagnostics and field data when available.
Lab data helps explain the mechanism.
Field data tells you whether users are actually experiencing the problem at scale.
Should You Remove All Third-Party Scripts?
No.
Third-party code exists because websites need functionality that would be expensive or impractical to build internally.
The right question is whether the benefit justifies the performance cost.
A useful classification is:
Keep
Essential functionality that users or the business genuinely require.
Optimize
Necessary services whose loading or implementation can be improved.
Delay
Useful functionality that does not need to participate in the initial experience.
Conditional load
Services needed only on certain pages or after certain actions.
Remove
Services that are obsolete, duplicated, rarely used, or no longer provide enough value.
This is a more useful strategy than attempting to achieve an arbitrary number of third-party requests.
A Practical Third-Party Performance Workflow
Step 1: Inventory
List every external domain and service used by the page.
Step 2: Identify ownership
Determine what each service does and who requested it.
Step 3: Establish necessity
Ask whether the functionality is still needed.
Step 4: Check page scope
Determine whether the service needs to load on every page.
Step 5: Determine timing
Ask whether it needs to run during the initial page experience.
Step 6: Measure cost
Check transfer size, request count, execution time, and main-thread activity.
Step 7: Choose an action
Keep, optimize, delay, conditionally load, or remove.
Step 8: Test functionality
Make sure analytics, advertising, forms, chat, embeds, and other required services still work.
Step 9: Measure performance again
Compare the new results with the baseline.
Step 10: Monitor field data
When enough real-user data is available, check whether Core Web Vitals actually improved.
Common Mistakes
Treating all third-party scripts as bad
Some are essential.
Treating all third-party scripts as harmless
External code can consume meaningful network and CPU resources.
Changing everything to async
Async loading does not remove execution cost.
Delaying everything by the same amount
Different services have different functional requirements.
Loading page-specific services globally
This creates unnecessary cost across unrelated pages.
Keeping old tags forever
Tag managers often accumulate obsolete services.
Ignoring advertising layout
Late-loading ads can contribute to layout instability if space is not handled properly.
Ignoring user interaction
A third-party script that does little during initial load can still create an INP problem later.
Looking only at transfer size
A small script can execute expensive code.
Looking only at lab data
Real users may experience very different conditions.
Removing useful business functionality just to improve a score
Performance optimization should support the website’s purpose rather than undermine it.
Third-Party Scripts and Core Web Vitals Checklist
General
- Inventory third-party services
- Identify who owns each service
- Remove obsolete services
- Remove duplicate functionality
- Avoid global loading when page-specific loading is possible
LCP
- Prevent unnecessary third-party requests from competing with critical resources
- Review scripts loaded before important content
- Avoid unnecessary third-party work during initial rendering
- Review embeds and external players
- Check the LCP timeline after changes
INP
- Identify third-party long tasks
- Review execution during user interactions
- Delay non-essential scripts where appropriate
- Reduce unnecessary tag execution
- Test chat, analytics, advertising, and widgets during interaction
CLS
- Reserve space for dynamic advertising
- Reserve space for embeds where possible
- Prevent late components from unexpectedly pushing content
- Test dynamic widgets on real layouts
Loading strategy
- Use async where script independence makes it appropriate
- Use defer where execution can wait until parsing completes
- Delay non-critical functionality
- Load page-specific services only where needed
- Use interaction-based loading where appropriate
- Avoid excessive preconnect and preload hints
Validation
- Test desktop
- Test mobile
- Inspect Network requests
- Inspect Performance traces
- Compare before and after
- Monitor field Core Web Vitals
Final Verdict
Third-party scripts are not automatically performance problems.
They become problems when optional external work competes with the things users actually came to the page to see and use.
A useful analytics system may be worth its cost. Advertising may be essential to the site’s business model. A chat widget may generate valuable leads. A video embed may be central to the content.
The answer is not to remove everything.
Instead:
Keep what matters. Remove what does not. Load what can wait later. Load page-specific functionality only where it is needed. Reserve space for dynamic content. And measure the actual impact.
For Core Web Vitals, the most important question is not how many third-party scripts a page contains.
It is whether those scripts interfere with rendering, responsiveness, or layout stability at the moments users need the page to respond.
That is the performance cost worth investigating.
Related Guides
- What Is INP? Interaction to Next Paint Explained
- How to Improve INP: JavaScript, Event Handlers and Long Tasks
- What Is LCP? Largest Contentful Paint Explained
- How to Fix Poor LCP: A Practical Troubleshooting Guide
- Why Your LCP Image Loads Slowly
- How to Eliminate Render-Blocking Resources
- What Is CLS? Cumulative Layout Shift Explained
- Image Optimization: WebP, AVIF, Sizing and Lazy Loading
- Lighthouse vs CrUX: Lab Data vs Real-World Data
- Website Speed Optimization Checklist
Recommended Resources
- web.dev: Optimize Third-Party JavaScript: Learn how external scripts affect performance and how to manage their impact.
- Google Search Central: Core Web Vitals: Review Google’s guidance on loading, responsiveness, and visual stability metrics.
- Chrome for Developers: Lighthouse Performance Audits: Learn how to investigate performance issues and interpret audit results.
- Google Tag Manager Help: Understand how tags are configured and managed.
- Google PageSpeed Insights: Test pages and review available performance diagnostics.