Performance Optimization with Docker & Magento2

Not for a current build. Adobe's supported matrix for Magento 2.4.9, generally available since 12 May 2026, lists OpenSearch 3 and no longer lists Elasticsearch, which the 2.4.8 line was the last to include. The same release replaces Redis with Valkey 9 in the supported stack and moves Varnish to 8. Performance advice written against Elasticsearch 7 still applies conceptually, since OpenSearch is a fork of it, but tune against the engine your Magento version actually supports.

Enough to fund the work. Google and Deloitte's Milliseconds Make Millions study found that a 0.1 second improvement in mobile site speed produced an 8.4 percent increase in retail conversions and a 9.2 percent increase in average order value. Portent's analysis of ecommerce sites found conversion rates falling around 4.42 percent for every additional second of load time. Those are averages across many sites rather than a guarantee for yours, but they establish that speed work is a revenue project, not a technical vanity project.

Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less, each measured at the 75th percentile of real visits. Note that these are field measurements from actual users, so a perfect score in a local Docker container proves nothing. Interaction to Next Paint replaced First Input Delay in March 2024 and is much harder to pass, because it measures every interaction rather than only the first one.

Use them for comparison, not as absolute figures. A container on a laptop has different CPU, different disk behaviour, no CDN, no real network latency and a tiny dataset, so the numbers will flatter you. What Docker is genuinely good for is A versus B testing: change one setting, rerun the same benchmark, and see the direction of travel. Absolute performance verdicts belong on staging infrastructure that resembles production, validated afterwards against field data from real visitors.

Full page caching in front of PHP. A cached category or product page served by Varnish never reaches Magento at all, which turns a request that costs hundreds of milliseconds into one that costs a few. Everything else, meaning OPcache, database tuning and search configuration, improves the requests that do reach PHP. Get caching right first, then measure what is left. Sites that skip this and tune PHP settings instead are optimising the slow path while ignoring the one that eliminates it.

OPcache above all, sized generously enough to hold Magento's very large codebase without evicting entries, with a realpath cache to match because Magento resolves an enormous number of file paths per request. Memory limit matters for CLI operations such as Composer and static content deployment rather than for page speed. Do not expect the JIT to help, since Magento requests are dominated by database, cache and I/O work rather than by the compute bound code JIT accelerates.

On 2.4.8 and earlier, Redis is supported and works well. On 2.4.9 Adobe's matrix lists Valkey 9, the community fork that continued from Redis's last open source release. It speaks the same protocol, so Magento's cache, session and page cache backends work against it without code changes and the switch is essentially an image change. Whichever you run, separate the cache and session databases, set a sensible eviction policy, and give the container enough memory that it is not evicting hot entries constantly.

The InnoDB buffer pool is the setting that matters, because it determines how much of a large schema lives in memory instead of on disk. After that, log file sizing, maximum allowed packet for big imports, and connection limits if you run many consumers. Do not copy a production configuration into a laptop container: a buffer pool sized for a dedicated database server will starve OpenSearch and PHP on the same machine and produce failures that look like a Magento problem.

Give it enough memory, since it reserves a Java heap on startup and will exit or thrash if the container is starved, and keep its data on a named volume rather than a bind mount. Beyond resources, the wins are in Magento: limit which attributes are searchable and filterable, because every one of them expands the index, and avoid running a full reindex on every save during development. A search engine that keeps dying is a resourcing problem, not a tuning problem.

Start from the sample configuration Magento ships, which already handles the URL rewriting and static file routing correctly, and resist rewriting it from scratch. The useful additions are compression, long cache lifetimes with immutable headers on versioned static assets, sensible client body limits for admin uploads, and HTTP/2 or HTTP/3. Most real front end gains after that come from the theme, meaning image formats and sizes, fewer render blocking requests and less JavaScript, not from the web server.

Check file sharing before blaming configuration. Magento reads thousands of small files per request, and on Windows and macOS every one of those reads crosses a virtualisation boundary when the source lives on a shared host folder. Moving a project into the WSL2 filesystem on Windows, or using VirtioFS or a synced volume mode on macOS, often produces a larger improvement than every PHP and MySQL setting combined. On native Linux this problem does not exist.

The configuration does, the results do not. Committing your tuned PHP, cache, database and web server settings to the repository means production runs exactly what you tested, which is the real value of containerising. What will not carry over is the absolute speed, because production has real traffic, a real catalogue, a CDN and network latency. Validate with field data from real users after deployment rather than assuming a fast local environment predicts a fast store.