How we deal with Content Flickering
Note: This document describes our approach to Content Flickering in depth.
In Webtrends Optimize, we do not experience content flickering for any test type, as long as the recommended approach is followed as described in this document.
Tag Implementation
In the Tagging Guide area of the UI, you’ll see our recommended tag integration.
Most importantly, we ask that you:
Put the tag in the
<head>Write it out as specified, with the HTML, not through JavaScript.
Do not add async or defer attributes
Correct implementation plays a vital role in avoiding content flickering – if our tag was in the <body> or included async or defer attributes, or if it was loaded into an async tag manager like Google Tag Manager, you’ll find that our tag is written to the page after some visual elements may have already loaded – thus too late to avoid content flickering.
Instead, having a synchronous tag in the <head> means we load our content without any visual elements having loaded, thus allowing us the opportunity to perform the rest of the techniques described in this document.
Example tag applied in Shopify
Content masking
Let’s now consider the journey to fetching tests and getting them onto the page.
There are 3 triggers for when you can ask Optimize to run:
“head”– immediately“dom”– on DOMContentLoaded“load”– on window.onload
From that moment, we then fetch tests asynchronously – evaluation is done in our servers and we only return the tests a user should fall into.
In many tools, you’ll find they wait for DOMContentLoaded or window.onload, but don’t apply any masking while this happens or it’s easily forgotten.
In Webtrends Optimize, we have a setting in your tag that allows you to either mask the page all of the time while this evaluation happens or manually controlled using an array of regexs (referred to commonly as “the whitelist”).
To cover the journey so far:
Tag placed in head, before visual content
Mask the page – let’s call this Mask 1.
Potentially wait for dom-ready event
Fetch tests
Execute tests.
Remove Mask 1.
Waiting for conditions in-test
In your test, you may also wait for certain conditions before being able to execute your changes.
For example:
Your initial checkout is a loading screen and content dynamically pulls in after a short delay
The loading mode is set to “head” (immediate), but you want to wait for a specific element or two to show up before running your test.
In this situation, we:
Apply a 2nd layer of masking. Mask 2.
Poll/wait for your conditions to be fulfilled.
Run your transformations
Remove Mask 2.
The full journey therefore looks like this:
Tag placed in head, before visual content
Mask the page – let’s call this Mask 1.
Potentially wait for dom-ready event
Fetch tests
Execute tests.
Apply mask 2
Wait for your element to show
Remove Mask 1.
Element shows up
Render changes
Remove Mask 2.
This may seem complicated, but we’ve made it easy to run tests properly.
Let’s look back at the activities described above.
Mask 1: This is handled in your tag, and is a typically 1-time setting when customers come on board with us.
Mask 2:
If you’re using the Visual Editor, you will be waiting for DOM-ready in the tag – no work is required.
If you’re running scripted tests, we suggest using the Optimize Build Framework (OBF) in which case there’s a single CSS rule near the top of the file to manage Mask 2.
That’s it. At most, 1 line of CSS to manage per test, assuming you’re a developer scripting your tests.
TLDR:
We’ve looked at every potential interaction point for content flickering and ensured Content Flickering cannot logically happen.
You will never hear us suggest that the solution to content flickering is to compress your images, put less code in our platform, or take your chances with an anti-flicker snippet. Instead, we’ll ensure that the above best practices are being used, and are confident that you will never go wrong.