Performance

Audit third-party script impact on load time

A scenario prompt for a GTM container with 12 tags plus a chat widget blocking the main thread for 900ms, weighing deferral against the marketing and analytics costs of delaying each script.

Works with Claude / GPT450 uses 4.3

The prompt

performance-third-party-script-audit
Lighthouse flags 900ms of main-thread blocking time from third-party scripts on a
site. The tags involved, per the report:

[- Google Tag Manager container with 12 tags total
- Facebook Pixel, firing on every page
- Hotjar session recording, firing on every page
- A live chat widget (Tawk.to-style), loaded via a script tag manually placed in
header.php, not through GTM
- Google Analytics 4, loaded twice: once through GTM and once hardcoded separately by
a previous developer]

Audit this like a consultant balancing speed against what marketing actually needs
these tags for, not by recommending "remove all third-party scripts":
1. Flag the duplicate GA4 load first as a pure win with zero trade-off: firing
   analytics twice adds load with no benefit and likely double-counts events, so
   removing the hardcoded one in favor of the GTM-managed one is safe to do
   immediately.
2. Address the chat widget: recommend deferring its load until user interaction
   (scroll, click, or a several-second delay) rather than loading it eagerly in the
   header, and note the trade-off explicitly: if the support team wants the chat
   bubble visible the instant a page loads for a subset of high-intent visitors (like
   the checkout page), a blanket delay could reduce chat engagement on that page
   specifically.
3. Address Hotjar and Facebook Pixel: recommend loading both via GTM with a trigger
   that fires after page load or after a short delay rather than immediately, and note
   the trade-off for Facebook Pixel specifically, delaying it slightly undercounts
   visitors who bounce in the first second or two, which matters if the marketing team
   is optimizing ad spend against that pixel's numbers.
4. Give the mechanism for each fix: GTM's own trigger and tag-firing-priority settings
   for tags managed there, and a small inline script using a scroll or click listener
   to inject the chat widget's script tag only when needed for the one script outside
   GTM.
5. Note this is achievable entirely from GTM's interface and a small header.php edit,
   no hosting-level access needed, but flag that whoever manages the ad accounts
   should sign off on the Facebook Pixel delay before it ships, since that's a
   marketing-attribution decision, not just a technical one.

Every third-party script audit eventually runs into a script that’s slow because someone outside engineering wants it to fire instantly, and the honest answer isn’t always “delay it,” it’s “delay it and tell the person who’ll notice first.” This prompt keeps that trade-off visible instead of treating every deferral as free.

List your GTM tags and their trigger conditions if you have export access, that’s faster than reverse-engineering firing order from the Lighthouse report alone.