Prebid.js: Rubicon is loaded after response from other bidders

[mercuryyy]

Please see attached image.

First file is prebid.js
next 3 is brealtime
next 1 is sovrn
(so fare they all started the request at the same time)
next 3 is rubicon fastlane json they start the request only after the others finish.

same response here:

shouldn't they all start the request at the same time? i think this might have something to do with when calling the rubicon "http://ads.rubiconproject.com/header/ACCOUNT-ID.js" file, which gets called at the same time as brealtime,sovrn

Im using latest build 0.12 (not pre) updated 1 day ago.

[bretg]

The Rubicon adapter loads another library before calling the exchange -- this may be a source of delayed start compared to adapters who don't load additional code.

You may be able to improve auction timing by 'preloading' the Rubicon library higher in the page, like just after loading Prebid. e.g.

 <script src="//ads.rubiconproject.com/header/ACCOUNTID.js" async></script>

[mkendall07]

agree with Bret, this is most likely caused by additional latency around loading the Rubicon library.
@bretg
Is removing the account.js dependency on your roadmap?

[mercuryyy]

@mkendall07

So i think when loading the account.js that's what loads the ad tags .fastlane .json file so i dont see how i can split this from the prebid code

setIntegration("pbjs"),window.rubicontag.run(a,o)}))}var b=window.location.protocol+"//ads.rubiconproject.com/header/",m="rubicon",v={"468x60
.....

[bretg]

@mercuryyy - you're right, loading the library is required. Note that it's not just code that's loaded, but also account configuration.

It is on the roadmap to move code and config either into the server and adapter, but it will take some time for that transition.

[mercuryyy]

Thank you @bretg so as for now there is no way to async load rubicon ?

[Deimos01]

Hello guys,

I just move the loading of "ads.rubiconproject.com/header/XXXXX.js" in the header of my page instead of letting prebid call it.

Here the result (ignore Criteo) :

Before

After

So i don't know if it's helping but this method is working for me (v0.11.0)

Thank you

[mercuryyy]

It looks good. How did you implement it in the code? Because header.js calls the account configuration for prebid settings

[mkendall07]

I don't really recommend loading Rubicon outside of prebid.js because it will be requested twice in that case (although it may speed up Rubicon response).

[snapwich]

@mkendall07 the rubicon adapter will detect if the rubicon code has already been externally loaded and if so will not make a second request.

[mercuryyy]

@snapwich @mkendall07

looks like loading rubicon header .js before prebid fixes a lot of latency problems and improves win rate by a good number.

Now i see the same behavior for AOL adapter but they load adtech .js for each ad units and they load 300-400 ms after the other bidders even worse then rubicon i think loading all bidders at the same time should be first priority ?

For anybody testing try adding this before your prebid code and share results.

(function() {
var bct = document.createElement('script');
bct.type = 'text/javascript';
bct.async = true;
bct.src = (document.location.protocol === 'https:' ? 'https:' : 'http:') + '//ads.rubiconproject.com/header/ACCOUNT_ID.js';
var node = document.getElementsByTagName('script')[0];
node.parentNode.appendChild(bct);
})();

[Deimos01]

@mercuryyy

Your code is working, i will realease (today or tomorrow) the rubicon optimized version on my network and confirm if it improves really the win rate :).

I just discovered maybe there is the same problem for Pulsepoint too :

I think if we load all the librairies externally, it could be a great improvement for latency and maybe the win rate.

[mercuryyy]

I'v experienced a 10% increase in bid win rate for rubicon after these changed. not to mention the ad visibility increased from 42% to 45% very very significant.

before: 2,000,000 impressions (rubicon won 281,000) seen this number stay the same for over 30 days

after 2,000,000 impressions (rubicon win 313,000)

Pretty significant change. i wonder why all the libraries from adapters are not set in an ararry and loaded all together async at the top of the prebid code?

[Deimos01]

Indeed, it's a great optimization for you !
I just launched my new optimized configuration. I will have a beginning of report tomorrow.

I have an other question.

Rubicon is always the longest partner to answer in my setup (like you can see in my previous picture), so i'm dependant of him to launch my adservercalls with the winner.
I think it's complicated to reduce the time of the answer so is it possible to switch the SSP adcalls priority in prebid ? Appnexus is always the first in my setup, i would like to switch with Rubicon.

Thank you !

[mkendall07]

@mercuryyy
We have talked about the idea of "pre-loading" adapter libraries before anything else to speed responses. While this sounds like a good idea, it's not ideal. The 2 main reasons we haven't pursued this are:
1) We'd prefer (and may require eventually) adapters have all their code contained within prebid (and not downloaded as a separate HTTP call)
2) Prefetching requires additional configuration and setup on the page.

Interested in hearing others thoughts on this as well

[mercuryyy]

@mkendall07
i think the addition to the win rate is well worth it. in response to "1"
I doubt all networks will get to load all the code from prebid in the next 1-2 years, increasing the performance tho can lead to better revenue and increase in popularity and more willing to improve.
Maybe its best to require them to update the adapters to include the code now or to use my method to async pre load their libraries.

I tried doing the same thing with The AOL library for example "https://secure-ads.pictela.net/rm/marketplace/pubtaglib/0_4_0/pubtaglib_0_4_0.js"

But it does not work in this case like it did with rubicon, now AOL is loading 300-400ms after rubicon, same problem i had before if i disable AOL i get a 3-4% increase in ad visibility and 5% better ad fill rate. so i can actually make 4-7% more money if i disable the AOL adapter. ;/ NOT to mention 1.5 Seconds decrease in page load time in google analytics from 8.5 to 7.0.

[mkendall07]

@mercuryyy
Yes valid points. Also it's up to pubs to manage and a/b test bidders to see which perform for them. This is all very publisher specific.

We will be taking a stronger stance on adapter performance when we release prebid 1.0.0. Expect to see more related to this soon.

[mercuryyy]

True, but most publishers wont know how to optimize bidders to load at the same time, and even after i fixed rubicon there is nothing i can do about AOL loading after rubicon. its up to the ad networks to make their adapters to a fixed standard.

As it might take a one adapter (network) longer time to give a bid response so yes a/b testing bidder and dropping them is important. But when bidders load like in the attached screenshot, you can see AOL started the request 300-400 ms after the other bidders then a/b testing wont mean much here because you cant get the full picture.

when you have:

sovrn - 200ms
rubicon 400ms
aol - 400ms

if they all loaded together prebid will end at 400ms but when aol loads 300ms after prebid ends at 700ms
this [400ms || 700ms] action end difference can result in 2-3% at fill rate and ad visibility rate change which is very significant in large scale and makes a/b testing not really valid

[bretg]

@mercuryyy - may I enquire what site you're working with? Would like to get your data point on performance characteristics. (If you'd rather not give the domain here, could find it with the Rubicon account ID or email me at YmdvcnNsaW5lQHJ1Ymljb25wcm9qZWN0LmNvbQ==)

[slimkrazy]

@mercuryyy

The team at AOL are re-writing that adapter (they never created the existing one) and should have a far better one pushed to this project within the next few weeks.

[Deimos01]

Hello,

Just to share the information.
After few days of running optimized version on my network, i can confirm a +10% increase of paid impressions for Rubicon.

900 000 per day => 1 000 000 per day

[mkendall07]

Closing this out as it's not an issue that can be addressed by prebid core.