At a glance
Total time spent loading and executing third-party scripts, ranked per origin (Klaviyo, Google Tag Manager, Tidio, Hotjar, Optimizely, etc.). Third-party scripts are JavaScript loaded from domains the merchant doesn’t control: marketing, analytics, chat, A/B testing, ad tools. The single largest avoidable performance drag on most ecommerce sites: brands routinely accumulate 8-15 third-party scripts that collectively add 1-3 seconds of main-thread blocking and 500KB-1.5MB of bytes. The card surfaces which third parties are most expensive, enabling rational vendor consolidation and deferral decisions.
Calculation
Calculated automatically from your Website Performance (PageSpeed + CrUX) data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK-based BigCommerce fashion store homepage audit, mobile, Wednesday 15 May 26.
What the ranked list is telling us:
- 2,390ms of cumulative third-party blocking time is in the red band (over 1,500ms). For perspective: 2,390ms is longer than the entire mobile p75 LCP target of 2,500ms. Every interaction on this site is paying a 2-3 second tax for third-party scripts.
- Two scripts (Attentive at rank 9, Zendesk at rank 10) are unambiguously removable. Both are legacy installs from prior tools that have been replaced. Total savings: 154KB + 320ms blocking time in 30 minutes of work (just removing the script tags).
- GTM at rank 1 hides multiple sub-tags. A 380ms blocking time for “the tag manager” is really a sum across 12 individual tags loaded through GTM. Quarterly GTM audit to remove unused tags reduces blocking time by 30-60 percent typically.
- Tidio at rank 2 (620ms) is the single largest cost. Chat widgets are valuable for conversion but don’t need to load before first paint. Deferring Tidio to load 2 seconds post-DOM-ready preserves the chat function while removing 620ms of blocking from the critical path.
- Klaviyo at rank 3 (410ms) deserves nuanced treatment. Popup + behavior tracking + product feeds. The popup component can defer 3 seconds; the behavior tracking should fire early (it captures pageview events critical to email-attribution); product feeds can fire async. Splitting Klaviyo’s loading into stages preserves attribution while reducing blocking.
- Hotjar at rank 4 (310ms) sampled at 10 percent instead of 100 percent drops blocking proportionally without losing analytical power for most use cases. Sampling rate is a Hotjar configuration setting.
- Cumulative impact of the optimisation plan: removing 2 dead scripts + GTM tag audit + deferring chat + sampling Hotjar = roughly 1,200-1,500ms reduction in third-party blocking time. Total mobile blocking drops from 2,390ms to ~900ms, which moves the page from third-party-bottlenecked to acceptable. Combined with image optimisation, the homepage’s mobile p75 LCP can drop from 4,820ms to roughly 2,200-2,400ms.
- Identify the dominant origin. Top-ranked origin typically delivers 30-50 percent of the total third-party cost.
- Categorise each origin by criticality. Conversion-critical (payment SDKs, attribution pixels on conversion pages) vs nice-to-have (chat, session recording, social tags).
- Apply the right fix per category. Critical = preconnect + minimise bundle. Nice-to-have = defer to post-load. Legacy = remove.
- Re-audit after each ship. Confirm the third-party blocking time dropped as expected.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in PageSpeed Insights / DevTools:- PageSpeed Insights, “Diagnostics” section includes a per-third-party table similar to this card.
- Chrome DevTools → Network tab, filter by initiator origin to see per-third-party transfer cost.
- Chrome DevTools → Performance tab, Bottom-Up view shows main-thread time by URL; identifies which third-party scripts dominate execution.
- Third-Party Web report, Google’s public dataset of third-party impact on web performance, useful for benchmarking your stack.
Cross-connector reconciliation:
Quick rule for support tickets: if a merchant says “I removed a script but Vortex IQ still shows it”, the most common cause is GTM still firing the tag (the script tag visible in HTML may have been removed but GTM injects it dynamically). Audit GTM configuration for the tag.
Known limitations / merchant FAQs
My marketing team needs these tools. Can I really remove or defer them? Mostly yes, with discipline. Defer ≠ remove; the tools still run, just after first paint. For most use cases: chat widgets, session recording, A/B testing, and behaviour tracking work just as well loaded 2-3 seconds after page-load as they do during initial render. The exceptions: conversion pixels on checkout pages (must fire when the conversion event happens, regardless of timing), and personalisation scripts that customise the above-the-fold view (rare in ecommerce). Will deferring my marketing scripts break attribution? Usually no. Most attribution windows operate at session-level, not millisecond-level. Klaviyo, Meta Pixel, Google Analytics all attribute correctly even with 2-3 seconds of script-load delay. The risk is real but small; test with a 14-day side-by-side comparison before broad rollout. My BC theme installs scripts via theme settings. How do I defer them? Two paths. (1) Theme-side: edit the theme’s HTML templates to adddefer or async attributes to script tags, or wrap with document.addEventListener('load', ...). Stencil supports custom theme code; the BC theme editor allows JS modifications. (2) GTM-side: if scripts are loaded via GTM, the GTM tag’s “Trigger” can be changed from “All Pages” to “Window Loaded” or a custom event. GTM-side is usually easier.
Why is GTM showing as the biggest cost when I configured it correctly?
GTM’s blocking time is the sum of all tags fired through it, not just GTM itself. If GTM has 12 tags configured and all fire on every page-view, the cumulative cost can exceed 500ms. The fix is GTM-internal: review tag triggers, remove unused tags, scope tags to relevant pages only.
Should I switch from multiple marketing tools to an all-in-one platform?
Often yes for performance reasons. Klaviyo + Tidio + Hotjar + Optimizely + Meta Pixel + GA4 = roughly 1,500-2,000ms of cumulative third-party blocking. Replacing with an all-in-one (e.g. Klaviyo handles email + popup + behaviour; consolidate analytics) typically halves the cost. Trade-off: all-in-one tools rarely match best-of-breed feature depth in any single category.
Can Vortex IQ defer scripts for me?
Read-only by design. Vortex IQ surfaces third-party cost; the merchant’s developers or BC theme editor handle the actual deferral. The Vortex Mind Pre-Launch Readiness report can create Kanban tasks per third-party with specific recommendations.
Are payment SDKs (Stripe.js, PayPal SDK) third-party?
Technically yes, but they’re functionally first-party for ecommerce: they’re required for the checkout to work. Performance treatment: load Stripe.js / PayPal SDK only on checkout pages, not site-wide. The savings are large (5-10 percent of homepage third-party cost) and the risk is zero (the scripts aren’t needed on the homepage).
My third-party cost is 2,000ms. Can I get to 500ms?
Yes, with disciplined work. Removal of dead scripts typically saves 200-400ms. Deferral of nice-to-have scripts saves 600-1,000ms. GTM tag audit saves 200-500ms. Vendor consolidation saves 100-400ms. Cumulative achievable reduction: 1,100-2,300ms. Brands that work through this card systematically routinely cut third-party cost by 60-75 percent.
Does AVIF / WebP image format affect third-party cost?
Indirectly. Image-CDN domains (Cloudinary, imgix) are technically third parties; their bytes count in this card. AVIF/WebP serving reduces bytes from the image CDN, which reduces the third-party byte total. Execution time is unaffected (image decoding happens on the rendering thread, not the main thread).
My site uses BC’s native image CDN. Is that third-party?
Depends on the CDN domain. If images serve from *.bigcommerce.com, Lighthouse may classify as third-party even though it’s BC infrastructure. The cost is real (DNS lookup + TLS handshake + cache state) but the performance characteristics are typically better than generic third-party scripts.