FLEDGE latency best practices
Maximise auction efficiency.
It's in everyone's best interest to make sure FLEDGE operates efficiently.
- People browsing the web want sites to load quickly. This means developers should build with FLEDGE efficiently as to not overutilize limited device resources, like compute or network resources, that are necessary to load sites and their embedded ads.
- Publishers want their sites to load quickly, providing users an efficient and responsive experience. Publishers also want effective advertising to maximize their revenue.
- Advertisers and adtechs want their ads to display quickly to provide the greatest utility.
This document outlines some best practices for FLEDGE implementation, to ensure your site operates at maximum efficiency.
Buyer (bidder) best practices
To make sure you're optimizing for FLEDGE auction efficiency, follow these best practices
Fewer interest group owners
To protect FLEDGE bidders in the same way that the browser protects different origins on the web using site isolation, the browser uses expensive resources (like operating system processes) to protect individual interest group owners.
To minimize the expenditure of these very expensive resources, having the fewest number of interest group owners is crucial. Avoid having different interest groups owned by various subdomains, for example if
adtech.example had interest groups owned by cats.
dogs.adtech.example, the browser would likely use two separate processes to run their bidding scripts.
Fewer interest groups bidding
The browser must do significant setup and preparation before invoking a buyer's
- Interest groups that represent users who are not the target of active advertising campaigns should have empty ad creative lists. This will prevent FLEDGE from executing
generateBid()scripts that don't have ads to bid on.
- Combining similar interest groups will decrease the number of times
generateBid()must be run. An interest group's
userBiddingSignalsproperty can be used to store additional metadata about the user, so fewer interest groups doesn't have to mean less effective targeting.
- Currently, FLEDGE supports seller-specified limits on the numbers of interest groups,and an API for buyers to specify the relative priority of their interest groups. This can be used to significantly reduce the number of bidding scripts to run.
Reuse bidding scripts
Set up a shared bidding script for separate interest groups. This prevents the browser from having to download, parse, and compile multiple scripts (which incurs extra network requests).
Network latency and resource usage can be very significant. Fewer real-time trusted bidding signals fetches can help reduce this latency.
As the explainer notes, the trusted bidding signal fetches can be combined when the
trustedBiddingSignalsUrl is reused amongst multiple interest groups, so be sure to use the same
trustedBiddingSignalsUrl between interest groups when possible.
Smaller real-time trusted bidding signals fetches
Network latency can be very significant, and this is directly impacted by how much data is transferred during the real-time trusted bidding signal fetches. Prefer storing ad-specific or interest-group-specific data in the interest group, rather than on the real-time trusted bidding signal server. Reserve the real-time trusted bidding signal data for only those truly real-time signals, like campaign budgeting or kill-switches.
Any signal that can be updated on a daily or longer basis should be stored in the interest group and updated via the daily updates.
Seller best practices
Make sure you're monitoring and optimizing for FLEDGE auction efficiency.
Monitor your auctions
Collect metrics on your auctions:
- The number of interest group owners and interest groups bidding significantly impacts auction performance and should be monitored. The metrics are visible in
biddingDurationMsecwhich indicates how long a bidder took to compute their bid. Though multi-core processors can execute multiple bidding scripts concurrently, this still has a significant effect on performance and is worth monitoring.
- Bidders may have insights into their own interest groups' bidding performance, but they may not be able to compare this to other bidders. Comparing relative win rates and bid rejection rates for different bidders may help identify cases where bidding compute resources were wasted due to interest groups never producing viable bids or excessive bidding with unapproved creatives.
Protect against slow bid scripts
Bidding scripts that take excessive time can slow the FLEDGE auction down for everyone involved.
- Use timeouts. FLEDGE includes some default time-outs for bidding scripts, but
perBuyerTimeoutscan be adjusted to ensure that no bidders participating in the auction are using excessive computation time.
- Consider participating in future timeouts and limits discussions, as described in Issue 293.
- Use limits. Setting bidding script timeouts can prevent one script execution using excessive time, but buyers are free to add users to many, potentially duplicate, interest groups, and each interest group gets a chance to bid and a separate timeout. By using
perBuyerGroupLimitsto set limits on numbers of interest groups, you can prevent individual buyers from consuming excessive auction time. Make sure to work with your buyers to ensure they set interest group priorities so that their most important interest groups are included in each auction.
Engage and share feedback
- GitHub: Read the proposal, raise questions and follow discussion.
- W3C: Discuss industry use cases in the Improving Web Advertising Business Group.
- Developer support: Ask questions and join discussions on the Privacy Sandbox Developer Support repo.
Find out more
- FLEDGE API developer guide: reference guide to API usage.
- FLEDGE demo: walkthrough of a basic FLEDGE deployment.
- The FLEDGE demo video explains how the demo code works, and shows how to use Chrome DevTools for FLEDGE debugging.
- FLEDGE API technical explainer
- Digging into the Privacy Sandbox
- Intent to prototype