Consent banners are usually treated as a legal checkbox. On an Edge Delivery Services (EDS) site, they’re also a performance feature: if you wire consent badly, you can add extra blocking scripts, delay personalization, and ship unnecessary network calls on every page.

This post outlines a pragmatic way to integrate a Consent Management Platform (CMP) with Adobe Experience Platform Web SDK on EDS, with a focus on staying fast.

Modern consent setups do three things that impact runtime performance:

  1. Control when data can be sent
    Web SDK will only send events once consent is “in”, “out”, or “pending” is resolved. Used correctly, this prevents wasted calls and lets you drop a lot of conditional logic that would otherwise run on every page.
    Consent overview
  2. Gate all marketing tech behind one decision
    Instead of letting every tag or pixel decide independently, a CMP sends a single signal that Web SDK and your tags consume. That’s fewer scripts evaluating consent on their own, and fewer race conditions to manage.
    Implement consent with a consent management platform (CMP)
  3. Avoid double work when preferences change
    When you call setConsent, Web SDK updates its consent cookie and uses it on the next page load. That avoids repeated discovery calls or extra server-side lookups just to re-learn the same preference.
    setConsent

On a fast, edge-cached site like EDS, the goal is simple: collect just enough information, just in time, without adding extra blocking work to every request.

Pattern 1: Let the CMP Lead, Web SDK Follow

Treat your CMP as the source of truth for the banner UI and categories, and Web SDK as the transport layer for those decisions.

Recommended flow:

  1. Load CMP early, but light

    • Include the CMP script as part of your base HTML or a very early block.
    • Avoid large frameworks just for the banner; keep the dependency tree small.

  2. Set Web SDK default consent to “out” or “pending”

    • In the Web SDK tag extension, configure Default consent to Out or Pending, depending on your legal stance.
    • Out: drop events until explicit consent.
    • Pending: queue events until consent is granted or denied, then send or discard.
      Consent configuration settings

  3. Listen for CMP events and call setConsent

  4. Only send events after consent is resolved

    • Use defaultConsent = "out" or "pending" to prevent Web SDK from sending events before the CMP has fired its decision.
    • Once setConsent returns, sendEvent calls will either send or be suppressed automatically.

This keeps Web SDK logic simple and avoids extra conditional code spread across your EDS blocks.

On EDS you often pre-hide containers to avoid personalization flicker. If you combine that with consent, be careful not to trap the page under a hidden layer.

Practical guidance:

The key is to avoid scenarios where:

That’s a pure UX and performance hit with no upside.

On an EDS site you want as few scripts as possible doing work on first paint. Use consent as the single gate for all non-essential marketing technology.

Best practices:

This reduces the number of scripts that even attempt to run on the initial view, which directly improves metrics like TTFB, FCP, and Total Blocking Time.

Pattern 4: Keep the EDS Stack Simple

A few EDS-specific notes:

The result is a predictable, debuggable flow that doesn’t require special handling per route or block.

Quick Checklist

Use this as a condensed “best practices” list for an EDS + Web SDK + CMP setup:

Done well, consent management becomes a performance optimization rather than a tax: you collect less, more intentionally, and you give EDS room to stay fast even as your data and personalization stack grows.