Checklist de optimización de rendimiento para Magento 2

Un checklist solo sirve si está en el orden correcto. Este está ordenado por impacto y por dependencia: primero la infraestructura, porque marca el techo de cada página; el frontend al final, porque nunca puede correr más que un backend lento. Recórralo de arriba abajo. No salte a la sección de frontend porque sea la visible: una tienda que devuelve el HTML en 1.800 ms no puede aprobar LCP por bien que afine las imágenes.

Esta es la lista de ejecución. Para el razonamiento detrás de cada punto —por qué el hit rate de Varnish importa más que instalar Varnish, por qué el bundling nativo de JS perjudica en HTTP/2— vea la guía de rendimiento para Magento 2 que la acompaña. Aquí solo recorremos la lista.

Antes de tocar nada: línea base

No puede demostrar una mejora que no midió. Anote primero estos números, con datos de campo, no solo con una ejecución de laboratorio:

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1: los tres Core Web Vitals con los que Google posiciona de verdad
• TTFB ≤ 800 ms: no es un Core Web Vital, pero es la base de todos ellos

Después:

• Saque los datos de campo de PageSpeed Insights (CrUX) para sus tres tipos de página principales —portada, categoría, producto—, por separado para móvil y escritorio.
• Ejecute Lighthouse solo para diagnosticar. Laboratorio ≠ campo. Una tienda puede sacar 95 en Lighthouse y aun así suspender Core Web Vitals en el campo, porque los usuarios reales llegan a páginas sin cachear, con redes más lentas y con sesión iniciada, cosas que la ejecución de laboratorio nunca toca.
• Pruebe también una página sin cachear con sesión iniciada: ese es el camino lento que una ejecución anónima y en frío de Lighthouse nunca ve.
• Apunte los números con fecha. CrUX es una ventana móvil de 28 días, así que volverá a comprobarlos dentro de un mes, no la misma tarde.

Capa 1 — Backend e infraestructura (el techo)

Las mejoras más grandes y baratas viven aquí. Nada de lo que venga después puede superar el TTFB que produce esta capa.

Full-page cache (Varnish)

• Varnish está delante de Magento, no la caché PHP integrada. Confirme un HIT en una página cacheable: curl -sI https://yourstore.com/ | grep -i x-magento-cache-debug.
• El hit rate de la caché es sano: apunte bastante por encima del 80 %. Compruébelo con varnishstat -1 | grep cache_hit. Auditamos con regularidad tiendas con Varnish por debajo del 40 %, lo que significa que la mayoría de los visitantes recibe el camino lento de todos modos.
• Los parámetros UTM y de marketing no están fragmentando la caché. Normalice o elimine ?utm_* en el VCL, para que cada enlace de campaña no genere una entrada de caché única.
• Nada vacía toda la caché con cada guardado de producto. Un vaciado completo en horario comercial mantiene la tienda permanentemente en frío.

Contenido privado (el impuesto del hole-punching)

• Audite cada etc/frontend/sections.xml del código. Cada sección personalizada añade carga a la petición /customer/section/load que se dispara en casi todas las páginas.
• La respuesta de section/load es pequeña y rápida. Compruébela en la pestaña Network con sesión iniciada y con un carrito. Hemos visto respuestas de más de 200 KB que tardan 800 ms y deshacen una página cacheada que por lo demás era rápida.

Redis

• Instancias separadas (o, como mínimo, bases de datos separadas) para la caché por defecto, la caché de página y las sesiones, para que un pico de sesiones no pueda expulsar sus entradas de caché.
• maxmemory-policy allkeys-lru en las instancias de caché. El noeviction por defecto lanza errores duros cuando Redis se llena, en lugar de descartar claves antiguas.
• Redis no está expulsando constantemente. Compruebe redis-cli info stats | grep evicted_keys y redis-cli info memory.

PHP y OPcache

• PHP 8.4 en 2.4.8 (8.4 es la rama recomendada para producción). Subir desde una rama anterior suele dar entre un 15 y un 25 % de mejora en tiempo de ejecución sin cambiar código. Tenga en cuenta que 2.4.9 requiere PHP 8.4 u 8.5 y abandona por completo 8.2.
• OPcache dimensionado para Magento: opcache.memory_consumption=512 o más, opcache.max_accelerated_files=60000 y opcache.validate_timestamps=0 en producción.
• Caché de realpath ampliada: realpath_cache_size=10M, realpath_cache_ttl=86400.
• Autoloader de Composer optimizado como parte del deploy: composer dump-autoload -o --apcu.

MySQL

• innodb_buffer_pool_size es adecuado: una parte grande del conjunto de trabajo debería caber en RAM.
• El log de consultas lentas está activado y se revisa. Una sola consulta personalizada sin índice puede dominar el TTFB de un tipo de página mientras todas las demás parecen ir bien.

Capa 2 — Higiene de configuración de Magento

Mejoras gratis. Son ajustes, no ingeniería.

• Modo producción. bin/magento deploy:mode:show devuelve production. El modo developer en una tienda en vivo es un impuesto grande y silencioso.
• Indexers por programación. bin/magento indexer:show-mode: todo en Update by Schedule. «Update on Save» bloquea tablas en un catálogo grande y ralentiza tanto el admin como la tienda.
• El cron está corriendo de verdad. bin/magento cron:status, más monitorización sobre la tabla cron_schedule. Un cron roto significa índices desactualizados, una cola de mensajes sin procesar y una degradación a cámara lenta que cuesta atribuir a una causa.
• Flat Catalog está DESACTIVADO. Quedó obsoleto hace años y hoy añade sobrecarga de indexación sin ningún beneficio en las consultas, porque la búsqueda pasa por OpenSearch. Sobrevive en las tiendas solo porque los artículos antiguos siguen recomendándolo.
• El bundling nativo de JS y el merge de JS/CSS están DESACTIVADOS. En HTTP/2 y HTTP/3, el bundle de varios megabytes es un impuesto de parseo y ejecución que cae directo sobre su INP. Haga el bundling en un pipeline de build real, con code splitting.
• El minificador de JS integrado de Magento está DESACTIVADO: es lento y da problemas en el deploy. Minifique en el paso de build o en el borde de la CDN.
• Opciones asíncronas activadas donde encajen: indexación asíncrona, envío asíncrono de correos de pedido y actualizaciones de stock diferidas para tiendas con mucho volumen.

Capa 3 — Búsqueda

• OpenSearch 2.19 (el objetivo de 2.4.8). El soporte de Elasticsearch se eliminó en 2.4.8, así que si viene de una rama anterior esto es un punto de migración, no una nota al pie.
• OpenSearch tiene heap suficiente y no es el cuello de botella oculto en las páginas de categoría y de navegación por capas con un catálogo grande.

Capa 4 — Frontend y recursos

Solo ahora —cuando el backend ya puede entregar el HTML rápido— el trabajo de frontend rinde de verdad.

• La imagen del LCP se precarga con fetchpriority="high" y no se carga en diferido. Cargar en diferido la imagen principal o la primera imagen de producto es la herida de LCP autoinfligida más habitual que encontramos.
• Cada imagen y cada embed tiene width/height explícitos (o una relación de aspecto reservada). Esto por sí solo corrige la mayor parte del CLS.
• WebP o AVIF servidos con negociación automática de formato en la CDN (Cloudflare, Fastly, CloudFront). No requiere cambios en el código.
• Todo lo que queda por debajo del pliegue se carga en diferido, incluidas las partes que la mayoría de los temas renderiza con avidez.
• El CSS que bloquea el renderizado está reducido, con el CSS crítico incrustado donde el tema lo permita.
• Los scripts de terceros están auditados. Los tag managers, los widgets de chat y las herramientas de A/B testing son con frecuencia el mayor contribuyente individual al INP. Cárguelos en diferido, y haga que cada uno justifique su coste.

La cuestión del tema, brevemente

Si una tienda Luma sigue suspendiendo INP y LCP después de todo lo anterior, probablemente esté chocando con el techo estructural de Luma: RequireJS y Knockout.js envían un grafo de JavaScript enorme en cada página. Hyvä lo sustituye por Tailwind y Alpine y envía una fracción; las tiendas migradas suelen pasar de suspender dos de los tres Core Web Vitals a aprobar los tres antes de cualquier ajuste a medida. Pero es una licencia de pago y una reconstrucción del frontend, no un interruptor de configuración. La regla honesta: migre si ya está rediseñando o cambiando de plataforma; si no, la optimización dirigida consigue mejoras reales por mucho menos. El análisis completo está en la guía de rendimiento.

Verifique que ganó de verdad

• Vuelva a sacar los datos de campo de CrUX / PageSpeed unos 28 días después del cambio. CrUX es una ventana móvil de 28 días, así que una mejora de laboratorio el mismo día no es prueba.
• Compare con su línea base fechada, por tipo de página, en móvil y escritorio.
• Siga vigilando el TTFB y el hit rate de Varnish como señales continuas, no como una comprobación puntual: los dos se desvían a medida que crecen el catálogo y el tráfico.

Una fecha límite que conviene señalar

Si está en Magento 2.4.6, el soporte termina el 11 de agosto de 2026: a partir de ahí no hay más parches de seguridad ni correcciones. En ese punto la actualización es una fecha límite de seguridad además de una oportunidad de rendimiento, y Adobe soporta pasar directamente de 2.4.6 a 2.4.8 sin el paso intermedio. Vea la guía de actualización de 2.4.6 a 2.4.9.

Emyrix hace optimización de rendimiento para Magento y Adobe Commerce: profiling, arquitectura de caché y trabajo de Core Web Vitals, medido contra datos de campo y no contra una puntuación de laboratorio. Si su tienda es lenta y prefiere saber por qué antes que adivinarlo, escríbanos.