We Made the Fastest Magento on the Planet - and the Platform Wasn't the Problem

Qoliber Engineering · 11 May 2026

For years, the loudest critique of Magento has been the same: it's slow. Sluggish admin. Heavy frontend. Cache-dependent in a way that makes operators nervous to ever run cache:flush in production.

We've heard it from agencies, partners, hosting providers, even from Adobe engineers in the corridors of Imagine. The narrative has hardened into a kind of received wisdom: Magento is slow because Magento is slow. Look elsewhere if you want speed.

We disagreed. And tonight we're shipping two modules that we believe end the conversation.

The status quo, briefly

The standard performance recipe for Magento is well-known: enable Full Page Cache, put Varnish in front, scale horizontally, tune MySQL, hope for the best. The recipe works. It also dodges the question.

Because the question isn't "how do we cache around Magento's hot path?" — it's "why is Magento's hot path slow in the first place?"

Most of the "platform is slow" answers boil down to the same handful of mechanisms:

• The Object Manager resolves every constructor argument through metadata array lookups at runtime — millions of them per request.
• The Layout system merges hundreds of XML files on every cache miss, then walks them through a reader pool, then dispatches generators.
• Catalog data is reassembled from EAV joins on every product page render, even when the underlying data hasn't changed since deploy.

These are real, measurable costs. None of them are fundamental to the platform. They're all the result of how Magento was built around generality and how the community settled into accepting that generality as fate.

We chose not to.

What changed today

Today we're shipping two new modules alongside our existing STOP Protocol (Speed Suite v2.3):

Object Manager Compiler 1.0 — the dispatch table, materialized

A standalone Composer package — qoliber/object-manager-compiler. Inspired by Symfony's DI container, where every constructor call is dispatched through pre-generated PHP classes the JIT can devirtualize.

We tried replacing Magento's container with Symfony's. We couldn't — too much of the runtime depends on the container's specific shape. So we replicated the bit that mattered: at deploy time, we walk every type Magento knows about and emit a bucket of static factory methods per area. At request time, those methods dispatch directly. No metadata lookup. No marker arrays. Just new.

Result: faster Object Manager object creation. Standalone, drop-in, no Magento file touched.

Catalog Assembler 1.0 — the database query that wasn't

A pipeline-design-pattern module that pre-compiles product data into a single Magento DataObject. Stored as a JSON file, in Redis, or as an OPcache-compiled PHP file. Loaded data flows into templates with as little customization as possible.

After warmup, the only DB queries left on a product page are for price and stock. Everything else — names, descriptions, images, attributes, related products, reviews — is materialized at compile time.

This is not for everyone. We know. But for stores that don't change their catalog every five minutes, the speedup is hard to argue with.

The numbers

On the same Mage-OS install. Default Luma theme. Default Hyvä theme. No exotic infrastructure. No CDN tricks. No "but we have 16 application servers."

That's the fastest Magento on the planet. Not the fastest under a Varnish hit. Not the fastest with a CDN doing the work. The fastest Magento. With cache:clean. With cache:flush. With FPM cold.

Why this took so long

It didn't take long because the problem was hard. It took long because nobody was looking.

The Object Manager Compiler started life as a question in November last year: "Why is the OM doing array lookups when the lookup table is static at deploy time?" The Layout Compiler in its current form took two architecture rewrites — first as a "supplement-after-generate" plugin (which we shipped in 2.1), then in 2.3 as a cache-replay plugin that replaces Magento's cold path entirely. The Catalog Assembler started as a benchmark and ended as a module because the benchmark numbers didn't make sense to leave on the table.

None of this required forking Magento. None of this required RFCs to Adobe. None of this required convincing a committee. Every line of code lives in user-space — Composer packages, Magento modules — and is drop-in installable on every Magento 2.4+ and Mage-OS install we've tested.

We just had to be willing to look at the hot path and ask, every time, "does this work need to happen here, or could it happen at deploy?"

That's the entire trick.

The platform was never the problem

Magento is a remarkable codebase. The Object Manager, EAV, the Layout system, the plugin architecture — these aren't bugs. They're general-purpose mechanisms that let tens of thousands of agencies build wildly different stores on top of one engine. That generality has a runtime cost.

You can either pay that cost on every request, or you can pay it once at deploy and never again. Most of the work we've shipped over the last two years is just teaching Magento — at deploy time, in deterministic, idempotent steps — to do the work it would otherwise do per-request.

The platform was never broken. The community just stopped pushing it.

We're proud of what tonight ships. We're prouder of having proved the point.

What's next

We're closing in on the last meaningful cold-cache cost: a Magento-internal cache interception bug that affects how state is rehydrated after cache:flush. Once that's captured, one more module ships and that completes Speed Suite v3.0 — planned for July or August this year.

With Object Manager Compiler now released, we believe the codebase is more than complete. Everything from here is polish.

If you're a partner running Magento at scale and you've ever quietly suspected that the platform should be faster than it is — you were right. Drop us a note. We'd love to hear what your install looks like.

The Qoliber Engineering Team qoliber.com · [email protected]

Modules available 11 May 2026 from 9:00 AM Warsaw time. Adobe Commerce, Magento, and related marks are trademarks of Adobe Inc.