Mi checklist de rendimiento para Adobe Commerce

Las páginas lentas cuestan ventas en cualquier plataforma, y las causas se repiten de una tienda a otra. Todo mi trabajo ha sido en Magento y Adobe Commerce, así que los detalles que siguen están escritos para Adobe Commerce. El orden de las comprobaciones y el razonamiento que hay detrás valen para la mayoría de los stacks.

Todos mis proyectos de rendimiento empiezan igual. Antes de tocar código, repaso estas doce comprobaciones en una copia de staging y con la monitorización de producción. Esa revisión suele explicar la mayor parte de la lentitud y me indica en qué conviene invertir la primera semana de trabajo.

El orden importa. Los problemas de infraestructura tapan todo lo que hay encima. Si la caché de página completa falla, ningún trabajo de frontend hará que las páginas de categoría parezcan rápidas. Por eso empiezo por la infraestructura y voy subiendo capa a capa.

Infraestructura

1. Tasa de acierto de la caché de página completa. Varnish o la caché de página completa integrada. Miro la tasa de acierto por tipo de página, porque una buena tasa en la portada puede ocultar una página de categoría que nunca se sirve desde la caché. Si en las categorías está por debajo del 80 % (una regla práctica mía), corrige eso primero. Las causas habituales son cookies o parámetros de URL que cambian la clave de caché, y bloques que desactivan la caché de toda la página. Una tercera causa son las etiquetas de caché que purgan mucho más de lo debido al guardar un producto.

2. Redis para sesiones y caché. Sesiones y caché van en instancias de Redis separadas, para que una caché llena no expulse las sesiones de los clientes. Reviso el uso de memoria, el número de expulsiones y la política de expulsión. Si hay expulsiones en la instancia de sesiones, los clientes pierden el carrito; si las hay en la de caché, la tienda reconstruye una y otra vez los mismos datos.

3. Salud del motor de búsqueda. Heap de OpenSearch o Elasticsearch, número de shards y slow log. Un heap escaso se nota en una navegación por filtros y unas búsquedas lentas bajo carga, mucho antes de que aparezcan errores. También compruebo que el índice de búsqueda no se reconstruye para todo el catálogo varias veces al día.

4. PHP-FPM y OPcache. Suficientes workers para el pico de tráfico, pero no tantos como para que el servidor empiece a usar swap. OPcache debe tener tamaño suficiente para todo el código, incluido el código generado. Cuando se llena, PHP recompila archivos en cada petición y los tiempos de respuesta se disparan sin causa aparente. Reviso opcache.memory_consumption, opcache.max_accelerated_files y la tasa de acierto.

Backend

5. Indexadores. Todos en «Update by Schedule», el cron se ejecuta cada minuto, ningún indexador está atascado en «processing» y ninguna tabla de changelog crece sin límite. «Update on Save» ralentiza cada guardado en el admin y puede bloquear tablas en horas de mucho tráfico. Un indexador atascado también explica muchos casos de precios o stock que se ven mal en la tienda.

6. Log de consultas lentas. Lo activo en staging con un volumen de datos como el de producción o lo leo de la monitorización de la base de datos en producción. Los culpables habituales son las tablas propias sin índices, seguidas de colecciones cargadas dentro de bucles y de atributos propios añadidos con JOIN a cada listado de productos. Un solo índice que falta en una tabla propia con mucho uso puede añadir segundos a una página.

7. Módulos de terceros en la ruta crítica. Los plugins y observers sobre la carga de productos, el renderizado de precios, el carrito y el checkout se ejecutan en casi cada petición. Los enumero, desactivo cada uno en una copia de staging y mido la diferencia. Normalmente sale una lista corta de dos o tres módulos que se llevan la mayor parte del tiempo de backend. Para cada uno decido si configurarlo, sustituirlo o eliminarlo.

8. Caché de layout y bloques. Un solo bloque marcado con cacheable="false" en un archivo de layout hace que toda la página quede fuera de la caché de página completa. Lo busco en el código y en cada módulo instalado. El contenido personalizado va en las secciones de contenido privado, que se cargan con JavaScript.

Frontend

9. Peso de JavaScript. En un tema basado en Luma cuento los módulos RequireJS que carga una página de producto y miro cuánto script se ejecuta antes de que la página sea interactiva. El bundling y la minificación ayudan algo; quitar módulos que nadie usa ayuda más. Las tiendas Hyvä evitan casi todo este problema, porque el tema no usa RequireJS ni la pila de JavaScript de Luma.

10. CSS crítico y carga de fuentes. Como mucho una hoja de estilos bloqueante, CSS crítico en línea para la primera pantalla y fuentes cargadas con font-display: swap para que el texto se vea mientras llegan. También cuento los archivos y pesos de fuente que pide cada página; una lista larga indica que el diseño creció sin que nadie vigilara el coste.

11. Imágenes. Tamaños correctos para cada breakpoint, WebP o AVIF, ancho y alto explícitos para que el contenido no se desplace al cargar, y carga diferida por debajo de la primera pantalla. La imagen principal del producto y la primera fila de la categoría deben cargarse de inmediato, porque diferir la imagen más grande de la página retrasa el Largest Contentful Paint.

12. Etiquetas de terceros. Analítica, chat, reseñas, tests A/B y píxeles de marketing. Cada contenedor del gestor de etiquetas cuesta milisegundos reales en el hilo principal. Enumero cada etiqueta y averiguo quién es su responsable y si alguien sigue usando sus datos. Quito las que nadie usa y cargo el resto tras el consentimiento y, cuando se puede, tras la primera interacción.

Qué te da la checklist

Al terminar las doce comprobaciones tengo una lista ordenada de problemas, cada uno con su coste y su lugar en el orden de corrección. La mayoría de las tiendas tienen tres o cuatro puntos que importan y muchos detalles menores que no. Esa lista se convierte en el plan de la fase de correcciones, presupuestado en horas para que decidas qué merece la pena.

La checklist no sustituye a la medición. Antes y después de cada cambio registro datos de usuarios reales en las páginas que generan ingresos, para que veas la mejora en las cifras.

Si quieres que la aplique a tu tienda con un informe por escrito, consulta el servicio de optimización de rendimiento.