“Reduce The Impact of Third Party Code” With Google Tag Manager

If you’ve run a Google Pagespeed Insights test you’ll likely have seen a message “Reduce the impact of third-party code”, something like the screenshot below.

In this post I share two simple ways we use Google Tag Manager to optimize third party code – things like Google Analytics code, Facebook Marketing Pixels, Live Chat and other javascript code that is important but not necessary to render the site.

Click play on the video below for a walkthrough of how we do this:

To use this method you’ll need to have Google Tag Manager setup and integrated with the site. It’s free and you can create an account at https://google.com/tagmanager

Method 1: Use the “All Pages Window Loaded” trigger

By default, Google sets up Tag Manager with a “Page View” trigger. If you have a look at the description below from Google’s website here https://support.google.com/tagmanager/answer/7679319?hl=en you’ll see that the Page View trigger fires the code immediately.

Instead we want to use the “Window Loaded” trigger which as you’ll see fires only after the page has fully loaded.

Analytics, marketing code and third party code is not necessary to render the page so we don’t actually need to fire the code immediately and it doesn’t matter if the code is 1 or 2 seconds slower to fire.

With the Page View trigger the code fires immediately and interrupts the page load and render whereas with the Window Loaded trigger it’s delayed under the page has finished loading thus we “Reduce the impact of third-party code”!

Page View Triggers Explained

Use Google Tag Manager’s page view triggers to fire tags when pages are loaded in web browsers. There are five trigger types that are based on page load events, and each type has different criteria to determine when the trigger should fire. The order of precedence for page view triggers is as follows:

  1. Consent Initialization: Designed to help ensure that consent settings are honored before any other triggers fire. The Consent Initialization trigger is used for tags that set or update the user consent state for your site, such as a Consent Management Platform tag or tags that set consent defaults. Each web container includes a Consent Initialization – All Pages trigger by default. The Consent Initialization trigger is not used for tags that should fire early on a site. For those cases, use an Initialization trigger. Learn more about consent settings.
  2. Initialization: Designed to fire before all other triggers except Consent Initialization triggers. Each web container includes an Initialization – All Pages trigger by default. Select this trigger to fire any tags that should fire before other triggers.
  3. Page View: Fires immediately when the web browser begins to load a page. Use this option if you only need data generated from page impressions.
  4. DOM Ready: Fires after the browser has finished constructing the full page in HTML and the Document Object Model (DOM) is ready to be parsed. Pageview-based tags that interact with the DOM to populate variables should use this trigger type to ensure that the correct values are available to Tag Manager.
  5. Window Loaded: Fires after the page has fully loaded, including any embedded resources such as images and scripts.

Method 2: Use a timer trigger

The second optimization method we use is a timer trigger. This trigger delays the firing of the code for a specified amount of time. This is particularly useful for live chat tools, This can improve page load speed and overall performance, especially for users who are quickly navigating through the website.

In the example you see we have a 7 second delay before firing the live-chat code. This has no practical impact on the user experience as most users will not be accessing the live chat immediately upon the page load but can’t significantly improve the site speed experience.