Feature: Cancel prebid when global timeout is reached

[BartVB]

If a user has a slow connection 'initAdserver' is called before prebid.js is even loaded. In most cases it's unproductive to continue loading prebid, because prebid won't be able to adjust the ad server targeting in time.

Chances are that the user is on a really slow mobile connection. It would be nice if the extra (fruitless) calls created by prebid.js could be canceled in that case.

I guess I could just set 'pbjs' to empty when the global timeout hits but that's far from elegant.

Thanks @BartVB and happy new year. Is your concern mainly around the additional outbound calls made after the timeout is reached? E.g.

0ms: first outbound bidder call made
300ms: second outbound bidder call made
500ms: timeout hit
600ms: third outbound bidder call made

And your point is the third call could be avoided. Is that the case? Or are you concerned about other bandwidth usage?

[BartVB]

A happy new year to you and your team too!

I'm concerned with everything that increases latency for the user. What I see on slow mobile devices/connections is something like this:

600ms: Page loaded
700ms: Prebid timeout is called
800ms: GPT and Prebid javascripts are loaded
1300ms: GPT is called, ads are loaded
1400ms: Bidder call 1
1450ms: Bidder call 2
1500ms: Bidder call 3

In this scenario it's no use to even load prebid.min.js because Prebid will not be able to affect ad targeting.

This is a rather extreme case, but at the least it would be nice to just cancel all outgoing bid requests that are still in the Prebid queue when the timeout happens.

Gotcha thanks @BartVB. I think there're 2 cases here:

Case 1
The case you outlined. pbjs hasn't even got loaded when the page timeout is reached.
In this case, canceling out the pbjs calls should be straightforward and would definitely have a positive impact on the page load.

Case 2
The example I gave in the previous comment, where the timeout happens in between bidder calls.
Not sure how likely this case will actually happen, because prebid.js goes through all bidder calls in an array fairly quickly. Like you said, this case may happen in mobile where the number of concurrent requests are limited. But that's controlled by the browser, so canceling pbjs calls may not have any effect.

Would you agree? If so sounds like case 1 (your example) is more relevant here and we should focus on that.

[BartVB]

We seem to have agreement on all points made :)

But case 1 and 2 are not that dissimilar. My guess is that it's going to be pretty hard (impossible?) to cancel loading prebid.min.js when the timeout is reached and the script hasn't loaded yet. If that's the case then all that's left is making sure that Prebid doesn't use any more CPU cycles than needed, that would also help the case where a few (or all) bid requests have been made already.

[Heray]

Thanks @BartVB. It took us a while to get bandwidth to rethink on this. Like you mentioned, case 2 is pretty hard to do. So we focused on case 1. The challenge we're running there is, in a good prebid setup, case 1 should happen less than 5%. Otherwise the header really should be restructured, so that the bids at least have a chance to get sent out. So we didn't want to spend much time trying to making a bad setup better, when the root cause can be fixed in a different way. Would like to hear your thoughts on this.

[BartVB]

This really depends on what the publisher wants. I've seen case 1 happen quite a few times on mobile devices. If these devices are slow and have a spotty connection then I (as a publisher) don't want to wait for header bidding. If just loading and parsing prebid takes 2 seconds then we're looking at approx 5 seconds before ads are loaded and at least 8 seconds before the ads are visible.

In such an environment it's better to just load GPT as quickly as possible. The added revenue of header bidding does not compensate for the loss in impressions because of this latency. Loading GPT as quickly as possible also means cancelling everything prebid related.

But I agree that this would complicated the implementation. I'm also not sure what the priority of this should be. I'll see if I can get some statistics regarding latency on mobile devices.

[protonate]

I haven't tested this but would it be possible to add the script tag that loads prebid as async and with an id attribute such that the bid timeout handler could remove the script tag altogether?

[mkendall07]

@BartVB
I'd like to point out our solution to load GPT before prebid.js here, as that might improve latency on mobile: https://github.com/prebid/Prebid.js/blob/master/integrationExamples/gpt/pbjs_example_gpt.html

[mkendall07]

I don't think it's practical to cancel in flight requests so closing this out for now.