Inside the Prebid.js wrapper

0:00Welcome, outcomes and key terms

Play from 0:00 A news publisher in Hyderabad asks a simple question. Why do our ads appear so late?

Play from 0:18 We open their wrapper. The timeout was never set, so Prebid can wait up to three seconds on every page. On their slowest pages, the first ad arrives three and a half seconds after the article. That's an illustrative case. By then, most readers have scrolled past the slot.

Play from 0:27 The fix took one line. Finding it took knowing where to look. This is Module 2 of the Header Bidding Masterclass: inside the Prebid.js wrapper.

Play from 0:38 By the end of this module, you'll be able to do four things.

Play from 0:42 Read a full Prebid wrapper, line by line, and spot four mistakes that quietly cost money.

Play from 0:49 Choose a timeout with a proper split test, judged on revenue per thousand sessions.

Play from 0:54 Keep ad slots from hurting your Core Web Vitals: LCP, INP and CLS.

Play from 1:02 And put consent, identity and data modules in the right order, with a time budget for each.

Play from 1:10 Eight terms for this module.

Play from 1:13 bidsBackHandler is the function Prebid calls when its auction is done. The failsafe timeout is your own timer that calls the ad server if anything goes wrong. disableInitialLoad tells GPT to wait for your signal before requesting ads. bidderTimeout is how long Prebid waits for bids.

Play from 1:34 LCP, Largest Contentful Paint, is how fast the main content appears. INP, Interaction to Next Paint, is how fast the page responds to a tap. CLS, Cumulative Layout Shift, is how much the page jumps. And an auction delay is time Prebid waits before the auction, so other modules can finish.

Play from 1:59 You're in Module 2 of eight. Module 1 followed one auction. This module opens the code that runs it.

Play from 2:10 Module 3 then moves part of the auction to a server. If you already maintain a Prebid wrapper, chapter one may be revision. Jump to chapter two for timeouts.

2:21Read a wrapper, line by line

Play from 2:21 Chapter one. Let's read a complete wrapper together. It's the real one running on our demo site. Don't worry if you're not a developer; we'll read it for intent, not syntax.

Play from 2:35 Here's the whole thing, folded into five blocks.

Play from 2:38 Block one loads the two libraries. Block two sets two numbers and lists the ad units. Block three tells GPT to wait. Block four configures Prebid and runs the auction. And block five hands over to Ad Manager and defines the slot.

Play from 2:51 About fifty lines in total. Every page with Prebid and GPT has some version of these five blocks.

Play from 3:04 The wrapper starts by loading Google Publisher Tag and Prebid.

Play from 3:09 Both scripts load with the async attribute. That means the browser keeps building the article while they download. Your headline doesn't wait for ad code.

Play from 3:19 Then come two command queues: googletag dot cmd and pbjs dot que. You can push commands into them before either library has loaded. They'll run, in order, as soon as it's ready.

Play from 3:35 Next, two numbers.

Play from 3:37 PREBID_TIMEOUT, here one thousand milliseconds. That's how long the header auction may run.

Play from 3:44 FAILSAFE_TIMEOUT, three thousand milliseconds. If anything goes wrong, the page calls the ad server at that point anyway.

Play from 3:53 Why three times bigger? The failsafe timer starts when this code runs, not when the auction starts. If Prebid's file takes eight hundred milliseconds to download on a slow connection, the auction only ends at around one point eight seconds. Prebid's own guidance is simply that the failsafe should be much larger than the auction timeout.

Play from 4:17 Then the ad units. This is your inventory list.

Play from 4:21 The code must match the GPT slot. By default, Prebid accepts either the slot's div ID or its Ad Manager ad unit path. Most wrappers use the div ID, and so does ours.

Play from 4:35 mediaTypes says what can show here, in this case a three hundred by two fifty banner.

Play from 4:41 And the bids array lists each partner, with its own parameters, like a placement ID.

Play from 4:47 In Prebid 11, that code does one more job. Prebid also uses it to find the slot's element on the page, to measure viewability. A wrong code now breaks two things, not one.

Play from 5:02 Block three is one line, and it's the one people forget.

Play from 5:06 googletag dot pubads dot disableInitialLoad.

Play from 5:10 Without it, the moment the page calls display on a slot, GPT requests an ad. That request leaves before Prebid has any bids.

Play from 5:20 With it, display only draws the slot. Nothing is requested until the wrapper calls refresh, after the auction.

Play from 5:30 Block four is Prebid's part.

Play from 5:33 setConfig applies global settings. Here: medium price granularity, and the bidder timeout.

Play from 5:40 addAdUnits registers the inventory. requestBids starts the auction, with the same timeout and one more thing: bidsBackHandler.

Play from 5:50 bidsBackHandler is the most important line in the wrapper. Prebid calls it when every bid is back, or when the timeout hits. Here it calls a function named initAdserver.

Play from 6:02 You'll also see a line that switches on test bids. That's for our demo only. It never belongs on a live site.

Play from 6:11 One detail about setConfig that catches teams out.

Play from 6:15 Each call replaces the values you pass at the top level. If one script sets a first-party data object, and a second script calls setConfig with another one, the first one is gone.

Play from 6:29 When two scripts both add settings, use mergeConfig instead. It keeps earlier values that don't conflict.

Play from 6:38 Here's initAdserver.

Play from 6:40 First, a guard. If the ad server has already been called, do nothing. This stops double requests when both the auction and the failsafe fire.

Play from 6:51 Then, inside both queues, Prebid writes its targeting onto every matching slot. That's setTargetingForGPTAsync.

Play from 7:00 And GPT refreshes the slots, which sends the request to Ad Manager.

Play from 7:05 Finally, the failsafe: a plain timer that calls initAdserver after three seconds, no matter what.

Play from 7:13 The last few lines are pure GPT.

Play from 7:16 defineSlot names the Ad Manager ad unit, the size, and the div. enableSingleRequest asks GPT to fetch every slot on the page in one request. enableServices switches GPT on.

Play from 7:31 And in the page body, display draws the slot. Because initial load is disabled, display doesn't fetch anything. The refresh in initAdserver does.

Play from 7:44 So here are the four pieces worth memorising.

Play from 7:47 requestBids starts the parallel auction. bidsBackHandler is the signal that Prebid is done. setTargetingForGPTAsync writes the winning bids into key-values. And the failsafe timer is your safety net if anything breaks.

Play from 7:59 If you can explain these four to a colleague, you understand most of what happens on a Prebid page.

Play from 8:12 You don't need the source code to audit a wrapper. You can ask the running page.

Play from 8:49 First: which Prebid is this? Version eleven point four nine. Worth knowing before you read any documentation.

Play from 9:07 What timeout is really in use? One thousand milliseconds. If this said three thousand, you'd have found the default nobody changed.

Play from 9:16 Price granularity? Medium, so ten-cent buckets.

Play from 9:21 Now the most important check. Prebid's ad unit codes, and GPT's slot IDs. Both say div-mpu. They match.

Play from 9:23 And how big is this build? Almost eight hundred modules. Our demo uses Prebid's full build, which is fine for a demo and terrible for a real site. We'll come back to that in chapter five.

Play from 9:24 Now a broken copy. Same page, but the Prebid code says div-mpu-1. Did the auction still run? Yes. RediAds won, just as before.

Play from 9:25 But what did the slot receive? Nothing. An empty list. The ad still served, but Ad Manager decided without any header bids. Nothing in the console turned red. That's why this mistake survives for months.

Play from 9:26 Four wrapper mistakes we see again and again.

Play from 9:30 One: ad unit codes that don't match the slot IDs. The auction runs, but its bids never reach the ad server.

Play from 9:39 Two: no failsafe, or a failsafe shorter than the timeout. One hanging partner, and the slot stays empty, or the auction gets cut off early.

Play from 9:50 Three: GPT requesting ads before Prebid is finished. Usually initial load wasn't disabled, or a theme script calls refresh too early.

Play from 10:01 Four: refreshing a slot without running a new auction. The old key-values are sent again, and the same bid can render again and again. Prebid calls this a stale render.

10:14What a timeout really does

Play from 10:15 Chapter two. The timeout is the most important number in your wrapper. Let's look at exactly what happens when it's reached.

Play from 10:25 There are two clocks on every Prebid page.

Play from 10:28 Prebid's clock is the bidder timeout. It starts when requestBids is called, and it ends Prebid's auction.

Play from 10:36 Your clock is the failsafe. It starts when the wrapper runs, and it calls the ad server whatever Prebid is doing.

Play from 10:43 One detail: if you pass a timeout to requestBids, that's the one used for that auction. If you don't, Prebid uses the bidderTimeout from setConfig. And if nobody sets either, the default is three thousand milliseconds.

Play from 11:00 So what happens at the moment the bidder timeout is reached?

Play from 11:04 Prebid stops waiting and runs its auction with the bids it already has.

Play from 11:10 It calls your bidsBackHandler, and tells it the auction timed out.

Play from 11:14 Bids still on their way are left out, however high they are. By default, Prebid also cancels those unfinished requests, since their answers can't be used.

Play from 11:27 One honest caveat about that deadline.

Play from 11:30 Browsers run timers when they can, not to the millisecond. On a busy page, the timeout can fire late.

Play from 11:38 So a bid that took a little longer than the timeout can still get in. Prebid's documentation notes you should see a clear drop-off a couple of hundred milliseconds past the threshold.

Play from 11:49 The practical lesson: a heavy page doesn't just slow your readers. It makes your timeout less precise.

Play from 11:58 Here's one auction with a thousand-millisecond timeout. Illustrative timings.

Play from 12:04 Partner A answers at three hundred and twenty milliseconds. B at four fifty. C at six ten.

Play from 12:12 Partner D answers at one thousand one hundred and fifty. It's left out.

Play from 12:18 Today, D bid two sixty, the highest price on the table. So you lost sixty cents CPM on this impression.

Play from 12:27 But to catch D, every ad on every page would wait at least another hundred and fifty milliseconds. Whether that's worth it is a question for data, not instinct.

Play from 12:39 Now the default. Three seconds.

Play from 12:42 On a typical article, a reader decides within a few seconds whether to keep reading or scroll. Illustrative. If the first ad arrives at three and a half seconds, a reader who scrolled at two never sees it.

Play from 12:57 An impression that never renders earns nothing. No CPM can make up for an ad that wasn't seen.

Play from 13:04 So a long timeout doesn't only slow the page. It can lower the number of impressions you actually sell.

Play from 13:12 Here's the trade-off as a picture. Illustrative shape, not a benchmark.

Play from 13:18 As the timeout grows, revenue from bids rises quickly at first, then flattens. The slow bidders add very little.

Play from 13:27 Meanwhile, the cost of waiting keeps rising: later ads, fewer impressions seen, a slower page.

Play from 13:34 Your best timeout sits near where the revenue curve flattens. Past that point, you're paying in speed for almost nothing. Let's see the trade-off on a real page.

Play from 13:46 Here's a page with one slow partner. Index will bid two sixty, the best price, but it takes one point four seconds to answer. Our timeout is one second.

Play from 14:12 Let's grab the auction's final record. It closed after about a thousand milliseconds. And look at the bids it received: OpenX, Sovrn and RediAds. Index isn't there.

Play from 14:25 Did Index answer at all? It did. Two sixty, at around fourteen hundred milliseconds. Too late. The auction had already finished.

Play from 14:32 So what went to Ad Manager? Two point zero zero, RediAds' bucket.

Play from 14:35 Now the same page, with a fifteen-hundred-millisecond timeout.

Play from 14:37 This time the auction took about fourteen hundred milliseconds, because it waited for Index, and Index made it.

Play from 14:38 And Ad Manager now sees two point six zero.

Play from 14:39 So which is better? Sixty cents more on impressions where Index wins. Or four hundred milliseconds sooner on every page. One page can't tell you. A test can, and that's the next chapter.

Play from 14:53 Two timeout mistakes before we move on.

Play from 14:56 One: two timeouts that disagree. Someone changes bidderTimeout in setConfig, but requestBids still passes the old number. Nothing changes, and everyone thinks the test failed.

Play from 15:11 Two: copying another site's timeout. Their partners, their readers and their pages aren't yours. Eight hundred might be right for them and costly for you.

Play from 15:23 Halfway check. Pause the video if you like.

Play from 15:34 Your timeout is a thousand milliseconds. RediAds bids two dollars and answers in time. Partner D bids two sixty, but answers at eleven hundred and fifty milliseconds. What does Ad Manager see in hb_pb?

Play from 15:44 Two point zero zero. Prebid had already run its auction at the timeout, so D's bid was left out, however high it was. Only RediAds' bucket went to Ad Manager.

15:57Choose your timeout with a test

Play from 15:58 Chapter three. Let's design a timeout test properly, run it, and read the results.

Play from 16:06 A good timeout test has four parts.

Play from 16:09 Arms: three or four timeouts. For example, eight hundred, one thousand and fifteen hundred milliseconds, plus your current setting as the control.

Play from 16:19 Assignment: each reader gets one arm, at random, and keeps it for the whole test. Not a new arm on every page view, or one reader's sessions mix arms.

Play from 16:31 Duration: at least a full week, so weekdays and weekends are both in it. Two weeks is better.

Play from 16:38 And one change at a time. Don't add a bidder halfway through.

Play from 16:44 In the wrapper, the split is a few lines.

Play from 16:47 A small script picks an arm the first time it sees a reader, and stores it in a first-party cookie, where your consent rules allow it.

Play from 16:56 It sets bidderTimeout from the arm, and passes the same number to requestBids.

Play from 17:02 And it labels the traffic: send the arm name to your analytics, and set it as a page-level key-value, so revenue can be split by arm.

Play from 17:12 Here's a nice side effect of random assignment. A big match night lands in every arm equally, so it can't fool the result.

Play from 17:22 Now the most important choice: what you measure.

Play from 17:26 Not CPM. A longer timeout usually raises CPM, because slow, high bids get in.

Play from 17:33 Measure revenue per thousand sessions. It's impressions per session, times CPM.

Play from 17:39 That captures both effects at once: higher prices, and fewer ads seen when readers leave or scroll before the ad arrives.

Play from 17:48 Alongside it, watch the timeout rate per bidder and your Core Web Vitals.

Play from 17:55 Here's a finished two-week test. All numbers illustrative.

Play from 17:59 Eight hundred milliseconds: three point one impressions per session, at one forty-two CPM. Revenue: four dollars forty per thousand sessions.

Play from 18:10 One thousand: three point one impressions, at one fifty-two. Four seventy-one.

Play from 18:16 Fifteen hundred: two point nine impressions, at one sixty. Four sixty-four.

Play from 18:22 Three thousand, the untouched default: two point six impressions, at one sixty-six. Four thirty-two.

Play from 18:31 So what does that table say?

Play from 18:33 CPM rises with every step. If you only looked at CPM, you'd pick three thousand. That's the worst arm for revenue.

Play from 18:42 Revenue peaks at one thousand, and fifteen hundred is nearly flat with it.

Play from 18:47 When two arms are this close, pick the shorter one. One thousand earns the same, and every page is half a second faster.

Play from 18:56 Before you call it, check the result held in both weeks. If the order of the arms flips from week to week, the difference is probably noise.

Play from 19:06 The same test shows you each partner. Illustrative numbers again.

Play from 19:12 Partner A answers in three hundred and twenty milliseconds at the median. It times out on two per cent of requests, and wins thirty-one per cent of auctions.

Play from 19:22 B and C are slower, but still win often.

Play from 19:26 Partner D answers in eleven hundred and fifty milliseconds. It times out on thirty-eight per cent of requests, and wins one and a half per cent.

Play from 19:35 You can collect these numbers from Prebid's events, such as bidTimeout and bidWon, through an analytics adapter.

Play from 19:44 So what do you do about partner D?

Play from 19:47 First, talk to them. A slow response is often a set-up problem on their side, or a data centre far from your readers.

Play from 19:56 Second, consider moving them to a server-side auction. That's Module 3.

Play from 20:02 Third, if neither works, remove them. A partner that rarely wins but often times out is costing you speed for almost nothing.

Play from 20:11 None of these numbers are rules. A partner with a low win rate can still lift prices for everyone else. Decide with the revenue data.

Play from 20:22 Three test mistakes we see often.

Play from 20:25 One: stopping after two days because one arm looks ahead. Early leads in a test often vanish.

Play from 20:34 Two: assigning arms per page view. One reader then sees several timeouts, and the arms blur together.

Play from 20:42 Three: testing once and never again. Partners get faster or slower. Repeat the test every quarter, or after any big change to your bidders.

20:55Core Web Vitals and ad slots

Play from 20:55 Chapter four. Google measures page experience with three Core Web Vitals. Ads can hurt all three, and the ad slot is where you control most of it.

Play from 21:08 First, the targets.

Play from 21:10 Largest Contentful Paint should happen within two point five seconds.

Play from 21:15 Interaction to Next Paint should be two hundred milliseconds or less.

Play from 21:20 Cumulative Layout Shift should be zero point one or less.

Play from 21:24 Each one is judged at the seventy-fifth percentile of real page loads, for mobile and desktop separately. So your slowest quarter of readers decides your score.

Play from 21:37 Largest Contentful Paint is usually your headline or hero image.

Play from 21:42 Ad scripts compete with that image for the network, and for the browser's main thread.

Play from 21:47 So load Prebid and GPT asynchronously, as our wrapper does. Never put ad scripts ahead of your hero image in the page's priority.

Play from 21:57 And keep your build lean. A smaller Prebid file finishes downloading and parsing sooner, so it gets out of the way sooner.

Play from 22:07 Interaction to Next Paint measures how quickly the page reacts when a reader taps.

Play from 22:13 If the main thread is busy running a long script when the tap arrives, the reaction waits. Bid processing and heavy creatives can both cause that.

Play from 22:24 Since version 10, Prebid yields the main thread while working through its command queue. That gives the page room to respond between steps.

Play from 22:33 You can turn that off, but only do it if your own code really needs Prebid to run all in one go.

Play from 22:41 Layout shift is the one ads damage most. Here's how it's scored.

Play from 22:46 Each shift scores its impact fraction times its distance fraction. Impact is how much of the screen was affected. Distance is how far things moved, compared with the screen's largest side.

Play from 23:00 Shifts are grouped into bursts of up to five seconds. Your CLS is the worst burst.

Play from 23:07 And here's the catch for ads. Shifts right after a tap or a key press don't count. But scrolling doesn't excuse a shift. An ad that loads while someone scrolls still counts.

Play from 23:21 Here's one unreserved slot on a phone. Illustrative geometry.

Play from 23:27 The screen is eight hundred pixels tall. The article starts at two hundred pixels. The ad slot above it has no height yet.

Play from 23:36 The ad arrives, two hundred and fifty pixels tall, and pushes the article down.

Play from 23:42 The moving content covered three quarters of the screen, before and after. That's an impact fraction of zero point seven five. It moved two fifty out of eight hundred pixels: a distance fraction of about zero point three one.

Play from 23:57 Multiply them: zero point two three. One ad has more than doubled the good threshold.

Play from 24:05 The fix is to reserve the space before the ad arrives.

Play from 24:10 Give the slot container a minimum height in CSS. Two hundred and fifty pixels for a three hundred by two fifty.

Play from 24:18 Now the article starts below the slot from the first paint. When the ad arrives, nothing moves. The score from this slot is zero.

Play from 24:27 If the slot can take several sizes, reserve the smallest one, and accept a small shift for larger ads. Or place multi-size slots further down the page, where shifts affect less of the screen.

Play from 24:42 The opposite move causes the same problem.

Play from 24:45 Some sites collapse a slot when no ad fills it. The space disappears, and everything below jumps up.

Play from 24:53 Removing reserved space can shift the layout just as much as inserting an ad.

Play from 24:59 So for slots near the top, keep the space and show a placeholder, or a house ad. It's cheaper than a bad CLS score.

Play from 25:09 Here's our article on a phone. The ad slot sits right under the byline, and it has no height reserved. Watch the text when the ad arrives.

Play from 25:34 There it goes. The hero image and the first paragraph jump down by two hundred and fifty pixels. The red outlines show everything that moved.

Play from 25:47 The score for that one shift is zero point one seven seven, already over the zero point one threshold. And the reader didn't do anything. The page just moved under them.

Play from 25:53 Now the same page with one line of CSS: a minimum height of two hundred and fifty pixels.

Play from 25:57 See the grey box? The space is held from the very first paint, before Prebid has even finished.

Play from 25:58 The ad arrives, and the score stays at zero. Same ad, same auction, same timing. One line of CSS.

Play from 26:00 One more tool for speed: lazy loading.

Play from 26:04 Slots far down the page don't need an auction when the page loads. Run their auction when the reader gets close to them.

Play from 26:12 That means fewer requests competing with your main content, and fewer auctions for ads nobody scrolls to.

Play from 26:19 But lazy slots still need their space reserved. A lazy ad that pushes content while the reader scrolls is exactly the shift we just measured.

Play from 26:31 Three Core Web Vitals mistakes we see.

Play from 26:34 One: testing speed without ads. A lab test with ads blocked, or without a consent banner, isn't what your readers get. Use real-user data.

Play from 26:46 Two: reserving desktop heights on mobile. Reserve the size the slot will really show on each screen width.

Play from 26:54 Three: a top-of-page slot that collapses on no-fill. It saves a few pixels and costs you CLS on every unfilled impression.

27:05Lean builds, data and identity

Play from 27:06 Last chapter. What goes into your Prebid file, and the modules that run before the auction even starts.

Play from 27:14 Prebid is modular. You choose which pieces go into the file your readers download.

Play from 27:21 A bloated build ships every adapter just in case, keeps the default timeout, and includes modules nobody configured. As you saw, our demo's full build has almost eight hundred modules.

Play from 27:34 A lean build includes only the adapters you use, the modules you've configured, and a tested timeout.

Play from 27:42 Build it from Prebid's download page, or with Prebid's own build tool, naming each module. Then check pbjs dot installedModules on the live page, to be sure that's what shipped.

Play from 27:56 Prebid 11 added a wait you should know about.

Play from 28:00 By default, Prebid now measures each ad unit's viewability with an intersection observer, before the auction starts.

Play from 28:08 The auction can't start until the observer reports. On a page busy with long scripts, that only happens once the longest one finishes.

Play from 28:18 There's a faster setting, called boundingBox, that doesn't wait. But Prebid warns it's less accurate. So the real fix is fewer long tasks on your page.

Play from 28:30 Real-time data modules, RTD for short, add information to bid requests before they go out. For example, the page's topic, or audience segments from a data partner.

Play from 28:43 That can raise bids, because buyers know more about the impression.

Play from 28:48 You give them a time budget called the auction delay. The default is zero, so they only help if their data is ready already.

Play from 28:58 You can mark one provider with waitForIt, so the auction waits for it, up to that budget. So budget it on purpose: a hundred-millisecond delay is a hundred milliseconds before any bid request leaves the page.

Play from 29:14 Now identity, and it starts with consent.

Play from 29:18 Your consent platform, the CMP, records the reader's choice. Where TCF consent applies, for example for readers in Europe, Prebid's TCF consent module reads it.

Play from 29:30 That module waits for the CMP with a timeout. The default is ten seconds. Set your own, deliberately, so a slow CMP can't hold up every ad.

Play from 29:41 For Indian traffic, which rules apply is a question for your legal team. The wrapper's job is to read whatever signal you have, before anything else runs.

Play from 29:53 Only after consent do the identity modules run.

Play from 29:57 User ID modules, like SharedID, give buyers a privacy-safe way to recognise a returning reader. Recognised readers usually attract higher bids.

Play from 30:08 They run only where consent allows. Since Prebid 11.14, if the CMP can't be found at all, the ID modules don't run.

Play from 30:19 And since Prebid 9, when ID modules are configured, the auction waits up to five hundred milliseconds for them by default. That's the user sync auction delay. Lower it if your IDs come back faster.

Play from 30:34 Put it all together as a budget. Illustrative values.

Play from 30:39 Consent: wait up to five hundred milliseconds for the CMP, not the default ten seconds.

Play from 30:45 Identity: allow a hundred milliseconds, not the default five hundred.

Play from 30:51 Real-time data: a hundred milliseconds, only for the one provider that proved its value.

Play from 30:58 Then the auction, with the thousand milliseconds your test chose. If every step used its full budget, one after another, the first ad request would leave after about one point seven seconds. For a returning reader with a fast CMP, it's much less.

Play from 31:16 If your wrapper was written for an older Prebid, check three things.

Play from 31:21 Since Prebid 10, functions like getBidResponsesForAdUnitCode return an array. Old code that reads dot bids still works, for now.

Play from 31:32 Since Prebid 11, setTargetingForGPTAsync no longer takes a custom slot-matching function as its second argument. That moved to a top-level setting called customGptSlotMatching.

Play from 31:46 And Prebid 11 rejects bids whose media type doesn't match the ad unit. A video bid on a banner-only slot is now thrown out.

Play from 31:58 Three mistakes from this chapter.

Play from 32:00 One: identity before consent. Either the consent module isn't in the build, or the ID modules are configured to run first. You risk privacy rules, or IDs that never attach.

Play from 32:15 Two: an RTD module with an auction delay nobody measured. Every page pays the wait, whether the data helps or not.

Play from 32:25 Three: modules in the build that nobody configured. They still download, still parse, and still cost your readers time.

32:35Recap and quick checks

Play from 32:36 Before we wrap up, three myths we hear almost every week.

Play from 32:41 Myth one: a longer timeout always earns more. It raises CPM. Past the flat part of the curve, it lowers revenue per session.

Play from 32:51 Myth two: more bidders always means more revenue. Every bidder adds requests and work. A slow partner that rarely wins costs speed and adds little.

Play from 33:03 Myth three: ads and Core Web Vitals can't coexist. Reserved slots, async scripts and a lean build keep most ad set-ups well inside the thresholds.

Play from 33:16 Let's recap Module 2.

Play from 33:18 Every wrapper needs matching ad unit codes, disabled initial load, a bidsBackHandler and a failsafe.

Play from 33:26 At the timeout, Prebid runs its auction with what it has. Late bids are left out.

Play from 33:33 Choose your timeout with a split test, judged on revenue per thousand sessions.

Play from 33:38 Reserve space for every slot, and don't collapse it near the top.

Play from 33:43 Consent first, then identity, then data, each with a time budget. And keep the build lean.

Play from 33:52 Quick check. Pause the video if you want to think.

Play from 33:58 A script error means bidsBackHandler never fires. What still sends the ad request to Google Ad Manager?

Play from 34:04 The failsafe timer. It calls initAdserver after three seconds, no matter what. And the guard inside initAdserver makes sure Ad Manager is only called once.

Play from 34:17 One more. A one-column mobile page shows a three hundred by two fifty ad near the top, with no space reserved. CLS is zero point two. What's the first fix?

Play from 34:31 Give the slot container a minimum height of two hundred and fifty pixels. The article then starts below the slot, and the ad arrives without moving anything.

Play from 34:44 That's Module 2. You can now read a wrapper, choose a timeout with data, and keep ads from wrecking your Core Web Vitals.

Play from 35:00 In Module 3, we take part of the auction out of the browser with Prebid Server. You'll see one real server request and response, and what happens to identity when the auction leaves the page.

Play from 35:08 Want a second pair of eyes on your own wrapper? Take the free monetisation health check on blog dot rediads dot com. See you in Module 3.