Flicker, personalization and page speed
15 Dec 2024 » Opinion
I have already written about the problem with flicker and the main solutions to it. I also remember how I received some comments agreeing with my views about the page speed zealots. The obsession with page speed is ever-increasing, which is having some unintended consequences. Today I want to show how you cannot have everything and you need to find a compromise.
The problem
Let’s consider the following sequence of events:
- User finds an interesting website after an Internet search and clicks on the link.
- Browser does not have anything from the website in its cache.
- Browser downloads the HTML of the main URL.
- Browser starts processing the HTML, top-down.
- Browser finds the URL of a tag manager, downloads it, and processes it.
- Tag manager hides the body of the page, to avoid flicker before any content is painted.
- Tag manager downloads any alternate content from the personalization engine.
- Browser continues processing the HTML, downloading any further assets and content.
- Browser paints content from the HTML; step 6 prevents this content from being visible.
- Tag manager replaces areas of the default content with the alternate content it downloaded in step 7.
- Tag manager unhides the page.
As you can see, a lot is going on. Some people expect that the whole process 11 takes less than 1.5 seconds. If any of these events take more than their fair share of time, the time until step 11 is going to be more than the expectation. We are talking of ~150ms for each step, and many unexpected things can happen. The Google Lighthouse scores have not helped with these unrealistic expectations, as the timing of step 11 is one of the key metrics.
I am going to stick with this sequence throughout the rest of the post. I am fully aware that there could be another sequence of events, like converting step 5 into an asynchronous download. However, describing all cases would require a very lengthy post that no one would read and the sequence above is generic enough for my explanation.
Pick two
The way I see it is that you have to take sides, you have 3 features and you need to choose 2:
- Fast page
- No flicker
- Personalization
Let’s see each combination.
Fast page and no flicker
With this combination, what you are basically foregoing is the capability of personalizing your website, by showing only the default content. In other words, you are removing steps 6, 7, 10, and 11, with the rendering in step 9 being visible to the end user. It is obvious that, with so many steps removed, you are more likely to be fast, and since there is no alternate content, there is no flicker.
However, I still have to find a marketing team that is happy without a website personalization and optimization engine. It is very easy to demonstrate the currency value of these marketing activities, which makes them a requirement.
Believe it or not, one of my customers’ IT team forced this approach down the marketing team’s throat. The compromise was to move the tag manager code (step 5) below the fold so that it would still be possible to personalize or optimize content below the fold. Since it is not initially visible until you scroll, flicker is not visible. The consequence was that it was impossible to personalize or optimize the top of the page, the most revenue-generating part of a page.
Fast page and personalization
If you skip steps 6 and 11, the browser will start showing content at step 9 instead of step 11. This will increase your Google Lighthouse score, as content will be shown early.
However, this will create a massive flicker. When step 9 is reached, the end user starts seeing the rendered page. Then, upon reaching step 10, parts of the content will be swapped with other content, right in front of the user. Human eyes can see changes happening within a few hundred milliseconds. The perception of the website will be quite negative: people will think that they are being scammed, as the offer they initially saw is no longer available. Again, I have yet to find a marketing team who is happy with flicker.
What surprises me the most about this option is that technical teams are happy with flicker. They do not see it as a major issue and to keep the page load time within their requirements, they will tolerate flicker. This is not a theoretical situation, one of my customers took this approach.
Personalization and no flicker
In this case, what we do is agree that 1.5 seconds is not a hard requirement, but a nice to have. In many scenarios, this goal will be achieved, but not always, and Google Lighthouse scores will show it.
In my personal opinion, this is the best option. Business teams usually favor this option, while IT teams are mainly driven by page speed. I still have scars from the battles I have had to fight with IT teams, defending this option.
The rules of the Internet
When fighting these battles, not only do I feel isolated, but I also have the feeling that my customers blame Adobe for this situation. Many expect Adobe to find a magic solution to get all 3 features. However, you will have noticed that this is the first time I have mentioned Adobe. All that I have explained above is generic to any digital marketing technology. These are the rules of the Internet.
One problem that I have not mentioned yet is that browsers have their own dynamics. They decide when and how content will be downloaded and there is no way to influence them. Maybe, if browsers created new APIs for client-side personalization libraries to interact with, we could mitigate the issue at hand. As far as I know, such APIs do not exist and are not expected.
Potential solution
Is there a better solution than having to pick 2 or reaching trade-offs? The short answer is yes.
The long answer is that you are not going to like it. This solution means moving much of the processing from client-side to server-side, just like what I explained in my posts on Adobe Target server-side. In this case, the steps from the beginning of the post would be rearranged to:
- User finds an interesting website after an Internet search and clicks on the link.
- Browser does not have anything from the website in its cache.
- Browser requests the HTML of the main URL to web server.
- Web server downloads any alternate content from the personalization engine.
- Web server manipulates the default content in its cache, applying the alternate content.
- Web server returns the HTML, which includes the personalized content.
- Browser starts processing the HTML, top-down.
- Browser finds the URL of a tag manager, downloads it, and processes it.
- Browser continues processing the HTML, downloading any further assets and content.
- Browser paints content from the HTML.
With this solution, you get all 3 features:
- Fast content, as there is no hiding of the page and the contents coming from the web server are ready to be displayed.
- No flicker, as the browser does not need to get alternate content while hiding the body.
- Personalization.
So, why is everybody not jumping into this solution? It turns out it has many issues, some of which are:
- It requires server-side processing, against current Content Management Systems best practices.
- This server-side processing is complex.
- Single Page Applications will require extensive re-architecture.
- Using the Visual Experience Composer in Adobe Target may not be possible, a major hurdle for marketing teams.
I have never seen any of my customers succeed with an Adobe Target server-side implementation. I have heard of one or two cases, but even then I am not very convinced of the capabilities.