The Next Generation of Visual Website Optimizer is launching on 29th April 2014 See What's Coming

Faster website loading: Visual Website Optimizer Asynchronous code snippet is live

Posted in News on March 13th, 2012

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 or Content Distribution Network (CDN, currently Amazon’s Cloudfront) 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 Content Distribution Network (Amazon Cloudfront). 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@wingify.com

Paras Chopra

CEO and Founder of Wingify by the day, startups, marketing and analytics enthusiast by the afternoon, and a nihilist philosopher/writer by the evening!

The Complete A/B Testing Guide

Know all that you need to get started:

  • What is A/B Testing?
  • Is it compatible with SEO?
  • How to start your first A/B test?
Show Me The Guide


Tags

24 Comments
Kayle
March 13, 2012

Will this code work with the Google Analytics integration?

Paras Chopra
March 13, 2012

@Kayle: yes, it will!

Michael Kjeldsen
March 14, 2012

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!

Paras Chopra
March 14, 2012

Yes, we’re quite excited about it too :)

Robert C
March 18, 2012

Will this a Asynchronous code work with your Magento extension?

Sebastian
March 19, 2012

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.

Paras Chopra
March 19, 2012

@Robert: yes, it will work.

John
March 19, 2012

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.

Paras Chopra
March 19, 2012

@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).

matthew hunt
March 19, 2012

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

Timo Kiander
March 22, 2012

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?

Cheers,
Timo

Paras Chopra
March 22, 2012

@Timo: we have updated WordPress plugin too. It should be automatically available when you update the plugin.

Mike
March 23, 2012

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)

Paras Chopra
March 24, 2012

@Mike: you cannot use both codes in one page. It can be either synchronous or asynchronous code.

Mike
March 24, 2012

I meant on different pages – but same site.

Paras Chopra
March 24, 2012

Yes, in that case, it shouldn’t be a problem.

Jean-Noel
April 24, 2012

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.

admin
April 25, 2012

@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.

Jean-Noel
April 25, 2012

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 :-)

Jai
September 17, 2012

@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).

Jean-Noel
September 17, 2012

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 :-)

Jai
September 18, 2012

@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?

Jai
October 8, 2012

@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?

Jai
October 9, 2012

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 a comment
Required
Required - not published


seven − = 3

Notify me of followup comments via e-mail.

RSS feed for comments on this post. TrackBack URL

I ♥ Split Testing Blog


Stay up to date

Recent Posts

Write for this blog!

We accept high quality articles related to A/B testing and online marketing. Send your proposals to contribute@wingify.com