Skip to main content
    SnapSiteScan

    SnapSiteScan verdict

    Third-party scripts dominate your page

    When third-party scripts are the largest measured cause, most of the loading time belongs to code your team did not write, cannot optimise, and can only choose to keep or remove.

    Ownership

    Marketing or analytics

    This is a marketing and analytics decision before it is an engineering task. Developers can defer these tags, but only the owner of the tag can decide whether it stays.

    What happens if you do nothing?

    Every visitor pays for tools that only a handful of people internally ever look at — and the slowdown reduces the very conversions the tags were installed to measure.

    Do this first

    1. 1

      List every tag and name an owner

      Confirm purpose, consent and dependencies with each tag owner. Remove only tags that are no longer needed, then check business functionality and event collection.

    2. 2

      Replace heavy widgets with a facade

      Chat, video and map embeds can be shown as a lightweight placeholder that loads the real widget only when clicked.

    3. 3

      Delay the rest until after interaction

      Delay optional tags only after agreeing on the tradeoff. Waiting for interaction or idle can lose early events; consent and essential functionality must remain correct.

    4. 4

      Set a budget and enforce it in the tag manager

      Without a limit, third-party weight returns within a quarter. The budget is what makes this fix permanent.

    From Lighthouse finding to a testable change

    Lighthouse evidence: Third-party summary / third-party insights; script execution and main-thread breakdowns

    Attribute blocking time to the domains actually named by Lighthouse, then confirm which tags your site controls. A third-party domain is not automatically unnecessary. A facade lets an optional embed wait until the visitor asks for it.

    A scoped code example

    <button type="button" id="load-map">Load map</button>
<div id="map-slot"></div>
<script>
document.getElementById('load-map').addEventListener('click', function () {
  const frame = document.createElement('iframe');
  frame.src = '/map-embed'; // Replace with your approved embed URL.
  frame.title = 'Location map';
  frame.width = '600';
  frame.height = '400';
  document.getElementById('map-slot').replaceChildren(frame);
  this.remove();
}, { once: true });
</script>

    When this recommendation does not apply

    This is an illustrative facade for an optional map, not a drop-in fix for consent, payments or security scripts. Confirm the provider URL, content security policy, responsive sizing and keyboard access. Delaying analytics can lose early events; preserve consent requirements and agree on measurement tradeoffs with the tag owner.

    Verify the result, not the estimate

    Check the embed opens with a keyboard and that necessary events still work after consent. Rescan the same URL and device, compare the third-party finding and TBT, and retain the earlier report. Do not treat missing audit evidence as a pass.

    How First Fix and Rescan & Compare work · Run a scan and keep a before/after report

    Official technical reference

    How do you know this verdict is yours?

    • The third-party summary reports a large share of total blocking time.
    • Requests to tag managers, chat widgets, A/B testing tools, heatmaps or ad networks.
    • Blocking time stays high even after your own JavaScript has been reduced.
    • The page is noticeably faster with an ad or script blocker enabled.

    Not worth your time given this verdict

    • Optimising your own code while third-party scripts dominate the main thread.
    • Hosting upgrades — these files are not served by you.
    • Image compression, unless images also appear as a top cause.

    Deprioritising a finding is a prioritisation call, not a claim that it never matters.

    When to stop

    When should you stop working on this?

    Reprioritise once repeated measurements show third-party work is no longer the dominant cause and every retained tag has a purpose and owner. Check interactions and consent, not just lab blocking time; provider behaviour can still change.

    Send this to your team

    The message that ends the discussion

    Most of our load time is third-party tags, not our own code. Developers can defer them but cannot delete them. Need owners to confirm which tags we actually still use.

    Quick answer

    How much are analytics, chat and marketing tags slowing my site down?

    When third-party scripts are the largest measured cause, most of the loading time belongs to code your team did not write, cannot optimise, and can only choose to keep or remove. This is a marketing and analytics decision before it is an engineering task. Developers can defer these tags, but only the owner of the tag can decide whether it stays.

    Owner
    Marketing or analytics
    First action
    List every tag and name an owner

    What to do next: Confirm purpose, consent and dependencies with each tag owner. Remove only tags that are no longer needed, then check business functionality and event collection.

    Not sure which verdict is yours?

    Run a scan to find an eligible First Fix from the returned Lighthouse evidence. Review its applicability, make one change, then use Rescan & Compare in the report to check fresh measurements. If no eligible finding remains, no fix is invented.

    Scan your site

    The other verdicts