A MutationObserver waits on the page and reacts to two changes: when the element is first added to the page, and when the element is updated with the variant.The second JavaScript snippet is added to the top of, because the observers need access to document.body. This is timing number (3) in the list above. This script uses the optimize.callback API to collect the timestamp of the experimentation library load. The first bit of JavaScript is run at the very top of, even before the Optimize snippet. You can’t execute this code reliably through a dependency like Google Tag Manager, because Google Tag Manager in many cases loads after all steps (1)-(4) have already happened, meaning you won’t get accurate measurements. The solution will rely on two pieces of JavaScript code running directly in the page template. Introduction to the JavaScript we’ll need (3) is interesting metadata about how the experimentation library itself works, and how fast it manages to apply the change after loading. If the element isn’t visible in the viewport, or if the experiment is applied before the base element becomes visible, the flicker is not a problem. The flicker is the time delta between (2) and (4). Time when the experiment change was applied to the page.Time when the experimentation library was loaded,.Time when the original element became visible in the viewport,.Time when the original element was added to the page,.In order to measure the severity of this flicker, we need to collect a number of timings: You’ve deployed the asynchronous snippet, and you are not using the anti-flicker JavaScript, so there’s a visible and measurable flicker in place.įlicker of the original (grey background) before the variant (red background) You’ve deployed Google Optimize using the new snippet. You’ve got an experiment running that treats a home page element, which is visible above the fold if the page is loaded without a scroll threshold in place. So, let’s assume the situation is as follows: But still, OUCH! Measuring the impact of flicker Naturally, if the container loads before that, the page is revealed faster. If the endpoint is unresponsive or lags, Google Optimize’s default anti-flicker snippet has the page wait for a maximum of 4 seconds (this is adjustable) before revealing the content. It doesn’t matter if there are mitigations in place for ad blockers and download errors. I simply can’t fathom the logic behind potentially sacrificing the usability of the entire page just to get better data quality for your experimentation.Ĭonsidering how crucial page performance and perceived page performance is these days, I steer clear of anti-flicker snippets that hide the entire page. This is, and has been, my biggest objection about how A/B-testing tools are implemented. The purpose here is to actually hide the entire page until the experimentation library has loaded. This is fairly elegant but it might introduce a slight flicker of another kind, where the element seems to “pop” into place out of sequence with the rest of the render.Ī similar solution is anti-flicker JavaScript. Only once the element has been actually added to the page, can Optimize then modify it and unhide it. ![]() They inject a style declaration that sets the visibility of all elements matching the CSS selector of the experimentation targets to hidden. Instead, libraries like Google Optimize, when loaded synchronously, actually hide the element that’s being tested. Since the library is loaded at the top of, a synchronously loaded library doesn’t have access to the elements it’s designed to modify (since those elements are created in the, which hasn’t yet been generated). However, it’s not like synchronous loading actually fixes anything automatically. Once the download is complete, and as soon as the browser has an available slot in its single thread of execution, it will start parsing and executing the JavaScript within the library.īy moving from asynchronous to synchronous loading, you solve part of this issue. ![]() Instead, it proceeds with the page render. ![]() Async load means that once the browser starts to download the library, it doesn’t wait for the download to complete. This is most often a problem when you’re running scripts asynchronously. The flicker happens because the page with the modified element is being rendered from the page HTML source, but the experimentation library needs to wait for an opening to allow the browser to process the experiment data. With JavaScript-based experimentation libraries, you’re subject to the rules and limitations of the page render in the browser. Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!
0 Comments
Leave a Reply. |