Mi checklist de rendimiento para Adobe Commerce

Cada proyecto de rendimiento empieza igual. Antes de tocar código, repaso la lista de abajo en una copia de staging y con la monitorización de producción. Normalmente explica la mayor parte de la lentitud y me dice dónde debe ir 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 categorías parezcan rápidas. Por eso empiezo por la base de la pila y voy subiendo.

Los umbrales de abajo son reglas prácticas mías, no cifras oficiales. Marcan dónde empiezo a hacer preguntas, no límites estrictos.

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 y no una cifra global, porque una portada sana puede ocultar una página de categoría que falla en cada petición. Si está por debajo del 80 % en categorías, corrige eso primero. Las causas habituales son cookies o parámetros de URL que cambian la clave de caché, bloques que desactivan la caché de toda la página y etiquetas de caché que purgan mucho más de lo necesario 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 la navegación por filtros y en los resultados de búsqueda lentos bajo carga, mucho antes de que aparezcan errores. También compruebo que el índice de búsqueda no se reconstruye entero 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. Todo en «Update by Schedule», cron ejecutándose cada minuto, ningún indexador atascado en «processing» y ninguna tabla de changelog creciendo 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 explica además muchos casos de precios o stock que se ven mal en la tienda.

6. Log de consultas lentas. Lo activo en staging con datos de tamaño real o lo leo de la monitorización de la base de datos en producción. Las tablas personalizadas sin índices son el culpable habitual, seguidas de colecciones cargadas dentro de bucles y atributos propios unidos 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. Suele salir una lista corta de dos o tres módulos que se llevan la mayor parte del tiempo de backend, y una decisión para cada uno: configurar, sustituir o eliminar.

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 secciones de contenido privado cargadas por JavaScript, no en bloques no cacheables.

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 diseño no salte y carga diferida fuera 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. El resto, cárgalo tras el consentimiento y tras la interacción siempre que se pueda.

Qué te da la checklist

Al terminar las doce comprobaciones tengo una lista ordenada: qué está roto, cuánto cuesta y qué corregir primero. La mayoría de las tiendas tienen tres o cuatro puntos que importan y una cola larga que no. Esa lista se convierte en el plan de la fase de correcciones, presupuestada en horas para que decidas qué merece la pena.

La checklist no sustituye a la medición. Registro datos de usuarios reales en las páginas que generan ingresos antes y después de cada cambio, para que la mejora se vea en cifras y no solo en la sensación de que la tienda va más rápida.

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