EDS Capabilities and Limits

Content Objective

This chapter covers:

• The full catalogue of what EDS can do (not just the marketing version)
• The two authoring models and which use cases each serves
• How the Query API replaces server-side content aggregation
• How experimentation works without a dedicated server
• How multi-site and multi-locale work in EDS
• The performance guarantees and how EDS achieves them
• Where EDS is stronger than traditional AEM

Before comparing EDS to AEM (next chapter), you need to understand EDS on its own terms. Evaluating a tool against what it was not designed to do leads to unfair conclusions.

EDS was designed for one primary use case: delivering editorial content at web-native performance. It excels at this. Understanding where it excels — and why — is the foundation for making good architecture decisions.

The Two Authoring Models

EDS supports two fundamentally different authoring experiences. They are not interchangeable — each has a different use case and capability set.

Document Authoring (DA)

Document Authoring uses da.live as the authoring environment. Authors write content in a document-like editor (similar to Google Docs or Word) and the EDS framework converts that document structure into web-ready HTML.

Best for:

• Marketing teams and non-technical authors
• Editorial content: articles, blog posts, landing pages, campaign pages
• Content that is primarily text with some media
• Teams that need to author without training on a CMS
• High-volume content production (hundreds of pages per month)

How content is structured: Tables in the document define blocks. Plain text, headings, and images become "default content." The document structure IS the page structure.

Content is stored in: da.live cloud storage (Adobe-managed), backed by AEM Assets

Universal Editor (xwalk)

Universal Editor provides an in-browser visual editor. Authors see the page exactly as it will appear and click on components to edit their properties in a properties panel.

Best for:

• Marketing teams that need visual precision
• Complex pages with many layout variants
• Teams migrating from traditional AEM (familiar UE experience)
• Pages where component layout is as important as content
• Highly branded pages with many design variations (hero variants, complex cards)

Content is stored in: AEM Cloud author instance (JCR), same as traditional AEM content

The critical difference: DA content lives in da.live and goes through the EDS content pipeline. UE/xwalk content lives in AEM JCR and is served through the bin/franklin.delivery servlet.

Content Authoring Capabilities

Rich Text

Both DA and UE support rich text:

• Headings (H1–H6)
• Bold, italic, underline
• Ordered and unordered lists
• Tables (converted to block definitions in DA)
• Links (internal and external)
• Code blocks

What rich text does NOT support in EDS:

• Custom styles (inline or span-level class application)
• Custom components inside rich text (no "insert component" in WYSIWYG RTE)
• Complex table structures (merged cells are not supported)

Media (Images and Video)

Images:

• EDS automatically generates responsive image variants using the AEM Assets pipeline
• <picture> elements with multiple <source> at different breakpoints are generated automatically
• WebP format is served where supported
• Authors reference images from DAM (both DA and UE)

Video:

• Embed via link (YouTube, Vimeo links are auto-converted to embed blocks)
• Native <video> support via a block that wraps a DAM-stored video file
• No server-side video processing in EDS itself (relies on external CDN or video platform)

Metadata

Page-level metadata (title, description, OG tags, canonical URL, hreflang) is authored in a Metadata block at the bottom of each page:

| Metadata            |
|---------------------|
| Title       | My Page Title        |
| Description | Page description...  |
| Image       | /media/og-image.jpg  |
| Template    | article              |

This metadata is read by scripts.js and placed in <meta> tags in the page <head>.

Template metadata is particularly powerful — it allows different page types to load different CSS or block combinations without any server-side routing logic.

The Query API — EDS's Answer to Server-Side Content Aggregation

In traditional AEM, a listing component (news archive, blog index, product list) uses a Sling Model or servlet to run a JCR query and return results. This is server-side computation.

EDS has no server-side computation. Instead, it uses the Query API — a pre-built JSON index of all pages in the site with their metadata.

How the Query API Works

1. When any page is published (or previewed), EDS indexes its metadata into a JSON file
2. The JSON file is available at /{path}/query-index.json
3. A listing block fetches this JSON at render time and builds the list client-side

// blocks/news-list/news-list.js

export default async function decorate(block) {
  const response = await fetch('/news/query-index.json');
  const data = await response.json();

  const articles = data.data
    .filter((article) => article.template === 'article')
    .sort((a, b) => new Date(b.date) - new Date(a.date))
    .slice(0, 10);

  block.innerHTML = '';
  articles.forEach((article) => {
    const card = document.createElement('article');
    card.innerHTML = `
      <a href="${article.path}">
        <h3>${article.title}</h3>
        <p>${article.description}</p>
        <time>${article.date}</time>
      </a>
    `;
    block.append(card);
  });
}

Query API Configuration

The fields that appear in query-index.json are configured in helix-query.yaml:

version: 1
indices:
  articles:
    include:
      - /news/**
    exclude:
      - /news/index
    target: /news/query-index.json
    properties:
      title:
        select: head > meta[property="og:title"]
        value: attribute(el, 'content')
      date:
        select: head > meta[name="publication-date"]
        value: attribute(el, 'content')
      author:
        select: head > meta[name="author"]
        value: attribute(el, 'content')

Capabilities of the Query API:

• Client-side filtering by any indexed field
• Client-side sorting by any field
• Pagination (slice the array)
• Search (filter by text content of title/description)
• Tag-based filtering

Limitations:

• No server-side sorting or filtering (entire index is fetched, then filtered in the browser)
• For very large sites (10,000+ pages), the JSON index can become large
• No real-time updates (index updates when pages are published)
• No complex relational queries (no JOIN equivalent)

Experimentation and Personalization

EDS has a built-in experimentation framework provided as a plugin. This is one area where EDS is more capable out of the box than traditional AEM.

The Experimentation Plugin

The experimentation plugin provides:

• A/B testing: Show variant A to 50% of users, variant B to the other 50%
• Split URL testing: Test /page-a against /page-b
• Audience targeting: Show different content based on attributes (geography, device, referrer)
• Campaign tracking: Show campaign-specific content to users arriving via UTM parameters

Configuration is done in page metadata — no backend required:

| Metadata                  |
|---------------------------|
| Experiment  | hero-test-01 |
| Instant Experiment | true  |

And in a separate experiment configuration page:

| Experiment Config                    |
|--------------------------------------|
| Experiment  | hero-test-01            |
| Variant     | control                 |
| Split       | 50                      |
|             |                         |
| Variant     | challenger              |
| Split       | 50                      |
| URL         | /home-challenger        |

The plugin intercepts page loads and serves the appropriate variant based on the configured split.

This is client-side experimentation — no server-side component. This means:

• No server-side session tracking
• No guaranteed consistent experience across sessions (cookie-based)
• Lower complexity and faster setup than AEM Targeting
• Works within the performance guarantee

Adobe Target Integration

For more sophisticated personalization (real-time audience data, AI-driven recommendations), EDS integrates with Adobe Target:

// scripts/delayed.js
import('../plugins/target/target.js');

The Target plugin runs in the delayed phase to not impact LCP.

Multi-Site and Multi-Locale

EDS has a lightweight multi-site model that differs significantly from AEM's MSM (Multi-Site Manager).

Language Copies via Folder Structure

Multi-locale is handled by folder structure:

/en/        ← English
/fr/        ← French
/de/        ← German
/es/        ← Spanish

Each locale folder contains its own content pages. There is no inheritance or live copy relationship between them.

Locale-specific metadata: Each page declares its language in metadata:

| Metadata                        |
|---------------------------------|
| Locale  | fr                    |
| hreflang | /en/page, /de/page   |

The hreflang metadata is converted to <link rel="alternate"> tags automatically.

Multi-Brand (Multiple Sites from One Repository)

Multiple brand sites can share a single GitHub repository using a path-based structure:

/brand-a/
/brand-b/
/shared/   ← Shared blocks and components

Brand-specific CSS themes can be loaded based on the template metadata:

// scripts/scripts.js (modified)
const template = getMetadata('template');
if (template) {
  loadCSS(`/themes/${template}/theme.css`);
}

This is less powerful than AEM's overlay system but works for many multi-brand scenarios.

Multi-Repo Themes (Cross-Repository)

EDS does not have a built-in cross-repository dependency system equivalent to AEM's dependency management. For shared components or themes across repositories, the options are:

1. NPM packages: Publish shared utilities as NPM packages and import them
2. Git submodules: Include shared code as a git submodule
3. Copy-paste: Duplicate shared code across repositories (common but creates maintenance burden)
4. External CDN: Host shared CSS/JS on a CDN and reference by URL

None of these are as elegant as AEM's overlay system or Maven dependency management. This is a genuine limitation.

The Performance Guarantee

EDS's defining claim is a guaranteed 100 LHS (Lighthouse Score) or equivalent Core Web Vitals performance.

This guarantee is structural — it is built into how the framework works:

The guarantee breaks when:

• Scripts are added to head.html (render-blocking)
• Large third-party scripts are loaded in the eager or lazy phase
• Images are not served through the EDS image pipeline (direct <img src="external-url">)
• A block's CSS introduces layout shifts (missing explicit dimensions before content loads)
• Heavy JS operations run in the decorate() function synchronously

The 100 LHS guarantee is real, but it is the developer's responsibility not to break it.

Where EDS Is Stronger

Key Takeaways

• Two authoring models: DA (da.live) for editorial simplicity, UE (xwalk) for visual precision
• Query API replaces server-side aggregation: Client-side JSON index for listing blocks
• Built-in experimentation: A/B testing and audience targeting without backend configuration
• Multi-locale via folder structure: No MSM, no live copies — simpler but less flexible
• Multi-brand from single repo: CSS custom property theming, template-based CSS loading
• Cross-repo sharing is weak: No built-in system; use NPM, submodules, or CDN
• Performance is structural: Built into the loading architecture, not bolted on later
• Performance is breakable: Head.html scripts, heavy eager JS, or external images break the guarantee

Next Steps

In the next chapter, we cover the comparison that matters most for experienced AEM developers: EDS vs AEM Feature Comparison.

We will cover every major AEM capability — Sling Models, editable templates, parsys, multifield, workflow, inheritance, ClientLibs, OSGi — and map each one to its EDS equivalent, workaround, or honest acknowledgment that there is no equivalent.