Dear Experience League Communities,
We are facing a critical issue with our website's loading speed and flickering problem related to the implementation of Adobe Target's anti-flicker solution. Despite our efforts and following the provided documentation, we have been unable to resolve the issue. We would really appreciate your assistance in finding a solution to this pressing matter.
The Problem: Our client has reported that our website is loading slowly, which we have traced back to the implementation of the anti-flicker snippet. However, removing the anti-flicker snippet causes the original control version to briefly appear before the Adobe Target variant loads, resulting in an undesirable user experience.
Our Current Approach: Following the guidance from Adobe's documentation and other relevant sources, we added the anti-flicker snippet before loading Adobe Target through Google Tag Manager (GTM). Unfortunately, this has not resolved the problem, and the flickering persists.
We have reviewed the documentation:
https://terrynwinter.com/adobe-target-how-to-avoid-page-blank-and-flickering-issues/
We highly appreciate your expertise and support in resolving this critical issue. Thank you for your time and consideration. We eagerly await your guidance and are open to any additional information or insights you may require from us to assist in diagnosing and resolving this problem.
Best regards,
Update
- The snippet is working but the issue is that there is a blank page that stays one the page for a bit before our activity loads.
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Hi @miguelbm_1989,
So if you already have the possibility to include the at.js directly in the head, then also as first and without async and defer attributes.
<script type="text/javascript" src="AT SCRIPT"></script>
I would edit the AT SCRIPT file. Around the at.js code some kind of wrapper code - for example an IF query. This checks the OptanonConsent cookie if accordingly Consent was already given. So you have the advantage that you do not have to wait for anything else.
In addition, if no reload of the page takes place when the Consent would be updated - OneTrust certainly has an event that you can listen to, so that even if the corresponding Consent inital is not yet given - but the user then give consent, then Adobe Target should also load (if that is desired).
Dear @miguelbm_1989 ,
Have you gone through my blog on Flickering & Page Blank Issues (I know that you have already shared the link above, didn't you get the solution?).
To avoid Page Blank Issue, rather than hiding the entire body, try to hide just the element or the entire container having the element you are trying to change. This will eliminate the Page Blank Issue and will not show the default content (Flickering) before the test content (Because you are hiding the element).
Thank You, Pratheep Arun Raj B (Arun) | NextRow Digital | Terryn Winter Analytics
Yes! thank you for the information.
Loading Adobe Target through GTM won't work because GTM can only be executed in an asynchronous way. So there will be some gap between the anti-flicker snippet being executed and Target being loaded, which is why you see a blank page for a relatively long period of time.
The best option will be to load Target in the <head> of the page, completely separately from GTM
Oh ok!! perfect. I think we will follow your advice @alexbishop thank you so much!
Hi @miguelbm_1989,
basically there are pros and cons how it is included.
Yes directly on the page and at the top of the head - is pretty cool, because you then also no pre-hiding snippet and target is available faster.
But there are also reasons why it is being loaded via e.g. a tag manager. Basically that works too - but you have to pay attention to something more. It is important that with both variants Target is only executed if the user has given consent (if this is required in the respective country).
So if you embed it directly in the head - it is necessary to wrap the code e.g. and create a query before that checks the consent if it is given or not. Also, if the page is already loaded and the user only then gives consent - must be ensured that Target is loaded / executed accordingly later.
But if you embed it as in your case via the GTM - you must ensure that a pre-hiding snippet is loaded (I personally recommend that the pre-hiding snippet then really synchronously on the page far above embed). It is also important that this is only loaded if consent is given - otherwise users without consent will see the page white for 3 seconds (this step is important and many do it wrong). In addition, it is important, especially for asynchronous loading, that the target is loaded as early as possible.
Hope this helps you.
Thank you for your reply and your help!!! We will follow your advice of embeding it directly in the head. Ana also, wraping the code thath checks the consent.
Hi! @Perrin_Ennen ,
Thank you for your previous response. We have decided to directly add the code instead of using GTM.
However, we are now facing another issue. When we add the AT implementation script <script async type="text/plain" src="AT SCRIPT"></script>, AT loads fast. However, when we add it with the OneTrust class class="optanon-category-c0002" <script class="optanon-category-c0002" async type="text/plain" src="AT SCRIPT"></script>, the loading time of AT is slower, and we are still experiencing flickering. We suspect that the OneTrust autoblocker might be having an impact on the performance.
We are currently stuck and unsure how to resolve it. Have you faced this problem before?
Hi @miguelbm_1989,
So if you already have the possibility to include the at.js directly in the head, then also as first and without async and defer attributes.
<script type="text/javascript" src="AT SCRIPT"></script>
I would edit the AT SCRIPT file. Around the at.js code some kind of wrapper code - for example an IF query. This checks the OptanonConsent cookie if accordingly Consent was already given. So you have the advantage that you do not have to wait for anything else.
In addition, if no reload of the page takes place when the Consent would be updated - OneTrust certainly has an event that you can listen to, so that even if the corresponding Consent inital is not yet given - but the user then give consent, then Adobe Target should also load (if that is desired).
Views
Like
Replies
Views
Likes
Replies
Views
Likes
Replies