Content Fragments in AEM for Headless Delivery
Adobe Experience Manager has long served as a complete platform for assembling digital experiences, but the way content is consumed today rarely fits the old monolithic template. Headless delivery strips away the presentation layer and hands structured data to whatever front-end stack a team prefers. Content Fragments are the building blocks that make this architecture practical inside AEM, separating editorial copy from layout without forcing content authors to think in code.
For Australian engineering teams the appeal is concrete. Government departments in Sydney and Brisbane, banks headquartered in Melbourne such as ANZ and NAB, and retailers from Perth to Adelaide all need to publish the same product description, policy summary, or campaign landing copy across a website, a mobile app, a kiosk, and sometimes a smartwatch app. A single source of truth that can be queried as JSON makes that work sane rather than heroic.
This piece walks through the fundamentals of Content Fragments, from what they actually are and how they differ from Experience Fragments, through modelling, delivery APIs, integration with modern JavaScript frameworks, and the performance trade-offs that matter once a site starts serving real traffic. Along the way you will see where Australian regulations such as the Privacy Act 1988 and the Australian Consumer Law shape what can be cached, where to draw boundaries, and which patterns hold up under scrutiny.
If you want to deepen this beyond a written guide, the recordings and slides from past CIRCUIT conferences remain a useful reference, and the CIRCUIT FAQ covers the practical questions developers most often ask before adopting the headless pattern in production.
What Content Fragments Are and How They Differ
A Content Fragment is a piece of editorial content stored under /content/dam rather than under /content. That single difference carries consequences: the fragment is treated as an asset, versioned, translatable, and queried through APIs instead of rendered as a page. Each fragment is created against a Content Fragment Model, which defines the schema: text fields, rich text, JSON, references to other fragments, and external links. Authors fill in the model; developers consume the output as structured JSON.
Experience Fragments look superficially similar but solve a different problem. An Experience Fragment is a piece of page-level composition, a paragraph plus a hero plus a call to action, designed to be reused across multiple pages while preserving layout. Content Fragments are intentionally layout-free. They give you copy and metadata, not HTML scaffolding.
The distinction matters for headless work. Experience Fragments are tied to AEM's template and HTL rendering, so handing them to a React app means either screen-scraping HTML or rebuilding the structure outside AEM. Content Fragments are already structured, so the receiving application can map fields directly to components. For Australian teams running government portals, a typical pattern is to put policy text and frequently asked questions into Content Fragments, then surface them on the main site, in a React-based internal portal, and inside a third-party chatbot widget, all from one place.
| Feature | Content Fragments | Experience Fragments | Standard AEM Pages |
|---|---|---|---|
| Stored under | /content/dam |
/content/experience-fragments |
/content/<site> |
| Primary purpose | Structured editorial content | Reusable page compositions | Full authored pages |
| Headless-friendly | Yes, JSON via Assets API | Limited, custom serializer often required | No, presentation-bound |
| Translation support | Full Translation Workflow | Full Translation Workflow | Full Translation Workflow |
| Versioning | Yes, native | Yes | Yes |
| Best consumer | SPAs, mobile apps, IoT, external systems | Other AEM pages | Web visitors |
Modelling for Reuse, Translation, and Compliance
The model is where headless projects succeed or fail. A Content Fragment Model is a schema authored in AEM, defining fields such as a short title, a body of rich text, a hero image reference, a list of related product fragments, and a set of metadata tags. Each field type has a delivery implication: text fields become JSON strings, multi-line fields can include structured markup, JSON fields carry arbitrary structured data, and reference fields become nested objects pointing at other fragments.
When a model is well designed the same fragment can be used across a Sydney-based retail site, a Melbourne campaign microsite, and an Adelaide government service. Australian English spelling is set at the field level, translation workflows pick up the rest, and content authors do not need to think about which consumer is going to read what they write.
Compliance also shapes the model. Under the Privacy Act and the Australian Privacy Principles, fragments that contain personal information must be flagged so they are not cached downstream, and any field that could carry a date of birth, a Medicare number, or a customer's contact details should be marked as restricted. AEM's metadata schema can enforce that at edit time, which is far more reliable than expecting developers to scrub JSON at the API gateway.
Authoring Workflow and Editorial Governance
Content Fragments move through workflows just like pages. Authors create drafts, editors review, legal or compliance approvers sign off, and only then does the fragment become available to downstream consumers. This is the part that tends to win over Australian governance teams, who are accustomed to the Notifiable Data Breaches scheme and the record-keeping expectations of agencies such as the Office of the Australian Information Commissioner.
Workflows can branch. A financial services team in Sydney might require marketing approval and legal review before publishing anything that mentions interest rates, while a Queensland tourism site might let editors publish directly. Modelling those branches in the workflow rather than in code keeps the audit trail clean and makes future reorganisations less painful.
A common extension is to integrate editorial tooling with broader enterprise systems. Teams that already use plugin-style architectures on the back end, for instance those exploring a plugin framework with MEF in .NET Core, can model approval steps as discrete services, each one registered and testable on its own.
Delivering Content via the Assets HTTP API
The standard delivery surface for Content Fragments is the Assets HTTP API, exposed at /api/assets and /content/dam. A GET on a fragment returns a JSON envelope with the element values, references, metadata, and variation names. Variations let authors store multiple renditions of the same content, such as a long-form description, a one-sentence summary, and a social post, all under one logical fragment.
For high-traffic Australian sites the practical delivery setup involves three layers. AEM serves as the origin, a CDN such as Akamai or Cloudflare sits in front with regional points of presence including Sydney and Melbourne, and the consuming application hydrates fragments on demand or pre-fetches them at build time. Caching headers must respect the cache TTL the editorial team sets, otherwise staging edits will leak into production.
Security also enters the picture. Anonymous delivery is fine for marketing fragments, but anything containing personal information needs authentication, and Australian Privacy Principle 6 governs what can be disclosed to a third-party host. A common pattern is to terminate auth at the edge and let only authorised consumers reach the protected elements.
Integrating with Modern Front-End Frameworks
Headless AEM works best when the front-end stack is comfortable consuming JSON. Next.js, Nuxt, and Gatsby all integrate cleanly. The pattern is straightforward: at request time the front end resolves which fragments it needs, fetches them through the API, and renders them inside React or Vue components. For static delivery, fragments can be pulled at build time and inlined into the bundle.
Sydney and Melbourne front-end shops tend to adopt this pattern early because it lets the same content appear on a campaign site, a product detail page inside an existing AEM site, and a small native application without duplicating editorial work. Teams that already manage AEM A/B testing with Adobe Target often extend that experimentation surface to headless properties, treating fragment variations as targeting inputs.
Less obvious integrations also benefit. A regional sports organisation in Sydney running a multilingual fan site might keep match reports as Content Fragments and surface them through a custom mobile app, while a parallel grassroots programme exploring how to adapt sport material for different age groups, similar to community sport traditions documented in pieces such as this overview of adapted school baseball, can use the same pattern to deliver age-appropriate content to coaches in different states.
Performance, Caching, and SEO Considerations
The performance story for headless AEM is more nuanced than the marketing decks suggest. The first request to a fragment can be slower than a traditional page render because the data layer has to resolve references, apply variations, and pass through any workflow checks. Once the fragment is in a CDN, however, the cost is amortised across every subsequent request, and Core Web Vitals improve because the JSON payload is small and cacheable.
Australian publishers pay particular attention to cache locality. A site serving visitors across Sydney, Brisbane, Perth, and Darwin will see different performance characteristics from each city depending on which CDN nodes are warm. Tuning that layer is a discipline covered in depth in resources on AEM performance tuning for high-traffic events, and most teams will revisit the configuration several times a year.
For search engines, structured data travels with the fragment when the model includes it, and teams that need server-side rendering for SEO typically hydrate fragments inside a Next.js getStaticProps or getServerSideProps call. Done well, the headless pattern outperforms the legacy template approach on every meaningful metric. Done badly, it introduces latency that no amount of CDN tuning will fix.
Watch the recordings from the 2015 and 2016 CIRCUIT conferences on the site to see how architects presented these patterns to their peers, browse the speaker pages to find presenters who specialised in headless delivery, and check the agenda archives for the specific sessions on Sightly, microservices, and IoT that touched on the same architecture. If your team is weighing a move to headless AEM or already running it and hitting the limits, the CIRCUIT site has the recordings, the agenda, and the speaker contacts to help you take the next step.