EDS Capabilities and Limits

Overview of EDS capabilities: authoring models, dynamic blocks, query API usage, experimentation, multi-site support, metadata handling, performance, and the cases where EDS is stronger than traditional AEM.

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

When any page is published (or previewed), EDS indexes its metadata into a JSON file
The JSON file is available at /{path}/query-index.json
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:

NPM packages: Publish shared utilities as NPM packages and import them
Git submodules: Include shared code as a git submodule
Copy-paste: Duplicate shared code across repositories (common but creates maintenance burden)
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:

Technique	Effect
LCP block prioritization	LCP image/text renders before any other JS/CSS runs
No render-blocking resources	JS and CSS load after first paint
Edge-side delivery	Pages served from CDN edge nodes, not origin servers
Automatic WebP	Smaller image payloads
Responsive images	Right-sized images for each viewport
Lazy loading	Images below fold load after LCP
Minimal JS payload	No framework JS (no React, no Angular)
No server-side rendering latency	Static HTML from edge cache

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

Capability	EDS Advantage
Time to first page	Authoring a new page takes minutes. No template creation, no component policy configuration.
Performance	Structural 100 LHS guarantee. Traditional AEM requires significant optimization effort to reach the same scores.
Authoring simplicity	DA authoring requires zero CMS training. Authors already know how to use a document editor.
Deployment speed	`git push` is deployment. No Cloud Manager pipeline required for code changes.
Experimentation	Built-in A/B testing without Adobe Target licensing.
Developer experience	Hot reload, no build step, changes visible in seconds.
Cost	Lower infrastructure cost for read-heavy sites (edge CDN, no persistent publish tier).
Scalability	CDN edge delivery scales horizontally with zero configuration.

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.