VWO Logo
Like this post?
Read our in-depth guide to Conversion Rate Optimization
Share this post
4 Min Read

Faster Website Loading: Visual Website Optimizer Asynchronous Code Snippet Is Live

Paras Chopra
Founder and Chairman of Wingify.

Any (synchronous) external or 3rd party JavaScript code you add on your website has potential to slow down your website. A vendor who says your website won’t slow down is probably lying. And, as every marketer knows today, page load time is pretty important. It affects your conversion rate and search rankings.

We are committed to our customers’ site speeds and therefore proud to announce immediate availability of asynchronous code snippet for Visual Website Optimizer (VWO). This new code snippet has been months into development and refinement, and now we are first A/B testing vendor to come up with an asynchronous code snippet and are very excited about it! If you are a Visual Website Optimizer user, we highly recommend you to update your code snippet to new asynchronous one.

What is Asynchronous loading?

Essentially, instead of loading VWO code and your website sequentially, asynchronous code will load both in parallel, thereby speeding up your website load. See following graphic to understand it fully:

Advantages of Asynchronous code snippet:

  • Much faster website loading: asynchronous code snippet loads variations and other data in parallel to your website loading, so unlike earlier synchronous code, your website loading is not stalled until we have loaded variation data and other VWO code. With new code snippet, all JavaScript code and variation data loads parallely.
  • Fallback to control in case our servers are unavailable: in a rare and unlikely case our servers are unresponsive or take some time to respond, a timeout will happen and your original page will be shown. As history shows, even though it is rare, due to network unavailability or DDOS attacks, even best networks and servers can become unresponsive. The asynchronous code snippet has a timeout setting (default is 2 seconds, but is configurable — see below), and if our servers don’t respond within that time, your normal page will get displayed.

How to get Asynchronous code?

Login to your Visual Website Optimizer account, and go to ‘Get Tracking Code‘ section (under Tools tab).

Settings available in Asynchronous code

In code snippet, you will find two variables that you can adjust (although we recommend keeping default values intact).

  • settings_tolerance=2000 this is the maximum time (in milliseconds) for which the code snippet will wait for test settings to arrive from our servers. If no settings arrive within this period, timeout will happen and your original page will get displayed (test won’t run in this case, as fallback has happened).
  • library_tolerance=1500 this is the maximum time (in milliseconds) for which the code snippet will wait for our JavaScript library to get downloaded from our Dynamic Content Distribution Network. If no file arrives within this period, timeout will happen and your original page will get displayed (test won’t run in this case, as fallback has happened).

Note that in normal circumstances, all the data and files that need to be download will get downloaded in 100-200 milliseconds, so the timeout is an absolutely maximum threshold and can safely be kept as it is.

If you decrease the threshold, one side effect of it would be that some visitors (with slower connections or with have local ISP/network issues) may not be able to become a part of your test (because timeout occurred for them), so you may potentially lose some visitors or conversions registered in your A/B test.

Compatibility of Asynchronous code snippet

The new code snippet is compatible with all browsers. WordPress, Joomla , Magento and Drupal plugins are available. (We are currently working to update Google Analytics and SiteCatalyst ย plugins)

Highly recommended: use new Asynchronous code

Because of numerous advantages of new asynchronous code snippet, we highly recommend you to start using it as soon as possible. In case you have any questions or suggestions, please feel free to contact us at support@vwo.com

AB Testing Done at Scale

Comments (24)

  1. Cool – even though it’s been in beta for a while it’s still a huge step towards a faster user experience. Keep up the good work!

  2. Hi Paras

    Thinking of the old “Amazon” study from 2007, where they found out that 100 ms extra load time decreases their sales by 1 % – this update increases conversions in it self ;). Great job Paras.

  3. But won’t this mean that visitors may see the original (control) variation before they see the variation they should be seeing? Because the website may load and show the original then after VWO is done loading it’ll flick over to the new version.

    1. @John: no there is no flickering. We use techniques to avoid flickering. (This blog also has asynchronous code installed, and you may not be noticing any flickering).

  4. so using vwo wordpress plugin will automatically make set to asynchronous code…? or do we still need to manually set it on wordpress?

  5. So … I’m using VWO plugin on my WordPress site (and not the code snippet).

    Is this update automatically available in a plugin too or do I still have to install this snippet?


  6. Does the Asynchronous code work in conjunction with the Synchronous code? (whole site is not on wordpress, so have to manually change some other pages)

  7. Interesting, however you hide the whole body via opacity: 0 while loading the snippet asynchronously. So while there is no flicker, this is because the whole page is hidden… which is potentially WAY worse.

    This is not a very clever antiflickering technique ;), but it may still interest some users. Note that there is absolutely no clever antiflickering technique that will allow you to use asynchronous loading.

    Which means if you use a JS based A/B testing solution, you have to deal with synchronous loading. This is just a fact.

    1. @Jean-Noel: while your assessment about opacity trick is correct, actually your reasoning of synchronous being better is wrong. Note that even if whole page is hidden, in the background page is getting loaded anyway. While, in comparison to synchronous, the whole page is stalled until the data arrives. So, in totality, asynchronous ensures much quicker page loads as comparison to synchronous loading.

  8. I did not say synchronous is better. I agree with your reasoning overall; loading asynchronously is a bit better.

    However, even if on the whole the page loads in 1000ms instead of 1200ms, what I meant is that you still have a stall period of 200ms: in the synchronous case, it’s a real stall, while in the asynchronous case, it’s a false stall (hidden page). But to the users, it’s the same (eg, if this 200ms delay turns off an user, he will bounce all the same).

    That’s why I said that A/B testing via JS inherently induces a stalling period similar to a synchronous load. Note that I am not an advocate of A/B testing on the server anyway, since JS has tons of other advantages compared to the server. But this one disadvantage cannot be removed. That was the meaning of my comment ๐Ÿ™‚

  9. @Jean-Noel: Heya, have you taken into account that for a page that loads in 1000ms, the first 4-600ms of that may be JS / CSS assets. If VWO asynchronously loads within that time (which it likely will), then there is no delay to the user at all (assuming the assets being downloaded don’t saturate the end users bandwidth). If the basic page assets take less than 200ms, then the page is likely fast enough that a little bit of extra time from VWO shouldn’t matter.

    I had been thinking the exact same thing as you, but now this seems to make a bit more sense in my head.

    (Disclaimer: I don’t represent VWO, I’m just a customer who’s trying to understand the implications so I can pick between async / sync).

  10. Even if the first elements are JS /CSS assets, the problem is the same since those elements *should* be loaded asynchronously (for CSS, asynchronous is by default anf there is in fact no way to force a synchronous load). So the HTML will start loading, and you then have to choose between hiding the page or blocking its load.

    So, same problem, except if you load your other JS scripts synchronously, which you should not ๐Ÿ™‚

  11. @Jean-Noel: Good point! I think it’s a tiny bit more complex than that though (but I am not sure about the implications yet). Yup, CSS is asynchronous (I did not realise this until today), but JS by default is not. If you put your JS after your CSS (which is generally a good idea), the JS will not be executed until the CSS has loaded, and thus the CSS is effectively blocking.

    I assume this is what you meant when you said: “So, same problem, except if you load your other JS scripts synchronously, which you should not :-)”

    Unfortunately, a lot of people still load their scripts in the head synchronously because they don’t know better. Or they are using tools where they don’t have so much control (WordPress or whatever). Or it’s a good idea to (any scripts which are going to directly affect the DOM at load, such as Modernizer or something custom, to prevent the page from jumping), alternately it’s sometimes a good idea if the number of requests being made in the head is small (<= 4) and then queuing is not an issue, so a script tag in head can give you the fastest usable page.

    I'm having a bit of trouble wrapping my head around what this means though. As best I can work out, I'm not 100% sure the above matters (as interesting as it is!) – The only speed advantage asynchronous VWO gives you is that the body has time to render / start fetching images and such while the VWO script is downloading / executing.

    Does this sound sane?

  12. @Paras: A test I’ve just set up with the async snippet is definitely flickering before page load. I’ve emailed VWO support about it and I was told that it was normal that some async tests will flicker and that I should switch to synchronous code. Would you be able to shed some light on why this is the case?

  13. Awesome, one of your engineers just followed up supports last email by explaining this a bit better (impressive service!). So it’s only if I directly edit CSS / JS using add CSS / JS then I get this flickering, but if I use the standard test editor then things are fine – I’ve just updated the test and now no flicker :).

Leave comment

Your email address will not be published. Required fields are marked *

More from VWO

A Psychological Guide to Improving Conversions

According to Harry Levi Hollingworth, the man who brought psychology into the world of advertising,…

Read More
Ankit Oberoi

Ankit Oberoi

17 Min Read

A/B testing for Joomla: plugin for Visual Website Optimizer

We already have A/B testing plugin for WordPress and Drupal. Today we are proud to…

Read More
Paras Chopra

Paras Chopra

Less Than a Min Read

Top 10 eCommerce Websites (by Conversion Rate)

The Nielson Company regularly releases data for conversion rate of different websites via its MegaView…

Read More
Paras Chopra

Paras Chopra

4 Min Read

Join 10,000+ Marketing, Product & UX Folks

Latest news, views & inspiration in experience optimization for driving growth

A value for this field is required.