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.
| What it counts | Per third-party origin: total bytes downloaded, total main-thread blocking time, total network time, and the number of subresources loaded. Lighthouse identifies third-party origins via known-third-party-domain lists (Google’s third-party-web list) plus heuristic detection of non-first-party hostnames. |
| Sample type | Lab data from Lighthouse audit. Reflects what loaded during the synthetic page-load. |
| Common ecommerce third parties + typical cost | (1) Google Tag Manager: 60-200KB, 100-400ms blocking time depending on tags configured. (2) Klaviyo: 80-200KB, 200-500ms (popup + behavior tracking + product feeds). (3) Tidio / Intercom / Zendesk Chat: 150-300KB, 300-700ms (chat widget + presence detection). (4) Hotjar / FullStory: 100-200KB, 200-500ms (session recording, heatmap collection). (5) Optimizely / VWO / Convert: 100-150KB, 200-400ms (A/B test variant fetching + DOM manipulation). (6) Meta Pixel + Google Ads pixel: 30-80KB combined, 50-150ms (conversion tracking). (7) Stripe.js / PayPal SDK: 30-50KB on checkout pages only, minimal blocking. |
| Why third-party scripts are expensive | (a) DNS lookup + TCP + TLS for each new origin = 100-300ms before any script bytes flow. (b) Synchronous loading in <head> blocks the parser. (c) Main-thread execution on slow CPUs takes 4-10x longer than developer’s machine. (d) Cascading fetches: many third parties load additional sub-resources (CSS, fonts, sub-scripts), compounding the cost. |
| Optimisation playbook | (1) Vendor consolidation: prefer all-in-one tools (Klaviyo replaces 3-4 marketing scripts) over best-of-breed multi-vendor stacks. (2) Defer non-critical scripts: chat widgets, session-recording, A/B testing don’t need to run before first paint. Use defer, async, or document.addEventListener('load', ...). (3) Preconnect to critical third parties: <link rel="preconnect" href="https://klaviyo.com"> warms the TLS handshake before the script tag fires. (4) Audit GTM configuration: GTM accumulates legacy tags over years. Quarterly review to remove unused tags reduces bundle size. (5) Move conversion pixels to fire only on relevant pages (Meta Pixel on PDPs and checkout, not the homepage). |
| The hidden cost | Third-party scripts often add functionality that one team values but degrades site performance. The decision to add a third party is rarely revisited once shipped; brands accumulate 5-10 scripts over 2-3 years that nobody actively maintains. Quarterly third-party audit is the right cadence. |
| Currency | n/a, this is duration in milliseconds and bytes. |
| Time window | T/7D/30D vsP |
| Alert trigger | total third-party blocking time > 1500ms (red), > 1000ms (amber). |
| Sentiment key | null (multi-metric card; thresholds on aggregate). |
| Roles | owner, operations |
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.| Rank | Third-party origin | Bytes | Blocking time | Function | Verdict |
|---|---|---|---|---|---|
| 1 | googletagmanager.com | 184KB | 380ms | Tag manager (12 tags configured) | Audit GTM; remove unused tags |
| 2 | tidio.co | 246KB | 620ms | Live chat widget | Defer to post-load |
| 3 | klaviyo.com | 178KB | 410ms | Email popup + behavior tracking | Defer popup; preconnect |
| 4 | static.hotjar.com | 142KB | 310ms | Session recording + heatmap | Sample 10% of sessions instead of 100% |
| 5 | connect.facebook.net | 64KB | 110ms | Meta Pixel | Move to PDPs and checkout only; remove from homepage |
| 6 | googleadservices.com | 38KB | 70ms | Google Ads conversion pixel | Same: scope to relevant pages |
| 7 | js.stripe.com | 42KB | 80ms | Stripe.js (loaded too early) | Lazy-load on checkout only |
| 8 | snap.licdn.com | 32KB | 90ms | LinkedIn Insight tag | Audit ROI; consider removal |
| 9 | cdn.attentive.com | 58KB | 140ms | SMS popup (legacy, unused) | Remove |
| 10 | static.zdassets.com | 96KB | 180ms | Zendesk Chat (legacy, replaced by Tidio) | Remove |
| Total | 1,080KB | 2,390ms | Critical, half is removable |
- 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.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify top 3 origins; categorise. |
| First 24 hours | Remove dead scripts (typically 2-3 of any audit). Defer non-critical. |
| First 7 days | GTM audit; remove unused tags. Consolidate vendors. |
| First 14 days | Re-audit; confirm cumulative reduction. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
psi_unused_js | Third-party scripts often ship more code than the page uses; unused-JS bytes overlap with third-party cost. |
psi_render_blocking | Third-party scripts in <head> block first paint; render-blocking opportunity surfaces these. |
psi_total_weight | Third-party scripts contribute to total page weight. |
psi_perf_score_summary | Composite score; third-party cost is a major contributor to TBT (30 percent of score weight). |
crux_inp_p75 | INP is heavily affected by third-party main-thread cost. |
crux_lcp_p75 | LCP delayed when third parties block render. |
psi_top_opportunities_ms | Composite ranking; third-party fixes typically rank in top 3. |
psi_top_opportunities_bytes | Same opportunities by byte savings. |
psi_caching_opportunities | Third-party scripts often have weak cache headers; revisits re-download. |
Klaviyo klv_email_health_kpis | If Klaviyo is the dominant third-party, email-attribution health and performance trade off. |
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.
| Reason | Direction | What to do |
|---|---|---|
| Third-party detection. Lighthouse uses Google’s third-party-web list; some custom domains (e.g. self-hosted variant of a tool) won’t be classified as third-party. | Vortex IQ may under-count | Manually classify any non-listed origins. |
| Run-to-run variance. Some third parties load conditionally based on user behaviour (popup triggers, A/B test variants). Different audit runs see different sets. | Either direction | Use 7-day rolling for trend. |
| Cache state. Vortex IQ runs cold-cache; warm-cache runs see fewer third-party byte downloads (still pay execution cost). | Vortex IQ higher byte cost | Use disabled-cache DevTools for direct comparison. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
psi_third_party_cost ↔ crux_inp_p75 | Third-party blocking time correlates with INP failures | Reducing third-party blocking by 500ms typically reduces INP by 100-300ms (third party cost is execution-pattern-dependent, not all blocking maps directly to interaction delay). |
psi_third_party_cost ↔ Email-attribution / paid-attribution accuracy | Trade-off: deferring marketing scripts reduces performance cost but may miss attribution signals | Attribution windows have grace periods; deferring scripts by 1-3 seconds typically doesn’t break attribution. Test before broad rollout. |
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.