Website Flicker: The Problem
03 Mar 2024 » Opinion
For the past 5 years or more, almost every client I work with has raised their concerns about flicker or the causes that generate flicker. For reasons that will become clearer in this post, this topic tends to be a bit heated, with very strong opinions on either side. I will try to stay away as much as I can from subjective matters, but I will also give you my point of view. This is the first post of a two-part series, where I will talk about the problem and potential solutions to this issue.
What is website flicker?
To make sure we are all on the same page (no pun intended), I would like to start by sharing a definition of the main term in my post. This being such a niche concept, I found very few definitions after an Internet search. Instead, I will try with my own definition:
Negative user experience where the contents of a web page change while it is loading.
This is how it evolves:
- The browser requests a URL.
- The server returns an HTML page.
- The browser starts to parse the HTML page from the top.
- As it finds external references in the HTML, the browser downloads assets and style sheets.
- The browser decides it has enough information to show the page with the contents and style it already has.
- The browser finds a
<script>tag and downloads the corresponding JavaScript. - The browser executes the JavaScript code, which modifies the content or style of the page.
- The browser continues to parse the HTML, finding more content and external references; as it has more information, it updates the visual experience.
You may think that these steps happen really fast, so fast that we do not even notice it. However, some of these steps take hundreds of milliseconds. In particular, if the time between steps 5 and 7 is long enough, our eyes will notice the change.
Why is it bad?
The summary is in my definition: negative user experience. According to one of the most cited research papers on the matter, a visitor will decide on their views of your website in 50ms. Previously, researchers thought that this threshold was 500ms. In any case, both numbers represent a really small amount of time. So, if flicker happens, it will affect the visitor’s decision.
If you find it hard to believe, think about your own experience. In my case, before I started working in digital marketing, flicker already made a really bad impression on me, it made a website look fishy. Why was it changing the content? What if I was interested in the initial content, the one that was replaced? Is the website trying to trick me?
Page speed and flicker
I was not sure where to address the elephant in the room, so I will do it next.
Page speed has always been a thing. We all want web pages to load as fast as possible. Various research papers have measured the amount of time visitors are willing to wait until the page loads. The summary is that people are very impatient and with very short attention spans. There is a proportional relation between load time and bounce rate: as load time increases, so does bounce rate. In other words, slow websites perform worse than faster ones. In recent years, Google’s ranking algorithm has started to take this metric into account.
There are many recommendations to reduce the load time. The one that matters the most to us is to move all JavaScript code to the bottom of the page.
Digital marketing and flicker
There is one particular tool in the digital marketing toolbox that is greatly affected by this issue: the personalization and optimization engine. In the case of Adobe, this is Adobe Target, which is the tool I will refer to moving forward.
The goal of Adobe Target is to offer personalized content, optimize the website using A/B tests, and show recommendations, among other features. All web pages have a default content, the content returned by the server in step 2 above. Adobe Target, using JavaScript, will download a set of instructions from the Adobe Target edge servers and manipulate the web page (the DOM) accordingly. This manipulation may produce flicker, as the browser may already have shown the default content.
There is a standard recommendation to avoid flicker: load the JavaScript library in the <head> section. If you are using a tag manager like Launch Tags, you will need to configure it accordingly. If you are not using a tag manager, check this page as an example of how to add at.js to the <head>: Implement Target without a tag manager. The goal of this approach is to give the WebSDK or at.js enough time to make a call to the Adobe Target edge servers and get any potential alternate content before the contents of the page are shown by the browser (step 5 above).
However, this is where things get ugly. I am sure you have already noted that there is a conflict: on the one hand, JavaScript code should be loaded at the bottom of the page to speed up the page load; on the other hand, Adobe Target JavaScript wants to be loaded at the top of the page to avoid flicker.
This is not a trivial discussion. I have encountered too often with zealots who have been given the task of reducing the page load time at all costs, even if it ruins the user experience. It is very difficult to argue with them, they see everything in black and white. It takes all my consulting soft skills of 12 years trying to convince them to spare Adobe Target, only to get some minor concessions.
You probably have guessed that I side with the digital marketers, who want to keep their Adobe Target code at the top of the page and avoid flicker at all costs. In my personal view, flicker has worse effects on user experience than a few hundred milliseconds additional delay on the website. My customers are well-established brands, many of them known worldwide. People find them by their name. SEO is not as important in this case and customers want my customer’s products or services.
In my next post I will address the potential solutions to the problem of flicker.