Patterns for better digital experiences.

From docs to real-world patterns for secure, scalable experiences at the edge.

Optimizing Tag Management on Edge Delivery Services

Integrating a tag management system such as Adobe Experience Platform Tags (formerly Adobe Launch) into a high-performance environment like Edge Delivery Services (EDS) introduces a familiar tension: how do you unlock rich personalization and analytics without compromising page speed or user experience?

There are two supported patterns for doing this on EDS. Which one you pick depends on whether personalization and Core Web Vitals are the priority, or whether marketer self-service and zero-deploy iteration matter more than shaving milliseconds off the eager phase.

Last verified: July 2026

Adobe's Web SDK, Tags, and AJO decisioning tooling move quickly. Confirm extension versions and UI details against current Experience League docs before implementing anything below.

Two Ways to Own the Web SDK on EDS

Option A - Code-owned Web SDK, Launch deferred. Code loads the Web SDK directly for both personalization and data collection; Launch loads late and only carries non-Adobe tags. See Performance and Personalization for the full pros/cons comparison across all approaches.

Option B - Web SDK extension inside Launch. Launch owns the Web SDK entirely, configured through Top/Bottom Page Event rules. This is a real, common tradeoff rather than a fallback - it trades some LCP headroom and personalization-timing precision for marketer self-service and zero-deploy iteration. See "When to Choose This Pattern" below.

When Does Launch Itself Load on EDS?

Option B assumes Launch is available early enough for a "Top Page Event" rule to actually count as early. On EDS that assumption usually doesn't hold: loading Launch in <head> costs Lighthouse points, so most EDS sites defer Launch into the lazy phase, well after the eager phase that determines LCP.

If Launch itself loads late, "Top Page Event" isn't early relative to the page - it's early relative to Launch's own late start. Personalization triggered from it inherits that delay, and if the Web SDK extension is bundled into Launch's rules, you've quietly relocated the same timing problem the direct-load approach exists to solve, without gaining anything back.

If you follow Option B, be explicit about when Launch loads on your site, and budget for that cost deliberately rather than treating it as a bug. If you follow Option A, this doesn't matter - Launch's load time only affects non-Adobe tags.

Recommended Default: Code-Owned Web SDK (the aem-martech Pattern)

The pattern actually running on production EDS + Adobe sites is straightforward: code owns the Web SDK end-to-end, and Launch is deferred and scoped to non-Adobe tags only.

Personalization and data collection both go through a single, code-owned Web SDK instance, loaded in the eager phase.
Flicker avoidance uses a MutationObserver watching data-block-status/data-section-status to gate DOM actions, rather than a blunt body-hide.
Launch loads late (for example, several seconds after initial render) and is scoped strictly to non-Adobe pixels and tags - it never carries the Web SDK extension.

Because Launch never bundles the Web SDK, the double-load problem can't happen: there's exactly one Alloy instance on the page, owned by code. Treat this as the default unless marketer self-service, zero-deploy iteration, or standardizing on one interface across many properties matters more to your organization than shaving milliseconds - in which case Option B below is a legitimate choice, not a compromise.

Option B in Detail: Web SDK Extension Inside Launch

When to Choose This Pattern

This pattern puts Web SDK inside Adobe Launch and drives personalization off a Top Page Event rule, with analytics on a Bottom Page Event rule. It's the right default when:

Marketing owns the event vocabulary and needs to add or change tags/rules without a code deploy.
The site isn't personalization-heavy or isn't on a CWV-critical page (a lead-gen microsite matters less here than a high-traffic product homepage).
You're standardizing tooling across many client properties and want one interface (Launch) for every implementation, rather than a mix of code-owned integrations per site.
Engineering bandwidth for this site is limited or shared across many properties, and Launch's UI-driven workflow reduces the support burden.

The tradeoff: Launch itself takes time to load and initialize before any rule can fire, so "Top Page Event" is only as early as Launch's own load allows. Budget for that explicitly - load Launch as early and lean as you can afford (a slim build, no unused extensions, async at minimum), and treat the resulting LCP/CWV number as the cost of this architecture rather than something to eliminate. If a client's personalization timing budget can't absorb that cost, that's the signal to move to the code-owned Web SDK pattern described above, or to a server-side/edge hybrid (see Hybrid Personalization) instead of forcing this pattern to do something it isn't built for.

To keep EDS experiences fast and responsive within this pattern, we follow two core principles:

Personalization early - Use the Web SDK to request and apply personalization as soon as possible during page load, so users see tailored content without noticeable delay.
Data collection later - Delay reporting and analytics beacons until after the initial experience is stable, reducing the impact on perceived performance and interaction readiness.

The Web SDK provides several features that make this feasible in practice.

Top/Bottom Page Events

Using Top/Bottom Page Events, you can:

Execute personalization logic early in the page lifecycle, so personalized content is resolved as part of the first meaningful paint.
Defer analytics and metric reporting until the page has fully rendered, keeping the initial render quick and smooth while still ensuring complete data collection.

Custom Build

The Web SDK Custom Build feature is a major improvement for performance-sensitive implementations:

Create a slimmed-down Web SDK bundle by excluding modules that the project does not use.
For example, if you don't need Media Analytics or Streaming Media, you can disable those modules.
This can significantly reduce the Web SDK library size (up to 50% in many setups), directly improving load times and bandwidth usage. Check the official docs for current module sizes before estimating your savings.

Quick Implementation Guide for Option B

Use the following high-level steps as a starting point for an EDS-friendly implementation:

Create or update your Adobe Experience Platform Tags property
- Ensure the property is configured for the site running on EDS.
- Add the Adobe Experience Platform Web SDK extension.
Configure Web SDK settings for your EDS site
- Set your datastream IDs and environment settings.
- Enable support for personalization in the Web SDK configuration.
Define a Top Page Event rule for personalization
- Trigger: Top Page Event (or equivalent early lifecycle trigger).
- Actions:
  - Collect the minimum context needed (e.g., URL, user segment info).
  - Call the Web SDK sendEvent to request and apply personalization as early as possible.
Define a Bottom Page Event rule for analytics
- Trigger: Bottom Page Event (after the page is fully rendered).
- Actions:
  - Populate analytics variables and product data.
  - Call sendEvent to send analytics and reporting beacons, keeping this work out of the critical rendering path.
Create a Custom Build of the Web SDK
- In the Web SDK configuration, exclude any modules you do not need (for example, Media Analytics or Streaming Media).
- Deploy and verify that the resulting bundle size is reduced and that essential personalization and analytics behavior still works end-to-end.
Test and monitor in EDS
- Validate that personalized content appears without flicker or delays.
- Confirm that analytics events arrive correctly and only after the initial content is stable.
- Monitor performance metrics (e.g., time to first paint, time to interactive) to ensure your configuration preserves the EDS performance profile.

By aligning Web SDK configuration, event timing, and bundle size with these steps, you can integrate Adobe Experience Platform Tags with Edge Delivery Services in a way that maintains fast, edge-optimized experiences while still delivering robust personalization and analytics. If Core Web Vitals or personalization depth become a priority, migrate to the code-owned pattern above rather than continuing to tune Launch.