Why JIT Compilation Makes WooCommerce Slower (And What We Do Instead)

By Vedanshu Jain | Published March 26, 2026 | Updated May 5, 2026

Why JIT Compilation Makes WooCommerce Slower (And What We Do Instead)

PHP is the engine WooCommerce runs on. Most hosts install it, apply some popular performance tips from the WordPress community, and call it optimised. We found that several of those tips actively hurt ecommerce stores. So we started from scratch.


The JIT Trap

PHP 8 introduced JIT — Just-In-Time compilation — and the WordPress community got excited. JIT sounds like an obvious win: instead of interpreting code line by line, PHP compiles it into faster machine instructions at runtime. Benchmarks looked great. Hosts started enabling it everywhere.

For WooCommerce, it made things worse.

JIT delivers real gains for CPU-intensive workloads: heavy mathematical processing, image manipulation, long-running scripts. WooCommerce is not that. A typical WooCommerce request spends the vast majority of its time waiting. On database queries, on file reads, on network calls to payment gateways. The CPU is mostly idle. JIT adds compilation overhead to a workload that didn’t need compiling in the first place.

Enabling JIT on a WooCommerce store is like installing a turbocharger on a car that spends its life sitting in traffic. We leave JIT off. It’s the right call for ecommerce, even if it’s not the popular one.


OPcache: Powerful When Tuned, Damaging When Not

OPcache stores compiled PHP bytecode in memory so PHP doesn’t have to recompile your store’s thousands of files on every request. You absolutely want it. But only when configured correctly.

Set it too conservatively and PHP constantly revalidates files, burning CPU. Set it too aggressively and your store starts serving stale code after updates. Plugins update on disk, but OPcache keeps running the old version in memory. We’ve seen this cause maddening bugs that are nearly impossible to trace.

We sized OPcache for WooCommerce’s actual footprint and tuned revalidation to be aggressive enough for speed, conservative enough to never serve outdated code.


PHP’s Single-Threaded Architecture

PHP is fundamentally single-threaded. Each PHP process handles exactly one request at a time. Concurrency comes entirely from having the right number of worker processes running simultaneously.

Too few workers and requests queue up. Invisible to you, immediately felt by customers as slow page loads. Under a traffic spike, the queue backs up fast.

Too many workers and you exceed available RAM, spilling into catastrophically slow swap memory.

We calculated the optimal workers-per-core ratio for WooCommerce’s specific memory profile and built it to scale dynamically with load.


How Long Should a Worker Stay Alive?

PHP workers accumulate memory over time. WooCommerce plugins compound this. Let workers live too long and memory creep degrades performance gradually. Recycle them too aggressively and you waste the warm state they’ve built up: loaded code, warm caches, initialised connections.

We tuned worker lifetime specifically for WooCommerce workloads. It’s a narrow window that required understanding how WooCommerce actually behaves over thousands of real requests.


The Unfair Advantage We Have Over Every Other Host

We are core contributors to WooCommerce itself. We know which hooks are expensive and why. We know how WooCommerce’s database queries behave under load because we’ve read the code that generates them. We know what changes between versions mean for hosting performance, often before the release goes public.

Most hosts configure PHP for WooCommerce from the outside. We configure it from the inside, with the same knowledge the people who wrote WooCommerce have. That’s the difference between tuning a car with a manual and tuning it with the original engineering specs.


Series: How We Built the Fastest WooCommerce Hosting (And the Secret Sauce Behind It)

← Why No Self-Respecting Host Should Run WooCommerce on an Intel i9  |  The Network Architecture That Makes WooCommerce Load Before Customers Notice →

Back to Blog

Built by ex-WooCommerce core developers

We're ex-WooCommerce core developers and ex-Google/Meta engineers who've scaled systems handling millions of requests per minute. We built the parts of WooCommerce that matter in production: performance, payments, and reliability. That's why we can operate your store end-to-end, not just host it.

Product

Company

Case Studies

Privacy Policy | Terms of Service

© 2026 Urumi. All Rights Reserved