Adobe Experience Manager: The CMS That Makes Websites Worse

For years now, I’ve been watching websites move onto Adobe Experience Manager. Sites belonging to large corporations, to brands, to institutions. Every time, the same scene plays out: the previous version was faster, easier to read, or simpler to navigate. The AEM version is heavier, slower to respond, or more confusing. Sometimes all three.

I’m not claiming this as a law. It’s an observation, repeated often enough that I eventually started keeping track, and never contradicted by a convincing case among the public sites I’ve been able to compare before and after, or that are well known enough for anyone to examine. I’ve looked. When someone shows me an AEM site that “works well,” it works well compared to other AEM sites. Not compared to what the same site did before, and not compared to what a leaner stack delivers on the same budget.

This isn’t a post about AEM’s price, or about maintaining it. It’s about something simpler and more uncomfortable: the end product, the thing visitors actually see, is worse. And about why that outcome is no accident.

What I look at, and how anyone can do the same

I’m not talking about an expert’s gut feeling. I look at four things, three of which can be measured.

First, Core Web Vitals from field data, meaning measurements from real Chrome users collected in the Chrome UX Report (CrUX), not a one-off lab test run from a fast workstation. LCP (Largest Contentful Paint) tells you how long it takes for the main content to appear; the “good” threshold is 2.5 seconds at the 75th percentile. INP (Interaction to Next Paint) measures how quickly the page responds to each click or keystroke; the threshold is 200 ms. CLS measures layout shifts. PageSpeed Insights shows these field values for any origin with enough traffic, for free, no account required.

Second, perceived smoothness: the lag between clicking a menu and seeing it react, whether scrolling stutters, whether carousels load in fits and starts.

Third, navigational clarity: how many levels deep, how many clicks to reach a product page or a form, and whether the information architecture survived the migration or was rebuilt to fit the templates.

Finally, the response time you actually feel on pages that aren’t served from cache: search results, customer accounts, forms.

To compare families of sites against each other, HTTP Archive publishes a Core Web Vitals Technology Report that cross-references CrUX with technology detection, and AEM is included. I use it with caution: detecting AEM behind a Dispatcher and a CDN is hit-or-miss, and comparing the average AEM site to the average WordPress site amounts to comparing enterprise accounts to personal blogs. The measurement that matters is the same site, before and after. That’s the one I make, and the one I invite you to make.

The pattern that repeats after migration

The first symptom is front-end weight. An AEM site loads its ClientLibs, the in-house mechanism that bundles JavaScript and CSS per component, then the scripts from Adobe’s ecosystem (Launch, Analytics, Target), then the third-party scripts marketing adds through Launch without ever involving a developer. Every component brings its own library, every team adds its own tag, and nobody ever removes one. The total often reaches several megabytes of JavaScript where the previous version loaded a few hundred kilobytes.

The second symptom is INP. All that JavaScript runs at the exact moment the user wants to interact. A menu that opens after a dead pause, a tab that reacts a beat late, a catalog filter that freezes the page. LCP can stay passable thanks to the CDN; INP, on the other hand, degrades almost every time, because it depends on what’s running in the browser.

The third symptom shows up on the authoring side. AEM promises autonomy for marketing teams. In practice, every new need goes through a component: Java or HTL code, an editing dialog, a ClientLib, a template policy, and then a deployment pipeline. Content teams end up more dependent on developers than they were before, and they work around it by stacking generic components or dropping in raw HTML. The public site inherits all of it.

The fourth symptom is caching. AEM’s architecture relies on the Dispatcher, an Apache module that serves pre-rendered pages. As soon as you turn on personalization, Target segments, profile-based content, or on-demand publishing, a growing share of pages can no longer be served from that cache. Response time falls back to whatever the publish instance can manage, and it shows.

One example I check regularly: the press site of a Munich-based automaker. A press site has exactly one job: let a journalist find a press release and download its photos in two clicks. The old version did that. The AEM version opens on a carousel of five news items you have to scroll through, a handful of links underneath, filters by brand and by topic, and a cookie banner warning that some modules will be disabled if you decline. Under the hood, the full Adobe kit: Launch, the Client Data Layer, the customer data platform, plus jQuery and core-js side by side. All of that to display press releases. The content hasn’t changed; the distance between the journalist and the press release has.

None of this comes down to a sloppy vendor. I’ve seen it with certified integrators, comfortable budgets, and competent teams. The result is close to mechanical.

Why it’s structural, not a botched implementation

AEM was never designed to produce fast web pages. It was designed to govern content inside a large organization: permissions, approval workflows, multi-site and multilingual management, reusable fragments, integration with Analytics, Target, the DAM, and the rest of the Experience Cloud. These are real strengths, for the IT department. Not one of them concerns the visitor.

Its technical foundation comes from Day Software, which Adobe acquired in 2010: a JCR repository (Jackrabbit, then Oak), the Apache Sling framework, OSGi bundles. Adobe then kept stacking: Touch UI, editable templates, Content Fragments, Experience Fragments, Cloud Manager, and finally the Cloud Service version. Each layer adds new concepts, and none of them retires the old ones. I’ve described the same kind of stacking at Meta, where fifteen years of acquisitions and pivots produced a maze that even seasoned developers struggle to get through. Same mechanism, same result.

That complexity pushes teams, almost automatically, toward custom code. Adobe’s Core Components handle the simple cases; everything else, meaning everything that makes a brand’s site distinctive, becomes bespoke code, written by an integrator, shipped with its own ClientLibs, and rarely revisited. Three years later, nobody knows which libraries are still doing anything.

Finally, to put it plainly, a fast AEM site requires four mechanisms tuned together and kept in tune over time: the component code, the bundling of their libraries, the Dispatcher cache, and the CDN in front of it all. On launch day, someone got them in tune. After that, nobody is paid to do it again. In detail, you have to master, all at once, library bundling, Dispatcher cache rules, cache invalidation, CDN configuration, and the personalization layer that cuts across all of it. Each team masters one piece. The optimal state exists on launch day, while the integrator is still around, and then it erodes.

Adobe knows this. Since 2023, the company has been pushing Edge Delivery Services (formerly Franklin, formerly Helix), a separate delivery pipeline: content written in Word or Google Docs, framework-free JavaScript in a Git repository, no ClientLibs, and a Lighthouse score of 100 checked on every pull request. Adobe even publishes a guide called Keeping it 100 and states in its FAQ that every EDS site can and should hit that score. In a press release, a customer quoted by Adobe goes from a Lighthouse score of 35 to 100 by switching to EDS. The interesting number isn’t the 100; it’s the 35. That was the starting point, on classic AEM. A vendor that builds a second product to get fast pages is admitting the first one couldn’t. And EDS doesn’t fix AEM, it routes around it, shifting the complexity into Git and office documents. I’ve already argued that moving complexity around is not the same as removing it.

Decisions made by people who will never open the tool

Who chooses AEM? Rarely the content editors who will spend their days in it, and never the visitors. The decision is made by IT or by the digital leadership, often in a company that’s already an Adobe customer for Analytics, Creative Cloud, or Target. It’s made on criteria of governance, integration, and reputation: the logo is reassuring, the consulting firm recommends it, the partner integrator is already an approved vendor in procurement.

“Will the site be better for users?” doesn’t appear on the scorecard, or if it does, only as a vendor promise, never as a measurement. Neither does the usability of the authoring interface: the people signing off will never write a single page.

The price doesn’t help bring the decision back down to earth. Adobe publishes no price list. Everything goes through a negotiated quote, by module (Sites, Assets, Forms), by deployment model, and by volume. Buyer reviews describe the pricing as opaque and high. Estimates published by integrators and pricing comparison sites put the annual license somewhere in the five-to-six-figure range, the initial implementation anywhere from several hundred thousand to several million dollars, and ongoing support at around 15 to 25 percent of the license. I don’t know what French contracts look like, and I won’t make up numbers. But spending on that scale, committed without a public price list and without any measurement of what it delivers to users, says something about how the decision gets made. I’ve already looked at Adobe’s pricing policy on the Creative Cloud side; at least there it’s legible. Here, it isn’t even that.

What that money buys is peace of mind for whoever signs. Not the quality of what visitors see.

What this says beyond Adobe

The first issue is sovereignty, in the most concrete sense. An AEM site is a proprietary technical model from end to end: the repository, the content structure, the components, the deployment pipeline in Cloud Manager, the bundled CDN, and now hosting on Adobe’s own infrastructure with the Cloud Service version. Getting out requires a rewrite. The content can be recovered; the site cannot. For a French company or a public institution, that means handing its public-facing channel to an American vendor, with an exit door that costs as much as another migration.

The second is the false promise of “digital experience.” The product’s very name contains the word experience. What it actually sells is internal governance: who can publish what, in which language, after which approval. All of that makes life better for the organization. None of it improves the page the user loads, and as we’ve just seen, the opposite happens.

The third goes beyond Adobe. Enterprise tools, CMSs included, produce mediocre-to-middling websites as soon as they’re deployed at scale. I’m fond of the French word simplexité, “simplexity”: complexity that has been tamed so it presents as simple to the user. AEM is its exact opposite. The complexity isn’t tamed beneath the surface; it rises all the way up to the visitor’s screen, in kilobytes of JavaScript and hundreds of milliseconds. The process got optimized, not the result.

Check for yourself, don’t take my word for it

AEM isn’t unusable. Some AEM sites hold up, and an excellent team can get something clean out of it for a while. But structurally, for the reasons laid out here, it produces sites that are worse in usability, experience, and performance than what the same site did before, or than what a leaner stack delivers on the same budget. I made the same case about headless WordPress: a simple, well-cached tool beats a sophisticated architecture that isn’t under control, and the latter is the rule, not the exception.

Don’t take my word for it. Pick a site you know has moved to AEM. Open PageSpeed Insights, look at the field data, INP in particular. Compare it with a Wayback Machine snapshot of the previous version if you can, or simply with a competitor’s site that didn’t make that choice. Count the clicks it takes to get to what you’re looking for.

And if you know of a site that actually improved by moving to AEM, in field data and not on a slide deck, send it my way. I’ve been looking for one for years. I’ll gladly publish the counterexample, because it would teach me something. For now, the list is empty.