The FUD Behind Web Page Flicker

By Adam Figueira

November 8, 2013

Some contend that web page flicker inherently causes a bad customer experience, or that it invalidates a website experience because visitors know that they’re being put into a test group.

Let’s start by defining what flicker actually is. The term “flicker” describes the very small potential that a visitor will see a visual artifact of your default/native website experience before the optimized experience renders. The typical cause of flicker is an asynchronous javascript tag (we’ll get to that later) that’s placed below other tags on the page.Fear, Uncertainty, Doubt (FUD)

So is flicker bad?

Maybe, maybe not. What’s great is digital marketers can test it, and finally put an end to the (sometimes emotionally charged) arguments about what experience is ideal.

Simply put, your website visitors are the ones who should tell you what’s a good experience and what’s a bad experience. By running a few simple tests, it may turn out that flicker doesn’t affect the customer experience at all―or that it actually helps it by way of emphasizing the change or experience you want visitors to see.

The key point of emphasis, however, is that marketers ought to (and do) have a choice. Just like there’s no one-size-fits-all website experience, there’s no single best way to implement marketing optimization technologies.

Let’s dive in a little deeper, and look at two ways to implement a tag-based marketing optimization technology.

Asynchronous Tag

As I mentioned earlier, use of an asynchronous javascript comes with the small (but possible) chance of introducing page flicker. If it turns out that page flicker is negatively affecting the customer experience, there are easy measures to fix it, while still preserving the benefits of using an asynchronous tag, namely, that it doesn’t extend page load times and cannot bring your website down.

Synchronous Tag

When placed in the right position in your page source code, a synchronous tag eliminates the risk of flicker, but in its place, it introduces the small (but possible) chance of bringing down―or slowing down―your website because a synchronous tag is a blocking script. Once again, there are easy measures to reduce some of these risks―namely, through the use of automated timeouts―while still preserving the no-flicker experience that synchronous tags offer.

The lesson in this debate is that it need not be debated. The implementation that is best for your business is that one that best meets the needs of your customers, as well as the goals of the experience you deliver to them.

Let’s draw an analogy to buying a car. There’s no one car that’s right for every single customer. That’s why we get to choose a manufacturer and model based on our needs, our driving style, the size of our family, etc. With these factors in mind, you might come to a completely different decision than me, even though our budget for a new car is exactly the same.

With regard to implementation of a tag-based solution, you don’t need to be scared into making a decision. Don’t get caught up in fear, uncertainty, and doubt (FUD). You should look for a vendor that supports both options, and ultimately, it should be up to you to decide.

Get more details in the white paper, 8 Best Practices for Deploying Customer Experience JavaScript.

Adam Figueira is a former product marketing director at Monetate.

Experience the future of ecommerce personalization

Book your personalized demo today.