slowdowns in version 11

[arossiIT]

Recently we switched from Prebid 10 to a version > 11 (we tried several versions). Since we had no deprecated modules, the configuration remained exactly the same (no changes at all).

We are noticing a delay in the start of the auction of almost 500 ms compared to version 10.
Even with debug enabled, no warnings/errors are reported.

We followed the migration guide
https://docs.prebid.org/dev-docs/pb11-notes.html
We can’t figure out what is causing it. Was some pre-auction delay introduced that could explain this lag?

[dgirardi]

Could you link to a live website using the configuration in question and either Prebid version?

[fcurtiItaliaonline]

Hi Demetrio,
here you can find the URL

Virgilio using Prebid 10
Virgilio using Prebid 11

[dgirardi]

TL;DR: after #15421, the behavior of v11 should improve; if it doesn't improve enough, either pbjs.yield = false or pbjs.setConfig({auctionOptions: {viewabilityMeasurement: 'boundingBox'}}) should bring it inline with v10. Also, the prebid bundle name may be significant - see last paragraph below.

I was not able to reproduce the difference on those two pages as they are; however, I can reproduce it if I add artificial busywork to the main thread - the hypothesis is that for some of your users the page is heavier (some of the other scripts in it do more than they do in my tests). In that case, the time from page load to auctionInit increases much more in v11 than it does in v10.

11 did introduce an auction delay related to viewability:

Prebid.js/libraries/percentInView/percentInView.js

Lines 183 to 196 in 3073fbf

	export function mkIntersectionHook(intersections = viewportIntersections) {
	return function (next, request) {
	PbPromise.race([
	PbPromise.allSettled((request.adUnits ?? []).map(adUnit =>
	intersections.observe(getAdUnitElement(adUnit))
	)),
	// according to MDN, with threshold 0 "the callback will be run as soon as the target element intersects or touches the boundary of the root, even if no pixels are yet visible"
	// https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API
	// However, browsers appear to run it even when the element is outside the DOM
	// just to be sure, cap the amount of time we wait for intersections
	delay(20)
	]).then(() => next.call(this, request));
	};
	}

it was never intended to be a significant delay - it's capped at 20ms which is an order of magnitude higher than what it needs. However if the page is busy it can become significant (and much higher than 20ms).

#15421 does two things that are relevant here:

• it improves how the 20ms cap is implemented so that it's more likely to actually work; it should now take priority over other tasks and reduce the delay. How effective this is depends on those other tasks - if they're long running, or they use the same scheduling priority they would still interfere.
• it adds an option to opt out of the delay completely with either pbjs.yield = false (which already exists as an option, but currently doesn't affect this delay) or auctionOptions.viewabilityMeasurement: 'boundingBox' (to turn off this specific delay only).

Also of note: your v11 page uses a different name for the prebid bundle (iampb.js vs v10's prebid.js). This turned out to be significant; chrome has an apparently undocumented feature (LowPriorityAsyncScriptExecution) which in my case was enabled by default and had the effect of prioritizing prebid over other scripts - but only when the script is recognizably prebid, the v11 page was paying a penalty until I disabled that feature. This may be a confounding factor if you're running A/B tests with different bundle names.

[patmmccann]

but only when the script is recognizably prebid

Do we know how that is defined?

[dgirardi]

Do we know how that is defined?

There's a list of patterns it matches against, but it's not easy to browse. The rule, summarized:

• path contains /prebid., /prebid/, /prebid_, /prebid3., /prebid4., /prebid9., /prebid-load.js, /prebid-wrapper.js, /prebidlink/, or .prebid. → tagged → exempt from demotion, but blocked by ad blockers
• anything else → untagged → demoted, but survives ad blockers

A prompt to test an arbitrary URL:

Decide whether Chrome would apply LowPriorityAsyncScriptExecution demotion to a script.

  Script URL: <SCRIPT_URL>
  Page URL:   <PAGE_URL>        (required: domain rules are relative to the document)

STEP 1 — Get Chrome's ad filter list (not EasyList; Chrome uses its own).
  Repo:   https://github.com/chromium/chromium-ads-detection  (branch master)
  Path:   third_party/filter_lists/<highest version>/filter_list.unindexed
          Sort versions numerically: 9.70.0 > 9.9.0.

STEP 2 — Parse it properly. Do NOT use `strings` and do NOT guess rule type from
byte prefixes; that cannot distinguish block from allow and will give a wrong answer.
  Schema:  components/url_pattern_index/proto/rules.proto  (in chromium/chromium)
  Framing: the file is chunked, not one flat proto — see
           components/subresource_filter/core/common/unindexed_ruleset.h
           Each chunk is a length-delimited `FilteringRules` message; the rules are
           in its `url_rules` field.
  Relevant UrlRule fields: semantics (1=BLOCKLIST, 2=ALLOWLIST), source_type,
  element_types (SCRIPT=2, ALL=32767), initiator_domains / request_domains
  (each with an `exclude` flag), url_pattern_type (1=SUBSTRING, 2=WILDCARDED,
  3=REGEXP), anchor_left, anchor_right, url_pattern.

STEP 3 — Match. A rule applies only if ALL hold:
  - url_pattern matches the script URL, honouring url_pattern_type and anchors
    ("^" = separator, "*" = wildcard, SUBDOMAIN anchor = "||");
  - element_types includes SCRIPT (or is ALL);
  - initiator_domains admits the PAGE's domain (an entry with exclude=true means
    the rule does NOT apply on that domain);
  - source_type is compatible (THIRD_PARTY only if script and page are cross-origin).

STEP 4 — Resolve. An ALLOWLIST match suppresses any BLOCKLIST match
(LoadPolicy::EXPLICITLY_ALLOW beats WOULD_DISALLOW). So:
  any ALLOWLIST match  -> NOT ad-tagged
  else any BLOCKLIST match -> AD-TAGGED
  else                 -> NOT ad-tagged

STEP 5 — Verdict. Chrome's default is low_pri_async_exec_target=kNonAds, which
EXEMPTS ad-tagged resources. So:
  AD-TAGGED     -> NOT demoted; runs at normal priority.
  NOT ad-tagged -> ELIGIBLE for demotion, if all other conditions also hold.

Output, in this order:
1. One line: "Ad-tagged: yes/no" and "Demotion: exempt / eligible-if-other-conditions-hold".
2. The matching rules, quoted, with their semantics.
3. The conditions you CANNOT determine from a URL alone, listed as caveats:
   async (not defer/module), cross-site, outermost main frame, >=3 GiB RAM,
   not a low-end device, document <3s old, not a reload/form submission, not
   render-blocking, not matched by <link rel=preload>, and fetchpriority != "high"
   (each of these being false means no demotion). Also note Chrome tags a resource
   if an ad script was on the JS stack at fetch time, which is not statically knowable.

If you cannot parse the ruleset, say so and stop. Do not fall back to guessing.

[fcurtiItaliaonline]

Hi @dgirardi ,
just to be transparent here you can find the performance we are registering for PreBid v10 and v11

Legenda

iamHBStart
the tracking runs just before window.pbjs.que.push

iamHBprebidStart
the tracking runs as first command inside window.pbjs.que.push

iamHBprebidRequested
the tracking runs on pbjs.onEvent bidRequested event

iamHBprebidEnd
the tracking runs as first command inside the pbjs.requestBids callback function (bidsBackHandler)

The reported metrics in in ms ( 3.3 k means 3.3 secs )

Prebid v10.23.0

Prebid v11.25.0

[dgirardi]

I think that tracks with the viewability changes as the likely culprit; the new delay would be between HBprebidStart and HBprebidRequested and that's where most of the delta is. HBStart is 100ms later on 11; could that be due to the bundle name quirk -or did you factor that out?

[fcurtiItaliaonline]

HBStart is 100ms later on 11; could that be due to the bundle name quirk -or did you factor that out?

It could be, but this delay is not what worries us the most