The Ultimate Guide to Third-Party Scripts & Marketing Tools Performance: Audit, Optimize & Govern in 2026

Every third-party script on your site was added for a reason: analytics provides data, chat drives leads, A/B testing improves conversions, social proof builds trust. But nobody measures the cumulative impact. The result is a tragedy of the commons — each team adds scripts that individually seem acceptable, but collectively make your site slow.

The compound effect is worse than the sum: 20 scripts that each add 100ms of blocking time don't add up to 2 seconds — they add up to 3–5 seconds because scripts compete for main-thread time, creating queuing delays. When Script A is executing, Scripts B through T must wait. When a user clicks a button during this queue, the interaction response (INP) must wait behind all queued scripts.

The hidden costs beyond load time:

• •Each external domain requires DNS lookup (20–120ms), TCP connection (20–100ms), and TLS handshake (50–150ms) — before any data transfers
• •Scripts that poll for updates (chat, notifications) consume CPU continuously, not just on load
• •DOM mutations from injected widgets trigger style recalculations and layout, affecting CLS
• •Cookie and localStorage writes from tracking scripts add I/O overhead
• •Memory leaks from poorly coded third-party scripts accumulate over session duration

The business irony: A SaaS marketing site running Intercom ($300/mo), Hotjar ($99/mo), Optimizely ($500/mo), Segment ($120/mo), HubSpot ($800/mo), and 10 additional tracking pixels pays $2,000+/month for tools that collectively add 3 seconds of load time — increasing bounce rate by 32–90% (Google's research). The scripts meant to acquire and convert customers are actively driving them away.

Platform-specific script landscapes:

• •E-commerce: Review widgets (200–500KB), chat (300KB–1MB), upsell/cross-sell popups, loyalty programs, payment SDKs, social proof notifications, exit-intent popups, affiliate tracking. Average: 15–30 scripts.
• •SaaS: Analytics stack (GA4 + Segment + Mixpanel), chat (Intercom/Drift), A/B testing (Optimizely/VWO), session recording (FullStory/Hotjar), email capture (HubSpot/Mailchimp), attribution (multiple pixels). Average: 20–35 scripts.
• •Lead generation: Form analytics, call tracking, CRM pixels (Salesforce/HubSpot), Google/Meta/LinkedIn ads pixels, remarketing tags, intent data providers. Average: 12–25 scripts.
• •Publishing: Ad networks (multiple), consent management, social sharing, comment systems, newsletter popups, paywall scripts. Average: 20–40 scripts.

A thorough audit is the foundation of all third-party optimization. You cannot optimize what you haven't measured.

Complete audit methodology:

1. 1Inventory all scripts: Open Chrome DevTools → Network tab → reload page → filter by 'JS'. Sort by 'Domain' to group scripts by provider. Record every external domain loading JavaScript.

1. 1Measure individual impact: For each script, record:

• •Transfer size (compressed file size over the wire)
• •Uncompressed size (actual JavaScript to parse and compile)
• •Main-thread execution time (Performance tab → Bottom-Up view → group by domain)
• •Number of network requests the script triggers (some scripts load additional resources)
• •DOM elements injected (Elements tab → check for dynamically added nodes)

1. 1Use WebPageTest domain blocking: The most accurate method — test your site normally, then test again with specific domains blocked. The speed difference is the true cost of that script. This captures cascading effects that individual measurement misses.

1. 1Check script firing scope: Many scripts load on EVERY page when they're only needed on specific pages. A review widget loading on the homepage, a checkout script loading on blog posts, a pricing calculator script loading site-wide.

1. 1Identify orphaned scripts: Scripts from tools you've uninstalled or stopped using. On Shopify, app scripts often persist after uninstallation. On WordPress, deactivated plugins may leave scripts behind.

Categorize by business value:

• •Essential: Payment processing, core analytics (GA4), consent management — cannot be removed or deferred
• •Important: Chat (drives leads), reviews (drives conversions), CRM integration — can be deferred or facade-loaded
• •Nice-to-have: Social sharing, secondary analytics, heatmaps — should be deferred or removed
• •Unknown/orphaned: No current owner, unclear purpose — remove immediately

The audit spreadsheet: Create columns for: Script name, Provider domain, Category, Transfer size, Execution time, Pages loaded on, Business owner, Last verified value, Action (keep/defer/facade/remove). This becomes your ongoing governance document.

E-commerce specific audit additions:

• •Profile scripts by page type: homepage, collection/category, product detail, cart, checkout
• •Payment SDKs (Stripe, PayPal, Affirm) should ONLY load on cart/checkout pages
• •Review widgets should ONLY load on product detail pages
• •Upsell/cross-sell should be deferred until after primary content renders

SaaS specific audit additions:

• •Check which scripts fire on pricing page interactions (toggles, sliders) — these directly cause INP failures
• •A/B testing scripts that modify the DOM before rendering cause visible flicker AND delay LCP
• •Session recording scripts (FullStory, Hotjar) are rarely needed site-wide — limit to specific pages or user segments

The facade pattern is the single most impactful technique for reducing third-party script cost without losing functionality. A facade shows a lightweight placeholder that looks like the real widget but loads zero JavaScript until the user interacts with it.

How facades work:

1. 1Create a CSS-only replica of the widget's visible element (chat button, video thumbnail, social feed preview)
2. 2When a user clicks/interacts, dynamically inject the real widget's script
3. 3Once the script loads, initialize the widget and open the interaction
4. 495%+ of visitors never interact with the widget — they never pay the performance cost

Chat widget facades (saves 500KB–1MB per widget): Chat widgets (Intercom, Drift, Zendesk, LiveChat, Crisp, Tidio) are the highest-value facade candidates because they're heavy (300KB–1MB JS), loaded on every page, and used by < 5% of visitors.

Implementation:

• •Create a CSS-only chat bubble button positioned in the bottom-right corner
• •Style it to match the real widget's appearance (color, icon, size)
• •On click: dynamically create a `<script>` element pointing to the real widget's SDK
• •Add an `onload` callback that initializes and opens the chat
• •For returning visitors who frequently use chat, you can skip the facade (cookie check)

YouTube/video facades (saves 500KB–1MB per embed): A YouTube iframe loads 500KB–1MB of JavaScript regardless of whether the user plays the video.

• •Show the video thumbnail image (available at `https://img.youtube.com/vi/VIDEO_ID/maxresdefault.jpg`)
• •Overlay a play button (CSS only)
• •On click: replace the image with the actual YouTube iframe with `autoplay=1`
• •This is the approach recommended by Google's Lighthouse

Social embed facades (saves 200–500KB per embed): Instagram, Twitter/X, and Facebook embeds each load their platform's JavaScript.

• •Screenshot the social post and display as a static image
• •Link to the original post for users who want to interact
• •Or: render the post content as HTML (text + image) without the platform SDK

Google Maps facades (saves 300–500KB):

• •Show a static map image (Google Static Maps API or a screenshot)
• •Link to Google Maps for interactive directions
• •Only load the interactive map if the user clicks 'Open interactive map'

Review widget facades (saves 200–500KB):

• •Render star ratings and review count as static HTML (data from your backend or cached API call)
• •Load the full review widget (with submission form, photos, filters) only when the user scrolls to the reviews section or clicks 'Read Reviews'

Implementation tips:

• •Use `IntersectionObserver` for scroll-triggered facades (load when the widget enters viewport)
• •Add a loading spinner/skeleton when the real widget is initializing after click
• •Test that the facade-to-real transition feels smooth (< 2 seconds)
• •Track facade click rates to understand actual widget usage

GTM is the most common mechanism for loading third-party scripts — and the most commonly misconfigured. GTM itself adds 80–100KB of JavaScript, but the tags it fires can add megabytes. An unoptimized GTM container is worse than individual script tags because all tags share a single execution context on the main thread.

GTM performance audit checklist:

1. 1Review every tag: Open GTM → Tags → list all active tags. For each tag, verify: Is it still needed? Is the trigger correct? Is it firing on the right pages?

1. 1Check container size: Workspace → Container size. Under 100KB is good. Over 300KB indicates bloat. Large containers take longer to download and parse.

1. 1Remove dead tags: Tags from campaigns that ended, tools you've stopped using, or duplicate tracking. 30–50% of tags in mature GTM containers are no longer needed.

1. 1Fix trigger timing: The biggest GTM performance mistake is firing all tags on 'All Pages' with 'Page View' trigger. This means every tag executes before the page finishes rendering.

Optimal trigger strategy:

• •Page View (fires immediately): Only GA4 base configuration, consent management
• •DOM Ready: Tags that need page structure but not visual rendering
• •Window Loaded (fires after everything loads): Hotjar, heatmaps, session recording, social pixels
• •Custom Event / Timer: Non-essential tags that can wait — fire 3–5 seconds after load
• •User Interaction: Tags that only matter when users engage — scroll tracking, click tracking

1. 1Avoid tag sequencing chains: Tag A fires → triggers Tag B → triggers Tag C creates a waterfall of blocking execution. Break sequences where possible.

1. 1Custom HTML tags: Audit all Custom HTML tags for:

• •Synchronous XHR requests (block the main thread)
• •Document.write() calls (block rendering)
• •Excessive DOM manipulation
• •Scripts loading additional scripts (creates dependency chains)

1. 1Server-side GTM: For high-traffic sites, migrate heavy tags to server-side GTM. This moves execution from the visitor's browser to a cloud server, eliminating client-side performance impact entirely. Best candidates: analytics data transformation, conversion API calls (Meta CAPI, Google Enhanced Conversions), and CRM data pushes.

GTM consolidation strategy: GTM can actually improve performance when used correctly — by consolidating 10–15 individual `<script>` tags into a single GTM container with controlled firing rules. The key: each tag must have specific, minimal trigger conditions instead of firing globally.

Third-party scripts are the #1 cause of INP failures across all platforms. When a user clicks a button, the browser must process the event handler — but if third-party scripts are also running on the main thread, the user's interaction has to wait.

How third-party scripts cause INP failures:

• •Analytics scripts firing on every interaction: Click handlers from GA4, Segment, or Mixpanel that process synchronously before the visual update
• •Chat widgets polling: Intercom/Drift checking for new messages every 5–15 seconds, creating periodic Long Tasks
• •A/B testing DOM mutations: Optimizely/VWO intercepting render events to apply variants, delaying visual updates
• •Social widgets loading on interaction: Facebook/Twitter SDKs loading lazily on first scroll, blocking simultaneous user interactions
• •Ad scripts recalculating: Ad placement scripts running layout calculations on scroll or resize events

Diagnosing third-party INP issues:

1. 1Open Chrome DevTools → Performance tab
2. 2Record a session with typical user interactions (click buttons, open dropdowns, type in forms)
3. 3Look for Long Tasks (>50ms bars) coinciding with interaction events
4. 4In the Bottom-Up view, identify which scripts are responsible for each Long Task
5. 5The Interactions lane shows exactly which interactions were slow and why

The `scheduler.yield()` solution: `scheduler.yield()` lets you break Long Tasks while maintaining execution priority — unlike `setTimeout(0)`, which sends your code to the back of the task queue.

async function processItems(items) { for (const item of items) { processItem(item); await scheduler.yield(); } }

This is specifically designed for improving INP: the browser processes any pending user interactions at the yield point, then resumes your code with the same priority. For browsers without `scheduler.yield()`, use the polyfill: `await new Promise(resolve => setTimeout(resolve, 0));`

Web Workers via Partytown: Partytown moves third-party scripts to a web worker, completely freeing the main thread. Best candidates for Partytown:

• •Analytics scripts (GA4, Segment, Amplitude)
• •Marketing pixels (Facebook, LinkedIn, Twitter)
• •Attribution tracking
• •Non-interactive monitoring scripts

Partytown is NOT suitable for scripts that directly manipulate the visible DOM (chat widgets, review widgets, A/B testing tools that modify page content).

Platform-specific INP fixes:

• •E-commerce: Product variant selectors that trigger price recalculation + analytics tracking + inventory checking simultaneously. Solution: debounce the analytics call, move inventory check to a web worker, and use CSS transitions (not JS) for visual updates.
• •SaaS pricing pages: Monthly/annual toggles that trigger A/B testing callbacks + analytics + price recalculation. Solution: pre-compute all pricing at build time, use CSS-only transitions for toggle animations, defer analytics to `requestIdleCallback`.
• •Lead gen forms: Form field validation triggers + CRM field mapping + analytics tracking on every keystroke. Solution: debounce validation to `onblur` instead of `oninput`, batch analytics events, async CRM writes.

How and when scripts load determines their performance impact. The difference between a well-loaded and poorly-loaded script can be 500ms+ of blocking time.

The three script loading modes:

1. 1Default (no attribute): Browser stops HTML parsing → downloads script → executes script → resumes parsing. This is render-blocking. Never use for third-party scripts.

1. 1`async`: Browser continues parsing while downloading. Executes immediately when download finishes (may interrupt parsing). Scripts execute in download-completion order, not source order. Use for: independent tracking scripts, analytics that don't depend on other scripts.

1. 1`defer`: Browser continues parsing while downloading. Executes after HTML parsing is complete, in source order. Use for: scripts that need the DOM, scripts with dependencies on each other.

Advanced loading patterns:

1. 1Dynamic injection (on user interaction):

const script = document.createElement('script'); script.src = 'https://widget.example.com/sdk.js'; document.body.appendChild(script);

Load only when needed — on click, scroll, or after a delay. This is the facade pattern's underlying mechanism.

1. 1requestIdleCallback loading:

requestIdleCallback(() => { const script = document.createElement('script'); script.src = 'https://analytics.example.com/pixel.js'; document.head.appendChild(script); });

Loads during browser idle time — when the main thread has nothing else to do. Best for non-urgent tracking scripts.

1. 1Intersection Observer loading (scroll-triggered):

const observer = new IntersectionObserver((entries) => { if (entries[0].isIntersecting) { loadReviewWidget(); observer.disconnect(); } }); observer.observe(document.getElementById('reviews-section'));

Loads when the target element enters the viewport. Perfect for below-fold widgets like reviews, social feeds, and maps.

Script priority guide for common categories:

• •Load immediately (async): GA4 base, consent management platform
• •Load on DOM Ready (defer): CRM integration, form validation
• •Load on Window Loaded: Heatmaps, session recording, social pixels
• •Load on idle: Secondary analytics, attribution pixels
• •Load on interaction: Chat widgets, review widgets, video embeds, maps
• •Load on specific pages only: Checkout scripts on checkout, review widgets on product pages

E-commerce sites have unique third-party script challenges because each stage of the customer journey (browse → product → cart → checkout) has different script requirements, but most stores load everything everywhere.

Product page script optimization:

• •Review widgets (Judge.me, Yotpo, Loox, Stamped): 200–500KB JS. Implement facade: show star rating + review count as static HTML, load full widget on scroll to reviews section or 'Read Reviews' click.
• •Upsell/cross-sell (Bold, Rebuy, Frequently Bought Together): 150–400KB. Defer until after primary product content renders. Question: does the conversion lift justify the speed cost? A/B test with and without.
• •Social proof notifications ('X people viewing this'): 100–300KB. Remove entirely — the marginal conversion benefit rarely justifies the INP impact.
• •Size/fit guides: Load on click, not on page load.

Cart page optimization:

• •This is where you PRELOAD checkout scripts: `<link rel="preload" as="script" href="stripe-sdk.js">` — so they're cached when the visitor reaches checkout.
• •Remove all marketing scripts from cart (heatmaps, social pixels, popups).
• •Keep only: analytics, cart functionality, payment SDK preloads.

Checkout optimization (most revenue-critical):

• •Remove ALL non-essential scripts: no chat, no popups, no heatmaps, no social proof, no exit-intent.
• •Each payment method loads its own SDK (Stripe: 200KB, PayPal: 300KB, Affirm: 150KB, Apple Pay: 100KB). Offer 2–3 methods maximum.
• •Debounce address validation — don't call the API on every keystroke.
• •Cache shipping rate calculations for repeated origin/destination combinations.

Platform-specific e-commerce considerations:

• •Shopify: Apps inject scripts that persist even after uninstallation. Check `theme.liquid` for orphaned script tags. Use Shopify's Script Editor (Plus) to move logic server-side.
• •WooCommerce: Cart fragments AJAX fires on every page load by default — disable on non-shop pages. Use `wp_dequeue_script()` to remove plugin scripts from pages where they're not needed.
• •BigCommerce: Use BigCommerce's native features (faceted search, reviews, multi-currency) instead of apps wherever possible — each app eliminated saves 100–500ms.

SaaS marketing sites and lead generation pages have a different script profile than e-commerce: the scripts are oriented toward tracking, attribution, personalization, and conversion rate optimization rather than product display.

The SaaS marketing stack problem: A typical SaaS marketing site runs: GA4 + Segment (analytics), Intercom or Drift (chat), Optimizely or VWO (A/B testing), FullStory or Hotjar (session recording), HubSpot or Marketo (marketing automation), Facebook + LinkedIn + Google Ads pixels (attribution), Clearbit or 6sense (visitor identification), Qualified or Chili Piper (routing), and custom event tracking. That's 15–25 scripts before any content-specific tools.

Optimization by script category:

Analytics stack consolidation:

• •Choose ONE analytics pipeline: GA4 direct, or Segment → GA4 + data warehouse. Don't run GA4 + Segment + Mixpanel + Amplitude simultaneously.
• •Use server-side tracking for conversion events (Meta CAPI, Google Enhanced Conversions) to reduce client-side pixel load.

Chat and conversational marketing:

• •Facade pattern (described in Step 2) is mandatory for chat widgets on marketing pages. Chat is used by < 3% of marketing page visitors.
• •On high-intent pages (pricing, demo request), you can load chat immediately — but still defer to Window Loaded.

A/B testing performance impact: A/B testing tools are particularly damaging because they must execute BEFORE the page renders (to apply the variant), making them inherently render-blocking.

• •Anti-flicker snippet: Hides the page for 100–500ms while the A/B script loads. If the script fails, the page is hidden indefinitely (most tools have a timeout, but it's often 4+ seconds).
• •DOM manipulation: Variants that modify DOM elements trigger layout recalculations.
• •Solution: Use edge-side A/B testing (Cloudflare Workers, Vercel Edge Middleware) to apply variants at the CDN layer, eliminating ALL client-side performance impact.

Session recording optimization:

• •FullStory, Hotjar, LogRocket, and Lucky Orange are heavy (200–500KB) and run continuously.
• •Don't record every visitor — sample 10–25% of sessions.
• •Don't record on every page — limit to conversion funnels.
• •Load on Window Loaded, never on Page View.

Landing page speed and CAC/CPL: Google Ads uses landing page experience as a Quality Score component. Faster landing pages = higher Quality Score = lower cost-per-click. The double benefit: you pay less per click AND convert more visitors.

• •Strip landing pages to essentials: GA4, consent, CRM form handler. Nothing else.
• •Target sub-1.5 second LCP on mobile landing pages.
• •We've seen clients reduce CPC by 12–18% and CPL by 10–20% after removing non-essential scripts from landing pages.

Pricing page INP optimization: SaaS pricing pages are highly interactive: monthly/annual toggles, seat count sliders, feature comparisons, plan selectors. Each interaction triggers JavaScript execution that must complete before the visual update.

• •Pre-compute ALL plan/tier prices at build time or page load — store in a lookup object
• •Use CSS transitions for toggle animations, not JavaScript re-renders
• •Debounce seat count sliders — don't recalculate on every pixel of movement
• •Remove A/B testing, heatmaps, and chat from pricing pages — INP is critical here

Without governance, third-party script bloat returns within 6–12 months. Every marketing campaign, every new tool trial, every agency recommendation adds scripts that are rarely removed.

The governance document: Maintain a living spreadsheet or wiki page with:

• •Every approved third-party script (name, domain, purpose, owner)
• •Performance budget: maximum total third-party JS size, maximum main-thread time
• •Approval process for new scripts
• •Quarterly review schedule
• •Removal criteria

New script approval process: Before any new third-party script is added:

1. 1Business case: What measurable outcome will this script deliver? (Not 'it would be nice to have' — specific metrics.)
2. 2Performance assessment: Measure the script's size, execution time, and CWV impact in a staging environment.
3. 3Budget check: Will adding this script push total third-party JS over the performance budget?
4. 4Loading strategy: How will it be loaded? (Defer, facade, interaction-triggered, page-specific)
5. 5Owner assignment: Who is responsible for this script? Who will evaluate its ongoing value?
6. 6Expiration date: Set a review date (3–6 months) to re-evaluate whether the script is providing value.

Quarterly script review: Every quarter, review all approved scripts:

• •Is the tool still being actively used?
• •Is the data/functionality it provides being acted upon?
• •Has the script been updated (new version, new size)?
• •Has the performance impact changed?
• •Can it be consolidated with another tool?
• •Should it be removed or replaced?

Performance budgets for third-party scripts:

• •Total third-party JavaScript: < 300KB (compressed)
• •Total third-party main-thread time: < 500ms
• •Maximum external domains: < 8
• •No individual script > 200KB
• •No script with main-thread time > 100ms (unless essential)
• •GTM container size: < 100KB

CI/CD enforcement: For engineering teams, implement automated checks:

• •Lighthouse CI with third-party budget assertions
• •Content Security Policy (CSP) headers that whitelist approved script domains — unauthorized scripts are automatically blocked
• •Automated alerts when new external domains appear in production

For sites that have exhausted basic optimization (deferral, facades, GTM tuning), advanced techniques offer further improvements.

Partytown (web worker execution): Partytown is an open-source library that moves third-party scripts from the main thread to a web worker. This is revolutionary for INP because web worker execution doesn't block user interactions.

How it works: Partytown creates a web worker and proxies DOM access from the worker back to the main thread using synchronous `Atomics` and `SharedArrayBuffer`. Scripts 'think' they're running on the main thread but are actually isolated.

Best candidates for Partytown:

• •Google Analytics / GA4
• •Facebook Pixel
• •Google Ads conversion tracking
• •LinkedIn Insight Tag
• •Twitter/X pixel
• •Any script that primarily sends data without modifying the visible DOM

NOT suitable for Partytown:

• •Chat widgets (need real-time DOM interaction)
• •A/B testing tools (need to modify DOM before render)
• •Consent management platforms (need immediate DOM access)
• •Payment SDKs (require secure main-thread execution)

Server-side GTM: Server-side GTM moves tag execution from the visitor's browser to a cloud server (Google Cloud Run). Benefits:

• •Zero client-side performance impact for migrated tags
• •Better data accuracy (no ad blockers)
• •Enhanced privacy (first-party context)
• •Reduced number of client-side network requests

Best candidates: Meta Conversions API, Google Enhanced Conversions, CRM data pushes, data warehouse syncs.

Cost: Server-side GTM requires a cloud server ($50–200/month for most sites) plus implementation effort.

Edge-side A/B testing: Replace client-side A/B testing tools with edge-side variant assignment:

• •Cloudflare Workers can assign variants at the CDN edge in < 1ms
• •Vercel Edge Middleware can modify responses before they reach the browser
• •No anti-flicker snippet needed — the correct variant is served directly
• •Zero client-side JavaScript overhead
• •Dramatically improves LCP by eliminating render-blocking A/B scripts

Content Security Policy (CSP) for script governance: CSP headers tell browsers which script domains are allowed. Unauthorized scripts are blocked automatically:

Content-Security-Policy: script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com https://js.intercomcdn.com;

This prevents rogue scripts from being injected by browser extensions, compromised third parties, or well-meaning team members adding scripts outside the governance process.

Every third-party script should be evaluated on its business ROI relative to its performance cost. This section provides frameworks for quantifying both sides of the equation.

Calculating performance cost:

1. 1Use WebPageTest domain blocking to measure your site speed with and without the script
2. 2Convert the speed difference to business impact using Google's bounce probability data:

• •1s→3s load time: 32% more bounces
• •1s→5s load time: 90% more bounces

1. 1Calculate lost revenue: (additional bounces × traffic × conversion rate × average order value)

Calculating script value:

• •Analytics: Value = decisions made using this data × estimated value per decision. If nobody looks at Hotjar recordings, the value is $0.
• •Chat: Value = (chat-originated leads × close rate × deal value) per month. If chat generates 5 leads/month at $500 each = $2,500/month value.
• •Reviews: Value = conversion rate lift from showing reviews × traffic × AOV. Test by A/B testing pages with and without reviews.
• •A/B testing: Value = net revenue from winning variants. If you haven't run a test in 3 months, current value is $0.
• •Social proof: Value = measurable conversion lift. Most social proof tools provide negligible lift — demand proof or remove.

The ROI calculation: Script ROI = (Monthly business value − Monthly performance cost) / Monthly subscription cost

If the ROI is negative — the script's performance cost exceeds its business value — remove it regardless of its subscription price.

Common scripts that fail ROI analysis:

• •Session recording on 100% of pages (sample 10% instead)
• •Multiple analytics tools tracking the same events
• •Social sharing buttons (< 0.5% click rate on most sites)
• •Exit-intent popups on mobile (Google penalizes intrusive interstitials)
• •Countdown timers and urgency tools (often tested, rarely show significant lift)
• •Chat widgets on low-intent content pages (blog posts, about page)