Fragments

Fragments are reusable chunks of site content: think headers, footers, or any element that appears on multiple pages. In Adobe Experience Manager (AEM) Edge Delivery Services, fragments have moved from “nice-to-have” add-ons to a built-in foundation of the product.

Making fragments first-class citizens eliminates duplicate markup, streamlines caching all the way to the CDN, and delivers consistent performance. Every new AEM project built with boilerplate now ships with header and footer fragments out of the box, so teams can author once and reuse everywhere with minimal effort.

How Fragments work

A fragment is a standalone piece of content (authored as either a document or a spreadsheet) that can be reused across multiple pages. Instead of copying the same content into every page, authors create a single source of truth and reference it where needed. This content is then inserted into the page at the time of delivery: documents are served as semantic HTML and spreadsheets as JSON (data-driven or table-like content).

Because fragments are delivered from separate resources, they can be cached and served independently. This improves performance and reduces the load on the main page, especially for content that appears across many parts of a site.

Referencing Fragments

Fragments can be referenced in multiple ways, depending on the use case.

• Automatically by boilerplate: Fragments (like the header and footer) are programmatically pulled in by the site's display logic.
• Conditionally by metadata: Fragments can also be loaded based on page metadata. For example, a promotional banner might only appear on pages using a specific template.
• Manually by authors: Authors can selectively place a Fragment block with an explicit reference to a fragment document using the .aem.page or .aem.live link.

Documents in the /fragments/ folders are automatically recognized and treated as fragments. For example, a link to https://main--site--org.aem.page/fragments/my-fragment will automatically be auto-blocked and decorated without additional author effort.

For implementation details, see the fragment block documentation.

When to use Fragments

Fragments are ideal for content that appears across multiple pages, but reuse isn’t the only reason to use them. Sometimes, isolating a complex section (even if it appears only once on site) can make some pages easier to manage from an authoring perspective. Creating smaller, more focused fragments can reduce visual and structural clutter.

Fragments can also improve delivery performance by allowing a more controlled loading pattern for content that may not be relevant to all users (like content below the fold). It is important, however, that performance considerations are not the primary driver for content modeling decisions about when to use fragments.

When to avoid Fragments

While fragments can offer reusability and simplicity, they also introduce a level of indirection which can sometimes make authoring less intuitive. Instead of managing all content for a page in one document, fragments require authors to deal with references, navigate between multiple documents, and understand the separate life cycles (preview/publish) between those resources. For this reason, it’s best to use fragments only when they provide a clear benefit.

In most cases, fragments are best suited to content that enhances the page but isn’t central to its meaning (like headers, footers, or supplemental sections). Primary canonical content should remain in the main document to ensure clarity for both authors and automated systems (like search engines and indexers) that are trying to identify the main content on a page.

This is especially relevant for tools like spiders and robots that don’t support JavaScript execution. Because fragments are decorated on the client side, their content may not be indexed alongside the rest of the embedding page. Failing to separate essential and auxiliary content can result in inconsistent indexing and negatively impact SEO performance.