If your product pages feel slow, start by finding which third‑party tags (chat widgets, analytics, review badges, ad scripts) are actually causing long tasks or large transfers, then reduce their impact rather than removing everything. The quickest useful route: run a Lighthouse lab audit on a representative product page, identify the worst offending hosts in the waterfall and performance trace, and treat non‑essential scripts with consent, defer or after‑interaction loading on a staging copy before deploying.
Contents
Baseline and where to run it
Pick one or two representative pages where customers actually convert (a product page with many variants, a top‑selling product and the cart/checkout). Run Lighthouse / PageSpeed Insights a few times to create a lab baseline and save the report(s). Lighthouse variability guidance is explicit: third‑party tags are a common source of inconsistent results, so repeat the test and keep the reports for comparison. Lighthouse variability guidance.
How to find the worst offenders
Open the saved Lighthouse report and the browser DevTools for the same page. Use the network waterfall to note large transfers and slow DNS/connect times, and use the Performance trace or the Long Tasks panel to identify scripts that block the main thread. Google’s publisher‑ads audits docs show how long JavaScript tasks and blocking work appear in a trace and why splitting or delaying them helps. Long tasks and blocking tasks guidance.
Record each offending script’s hostname and script URL (example: cdn.example-vendor.com/script.js). That gives you an exact list to check against vendor docs and your site code.
Prioritise scripts by user value
Not all scripts are equal. Make a two‑column list: (A) scripts required for checkout, payment gateways, fraud/security or legal obligations, and (B) non‑essential conveniences (chat widgets, recommendation widgets, some review badges, ad trackers). Keep A in place or test changes extremely carefully; treat B as primary candidates for defer/remove/consent. WooCommerce’s performance checklist reminds you to look at plugins and third‑party features as likely sources of slowness. WooCommerce performance best practices.
Loading and mitigation strategies
- Prefer platform APIs over editing inline tags. For WordPress, use wp_enqueue_script() and the script loading strategy to add async/defer or otherwise control timing from theme/plugin code instead of manually editing output. See the function and theme asset guidance. wp_enqueue_script() and including assets in themes.
- Consent‑based loading for tracking. Use a consent management platform (CMP) or Consent Mode where available so analytics and advertising tags load only after consent (or operate in a cookieless mode when consent is denied). Consult the tag vendor and CMP docs for the exact integration steps. Google Analytics Consent Mode.
- Interaction‑based lazy load for widgets. Delay chat widgets, heavy review widgets or recommendation carousels until the user interacts (clicks help, scrolls, or focuses a support button). This preserves first‑paint and initial interactivity while keeping the widget available when useful.
- Async/defer and inlined critical scripts. Where a script is needed early but can be non‑blocking, prefer async or defer. For truly critical, tiny boot code you control, inline minimal code to bootstrap and defer the rest. Always check vendor compatibility before changing how a tag loads.
- Host locally only after checking vendor policy. Downloading a third‑party script and serving it from your origin reduces network handshakes, but it may violate licensing or break automatic updates and caches; confirm the vendor allows self‑hosting and consider SRI/updates if you self‑host.
SRI and caching notes
Subresource Integrity (SRI) allows the browser to verify an externally hosted resource has not been tampered with, but it requires CORS and vendor stability. Only add SRI where the vendor provides stable, CORS‑enabled assets and you understand the update implications. See the W3C SRI spec for details. W3C: Subresource Integrity.
When you control hosting for static assets, ensure sensible Cache‑Control/ETag headers to let browsers reuse resources; PageSpeed guidance on browser caching explains the typical goals. Leverage browser caching.
Staging, testing and verification
Always make changes on a staging copy first. Apply one change at a time so you can see its effect. Re‑run Lighthouse several times to account for variability and compare the specific metrics you care about (Lab LCP, Total Blocking Time / long tasks, and network transfer size). The Lighthouse variability page explains why multiple runs are required when third‑party tags are involved. Lighthouse variability guidance.
After deploying, monitor real‑user metrics (your analytics/RUM product) for regressions in actual visitor LCP, interaction readiness or error reports. Provider‑specific RUM instrumentation steps are outside this guide; follow your RUM/analytics vendor docs for field metrics.
Decision table: remove, defer, consent or host
Remove the script
When to use it: Non‑essential widget with low business value.
Pros: Eliminates load and blocking; simplest result.
Cons: Loss of functionality; impacts customer workflows if misjudged.
Defer / async
When to use it: Scripts needed but not immediately (non‑blocking).
Pros: Improves initial interactivity and reduces blocking.
Cons: Some vendors rely on synchronous load order; test compatibility.
Consent or CMP gating
When to use it: Tracking and personalised advertising.
Pros: Meets privacy/legal needs; prevents unnecessary load for many users.
Cons: Requires CMP integration and vendor consent handling.
Interaction‑based load
When to use it: Support/chat widgets, heavy recommendation widgets.
Pros: Preserves early load performance while keeping widget available.
Cons: May slightly delay widget availability until user acts.
Host locally + SRI
When to use it: Vendor allows self‑hosting and updates are manageable.
Pros: Fewer cross‑origin handshakes, possible cache benefits.
Cons: Update/maintenance burden; SRI breaks on vendor updates unless updated.
Short checklist before you deploy changes
- Run Lighthouse on a representative page and save the report (multiple runs).
- From DevTools, note offending script URLs and hostnames (network waterfall, long tasks).
- Classify each script: critical (checkout/security) vs non‑essential.
- Check each vendor’s integration docs for async/defer or consent patterns before editing tags.
- Make changes on a staging copy and re‑run Lighthouse (multiple runs) to compare.
- Deploy one change at a time to production and monitor real‑user metrics for regressions.
- Keep a short change log and a rollback plan sourced from your host or staging process.
Example: checking an imagined shop
Imagine a small shop with a bestselling product page. A Lighthouse run flags long tasks from a chat widget and a large transfer from a recommendation carousel. The shop classifies the chat widget as medium value and the carousel as low value. On staging they:
- Deferred the recommendation carousel until after the page’s idle period and removed an unused image loader script.
- Switched the chat widget to load only after a click of a “Help” button (interaction‑based load).
They re‑ran Lighthouse several times to reduce test variability. The lab numbers in the fictional example showed fewer long tasks and a lower transfer size; in production they monitored RUM for a week to ensure there were no functional regressions. (This is a hypothetical scenario to illustrate the steps — verify actual outcomes in your own lab and RUM data.)
Related guides you may find useful: “Before you remove a WordPress plugin, check what depends on it” and “Improve product‑page LCP and image performance without re‑shooting photos”.
Make one small change on staging (defer a low‑value widget or gate analytics by consent), re‑run Lighthouse three times, note the change in long tasks and transfer bytes, and monitor your RUM for a week. That single measured step gives you evidence for the next action.