05-11-2020 11:36 PM - edited 05-11-2020 11:40 PM
after using Adobe Target synchronously (through utag.sync.js) my company wants to jump on the asynchronous train using Adobe Experience Cloud Visitor ID as tag in conjunction with the latest Adobe Target tag (2.3.0), both bundled into the utag.js.
The target library is played out using the visitor ID service is used, all good so far.
Problem is: the page flickers when displaying Target A/B tests which was never the case when we synchronously played out the old at.js library via utag.sync.js and it blocked the rendering of other page parts.
Of course it's an asynchrounous issue since the necessary calls to Target to retrieve information about the running A/B tests while the rest of the page continuing to load / render.
Adobe is having it's own documentation on this, providing a body-hide script that needs to be implemented on the page (I placed it in the utag.sync.js for testing). This script has a built-in timeout which will show the body again after 3s of white void.
Correct me if I am wrong but looking at the target tag the body should be shown as soon as the necessary target calls are made which never seems to happen. So we have an ugly 3s white page before anything is shown even though there are Target activities already rendered on the body, i.e. partially cut off animations as soon as the body shows.
Again, I can see all target activities being loaded in the network request (filtered for "delivery?client=") and on the page so basically the library does what it should, just not show the content on time...
Grateful for any ideas
Hi @bjoern_koth, it has been my experience with other personalization tools that the only way to avoid the flicker issue is to implement synchronously.
That said, for the 3 second built-in timeout, have you tried editing it to see if 2 seconds, or even 1 second, works? I worked on a similar issue before and we went down the route of manipulating the timeout to reduce the "hide" as much as possible.
Hi Jane, thanks for the input. We're also looking into a different approach which is instead of the global hide and show have the page let us know which are the relevant pieces on it which may be changed and to only hide/show those. Another approach would be using skeleton loaders on the page itself for heavy content such as banners which may be subject to dynamic replacement.
Bottom line is that we want to play out Target with Tealium but due to the increasing number of warnings on Chrome about synchronously (through utag.sync.js) loaded scripts it is not completely unthinkable that at some point in the future Chrome might block them altogether for the sake of speed (which is already the case for low network speeds).
Also funny that Adobe's Launch is actually also leaving the pre-hide task up the pages who integrate it but has no means of synchronous code injection due to its async by default nature.
We'll see where we end up