Alright, now for something completely different. Let’s talk Adobe Experience Manager Content Fragments, and let’s talk a little about Fragment blocks, because both can be used in a similar way. This is a very quick one that I hope someone gets some value out of as I recently ran into it and was a little surprised it happened.
Let me get it setup a little:
You’re running into this scenario: you update a Content Fragment. You save it. You publish it. You go look at the page that uses it.
Annnnnd… Nothing changed.
So you publish it again, because that’s what anyone would do. What you see shocks you: it’s still the old copy, sitting right there. You scratch your head and ponder, “How did I get here? What were the life decisions that led me down this path?”
New idea! Let’s clear the browser cache.
Sometimes that maybe actually does fix it, but not every time… and now you’ve spent several minutes on something that should have been about nine seconds.
This has been coming up for some time now, even in the era of AI. The reason is annoying and I feel you. Publishing a Content Fragment and updating the pages that reference it are two different events.
Whether the second one happens on its own comes down to a detail nobody really tells you, which is how your pages actually consume the fragment.
Why that is a thing
If the content gets baked into the page when the page is published, then every page holding a copy goes stale the moment you edit the fragment, and the only thing that dislodges it is republishing all of them. Ten pages, fine, but let’s say it’s something like 10,000… that doesn’t feel good. I fully understand the pain here.
If instead the page fetches the fragment at runtime, through a fragment include or a GraphQL query, the edit lands without republishing anything, give or take whatever cache TTLs sit in front of it.
The option that never came up
For a lot of what people build, Content Fragments might actually be overkill, but it really depends on the purpose.
If you’re delivering web only, you’re on Edge Delivery, and you have no second channel, no headless consumer, no custom app or third party pulling the content you’ve created, and the only thing you care about is authoring simplicity and design control, then the Fragment block in Edge Delivery is usually the better road.
Author a document, put it in a /fragments/ folder, reference it. No fragment model, no GraphQL layer, none of the complex decisioning that needs to take place.
There’s a catch. Edge Delivery fragments pulled in by the browser are their own separate resource. Part of the reason Adobe warns that content may not be indexed alongside the rest of the embedding page.
Here’s kind of a breakdown of what this looks like.
Fragment block | Content Fragments | |
|---|---|---|
| Setup | A document in /fragments/ | Model, GraphQL layer, consume pattern |
| Propagation | No republish needed | Depends entirely on the consume pattern |
| Variants and personalization | Not modelled | Yes |
| Feeds non-web surfaces | No | Yes |
| Indexing | Client-side, so keep primary content out | Can be published as semantic HTML via the overlay |
So none of these are the right answer on their own. Your business requirements are going to decide which one gets implemented when/where.
Here’s a made-up scenario. Semi-inspired by something I sat through recently where a decision was made to go with Content Fragments even though the business requirements no longer justified them.
Let’s say that you’re trying to figure out a promotional callout that needs to appear across a few hundred pages. If that were the whole requirement, the Fragment block handles it cleanly. That’s the decision. No Questions, Next task please.
But, I tend to ask more questions.
“Does this content need to be personalized by segment?” “Is there an integration with another partner or service or something along those lines?” “Is there an external app we need to feed with this content?”
Yes to any of those: Content Fragments are probably the right call.
Well, here’s the part that is from real-life: Maybe the app slips, it wasn’t real, the partner integrations get cancelled, and personalization turns out to be maybe just two different variants that no one has gotten around to building.
What’s left is a promotional callout appearing across a few hundred pages of a website, which is web-only reuse, which is the exact thing a Fragment Block does with a fraction of the setup.
Nobody reconsiders the decision, because it doesn’t feel like it’s necessary. It got made. There was a slide about it that everyone loved in the presentation, it looked good too - followed brand guidelines and everything.
So the full Content Fragment model stays, and so does the server-side de-referencing that got wired up along the way. The first time anyone counts the cost is when someone changes one word and has to republish four hundred pages to make it show up when they were trying to get messaging out quickly.
The dividing line isn’t “do I have reusable content,” because everybody has reusable content. It’s whether this content needs to feed something that isn’t a website. Ask that one early, and ask it out loud.
Sources
- Publishing Content Fragments to Edge Delivery as self-contained semantic HTML, via the overlay and the json2html transformation, from Adobe’s “Publishing AEM Content Fragments to Edge Delivery Services” and “JSON2HTML for Edge Delivery Services”.
- Client-side decoration of fragments, the indexing caveat, and the guidance to keep primary canonical content in the main document, from “Fragments”.