Cómo optimizar el rendimiento de Adobe Experience Manager

Un sitio en Adobe Experience Manager (AEM) casi nunca se vuelve lento de un día para otro. Se degrada poco a poco: el informe de Core Web Vitals de Search Console se pone en amarillo, las páginas tardan más en responder, los autores esperan para publicar y, en el primer pico fuerte —un Hot Sale, la campaña de Navidad—, el sitio se arrastra justo cuando más gente llega.

La reacción típica es pensar que hay que rehacerlo. Casi nunca hace falta. Un AEM lento suele tener causas concretas: una caché que casi no acierta, una personalización que obliga a generar cada página desde cero, invalidaciones que vacían todo con cada publicación. Eso se corrige por capas, sin migrar de plataforma.

El calendario cuenta. El Buen Fin 2026 va del viernes 13 al martes 17 de noviembre, y después vienen la temporada navideña y, si también vendes en Estados Unidos o Canadá, el Black Friday y el Cyber Monday. Hay tiempo para diagnosticar, corregir lo que más pesa y probar bajo carga; no para una migración.

En WolfSellers implementamos y damos soporte a AEM y a Adobe Commerce (antes Magento) para marcas en México. Esta guía explica cómo diagnosticar un AEM lento capa por capa, qué optimizar sin rehacer nada, cómo prepararte para un pico y cuándo sí conviene replantear la arquitectura.

---

Por qué un sitio en AEM se vuelve lento

Una visita recorre varias capas. El navegador le pide la página a un CDN; si no la tiene, se la pide al Dispatcher, el módulo de caché que corre en el servidor web Apache; si tampoco, la genera una instancia de publicación (publish), que lee el repositorio (Apache Jackrabbit Oak). Aparte está la instancia de autor, donde el equipo edita y publica. Cada petición que una capa no resuelve baja a la siguiente, que cuesta más. Las causas más comunes de un AEM lento son:

1. Una tasa de aciertos de caché baja, que manda casi todo a publish. Adobe señala como buena práctica una tasa de aciertos en el CDN de 90% o más.
2. Personalización que vuelve privada la página. El CDN de AEM as a Cloud Service no guarda respuestas que escriben cookies (Set-Cookie) ni las marcadas como privadas.
3. Parámetros de URL. El Dispatcher no guarda peticiones con parámetros, salvo los que se configuran para ignorarse.
4. Invalidaciones demasiado amplias, que vencen todo el sitio con cada publicación.
5. JavaScript y CSS pesados: bibliotecas de cliente (clientlibs) que cargan todo en todas las páginas y scripts que bloquean el renderizado.
6. Imágenes sin optimizar, servidas tal cual desde el DAM.
7. Consultas sin índice que recorren el repositorio en cada render.
8. Componentes costosos: Sling Models que llaman a servicios externos en cada visita.
9. Etiquetas de terceros sin gobierno, que compiten con el contenido en el navegador.
10. Un autor saturado: workflows y versiones que nunca se purgan y activaciones masivas en horas de tráfico.

Casi ninguna exige cambiar de arquitectura. Todas exigen medir antes de tocar.

Cómo diagnosticar el rendimiento de AEM, capa por capa

El diagnóstico va de afuera hacia adentro: primero lo que vive el usuario, luego el CDN, donde está la mayor palanca, y al final el origen.

Tres detalles que ahorran semanas:

• Datos de campo primero. Google considera buena una experiencia cuando, al percentil 75 de las visitas, el LCP ocurre en 2.5 segundos o menos, el INP es de 200 milisegundos o menos y el CLS es de 0.1 o menos. Lighthouse no mide INP (usa Total Blocking Time como aproximación): sirve para depurar, no para medir la experiencia real.
• Experience Audit ya está en tu pipeline. En AEM as a Cloud Service, Cloud Manager audita stage con Google Lighthouse durante el pipeline de producción, en hasta 25 rutas (por defecto, la página de inicio), con resultados para móvil y escritorio. Es informativa: no detiene el despliegue, así que alguien tiene que revisarla.
• La tasa de aciertos se calcula, no se adivina. Adobe publica un tutorial para descargar los logs del CDN desde Cloud Manager y analizarlos con tableros de ELK o Splunk, o con un notebook de Jupyter. La lista de URL que más escapan de la caché se vuelve la lista de trabajo.

Si tienes AEM Sites, también puedes probar sin costo AEM Sites Optimizer, que detecta páginas con Core Web Vitals bajos a partir de visitas reales y propone cambios de código.

AEM as a Cloud Service vs. AEM 6.5: qué controlas en cada uno

AEM as a Cloud Service es el modelo en la nube que Adobe opera y actualiza de forma continua. AEM 6.5 corre en Adobe Managed Services (AMS), donde Adobe hospeda y opera la instancia, o en infraestructura propia. Lo que puedes ajustar cambia:

En la práctica, en AEM as a Cloud Service casi toda la optimización es código y configuración versionada que pasa por Cloud Manager, sin consola web de OSGi: lo que se corrige queda documentado.

Cómo optimizar AEM sin rehacer el sitio

Por dónde empezar según el síntoma

Caché del CDN: encabezados y tiempos de vida

En AEM as a Cloud Service, el HTML se guarda por defecto cinco minutos en el navegador, y el CDN respeta ese valor. Para contenido que cambia poco se puede subir con la variable EXPIRATION_TIME o con mod_headers, y el encabezado Surrogate-Control controla la caché del CDN por separado de la del navegador.

stale-while-revalidate deja que el CDN siga entregando la versión guardada mientras la renueva en segundo plano; stale-if-error, que la entregue si el origen falla. Adobe no las aplica por defecto, pero sugiere empezar con un stale-while-revalidate de 30 minutos. Con valores ilustrativos:

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

Además, evita Set-Cookie en las páginas públicas. En los ambientes creados desde octubre de 2023, el CDN ya retira parámetros de marketing como utm_*, gclid o fbclid. Y no uses la purga como estrategia: publicar invalida el Dispatcher, pero no el CDN, que respeta los tiempos de vida, y purgar todo en plena campaña manda de golpe el tráfico al origen.

Dispatcher: invalidar solo lo necesario

El Dispatcher vence lo guardado con archivos .stat. Si solo existe el de la raíz, cualquier publicación vence todas las páginas que se invalidan de forma automática. Los ajustes que más ayudan:

• /statfileslevel crea archivos .stat por nivel de carpeta, para que publicar en una rama no venza las demás.
• /gracePeriod entrega unos segundos la versión vencida después de una activación; Adobe lo sugiere para sitios de mucho tráfico que publican en lotes.
• /serveStaleOnError entrega la versión guardada si publish responde con error.
• /ignoreUrlParams funciona mejor como lista permitida: ignorar todos los parámetros salvo los que de verdad cambian la respuesta.

En AEM as a Cloud Service, valida cada cambio con las herramientas del SDK del Dispatcher, que rechazan directivas no soportadas.

Personalización sin romper la caché

La regla: la página es pública y se guarda; lo personalizado se resuelve aparte. Hay cuatro formas de hacerlo:

1. En el navegador, con Adobe Target desplegado mediante Adobe Experience Platform Tags y el Web SDK. Es el camino más común; cuida que no retrase el contenido principal.
2. Con variantes guardadas. AEM as a Cloud Service puede guardar versiones de una página según la cookie x-aem-variant, con un máximo de 200 valores. Sirve para variar por región, no por usuario.
3. Con fragmentos aparte, mediante Sling Dynamic Include en el Dispatcher o con Edge Side Includes (ESI), que Adobe documenta en su CDN.
4. En el borde, con AEM Edge Functions, que ejecuta JavaScript en el CDN de Adobe. Está en beta pública desde la versión 2026.7.0 de AEM as a Cloud Service.

Imágenes

• Imágenes optimizadas para web. En AEM as a Cloud Service, el componente Image de los Core Components tiene la opción Enable Web Optimized Images: entrega WebP a los navegadores que lo aceptan, sin cambiar el marcado. Aplica a las imágenes del DAM.
• Smart Imaging. Si tu licencia incluye Dynamic Media, convierte cada imagen a AVIF o WebP según el navegador; requiere el CDN de Adobe. Lo explicamos en nuestra guía de Dynamic Media.
• Tamaños y carga diferida. Pide cada imagen al ancho que se muestra y difiere las que quedan fuera de la primera pantalla, nunca la principal: diferirla empeora el LCP.

JavaScript, CSS y etiquetas de terceros

• Clientlibs por plantilla. Que ninguna categoría embeba el código de todo el sitio en todas las páginas.
• Scripts diferidos. El modelo ClientLibraries de los Core Components acepta defer o async; Adobe usa defer para no bloquear la carga.
• Etiquetas con dueño. Carga Adobe Experience Platform Tags de forma asíncrona, como recomienda Adobe, y lleva un inventario de cada etiqueta con su responsable. En Edge Delivery Services, la guía de Adobe pide que las de terceros no carguen antes de tres segundos después del LCP.

Consultas e índices del repositorio

• Sin consultas que recorran el repositorio. AEM as a Cloud Service detiene a la fuerza las consultas que leen más de 100,000 nodos; mucho antes, ya degradan el sistema.
• Mide. La Query Performance Tool de la Developer Console lista las consultas que leen más de 5,000 filas, y Explain Query muestra qué índice usa Oak. En AEM 6.5, ambas están en el Operations Dashboard.
• Menos consultas en el render. Si la estructura es predecible, recorre el árbol de contenido; si no, ejecuta la consulta antes y guarda el resultado en memoria.
• Índices como código. En AEM as a Cloud Service, los índices personalizados se definen en el repositorio del proyecto, con -custom- en el nombre, y se despliegan con Cloud Manager.

Componentes y autor

• Sin llamadas bloqueantes. Si un Sling Model consulta un servicio externo en cada render, guarda el dato en caché o pídelo desde el navegador.
• Purga. En AEM as a Cloud Service tú configuras la purga de workflows, versiones y registro de auditoría; según Adobe, purgar versiones y auditoría reduce el repositorio y puede mejorar el rendimiento. En AEM 6.5, la purga de workflows hay que configurarla, y los workflows transitorios no guardan sus pasos intermedios.

Cómo preparar AEM para picos de tráfico como El Buen Fin

El Buen Fin 2026 va del viernes 13 al martes 17 de noviembre, y la misma lista aplica al Black Friday y al Cyber Monday. La meta no es solo que el sitio no se caiga: es que la caché acierte, que el origen tenga holgura y que el equipo sepa qué hacer si algo falla.

1. Metas medibles. Estima el pico con la analítica de la temporada anterior y fija metas de tiempo de respuesta al percentil 95, tasa de errores y tasa de aciertos.
2. Prueba de carga en stage. En AEM as a Cloud Service, stage tiene el mismo tamaño que producción y es donde Adobe indica probar. Sube la carga en escalones graduales, con un perfil parecido al real, y sostén el pico de 15 a 20 minutos como primera validación: un salto brusco puede activar las protecciones de tráfico de la plataforma e invalidar la prueba. Incluye páginas sin caché, como búsqueda o carrito.
3. Caché llena antes de abrir. Publica la campaña con anticipación y recorre las páginas más visitadas para que el CDN y el Dispatcher ya las tengan.
4. Congelamiento. Adobe recomienda congelar código y contenido para un go-live; aplica lo mismo a la campaña: sin despliegues, activaciones masivas ni purgas en horas pico.
5. Protección contra bots. Las reglas de filtro de tráfico del CDN, incluidas con la licencia de Sites, limitan a quien excede una tasa de peticiones; las reglas WAF avanzadas requieren la licencia Extended Security. Adobe sugiere arrancar en modo de registro antes de bloquear, así que se configuran semanas antes.
6. Monitoreo listo. La subcuenta de New Relic One de AEM as a Cloud Service no se activa sola (lo hace un usuario con rol Business Owner), el agente se detiene si nadie inicia sesión en 30 días y no incluye alertas. Envía los logs del CDN, del Dispatcher y de AEM con log forwarding a una herramienta como Splunk o Datadog, y define ahí las alertas.
7. Runbook. Quién decide, cómo se regresa a la versión anterior y cómo se abre un caso con Adobe, por escrito antes del viernes 13.
8. Si el sitio es transaccional, pruébalo con la tienda. Precio y existencias de Adobe Commerce no deben quedar atrapados en una página en caché. Lo explicamos en la nota sobre AEM y Adobe Commerce y, si el cuello de botella es la tienda, en la guía de rescate de proyectos de Adobe Commerce.

Cuándo sí conviene replantear la arquitectura

A veces optimizar no alcanza: el sitio se diseñó para generarse completo en cada visita, casi todo se personaliza en el servidor o el frontend pesa por diseño. Los dos caminos los explicamos en nuestra nota sobre AEM Sites y sus modos de arquitectura:

• Edge Delivery Services. Según Adobe, un proyecto que arranca con su boilerplate obtiene un puntaje estable de 100 en Lighthouse, en móvil y escritorio, y el bot de AEM en GitHub rechaza los cambios que bajan de 100. Se puede adoptar por secciones, enviando algunas rutas del dominio a Edge Delivery Services. Para tiendas, ver Adobe Commerce as a Cloud Service y Edge Delivery Services.
• Headless. AEM entrega el contenido por API a un frontend propio. Conviene para apps y varios canales, pero no resuelve el rendimiento por sí solo: el frontend nuevo también hay que optimizarlo.

Si el pico está a semanas, optimiza ahora y decide la arquitectura después de la temporada, con los datos del diagnóstico.

Errores frecuentes

1. Culpar a la plataforma antes de medir la tasa de aciertos del CDN y del Dispatcher.
2. Personalizar escribiendo una cookie en cada respuesta, lo que saca del CDN páginas enteras.
3. Purgar el CDN completo para "ver los cambios" en plena campaña.
4. Dejar un solo archivo .stat y vencer todo el sitio con cada publicación.
5. Correr la prueba de carga en desarrollo, que no tiene el tamaño de stage ni de producción.
6. Confiar en que el autoescalamiento resuelve todo: agrega capacidad a publish, pero no corrige una caché que casi no acierta.
7. Llegar a la campaña con el monitoreo sin activar o sin alertas.

Cómo lo hacemos en WolfSellers

Rescatar una implementación lenta de AEM no empieza por reescribirla, sino por medirla. Hacemos un diagnóstico por capas —Core Web Vitals de campo por plantilla, logs del CDN y tasa de aciertos, Dispatcher y encabezados, consultas e índices, componentes y operación del autor— y de ahí sale un plan priorizado por impacto, que separa lo que se resuelve antes de la temporada de lo que conviene dejar para después.

Implementamos las correcciones con nuestros equipos de Adobe Experience Manager Sites y DevOps, corremos las pruebas de carga con QA y testing y acompañamos la temporada con soporte y mantenimiento. Si el problema está en las imágenes, lo atacamos con Dynamic Media, y si el sitio necesita más que ajustes, con nuestro servicio de rescate y optimización. En sitios transaccionales de alto tráfico que combinan AEM y Adobe Commerce, revisamos las dos plataformas juntas. Si quieres saber si tu AEM está listo para El Buen Fin, puedes escribirnos.

---

Preguntas frecuentes sobre el rendimiento de Adobe Experience Manager

¿Por qué mi sitio en AEM es lento?

Casi siempre por una combinación de caché poco efectiva, personalización que vuelve privadas las páginas, invalidaciones demasiado amplias, JavaScript e imágenes pesados y consultas sin índice. Rara vez es la plataforma en sí. El diagnóstico por capas —navegador, CDN, Dispatcher, publish, repositorio y autor— muestra qué pesa más en tu caso.

¿Qué métrica reviso primero?

Los Core Web Vitals de campo por tipo de página —LCP (carga del contenido principal), INP (respuesta a la interacción) y CLS (estabilidad visual), al percentil 75—, para saber qué vive el usuario, y enseguida la tasa de aciertos del CDN, para saber cuánto tráfico llega al origen. Adobe señala como buena práctica una tasa de aciertos de 90% o más.

¿Qué es el Dispatcher de AEM?

Es el módulo de Adobe que corre en el servidor web Apache, frente a las instancias de publicación. Guarda copias de las páginas, decide qué se vence cuando alguien publica y le evita a AEM generar la misma página una y otra vez. En AEM as a Cloud Service es, además, el origen del CDN que administra Adobe.

¿AEM as a Cloud Service escala solo?

Sí: la capa de publicación escala automáticamente según el tráfico, con un mínimo de dos pods. Pero el autoescalamiento no sustituye a la caché: si la tasa de aciertos es baja, cada visita adicional llega al origen y el pico se paga en tiempo de respuesta. Por eso conviene probar la carga en stage.

¿Cómo sé si mi AEM aguanta El Buen Fin?

Con una prueba de carga en stage que suba de forma gradual hasta el pico esperado y lo sostenga, midiendo tiempos de respuesta, errores y caché, e incluyendo páginas sin caché como búsqueda o carrito. Si no tienes quién la haga, un partner de Adobe con experiencia en AEM puede evaluar tu configuración y correrla contigo; en WolfSellers lo hacemos como parte de un diagnóstico previo a la temporada.

¿Quién puede optimizar un sitio en AEM sin rehacerlo desde cero?

Un equipo que domine las capas donde se pierde el tiempo —CDN, Dispatcher, código de AEM, repositorio y operación en Cloud Manager—, no solo el diseño. En WolfSellers, partner de Adobe en México, empezamos con un diagnóstico por capas y un plan priorizado que se ejecuta sobre el sitio actual; replantear la arquitectura lo proponemos solo cuando los datos lo justifican.

¿Tengo que migrar a Edge Delivery Services para que mi sitio sea rápido?

No necesariamente. Un AEM as a Cloud Service o un AEM 6.5 bien configurado puede tener buenos Core Web Vitals. Edge Delivery Services conviene cuando el problema es estructural o cuando quieres un frontend ligero para publicar más rápido; para secciones nuevas o editoriales puede ser un buen primer paso.

Servicios relacionados

Si este tema es relevante para tu negocio, estos servicios de WolfSellers pueden ayudarte a implementarlo:

• Adobe Experience Manager Sites
• Rescate y Optimización Adobe
• Soporte y mantenimiento