Website Flicker: The Solutions

31 Mar 2024 » Opinion

In my last post, I introduced the problem with flicker. The post was already becoming too long and I decided to split it into two. This is the second part, where I will explain the solutions that can be applied. If you have landed directly on this post, I strongly recommend that you first read my previous post.

Let me start with the bad news: there is no perfect solution. I know this is not what many want to read. However, there is nothing you can do about it, it is in the nature of how browsers have been designed. Optimization tools came later and are not considered by browser developers. All we can do is try to find satisfactory alternatives, although not ideal.

Pre-hiding snippet

This is the standard solution for Adobe Target. Depending on the method of deploying Adobe Target, there are two slightly different snippets:

This solution works as follows:

  1. The browser starts processing the HTML.
  2. In the <head> section, the pre-hiding snippet hides the whole body.
  3. The browser continues processing the HTML, but any changes to the Document Object Model (DOM) will not be seen yet.
  4. The call to Adobe Target edge servers succeeds: the DOM is updated with the new content
  5. The Adobe Target code undoes the action in step 2, which means that the body is finally shown.
  6. If the call to Adobe Target edge servers fails or takes too long, after a timeout, the body is shown anyway.

There are a few additional notes that you should consider:

  • The snippet must be embedded in the <head> section of the HTML. This guarantees that, when the browser executes this JavaScript code, no content has been shown.
  • It cannot be added to tag managers, even if you load the tag manager from the <head>. The reason is very simple: by the time the tag manager is loaded and executed, the browser might have already shown some content from the <body>.
  • If you feel like the default timeout of 3000 (ms) is too short or too long, feel free to change it to another value that works better for you. This value is at the very end of the snippet.
  • Check that the CSS class that is added by the code is unique and you are not using it anywhere in your CSS.

This is the best practice and I strongly recommend this solution. I would not even consider the options I will explain below. I am only documenting them as I have had many customers who were willing to explore all options.

Move experiences below the fold

This is probably the most rudimentary alternative and the least useful. The idea is to only apply changes (i.e. Activities in Adobe Target) to the content below the fold. Since the content above the fold does not change, flicker is not observable.

I can see a couple of major issues:

  • The first one is the most obvious: you cannot personalize or optimize anything above the fold. This is really bad, as many visitors will not scroll down and will never see the alternate content. Besides, it is usually above the fold where you can have the biggest impact with your personalization or optimization activities.
  • Second, you need to evaluate what “below the fold” means in your case. You will need to take statistics of the screen sizes of your visitors, statistics of where your content sits on the screens and decide where to draw the line. I can guarantee that there will always be cases where flicker will be visible.

Accept flicker

As crazy as it sounds, I have had customers who were willing to accept flicker if that meant that their website loaded faster. They have even used tools to measure flicker, taking screenshots every few milliseconds and analyzing every minute detail. In their view, moving the tag manager (and, with this, Adobe Target) to somewhere in the <body> was worth the extra milliseconds they gained.

I need to clarify that this view always comes from the IT team, never from the marketing team. The latter understands the big impact of flicker and knows that a slightly faster website might not be that important. However, when the big bosses give the IT team this power, they will use it.

Hybrid or pure server-side

The last option that I am going to explain should be familiar if you have been following my blog. The idea is to have the content servers play a role in the personalization or optimization. If the problem is with the client, why do we not move part or all of the code server-side?

  • In a hybrid implementation, the content servers issue the request to the Adobe Target edge network, embed the result in the HTML, and let the Adobe Target JavaScript process it in the browser. This concept of hybrid is very different from the explanation I have in my old post from 2019 on hybrid Adobe Target. I hope I am not confusing you.
  • In a pure server-side implementation, the content servers issue the request, process the response, modify the HTML, and send the resulting HTML to the browser. I have an old post on Adobe Target server-side, which you can use as a general reference, but note that a lot has changed in the last 6 years.

One of my coworkers asked me a few days ago to document how to implement these solutions. Unfortunately, it is not so easy, with so many different cases and combinations. I tried to explain this issue in my post on Server-side Implementation.

What I can do is summarize the problems that you will need to solve for:

  • The solution is totally dependent on the Content Management System and Content Delivery Network. You will likely need to write custom code for both.
  • The cache strategy will take a big hit. All pages that have alternate content cannot be cached in full.
  • You will need additional server capacity to execute the extra code that must run on every page view.
  • There is no concept of DOM in the server. You will need to design a solution to process the instructions, usually based on CSS selectors, to manipulate the raw HTML.

Let me know in the comments if you have used other solutions.

 

Photo by Nikhita Singhal on Unsplash

Related Posts