JavaScript Tag

Below, you’ll find details for tagging your website with Webtrends Optimize Tag.

What is the Webtrends Optimize Tag?

The Webtrends Optimize tag is the javascript tag you add to your website, which allows us to interface with it. It is typically a single SCRIPT tag, and when added into the HEAD tag of your website allows us to run experiments + optimals, track user activity, and provide all other experiences we build.

How to get your Tag

You can find a full tagging guide in the Optimize UI, found in the top nav. This includes guidance on Content Security Policies, Tag Management containers, etc.

Broadly, as mentioned above, this will involve placing one SCRIPT tag into the HEAD of your website (or at least the pages you wish to test and track on).

How it works – serving experiences, behavioural tracking



  1. Your users request the web page, in the same way they do today.
  2. Your server returns a web page, in the same way it does today.
  3. That web page contains our Tag, before any visual elements. This triggers as the page loads in the browser. At this point, we mask the page (optionally, to avoid flickering).
  4. A request is made to Optimize to see if there is anything on the page that needs to executed (a test/target) or tracked (clicks, page loads, revenue, etc.
  5. Our servers respond with instructions of transformations to make to the page (with Javascript and CSS), and things to track. These are executed when the response is handled on the page.
  6. The optional masking is removed, and the final page is ready for a user

Impact on page load performance

Firstly, note that any JavaScript can affect page load performance. Minimal, lightweight pages are encouraged by google, and anything you add to a page (additional sections to your website, additional functionality, or 3rd party vendors) all detract from ideal page load speeds.

When considering page load performance, we typically consider the metrics that Google Lighthouse allows us to report on. These will be discussed below.

DOM Content Loaded, First Contentful Paint – “load speed”

This considers how quickly the page loads in and gets content onto the page. For these metrics, the weight of our tag, and in-memory footprint is important.

To minimise our footprint here and keep our tag as small as possible, we:

  • Write concise code in ES5, and not transpiling – something that our competitors do. Using transpiled code adds unnecessary bloat – something others don’t consider when their tag is already considerably large.
  • Avoid using libraries, which often contain a plethora of features that you’ll never need.
  • A loader – dependancy mechanism. We have a minimal loader, and subsequent requests are pulled in as dependancies. This allows the rest of the page to continue to load, whilst we make decisions about the user and execute everything we need to – something which is better for initial footprint than having a very large file that’s blocking the critical path to content loading.

Contentful shift

This metric considers content shifting the page, which is often the case when experimenting.

To improve this, we implement masking on the page to hide areas of the website which are likely to change or jump. By only showing users the final content, they don’t recieve a jittery experience, which Google is currently penalising.

Closing thoughts

We experiment and personalise our own website. As part of our process, we discovered that our website itself, without any additional software, had poor performance. By buidling a website with great performance scores – 95+ – we noticed that our tag had minimal-to-no impact. Even when running tests, our scores remain at 90+, often 100.

We have, and continue to, find any opportunity to reduce our footprint though, and come up with solutions which ensure solid onsite experience which reflects in good performance scores.

For Shopify:

To understand how to do this, see the details found here.