Same auction, two places it can run: right inside your browser, or on a server far away. That one choice quietly shapes page speed, how many buyers can take part, and how well the ads are matched to you.
The question is simply: where does the auction run, the browser or a server? There is no universally right answer, only a trade-off, so let us make the trade-off concrete.
Client-side
The auction runs in the user’s browser via Prebid.js. Each bidder is called directly from the page, so the bidder sees the user’s browser and cookies first-hand. That gives the best identity match, full transparency, and tight control. The cost is that every bidder is more JavaScript and more network requests in the page, and browsers cap how many connections a page can open at once.
Server-side
The browser makes one call to a server (Prebid Server or an SSP’s server-to-server endpoint), and the server fans out to many bidders. Browser latency and page weight stay low, and you can include far more bidders. The cost is match rate: the server has to sync user IDs across domains, and cookie matching server-to-server is lossy, so bidders value the impression less accurately.
| Dimension | Client-side | Server-side |
|---|---|---|
| Identity / cookie match | Strong (direct) | Weaker (synced, lossy) |
| Browser latency / page weight | Higher | Lower |
| Number of bidders feasible | Limited by connections | Many |
| Transparency / control | Full | You trust the server’s auction |
Quick check
Server-side lets you add many more bidders with less page weight. What do you give up to get that?
Key idea
The core trade is match versus scale. Client-side buys identity match and control at the cost of page performance; server-side buys latency and bidder count at the cost of match rate.
Hybrid
Most large publishers run a hybrid: their few highest-value, best-matching partners client-side, where match quality pays off most, and the long tail server-side for scale. A rough rule: a high-value audience with a few key partners leans client-side; many partners or performance-sensitive mobile leans server-side; at scale, hybrid wins.
Note
This split sets up the rest of the curriculum: Track B goes deep on client-side Prebid.js, and Track E goes deep on server-side.