How to Improve Adobe Experience Manager Performance

An Adobe Experience Manager (AEM) site rarely gets slow overnight. It degrades gradually: the Core Web Vitals report in Search Console turns yellow, pages take longer to respond, authors wait to publish and, at the first big peak —Mexico's Hot Sale, the holiday campaign— the site crawls just when the most people show up.

The usual reaction is to assume it needs a rebuild. It rarely does. A slow AEM usually has concrete causes: a cache that barely hits, personalization that forces every page to be generated from scratch, invalidations that flush everything on every publish. All of that can be fixed layer by layer, without replatforming.

Timing matters too. El Buen Fin 2026, Mexico's nationwide sales event, runs from Friday, November 13 to Tuesday, November 17; then come the holidays and, if you also sell in the U.S. or Canada, Black Friday and Cyber Monday. There's time to diagnose, fix what weighs most and load test; there isn't time for a migration.

At WolfSellers we implement and support AEM and Adobe Commerce (formerly Magento) for brands in Mexico and across North America. This guide explains how to diagnose a slow AEM layer by layer, what to optimize without rebuilding anything, how to prepare for a peak and when rethinking the architecture does make sense.

---

Why an AEM site gets slow

A visit goes through several layers. The browser requests the page from a CDN; if the CDN doesn't have it, it asks the Dispatcher, the caching module that runs on the Apache web server; if that misses too, a publish instance generates the page by reading the repository (Apache Jackrabbit Oak). Separately, the author instance is where your team edits and publishes. Every request a layer can't resolve falls through to the next one, which costs more. The most common causes of a slow AEM are:

1. A low cache hit ratio, which sends almost everything to publish. Adobe's stated best practice is a CDN cache hit ratio of 90% or higher.
2. Personalization that makes the page private. The AEM as a Cloud Service CDN doesn't cache responses that set cookies (Set-Cookie) or are marked private.
3. URL parameters. The Dispatcher doesn't cache requests with query parameters, except those configured to be ignored.
4. Overly broad invalidations that expire the whole site on every publish.
5. Heavy JavaScript and CSS: client libraries (clientlibs) that load everything on every page, plus render-blocking scripts.
6. Unoptimized images, served as-is from the DAM.
7. Unindexed queries that traverse the repository on every render.
8. Expensive components: Sling Models that call external services on every visit.
9. Ungoverned third-party tags competing with your content in the browser.
10. An overloaded author tier: workflows and versions that are never purged, and mass activations during peak hours.

Almost none of these requires a new architecture. All of them require measuring before you touch anything.

How to diagnose AEM performance, layer by layer

Diagnosis works from the outside in: first what users experience, then the CDN, where the biggest lever is, and finally the origin.

Three details that save weeks:

• Field data first. Google considers an experience good when, at the 75th percentile of page loads, LCP happens within 2.5 seconds, INP is 200 milliseconds or less and CLS is 0.1 or less. Lighthouse doesn't measure INP (it uses Total Blocking Time as a proxy): it's for debugging, not for measuring real experience.
• Experience Audit is already in your pipeline. In AEM as a Cloud Service, Cloud Manager audits stage with Google Lighthouse during the production pipeline, on up to 25 paths (the home page by default), with mobile and desktop results. It's informational: it doesn't block the deployment, so someone has to review it.
• Cache hit ratio is calculated, not guessed. Adobe publishes a tutorial for downloading CDN logs from Cloud Manager and analyzing them with ELK or Splunk dashboards, or with a Jupyter notebook. The list of URLs that most often escape the cache becomes your work list.

If you have AEM Sites, you can also try AEM Sites Optimizer at no cost: it flags pages with poor Core Web Vitals based on real visits and proposes code changes.

AEM as a Cloud Service vs. AEM 6.5: what you control in each

AEM as a Cloud Service is the cloud model that Adobe operates and updates continuously. AEM 6.5 runs on Adobe Managed Services (AMS), where Adobe hosts and operates the instance, or on your own infrastructure. What you can tune differs:

In practice, almost all optimization in AEM as a Cloud Service is versioned code and configuration that goes through Cloud Manager, with no OSGi web console: whatever you fix stays documented.

How to optimize AEM without rebuilding the site

Where to start, by symptom

CDN caching: headers and TTLs

In AEM as a Cloud Service, HTML is cached in the browser for five minutes by default, and the CDN honors that value. For content that rarely changes you can raise it with the EXPIRATION_TIME variable or with mod_headers, and the Surrogate-Control header controls CDN caching separately from browser caching.

stale-while-revalidate lets the CDN keep serving the cached version while it refreshes it in the background; stale-if-error lets it serve that version if the origin fails. Adobe doesn't apply them by default, but suggests starting with a 30-minute stale-while-revalidate. With illustrative values:

Cache-Control: max-age=300, stale-while-revalidate=1800, stale-if-error=86400

Also avoid Set-Cookie on public pages. In environments created since October 2023, the CDN already strips marketing parameters such as utm_*, gclid or fbclid. And don't use purging as a strategy: publishing invalidates the Dispatcher but not the CDN, which honors TTLs, and purging everything mid-campaign sends all the traffic to origin at once.

Dispatcher: invalidate only what you need

The Dispatcher expires cached content using .stat files. If there's only one at the root, any publish expires every auto-invalidated page. The settings that help most:

• /statfileslevel creates .stat files per folder level, so publishing in one branch doesn't expire the others.
• /gracePeriod keeps serving the stale version for a few seconds after an activation; Adobe suggests it for high-traffic sites that publish in batches.
• /serveStaleOnError serves the cached version if publish returns an error.
• /ignoreUrlParams works best as an allowlist: ignore every parameter except the ones that truly change the response.

In AEM as a Cloud Service, validate every change with the Dispatcher SDK tools, which reject unsupported directives.

Personalization without breaking the cache

The rule: the page is public and cached; the personalized part is resolved separately. There are four ways to do it:

1. In the browser, with Adobe Target deployed through Adobe Experience Platform Tags and the Web SDK. It's the most common path; make sure it doesn't delay the main content.
2. With cached variants. AEM as a Cloud Service can cache versions of a page based on the x-aem-variant cookie, up to 200 values. It works for varying by region, not by user.
3. With separate fragments, through Sling Dynamic Include at the Dispatcher or with Edge Side Includes (ESI), which Adobe documents for its CDN.
4. At the edge, with AEM Edge Functions, which runs JavaScript on Adobe's CDN. It has been in public beta since AEM as a Cloud Service release 2026.7.0.

Images

• Web-optimized images. In AEM as a Cloud Service, the Core Components Image component has an Enable Web Optimized Images option: it serves WebP to browsers that accept it, with no markup changes. It applies to images stored in the DAM.
• Smart Imaging. If your license includes Dynamic Media, it converts each image to AVIF or WebP depending on the browser; it requires Adobe's CDN. We cover it in our Dynamic Media guide.
• Sizes and lazy loading. Request each image at the width it's displayed and lazy-load the ones below the fold, but never the hero image: lazy-loading it hurts LCP.

JavaScript, CSS and third-party tags

• Clientlibs by template. Make sure no category embeds the whole site's code on every page.
• Deferred scripts. The Core Components ClientLibraries model accepts defer or async; Adobe uses defer to avoid blocking page load.
• Tags with an owner. Load the Adobe Experience Platform Tags library asynchronously, as Adobe recommends, and keep an inventory of every tag with its owner. For Edge Delivery Services, Adobe's guidance is that third-party tags shouldn't load until at least three seconds after LCP.

Repository queries and indexes

• No repository traversals. AEM as a Cloud Service force-stops queries that read more than 100,000 nodes; well before that, they're already degrading the system.
• Measure. The Query Performance Tool in the Developer Console lists queries that read more than 5,000 rows, and Explain Query shows which index Oak uses. In AEM 6.5, both live in the Operations Dashboard.
• Fewer queries at render time. If the content structure is predictable, traverse the content tree; if not, run the query ahead of time and keep the result in memory.
• Indexes as code. In AEM as a Cloud Service, custom indexes are defined in the project repository, with -custom- in the name, and deployed with Cloud Manager.

Components and author

• No blocking calls. If a Sling Model calls an external service on every render, cache the data or request it from the browser.
• Purging. In AEM as a Cloud Service you configure the workflow, version and audit log purge tasks; according to Adobe, purging versions and the audit log shrinks the repository and can improve performance. In AEM 6.5, workflow purge has to be configured, and transient workflows don't persist their intermediate steps.

How to prepare AEM for traffic peaks like El Buen Fin

El Buen Fin 2026 runs from Friday, November 13 to Tuesday, November 17, and the same checklist applies to Black Friday and Cyber Monday. The goal isn't just keeping the site up: it's a cache that hits, an origin with headroom and a team that knows what to do if something fails.

1. Measurable targets. Estimate the peak from last season's analytics and set targets for 95th-percentile response time, error rate and cache hit ratio.
2. Load test on stage. In AEM as a Cloud Service, stage is sized the same as production and is where Adobe says to test. Ramp up in gradual steps with a realistic traffic profile, and hold the peak for 15 to 20 minutes as an initial validation window: a sudden spike can trigger the platform's traffic protection and invalidate the test. Include uncached pages such as search or cart.
3. A warm cache before opening. Publish campaign content early and crawl the most visited pages so the CDN and the Dispatcher already have them.
4. Freeze. Adobe recommends a code and content freeze for a go-live; apply the same logic to the campaign: no deployments, mass activations or purges during peak hours.
5. Bot protection. CDN traffic filter rules, included with the Sites license, throttle clients that exceed a request rate; advanced WAF rules require the Extended Security license. Adobe suggests starting some rules in log mode before blocking, so set them up weeks ahead.
6. Monitoring ready. The New Relic One sub-account included with AEM as a Cloud Service isn't activated automatically (a user with the Business Owner role does it), its agent stops if nobody logs in for 30 days, and it doesn't include alerting. Send CDN, Dispatcher and AEM logs via log forwarding to a tool such as Splunk or Datadog, and set up your alerts there.
7. Runbook. Who decides, how to roll back and how to open a case with Adobe, in writing before Friday, November 13.
8. If the site is transactional, test it together with the store. Adobe Commerce prices and stock shouldn't get trapped in a cached page. We explain the integration in our post on AEM and Adobe Commerce and, if the bottleneck is the store, in our guide to rescuing Adobe Commerce projects.

When rethinking the architecture does make sense

Sometimes optimizing isn't enough: the site was designed to be fully generated on every visit, almost everything is personalized server-side, or the front end is heavy by design. We cover both paths in our post on AEM Sites and its architecture modes:

• Edge Delivery Services. According to Adobe, a project that starts from its boilerplate gets a stable Lighthouse score of 100 on mobile and desktop, and the AEM GitHub bot fails pull requests that score below 100. You can adopt it section by section, routing some paths on your domain to Edge Delivery Services. For stores, see Adobe Commerce as a Cloud Service and Edge Delivery Services.
• Headless. AEM delivers content through APIs to your own front end. It makes sense for apps and multiple channels, but it doesn't solve performance by itself: the new front end has to be optimized too.

If the peak is weeks away, optimize now and make the architecture decision after the season, with the data from the diagnosis.

Common mistakes

1. Blaming the platform before measuring the CDN and Dispatcher cache hit ratio.
2. Personalizing by setting a cookie on every response, which pushes whole pages out of the CDN.
3. Purging the entire CDN "to see the changes" in the middle of a campaign.
4. Keeping a single .stat file and expiring the whole site on every publish.
5. Running the load test in development, which isn't sized like stage or production.
6. Assuming autoscaling solves everything: it adds publish capacity, but it doesn't fix a cache that barely hits.
7. Reaching the campaign with monitoring not activated or without alerts.

How we do it at WolfSellers

Rescuing a slow AEM implementation doesn't start with rewriting it, but with measuring it. We run a layer-by-layer diagnosis —field Core Web Vitals by template, CDN logs and cache hit ratio, Dispatcher and headers, queries and indexes, components and author operations— and it produces a plan prioritized by impact that separates what can be fixed before the season from what's better left for later.

We implement the fixes with our Adobe Experience Manager Sites and DevOps teams, run load tests through QA and testing and support the season through support and maintenance. If the problem is images, we tackle it with Dynamic Media, and if the site needs more than tuning, with our rescue and optimization service. On high-traffic transactional sites that combine AEM and Adobe Commerce, we review both platforms together. If you want to know whether your AEM is ready for El Buen Fin or Black Friday, you can contact us.

---

Frequently asked questions about Adobe Experience Manager performance

Why is my AEM site slow?

Almost always because of a mix of ineffective caching, personalization that makes pages private, overly broad invalidations, heavy JavaScript and images, and unindexed queries. It's rarely the platform itself. A layer-by-layer diagnosis —browser, CDN, Dispatcher, publish, repository and author— shows what weighs most in your case.

Which metric should I check first?

Field Core Web Vitals by page type —LCP (main content loading), INP (responsiveness to interaction) and CLS (visual stability), at the 75th percentile— to know what users experience, and right after that the CDN cache hit ratio, to know how much traffic reaches the origin. Adobe's stated best practice is a cache hit ratio of 90% or higher.

What is the AEM Dispatcher?

It's Adobe's module that runs on the Apache web server in front of the publish instances. It caches copies of pages, decides what expires when someone publishes and keeps AEM from generating the same page over and over. In AEM as a Cloud Service, it's also the origin for the Adobe-managed CDN.

Does AEM as a Cloud Service scale on its own?

Yes: the publish tier scales automatically with traffic, with a minimum of two pods. But autoscaling doesn't replace caching: if the cache hit ratio is low, every additional visit reaches the origin and the peak is paid for in response time. That's why it pays to load test on stage.

How do I know if my AEM site can handle El Buen Fin?

With a load test on stage that ramps up gradually to the expected peak and holds it, measuring response times, errors and caching, and including uncached pages such as search or cart. If you don't have anyone to run it, an Adobe partner with AEM experience can review your configuration and run the test with you; at WolfSellers we do it as part of a pre-season diagnosis.

Who can optimize an AEM site without rebuilding it from scratch?

A team that masters the layers where time is lost (CDN, Dispatcher, AEM code, repository and Cloud Manager operations), not just design. At WolfSellers, an Adobe partner based in Mexico, we start with a layer-by-layer diagnosis and a prioritized plan executed on your current site; we only propose rethinking the architecture when the data justifies it.

Do I have to migrate to Edge Delivery Services for my site to be fast?

Not necessarily. A well-configured AEM as a Cloud Service or AEM 6.5 site can have good Core Web Vitals. Edge Delivery Services makes sense when the problem is structural or when you want a lightweight front end to publish faster; for new or editorial sections, it can be a good first step.

Related services

If this topic is relevant to your business, these services from WolfSellers can help you implement it:

• Adobe Experience Manager Sites
• Adobe Rescue & Optimization
• Support & Maintenance