Third-party scripts: measure their cost and load them only when needed

Reduce third-party script costs by identifying which services load, testing their effect on real tasks, and removing or delaying work that visitors do not need immediately. async and defer change scheduling; they do not remove execution costs. A useful audit therefore follows the page beyond its initial load, through consent choices, product selection, search and support.

A script can be commercially useful and still be loaded at the wrong moment. The practical decision is which pages and interactions need it, who owns that decision, and how the site behaves when the service is unavailable.

Build an inventory that includes the scripts you did not add directly

Start with representative templates: a landing page, an article, a product page and a checkout entry point where applicable. Open the Network panel in Chrome DevTools and record a fresh navigation. Inspect request domains, resource types and initiators. A small bootstrap script can load a larger dependency tree, so record the service and its descendants rather than judging its first file alone.

Repeat after accepting optional tracking, opening chat and playing embedded media. Compare with the state before consent. Your inventory should include tag-manager containers, directly inserted tags, app integrations, embedded frames and code added by the content system. A domain list is a starting point, not a reliable ownership list: a first-party URL can serve vendor code.

For each service, record its purpose, owner, affected templates, loading trigger and removal procedure. Add observations for transferred data, CPU activity and visible behavior. Keep these as separate fields. A script with a small download can still perform expensive work, while a large media transfer may consume bandwidth without the same JavaScript execution pattern.

Do not collect customer identifiers in the audit. A reproducible test needs a scenario and configuration, not a recording containing private checkout information. Save sanitized traces and document the browser version, viewport, network settings and consent state.

Compare controlled runs before assigning blame

Record a baseline, then use DevTools request blocking to prevent a suspected URL or domain from loading. Reload and perform the same actions. Restore the request and repeat the comparison. Use several runs under the same conditions because vendor responses, cache state and background work vary.

Blocking is a diagnostic experiment. If a product configurator disappears, the faster result does not represent an acceptable replacement. Record the missing functionality alongside the performance change. Blocking a tag manager can also remove many vendors at once; investigate those children individually before attributing the entire difference to the container.

Read the Performance recording alongside the waterfall. Find long tasks and inspect the functions, script URLs and interactions around them. For a responsiveness problem, follow the INP troubleshooting workflow. A standard Lighthouse navigation run helps explain loading and blocking, but does not reproduce a customer's full interaction history.

Older reports include a Lighthouse audit named “Reduce the impact of third-party code.” Chrome's documentation marks that standalone audit as moved in Lighthouse 13. Do not treat its old 250 ms trigger as a universal performance budget or expect identical audit labels in every current report. Inspect the report version and use current diagnostics plus the browser trace.

Choose the earliest necessary loading moment

Use a loading policy that matches the feature. This comparison describes classic external scripts; module scripts have different default scheduling behavior.

Consult the vendor's documented integration before changing attributes. An inline initializer that assumes a library already exists can fail when the library becomes asynchronous. Removing the failure message is not a fix: verify that events arrive once, in the intended sequence, with the expected consent state.

Avoid a blanket “load every tag after the first interaction” rule. It can move work onto the exact click you want to make responsive. Similarly, an arbitrary timeout changes when the cost occurs without proving that the moment is safe. Start with fewer tags, narrower page targeting and smaller functionality before adding scheduling machinery.

Replace optional embeds with an accessible facade

A facade is a lightweight representation of a feature that loads the real embed only when requested. Google's embed best practices describe this pattern. Its value comes from avoiding unnecessary initialization for visitors who never use the feature.

The following illustrative HTML creates a keyboard-operable activation button and a reserved frame area. Replace the example endpoint with an approved embed URL that permits framing, and localize the visible labels for your site.

<div class="media-slot" id="media-slot">
  <button type="button" id="load-media">Load product video</button>
</div>
<p id="media-status" role="status"></p>
<style>
  .media-slot { aspect-ratio: 16 / 9; background: #edf2f7; }
  .media-slot iframe { width: 100%; height: 100%; border: 0; }
</style>
<script type="module">
  const button = document.querySelector('#load-media');
  const slot = document.querySelector('#media-slot');
  const status = document.querySelector('#media-status');
  button.addEventListener('click', () => {
    button.disabled = true;
    status.textContent = 'Loading video';
    const frame = document.createElement('iframe');
    frame.title = 'Product video';
    frame.src = 'https://example.com/embed/product-video';
    frame.allowFullscreen = true;
    frame.addEventListener('load', () => {
      status.textContent = 'Video frame loaded';
    });
    slot.replaceChildren(frame);
    frame.focus();
  }, { once: true });
</script>

This is a loading pattern, not a complete player integration. The frame's load event cannot prove that a cross-origin player is usable; use the provider's supported readiness API when available. Add an ordinary fallback link and a recovery path in production. Account for Content Security Policy, permissions and any required consent before creating the frame.

The reserved ratio should match the final embed. Otherwise the delayed insertion can trade a faster initial load for a visible jump. Apply the same principle to advertisements and chat panels, using the guidance on preventing layout shifts. Test the button with a keyboard and ensure focus remains understandable after replacement.

Load a chat integration once, with a recoverable failure

For a script-based widget, keep a single loading promise so repeated clicks do not insert duplicate scripts. The example below shows a loader only. The vendor URL and its readiness callback must be adapted to the integration; a script download completing does not necessarily mean chat is ready.

let chatScriptPromise;

export function loadChatScript() {
  if (chatScriptPromise) return chatScriptPromise;
  chatScriptPromise = new Promise((resolve, reject) => {
    const script = document.createElement('script');
    script.src = 'https://example.com/widgets/chat.js';
    script.async = true;
    script.onload = () => resolve();
    script.onerror = () => {
      script.remove();
      chatScriptPromise = undefined;
      reject(new Error('Chat script could not be loaded'));
    };
    document.head.append(script);
  });
  return chatScriptPromise;
}

Call this function from the chat button's click handler after checking the required permission. Show a loading state, catch rejection, and offer an alternative contact route. Disable repeated activation while loading, then open the widget through its documented API. Do not assume a global method name or simulate a successful initialization.

Measure that first activation as well as later messages. A small loader does not make the downloaded widget cheap. If the vendor performs a long synchronous startup, ask about a smaller integration or a supported staged initialization. The guide to reducing JavaScript execution time explains how to distinguish downloading less code from scheduling its execution more carefully.

Treat consent changes as performance scenarios

Test at least three paths: no optional permission, permission granted, and permission changed later. Check the network log as well as the banner's appearance. A banner that looks correct can coexist with an integration that was already initialized elsewhere in the theme.

Consent controls and loading controls are related but different. Configure the site's approved consent policy and the vendor's supported mode; do not infer that a defer attribute prevents data collection. Where a feature requires permission, enforce that gate before its initialization. Do not assume that opening a video or chat automatically supplies every permission a vendor might request.

On acceptance, update the visible interface promptly and avoid initializing every optional feature in the same synchronous handler. Preserve required event ordering and document any measurement lost by delayed analytics. A smaller analytics dataset can be an intentional tradeoff; silently claiming that delayed collection is identical is not justified.

Test rejection and withdrawal too. Removing a script element does not undo executed code, timers or requests. Follow the provider's cleanup and consent-update interfaces. This is an implementation audit, not a claim that a particular setup satisfies every jurisdiction's rules.

Keep the tag manager from becoming a second application

Export or review the container configuration with the responsible team. Look for duplicate analytics installations, expired campaigns, broad “all pages” triggers, repeated custom HTML and listeners that fire more often than the business event requires. Check whether a platform app already sends the same event.

Consolidate the event contract before rewriting triggers. For a purchase, for example, agree on the event name, dispatch point and deduplication identifier without putting real order data in documentation. Verify behavior in the vendor's debugging tools and in the network log. A faster page that double-counts transactions has not completed the task.

Server-side tagging can move selected processing away from the browser, but it does not automatically remove browser collectors or their work. Treat that as a separate architectural change with its own data and operational requirements. Measure the remaining browser code instead of assuming a server endpoint makes the client free.

Make self-hosting and vendor changes deliberate decisions

Self-hosting may change connection and caching behavior, but it does not reduce a script's computation by itself. Check the license, supported update mechanism and vendor requirements before copying code. Assign responsibility for security updates and compatibility changes. A frozen file is not a sustainable optimization if its remote API changes underneath it.

Do not hide the main content while waiting indefinitely for an experimentation service. Define an acceptable fallback with the experiment owner and test a slow or unavailable service. For critical payments, identity or anti-abuse integrations, coordinate changes with the responsible team and test the full flow. The goal is resilient functionality, not deleting dependencies until a score becomes green.

Give every new integration an owner and an exit

Use the performance checklist to create an entry for the next tag before it is enabled. Record its purpose, affected pages, activation rule, evidence of benefit, test scenarios, rollback procedure and review date. Assign a person or team inside your organization; an anonymous entry will be difficult to retire later.

Set budgets from your measured baseline and business requirements, covering transfer size, main-thread work and affected interactions. There is no single universal third-party allowance. Review actual user results after deployment and investigate regressions by template and consent state. The page-speed guides provide the adjacent diagnostics when the remaining delay comes from images, styles or first-party code.

Start with the most expensive integration whose purpose is unclear. Reproduce its cost, ask its owner whether it is still needed, and remove or narrow it in a reversible change. Then retest the task the visitor came to complete.