.svg){kind=logo}
Every marketer is protective of their website customer experience, for very good reason. Online brand experiences can instantly help or hinder brand trust. This is particularly true for ecommerce websites with the objective to build trust and confidence quickly so shoppers will share their personal details and payment information.
Achieving fast, smooth page loads plays a significant role in ensuring consistently great visitor experiences. Websites with heavy graphics, large media files, multiple elements, dynamic text and images (like on a publisher site) or externally served content (such as ad-served creative) are more likely to incur slower page load times and elements which load at different rates.
In fact, according to Sweor 88% of web visitors are less likely to return to a site after a bad experience and 57% of visitors say they wouldn’t recommend a business with a poorly designed website.
Slow page loads not only impact visitor perception of the brand—there’s a direct correlation between page speed and visitor behavior as well. A study by Radware found that page speeds significantly impact conversions. By resolving page speed issues, Walmart discovered that for every 1 second of improvement they increased conversions by 2%.
Whenever we add a third-party tag to our website, from analytics to ad serving, it will automatically cause a slight reduction in page speed. This creates a double edged sword for data-driven, conversion-obsessed marketers and CRO practitioners like ourselves. We know the gains made through website personalization and optimization will far outweigh any small potential performance loss, but not at the expense of the customer experience.
But wait, there’s more. Some A/B testing and personalization snippets can cause slow page loads and a usability issue called ‘flicker’.
What is flicker?
Simply, flicker refers to the phenomenon of a webpage loading in one state (such as a base page) and then transitioning to show something different (such as a dynamic variation of the page for improved personalization or experimentation). The key problem is that your visitors can often witness this change as it’s occurring, usually by seeing a flash of the original page before the new page is fully loaded.
Although this occurs within microseconds, it doesn’t take much to spook some shoppers that there’s potentially something amiss with the site if they experience redirects or flicker.
What can cause flicker?
The most common source of flicker is A/B testing and website optimization solutions. Almost all of these tools are implemented on your website through a JavaScript snippet that manipulates the HTML and/or CSS. When the base webpage is able to render ahead of these solutions making the desired changes, your visitors can potentially get served a fat slice of flicker pie.
How Website Tagging Impacts Flicker
The most common reasons for experiencing flicker are related to how the JavaScript snippet is implemented.
Running page manipulating snippets asynchronously
JavaScript snippets can be told to run in two ways, synchronously and asynchronously. If a snippet is set to run synchronously the browser will wait to continue its tasks until after the snippet has finished loading. In contrast, running snippets asynchronously does not cause the browser to wait and can run multiple processes simultaneously.
Page manipulating snippets are not prioritized
As your visitor’s browser interprets what to do it parses the HTML of your website from the top down. Scripts found earlier on the page will run sooner that scripts found later. This is especially true if the snippets are running synchronously. To minimize any chance of flicker you want to make sure any snippets that manipulate the page are the first snippets that are run by placing them as high in the <head> as possible.
Page manipulating snippets are served using a tag manager
Serving your personalization or optimization snippet from a tag manager is never a good idea if you care about your web visitor’s experience. First, most tag managers load asynchronously meaning the webpage can continue rendering while it runs. Second, after the tag manager is loaded only then does it run the optimization snippet. This adds a huge amount of latency to when the optimization snippet is able to finally run, and will almost always guarantee flicker.
Optimization snippets leveraging external data
Some web personalization ideas employ the use of third-party web deanonymization solutions (e.g. 6sense, ClearBit). These solutions themselves are served through JavaScript snippets, and their ability to populate data for the optimization solution to use requires a thoughtful approach to ensure a high performance website.
Most of the challenges encountered with using third-party data are centered around the desire to personalize the hero section of a website on the very first page view. To enable this use case you’ll want to make sure that your deanonymization provider returns data quickly, and can be run synchronously before your optimization snippet. This will ensure that if there’s data available the optimization solution is able to leverage it.
Another option is to have your optimization solution stylishly fade in the personalized elements above-the-fold that leverage third-party data.
The Catch-all Solution
Maybe your flicker is due to one of the reasons listed above but the obvious solution is not possible for you to implement. Perhaps your legal team requires every third-party script to be served from a tag manager. Maybe your developers are focused on page speed and see any script running synchronously as a threat to their goals.
At Intellimize, we’ve solved the flicker issue so you can continue to protect your user experience and we’ve reduced page speed latencies. Want to know more? Let’s talk, we’d be happy to share.
