The Performance Work Mage-OS Ships and Magento Doesn't

Most Magento performance advice is about your store — your cache config, your images, the extension stack nobody has audited in three years. This is about the platform underneath it, and specifically three things Mage-OS ships that Magento doesn't.

Two of the three are Composer packages you could install on plain Magento Open Source this afternoon. Mage-OS picks them, pins them and turns them on. That's a smaller claim than "exclusive features," and it's still the reason I'd look at the distribution.

Compiled plugins

Every Magento class with a plugin attached gets a generated interceptor. At runtime, each intercepted method asks the plugin list whether anything is registered for it — the ___callPlugins path — and it asks on nearly every call, whether a plugin exists or not.

creatuity/magento2-interceptors compiles that decision away. The generated code holds a switch statement calling the specific plugins directly, so the lookup never happens.

Mage-OS pins it, and I checked the metapackage rather than trusting a changelog: creatuity/magento2-interceptors at 1.3.8 is a require of mage-os/product-community-edition 3.4.0.

The number attached to it is about 10% off server response time, 5–15% depending on mode. That's the module authors' figure and the one the Mage-OS bundling proposal used, alongside a note that it's been in production since 2019 across more than 49,000 Composer installs. I haven't benchmarked it, and I couldn't find anyone who has published a benchmark on a real store, so treat 10% as a claim from people with a track record and not as a measurement.

The part I find genuinely interesting is that this was proposed to Magento and never merged, on architectural grounds. If you maintain a platform running on tens of thousands of stores with extension stacks you've never seen, declining to change how interception works is a perfectly good answer. Mage-OS serves a smaller and more engaged set of stores, looked at the same module, and shipped it on by default. Same code, different risk appetite. That's the argument for a community distribution in a single example, and it's more persuasive than anything on the governance page.

Living with it costs you two things. Any change to plugin configuration means clearing generated/code and var/cache, so your local workflow and your deploy scripts both need to know — a team that forgets will lose an hour to a plugin that "isn't running." And stack traces change, because plugins get called directly instead of through ___callPlugins. That second one I'd call a straight improvement; you can finally see what's actually executing.

Two documented edge cases deserve a look at your own code. Plugin names that differ only by case on the same class compile only one of the two. And there's an older report about disabling a plugin in one scope but not another, which the proposer couldn't reproduce on 2.4.7.

Would I turn it on? On a store with a staging environment somebody trusts, yes. On a store where deploys happen by hand and nobody's quite sure what the last one did, I'd leave it alone — not because the module is fragile, but because the cache-clearing rule punishes exactly that kind of team. It's a compiled_plugins cache type, so switching it off is a config change and removing it is one Composer command.

Lazy object loading

This one Mage-OS wrote themselves, and it's the work that changed how seriously I take the project.

Magento's DI factory builds dependencies eagerly. Mage-OS added PHP 8.4 lazy-ghost objects to the compiled factory through ReflectionClass::newLazyGhost(), so construction waits until something actually uses the object. A compile-time scan excludes everything PHP can't lazify — interfaces, abstracts, traits, final, enum and readonly classes, anything extending an internal class, proxies — and the whole path is gated on PHP 8.4, so older runtimes pay nothing at all.

Then they marked 74 core classes #[NonLazy], because making something lazy when it gets realized on every request is pure overhead. Those 74 weren't guesses. They came out of per-class realization-rate telemetry gathered across fourteen workloads — storefront URLs cold and warm, plus a couple of CLI commands — and the rates split cleanly, with most classes sitting at one end of the range or the other.

That's more rigor than I expected. Both changes landed in May 2026 and ship in 3.0, and if an extension assumes eager construction and falls over, there are opt-outs globally and per class.

bfcache, speculation rules and view transitions

mage-os/module-theme-optimization wires up three browser features that almost no Magento store uses: back/forward cache, speculative preloading through the Speculation Rules API, and view transitions. Settings sit under Stores > Configuration > Advanced > System with website and store-view scope, and all three default to on. Any theme, 2.4.5 or newer.

The default I actually care about is the exclusion list, which already covers customer, login, logout, auth, cart, checkout and search. Speculation rules pointed carelessly at a Magento store will happily prerender an add-to-cart URL. Somebody having thought about that before shipping is the difference between a feature and a support ticket.

The caveat comes from Mage-OS's own README: "bfcache availability varies based on your Full Page Cache engine and hosting. Some require additional setup," naming Varnish and Fastly. Varnish is what most serious Magento stores run, so assume the headline feature needs work on your stack before it does anything. Chrome DevTools has a Back/forward cache panel that tells you in about a minute, which is worth more than a year of assuming.

What I'd measure before repeating any of this

Every number above comes from the people who wrote the code. They did measure it, their claims are specific, and nobody independent has checked them.

Before I'd say "10%" to a client's finance director, I'd want response time before and after on the same hardware, with the full-page cache in the state production actually runs it — compiled interceptors change PHP execution, so a benchmark that hits Varnish is measuring Varnish. I'd test against the store's real extension stack instead of a clean install, since the gain scales with how many plugins there are and so does the chance of tripping over one. And I'd watch INP and LCP on category and product templates, not the homepage.

Half a day of work, and it fits inside a normal performance engagement.

One that hasn't shipped

There's an open pull request on the Mage-OS core fork that stores each non-global compiled DI area as its diff from global rather than a full copy. The numbers are hard to ignore: 44.6 MB of compiled DI metadata down to roughly 7 MB, with crontab.php turning out to be a byte-for-byte duplicate of global.php at 6.5 MB.

It's open and unmerged, so nobody has it today. I mention it because compiled DI size shows up in deploy times and disk on every environment you run, and that sort of thing never makes a feature list.

So is Mage-OS faster?

Probably, a little, mostly from compiled plugins. Nobody independent has measured it.

That's a weaker claim than the marketing makes and I'm comfortable with it. A distribution that ships a 10%-class optimization by default, does its own DI work against telemetry instead of intuition, and sets sane defaults on speculation rules is making better decisions for you than a stock install does. What it won't do is rescue a store that's slow for the usual reasons. If your TTFB is two seconds, none of this is your problem.

Emyrix does Magento and Mage-OS performance work, including the before-and-after measurement that tells you whether a change earned its place. We have no commercial relationship with the Mage-OS Association, Creatuity or any of the module authors named here. If you want your store measured properly, get in touch.

Module behavior, versions and claims are from the Mage-OS and Creatuity repositories and the Mage-OS bundling proposal; the metapackage requirement was read from the Mage-OS Composer repository on August 18, 2026. Performance figures quoted are the module authors' own and are not independently verified.