El trabajo de rendimiento que Mage-OS incluye y Magento no

La mayoría de los consejos de rendimiento para Magento tratan sobre su tienda: su configuración de caché, sus imágenes, el stack de extensiones que nadie ha auditado en tres años. Esto trata sobre la plataforma que hay debajo, y en concreto sobre tres cosas que Mage-OS incluye y Magento no.

Dos de las tres son paquetes de Composer que podría instalar esta misma tarde en un Magento Open Source normal. Mage-OS los elige, fija sus versiones y los activa. Es una afirmación más modesta que «funciones exclusivas», y sigue siendo la razón por la que yo miraría la distribución.

Plugins compilados

Cada clase de Magento con un plugin asociado recibe un interceptor generado. En tiempo de ejecución, cada método interceptado pregunta a la lista de plugins si hay algo registrado para él —la ruta ___callPlugins—, y lo pregunta en casi cada llamada, exista un plugin o no.

creatuity/magento2-interceptors compila esa decisión y la elimina. El código generado contiene un switch que llama directamente a los plugins concretos, de modo que la búsqueda nunca ocurre.

Mage-OS lo fija, y yo comprobé el metapaquete en lugar de fiarme de un changelog: creatuity/magento2-interceptors en 1.3.8 es un require de mage-os/product-community-edition 3.4.0.

El número que lleva asociado es en torno a un 10 % menos de tiempo de respuesta del servidor, entre un 5 y un 15 % según el modo. Es la cifra de los autores del módulo y la que usó la propuesta de inclusión en Mage-OS, junto con una nota de que lleva en producción desde 2019 en más de 49.000 instalaciones vía Composer. No lo he medido, y no he encontrado a nadie que haya publicado una medición en una tienda real, así que trate ese 10 % como una afirmación de gente con trayectoria y no como una medida.

La parte que me parece realmente interesante es que esto se propuso a Magento y nunca se integró, por razones arquitectónicas. Si mantiene una plataforma que corre en decenas de miles de tiendas con stacks de extensiones que nunca ha visto, negarse a cambiar cómo funciona la intercepción es una respuesta perfectamente buena. Mage-OS sirve a un conjunto de tiendas más pequeño y más implicado, miró el mismo módulo y lo incluyó activado por defecto. Mismo código, distinto apetito de riesgo. Ese es el argumento a favor de una distribución comunitaria en un solo ejemplo, y es más convincente que cualquier cosa de la página de gobernanza.

Vivir con él le cuesta dos cosas. Cualquier cambio en la configuración de plugins implica limpiar generated/code y var/cache, así que tanto su flujo local como sus scripts de deploy tienen que saberlo: un equipo que lo olvide perderá una hora con un plugin que «no está funcionando». Y los stack traces cambian, porque los plugins se llaman directamente en lugar de a través de ___callPlugins. Esto segundo yo lo llamaría una mejora sin más; por fin se ve lo que se está ejecutando de verdad.

Dos casos límite documentados merecen un vistazo a su propio código. Los nombres de plugin que solo se diferencian en mayúsculas sobre la misma clase compilan solo uno de los dos. Y hay un informe antiguo sobre desactivar un plugin en un ámbito pero no en otro, que el proponente no pudo reproducir en 2.4.7.

¿Lo activaría? En una tienda con un entorno de staging en el que alguien confía, sí. En una tienda donde los deploys se hacen a mano y nadie está muy seguro de qué hizo el último, lo dejaría estar; no porque el módulo sea frágil, sino porque la regla de limpieza de caché castiga exactamente a ese tipo de equipo. Es un tipo de caché compiled_plugins, así que apagarlo es un cambio de configuración y quitarlo es un comando de Composer.

Carga lazy de objetos

Esta la escribió Mage-OS por su cuenta, y es el trabajo que cambió lo en serio que me tomo el proyecto.

La fábrica de DI de Magento construye las dependencias con avidez. Mage-OS añadió objetos lazy-ghost de PHP 8.4 a la fábrica compilada a través de ReflectionClass::newLazyGhost(), de modo que la construcción espera hasta que algo usa el objeto de verdad. Un análisis en tiempo de compilación excluye todo lo que PHP no puede hacer lazy —interfaces, clases abstractas, traits, clases final, enum y readonly, cualquier cosa que extienda una clase interna, proxies—, y toda la ruta está condicionada a PHP 8.4, así que los runtimes antiguos no pagan nada en absoluto.

Después marcaron 74 clases del núcleo como #[NonLazy], porque hacer lazy algo que se realiza en cada petición es sobrecarga pura. Esas 74 no fueron suposiciones. Salieron de telemetría de tasa de realización por clase recogida en catorce cargas de trabajo —URLs de la tienda en frío y en caliente, más un par de comandos CLI—, y las tasas se separaron limpiamente, con la mayoría de las clases en un extremo del rango o en el otro.

Es más rigor del que esperaba. Ambos cambios llegaron en mayo de 2026 y vienen en la 3.0, y si una extensión da por hecho la construcción con avidez y se cae, hay opciones para desactivarlo de forma global y por clase.

bfcache, reglas de especulación y view transitions

mage-os/module-theme-optimization conecta tres funciones del navegador que casi ninguna tienda Magento usa: la caché de avance/retroceso, la precarga especulativa a través de la Speculation Rules API y las view transitions. Los ajustes están en Stores > Configuration > Advanced > System con ámbito de sitio web y de vista de tienda, y los tres vienen activados por defecto. Cualquier tema, 2.4.5 o superior.

El valor por defecto que me importa de verdad es la lista de exclusión, que ya cubre customer, login, logout, auth, cart, checkout y search. Unas reglas de especulación apuntadas sin cuidado a una tienda Magento prerenderizarán encantadas una URL de añadir al carrito. Que alguien haya pensado en eso antes de publicarlo es la diferencia entre una función y un ticket de soporte.

La salvedad viene del propio README de Mage-OS: «bfcache availability varies based on your Full Page Cache engine and hosting. Some require additional setup», nombrando a Varnish y Fastly. Varnish es lo que usan la mayoría de las tiendas Magento serias, así que dé por hecho que la función estrella necesita trabajo en su stack antes de hacer nada. Chrome DevTools tiene un panel de Back/forward cache que se lo dice en un minuto, lo que vale más que un año de suposiciones.

Qué mediría antes de repetir nada de esto

Cada número de arriba viene de la gente que escribió el código. Lo midieron, sus afirmaciones son concretas, y nadie independiente las ha comprobado.

Antes de decirle «10 %» al director financiero de un cliente, querría el tiempo de respuesta antes y después en el mismo hardware, con la full-page cache en el estado en que corre producción de verdad: los interceptors compilados cambian la ejecución de PHP, así que un benchmark que golpea Varnish está midiendo Varnish. Probaría contra el stack de extensiones real de la tienda y no contra una instalación limpia, porque la mejora escala con cuántos plugins hay, y también la probabilidad de tropezar con uno. Y vigilaría el INP y el LCP en las plantillas de categoría y producto, no en la portada.

Medio día de trabajo, y cabe dentro de un proyecto de rendimiento normal.

Uno que todavía no ha salido

Hay un pull request abierto en el fork del núcleo de Mage-OS que guarda cada área de DI compilada no global como su diferencia respecto a global en lugar de una copia completa. Los números cuesta ignorarlos: de 44,6 MB de metadatos de DI compilados a unos 7 MB, y crontab.php resultó ser un duplicado byte a byte de global.php, con 6,5 MB.

Está abierto y sin integrar, así que hoy nadie lo tiene. Lo menciono porque el tamaño de la DI compilada aparece en los tiempos de deploy y en el disco de cada entorno que tenga, y ese tipo de cosas nunca llega a una lista de funciones.

Entonces, ¿Mage-OS es más rápido?

Probablemente, un poco, sobre todo por los plugins compilados. Nadie independiente lo ha medido.

Es una afirmación más débil que la del marketing y me siento cómodo con ella. Una distribución que incluye por defecto una optimización de la clase del 10 %, hace su propio trabajo de DI a partir de telemetría en lugar de intuición y pone valores por defecto sensatos en las reglas de especulación está tomando mejores decisiones por usted que una instalación estándar. Lo que no hará es rescatar una tienda que es lenta por las razones de siempre. Si su TTFB es de dos segundos, nada de esto es su problema.

Emyrix hace trabajo de rendimiento en Magento y Mage-OS, incluida la medición de antes y después que le dice si un cambio se ha ganado el sitio. No tenemos ninguna relación comercial con la Mage-OS Association, Creatuity ni ninguno de los autores de módulos nombrados aquí. Si quiere que su tienda se mida como es debido, escríbanos.

El comportamiento de los módulos, las versiones y las afirmaciones proceden de los repositorios de Mage-OS y Creatuity y de la propuesta de inclusión en Mage-OS; el requisito del metapaquete se leyó del repositorio de Composer de Mage-OS el 18 de agosto de 2026. Las cifras de rendimiento citadas son de los propios autores de los módulos y no están verificadas de forma independiente.