Adobe Commerce Optimization

Adobe Commerce can run a large, complex catalog at real scale — the platform itself is rarely the bottleneck once you get past a few hundred thousand SKUs. What actually determines whether a Commerce deployment feels fast is whether it's treated as a cache-first system from day one, whether the database is tuned for EAV at scale rather than left on defaults, and whether the storefront's JavaScript footprint gets the same scrutiny as the backend. Most underperforming Adobe Commerce sites we inspect have a healthy database and an untuned cache layer, or a fast backend serving a bloated Luma frontend that never had a chance at Core Web Vitals.

Full-Page Cache Is Not Optional at Scale

Adobe's own documentation is explicit that Varnish (or a comparably capable edge cache) is required for production, not a nice-to-have. The numbers back this up: benchmarking on Magento 2.4.8 with a 10,000+ SKU catalog showed time-to-first-byte falling from 800-3,000ms uncached to 10-50ms with Varnish tuned correctly, with supported concurrency rising from roughly 50-200 users to 10,000+. A separate throughput comparison measured Varnish at 9,273 requests/second against 2,429 req/s for file-based caching, with sub-millisecond cache hit times.

Getting there requires more than installing Varnish:

• Target a 95%+ full-page-cache hit rate on catalog and CMS pages, using tag-based invalidation rather than aggressive TTL expiry.
• Keep default TTLs reasonably long (Adobe's default is 86,400 seconds) and rely on cache tags to invalidate precisely, not blanket flushes.
• Use hole-punching for genuinely dynamic blocks (cart count, personalized recommendations) instead of excluding entire pages from cache.

Database and Indexing at Large Catalog Scale

Past roughly 50,000-100,000 SKUs, the EAV model's join overhead and the indexer pipeline become the dominant cost, not raw page rendering. The two highest-leverage moves:

• Move faceted search and layered navigation off MySQL onto OpenSearch or Elasticsearch. This is consistently identified as the single biggest win for large catalogs — MySQL-driven faceting on tens of thousands of SKUs generates expensive aggregation joins that a dedicated search engine handles natively.
• Tune MySQL for the buffer pool, not just add hardware. Setting innodb_buffer_pool_size to roughly 70-80% of available RAM on a dedicated database node, monitoring the buffer pool hit ratio (targeting above 99%), and enabling the slow query log to catch unindexed queries against quote, order, and catalog index tables are standard first moves before considering read replicas.

Watch the price and catalog-rule index tables specifically — catalog_product_index_price and catalogrule_product scale with products × customer groups × websites, and can reach tens of millions of rows in a mid-size B2B deployment with multiple price books. Reducing indexer batch size (for example from the default 5,000 rows down to 1,000) has been shown to cut full reindex time roughly in half on constrained MySQL configurations, at the cost of more frequent, smaller index runs.

Checkout Is the Bottleneck That Matters Most

Adobe's own Commerce checkout performance guidance sets explicit targets: sub-2-second page load, sub-500ms shipping-rate calculation, sub-1-second place-order API response. In practice, the checkout path breaks down for a few recurring reasons:

• Synchronous external calls to shipping carriers and payment processors on every step, where a slow third-party response becomes your latency.
• Session storage under-provisioned — file-based or thinly-resourced Redis session storage causes I/O contention under concurrent checkout load.
• Database locking on high-volume order placement — concurrent writes to sales_order, sales_order_item, and inventory reservation tables can push place-order latency into the tens of seconds during traffic spikes if left synchronous.

The fix pattern that holds up under B2B order volume: decouple checkout from downstream work. Show the confirmation page immediately, then push ERP synchronization, invoicing, and notification emails onto a queue (RabbitMQ is Adobe's own default) instead of blocking the customer-facing request on them.

Cloud vs. On-Premise, and the Honest Core Web Vitals Gap

Adobe Commerce Cloud Service and Commerce Cloud Pro bring managed horizontal auto-scaling and New Relic-based observability out of the box — APM tracing on checkout and add-to-cart transactions, infrastructure monitoring, and CDN integration without building the SRE stack yourself. On-premise remains defensible when you need non-standard database topology or strict data residency, but then your team owns replicating that scaling and monitoring discipline manually.

The gap that surprises most stakeholders is Core Web Vitals on mobile. A 2026 audit of 30+ live stores on stock Luma themes found average mobile LCP in the 4.2-5.8 second range against a 2.5-second target, and mobile INP averaging 310-520ms against a 200ms threshold — meaning most untouched Luma storefronts fail mobile Core Web Vitals regardless of how well the backend is tuned. Backend caching and indexing work reliably shaves 400-600ms off load time, but it does not by itself flip a failing score to a passing one. Closing that gap requires addressing the frontend directly — migrating to Hyvä (a lightweight Alpine.js/Tailwind theme built specifically to replace Luma's JavaScript-heavy defaults) or investing seriously in PWA Studio, where warm-navigation performance can be excellent but cold-start bundle size still needs active management.

We treat Adobe Commerce performance as three separate disciplines that all have to be addressed — cache-first infrastructure, EAV-aware database tuning, and a frontend that isn't fighting the platform's own JavaScript weight — because tuning only one of the three consistently leaves real revenue on the table.