DEV Community: Magevanta

Magento 2 Async Operations and Message Queues: A Performance Deep Dive

Magevanta — Fri, 08 May 2026 07:42:57 +0000

Every Magento 2 store has operations that are too slow to run synchronously during a web request. Sending transactional emails. Updating inventory across thousands of products. Re-indexing after bulk catalog changes. Running price calculations for complex customer segments.

The naive approach — doing it all in-process during the HTTP request — results in timeouts, frustrated customers, and overwhelmed PHP workers. Magento 2's message queue framework is the proper solution, and when configured correctly, it can dramatically improve perceived performance while making your architecture more resilient.

This guide covers everything you need to know about Magento 2's async operations and message queue system: the architecture, RabbitMQ setup, consumer tuning, and practical patterns for pushing your own heavy workloads off the critical path.

What Is the Message Queue Framework?

Magento 2's message queue framework (introduced in 2.0 for B2B, available in all editions since 2.2) is a pub/sub system that decouples producers (code that initiates work) from consumers (code that processes it).

Instead of:

Request → Process → Wait → Response

You get:

Request → Publish message → Return immediately
          (Consumer picks up message and processes asynchronously)

The framework supports two backends:

MySQL — Simple, no extra infrastructure, works out of the box. Limited throughput.
RabbitMQ — Enterprise-grade, high-throughput, supports complex routing. Recommended for production.

What Magento Already Uses Message Queues For

Before building custom async logic, it's worth knowing what Magento already processes asynchronously:

Topic	What It Does
`async.operations.all`	Bulk REST API operations (product updates, etc.)
`inventory.reservations.updateSalabilityStatus`	MSI stock updates
`sales.rule.quote.trigger.recollect`	Cart price rule recalculations
`product_action_attribute.update`	Bulk attribute updates from Admin grid
`async.magento.cataloginventory.api.stockregistryinterface.updatestockitembysku.post`	Async stock updates via API

If you're using bulk operations in Admin or the Async REST API, these queues are already doing work for you.

Architecture Overview

The message queue system has four key components:

Publisher — Sends a message to a topic
Topic — Named channel (e.g., mycompany.product.sync)
Queue — Storage for pending messages (MySQL table or RabbitMQ queue)
Consumer — Long-running process that polls the queue and processes messages

Configuration is split across three XML files in your module:

etc/
├── queue_topology.xml   # Defines exchanges and bindings
├── queue_publisher.xml  # Connects topics to exchanges
├── queue_consumer.xml   # Defines consumer handlers
└── communication.xml    # Defines topic schemas

Setting Up RabbitMQ

For anything beyond development, use RabbitMQ. MySQL queues work but have limitations under load — they use polling, table locks, and don't support priority queues or dead letter exchanges.

Installation

# Ubuntu/Debian
apt install rabbitmq-server
systemctl enable rabbitmq-server
systemctl start rabbitmq-server

# Enable management UI
rabbitmq-plugins enable rabbitmq_management
# Access at http://localhost:15672 (guest/guest)

Magento Configuration

// app/etc/env.php
'queue' => [
    'amqp' => [
        'host' => 'localhost',
        'port' => '5672',
        'user' => 'magento',
        'password' => 'your-password',
        'virtualhost' => '/',
        'ssl' => false,
    ]
]

Create a dedicated RabbitMQ user:

rabbitmqctl add_user magento your-password
rabbitmqctl set_permissions -p / magento ".*" ".*" ".*"
rabbitmqctl set_user_tags magento monitoring

Verify the Connection

bin/magento queue:consumers:list

If this returns a list of consumers without errors, the AMQP connection is working.

Building a Custom Async Operation

Let's walk through a real example: a custom product sync to an external ERP system that currently runs synchronously during the admin product save.

Step 1: Define the Topic Schema

<!-- etc/communication.xml -->
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Communication/etc/communication.xsd">
    <topic name="mycompany.erp.product.sync" request="MyCompany\ErpSync\Api\Data\SyncRequestInterface"/>
</config>

Step 2: Configure the Publisher

<!-- etc/queue_publisher.xml -->
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework-message-queue:etc/publisher.xsd">
    <publisher topic="mycompany.erp.product.sync">
        <connection name="amqp" exchange="magento" disabled="false"/>
        <!-- Fallback to MySQL if RabbitMQ unavailable -->
        <connection name="db" exchange="magento-db" disabled="true"/>
    </publisher>
</config>

Step 3: Configure Topology (RabbitMQ)

<!-- etc/queue_topology.xml -->
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework-message-queue:etc/topology.xsd">
    <exchange name="magento" type="topic" connection="amqp">
        <binding id="erpSyncBinding"
                 topic="mycompany.erp.product.sync"
                 destinationType="queue"
                 destination="mycompany.erp.product.sync"/>
    </exchange>
</config>

Step 4: Define the Consumer

<!-- etc/queue_consumer.xml -->
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework-message-queue:etc/consumer.xsd">
    <consumer name="myCompanyErpProductSync"
              queue="mycompany.erp.product.sync"
              connection="amqp"
              consumerInstance="Magento\Framework\MessageQueue\Consumer"
              handler="MyCompany\ErpSync\Model\ProductSyncHandler::processMessage"
              maxMessages="1000"/>
</config>

Step 5: Implement the Handler

// Model/ProductSyncHandler.php
namespace MyCompany\ErpSync\Model;

use MyCompany\ErpSync\Api\Data\SyncRequestInterface;
use Psr\Log\LoggerInterface;

class ProductSyncHandler
{
    public function __construct(
        private readonly ErpApiClient $erpClient,
        private readonly LoggerInterface $logger
    ) {}

    public function processMessage(SyncRequestInterface $request): void
    {
        try {
            $this->erpClient->syncProduct(
                $request->getSku(),
                $request->getProductData()
            );
        } catch (\Exception $e) {
            // Log but don't re-throw — Magento will handle dead letters
            $this->logger->error('ERP sync failed: ' . $e->getMessage(), [
                'sku' => $request->getSku(),
            ]);
        }
    }
}

Step 6: Publish from Your Event Observer

// Observer/ProductSaveAfter.php
namespace MyCompany\ErpSync\Observer;

use Magento\Framework\MessageQueue\PublisherInterface;
use MyCompany\ErpSync\Api\Data\SyncRequestInterfaceFactory;

class ProductSaveAfter implements \Magento\Framework\Event\ObserverInterface
{
    public function __construct(
        private readonly PublisherInterface $publisher,
        private readonly SyncRequestInterfaceFactory $requestFactory
    ) {}

    public function execute(\Magento\Framework\Event\Observer $observer): void
    {
        $product = $observer->getEvent()->getProduct();

        $request = $this->requestFactory->create();
        $request->setSku($product->getSku());
        $request->setProductData($this->extractProductData($product));

        // Non-blocking: returns immediately, consumer picks up async
        $this->publisher->publish('mycompany.erp.product.sync', $request);
    }
}

The admin product save now returns instantly. The ERP sync happens in the background.

Running Consumers in Production

Consumer processes are long-running PHP daemons. They need to be managed like a service.

Supervisor Configuration

; /etc/supervisor/conf.d/magento-consumers.conf
[program:magento-erp-sync]
command=/usr/bin/php /var/www/html/bin/magento queue:consumers:start myCompanyErpProductSync --max-messages=10000
directory=/var/www/html
user=www-data
autostart=true
autorestart=true
startretries=10
stderr_logfile=/var/log/supervisor/magento-erp-sync.err.log
stdout_logfile=/var/log/supervisor/magento-erp-sync.out.log
stopasgroup=true
killasgroup=true

[program:magento-inventory-reservations]
command=/usr/bin/php /var/www/html/bin/magento queue:consumers:start inventoryQtyCounter --max-messages=10000
directory=/var/www/html
user=www-data
autostart=true
autorestart=true

Reload Supervisor after changes:

supervisorctl reread
supervisorctl update
supervisorctl status

Key Consumer Options

bin/magento queue:consumers:start <consumer-name> \
  --max-messages=10000 \   # Restart after N messages (prevents memory leaks)
  --batch-size=100 \       # Process N messages per iteration
  --single-thread \        # Run as single-threaded (default)
  --pid-file-path=/tmp/consumer.pid

The --max-messages flag is critical. Long-running PHP processes accumulate memory leaks from Magento's object manager. Setting a reasonable limit (1000-50000 depending on message size) and letting Supervisor restart the process is safer than running indefinitely.

Scaling Consumers

For high-throughput scenarios, run multiple consumer instances in parallel:

; Multiple parallel consumers for high-volume queue
[program:magento-erp-sync]
command=/usr/bin/php /var/www/html/bin/magento queue:consumers:start myCompanyErpProductSync --max-messages=5000
numprocs=4               ; Run 4 parallel consumers
process_name=%(program_name)s-%(process_num)02d

With RabbitMQ, multiple consumers on the same queue use round-robin distribution automatically. With MySQL queues, Magento handles locking to prevent double-processing, but MySQL queues don't scale as gracefully.

The Async Bulk Operations API

For mass operations (importing thousands of products, bulk price updates, etc.), Magento's Async Bulk REST API is built on top of the message queue framework:

# Async bulk product update
curl -X POST https://yourstore.com/rest/async/bulk/V1/products \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '[
    {"product": {"sku": "SKU001", "price": 29.99}},
    {"product": {"sku": "SKU002", "price": 39.99}},
    ...
  ]'

The response returns immediately with a bulk operation UUID:

{
  "bulk_uuid": "a1b2c3d4-...",
  "request_items": [...]
}

Check status asynchronously:

curl https://yourstore.com/rest/V1/bulk/a1b2c3d4-.../status \
  -H "Authorization: Bearer YOUR_TOKEN"

This approach is dramatically faster for bulk imports than the synchronous REST API because:

The HTTP request returns in milliseconds
Operations are batched and processed by consumers
Multiple consumers can parallelize the work
Failed operations are tracked and retriable without re-running everything

Monitoring Queue Health

RabbitMQ Management Console

The RabbitMQ management UI (http://your-server:15672) gives you:

Queue depths (are messages piling up?)
Consumer counts (are consumers running?)
Message rates (throughput per second)
Dead letter queue contents (failed messages)

CLI Monitoring

# List all queues and their message counts
rabbitmqctl list_queues name messages consumers

# Check if consumers are running
bin/magento queue:consumers:list

# Magento's bulk operation status
bin/magento queue:consumers:start --help

Alert on Queue Depth

Set up monitoring to alert when queue depth exceeds thresholds:

# Simple bash check (add to cron or monitoring system)
DEPTH=$(rabbitmqctl list_queues name messages | grep "mycompany.erp.product.sync" | awk '{print $2}')
if [ "$DEPTH" -gt 1000 ]; then
  echo "WARNING: ERP sync queue depth is $DEPTH" | mail -s "Queue Alert" ops@yourcompany.com
fi

Common Pitfalls and How to Avoid Them

Pitfall 1: Not Handling Failures

If your consumer throws an unhandled exception, the message may be lost (MySQL) or moved to a dead letter queue (RabbitMQ). Always catch exceptions in your handler and implement retry logic or alerting for persistent failures.

Pitfall 2: Running Consumers via Cron Only

Magento's default setup uses cron to start consumers. This adds up to a 1-minute delay before a consumer starts processing new messages. For latency-sensitive operations, run consumers as persistent daemons via Supervisor instead.

Pitfall 3: Large Message Payloads

Message queues are optimized for small messages. Avoid putting large data blobs (full product objects, images) in messages. Instead, pass identifiers:

// Bad: serialize the entire product
$this->publisher->publish('topic', $product->getData()); // Could be 50KB+

// Good: pass just the ID
$this->publisher->publish('topic', ['product_id' => $product->getId()]); // Bytes
// Consumer loads the product from DB when processing

Pitfall 4: Ignoring Memory Limits

Long-running consumers will eventually exhaust PHP memory without --max-messages. The Supervisor restart approach is the standard pattern — don't fight it.

Quick Reference: When to Use Message Queues

Scenario	Async?	Why
Sending transactional emails	✅ Yes	No customer-facing impact from delay
Syncing to external ERP/PIM	✅ Yes	External API latency shouldn't block save
Bulk product/price updates	✅ Yes	Can take minutes; use Async Bulk API
Re-indexing after bulk import	✅ Yes	Resource-intensive, not time-critical
Updating cart totals	❌ No	Customer expects immediate feedback
Inventory check at checkout	❌ No	Must be synchronous for accuracy
Generating invoices	⚠️ Depends	Async OK if email delivery is the only output

Conclusion

Magento 2's message queue framework is one of the platform's most underutilized performance tools. Most stores that struggle with slow admin saves, timeout-prone bulk operations, or overloaded PHP workers could benefit significantly from pushing work off the critical path.

The investment is real — you need RabbitMQ in production, Supervisor to manage consumers, and careful attention to message schema design. But the payoff is equally real: admin product saves that return in milliseconds, bulk imports that don't time out, and an architecture that handles traffic spikes gracefully because expensive work is queued rather than executed inline.

Start with Magento's built-in async operations (the Async Bulk REST API is available today with no custom code), then identify the top 2-3 synchronous operations in your codebase that are causing the most pain, and implement them as async consumers. Your customers — and your PHP workers — will thank you.

Magento 2 Layout XML Performance: Trim Blocks, Speed Up Rendering

Magevanta — Fri, 08 May 2026 07:42:49 +0000

Magento 2's layout XML system is the backbone of every page render. It controls which blocks get instantiated, which templates get rendered, and how the page tree is assembled before PHP hands off output to the browser. It's also one of the most overlooked performance vectors in the platform.

Unlike database queries or JavaScript bundles, layout XML overhead is invisible in standard monitoring. You won't see it in a slow query log. It won't show up as a large network request. It hides inside TTFB — Time to First Byte — silently burning CPU cycles while your server assembles the block tree.

This guide dives deep into Magento 2 layout XML performance: how to audit what's being rendered, how to remove what isn't needed, and how to use caching and lazy rendering to get the most out of the system.

How Magento 2 Layout XML Works

Before optimizing, understand the rendering pipeline:

Layout handle collection — Magento collects all applicable layout handles for the current page (e.g., default, cms_index_index, catalog_category_view_type_layered).
XML merging — All XML files matching those handles are merged into a single layout tree.
Block instantiation — Every <block> element in the tree is instantiated as a PHP object.
Template rendering — Each block renders its .phtml template, recursively rendering child blocks.
Output assembly — The rendered HTML is assembled and sent to the client (or written to FPC).

The problem: Magento instantiates all blocks in the tree, even ones whose output is never used on the current page. Third-party extensions are notorious for adding blocks to default.xml that run expensive logic on every single page.

Auditing Your Layout Tree

Enable Layout Debug Output

The fastest way to see what's being rendered is to enable Magento's built-in template hints:

bin/magento dev:template-hints:enable --type frontend
bin/magento cache:flush

Navigate to your store with ?templatehints=magento appended to the URL (you may need to set a hint secret in config). Every block will be outlined with its class name and template path.

Use the Profiler

Enable Magento's built-in profiler for deeper insight:

bin/magento dev:profiler:enable html

Visit a page and look at the profiler output at the bottom. Sort by sum to find the slowest blocks. Look for anything over 50ms that you don't recognize.

Disable the profiler when done:

bin/magento dev:profiler:disable

Programmatic Block Tree Inspection

For a non-visual audit, you can dump the full layout structure from the CLI:

# See all layout handles for a given page type
bin/magento dev:layout:deps --theme Magento/luma

Or write a quick script to dump the merged layout XML for a specific handle:

$layout = $objectManager->get(\Magento\Framework\View\LayoutInterface::class);
$layout->getUpdate()->load(['default', 'catalog_product_view']);
echo $layout->getUpdate()->asString();

The Top Performance Offenders

1. Blocks in `default.xml` with Heavy Constructors

Extensions often add blocks to default.xml because it's the safest choice for the developer — the block will always be there. But this means the block is instantiated on every single page, including your homepage, product pages, and checkout.

Look for patterns like this in vendor/ or app/code/:

<!-- vendor/somevendor/somemodule/view/frontend/layout/default.xml -->
<referenceContainer name="after.body.start">
    <block class="SomeVendor\SomeModule\Block\Tracker" name="somevendor.tracker" template="tracker.phtml"/>
</referenceContainer>

If the block constructor makes a database call, hits an external API, or loads configuration, it runs on every page.

Fix: Use a \Magento\Framework\View\Element\Template subclass and defer logic to _toHtml() or getCacheLifetime(), or move the block to a specific layout handle if it's only needed on certain pages.

2. Excessive Layout Handles

Every additional layout handle merges more XML, which means more parsing and more blocks. Some stores accumulate dozens of custom layout handles from extensions that each add their own block modifications.

Check how many handles are loaded on a typical page:

$handles = $layout->getUpdate()->getHandles();
var_dump(count($handles)); // Ideally < 20 on a typical page

If you're seeing 40+ handles, investigate which extensions are adding them and whether they're all necessary.

3. Widget Instances

Magento widgets are powerful but expensive. Each widget instance triggers a database query to load its configuration and an additional layout merge. Stores with dozens of active widgets accumulate significant per-request overhead.

-- Check your widget count
SELECT COUNT(*), instance_type FROM widget_instance GROUP BY instance_type ORDER BY COUNT(*) DESC;

If you have 50+ widget instances, consider replacing frequently-used ones with hardcoded blocks or static HTML. Widgets that appear on every page (via all pages page group setting) are especially expensive.

4. Unnecessary `<remove>` Calls

Many themes and extensions use <remove name="block.name"/> to hide blocks. This is wasteful — the block is still instantiated before being removed. The correct approach is:

<!-- Wrong: instantiates block then removes it -->
<remove name="breadcrumbs"/>

<!-- Better: prevent rendering via remove attribute -->
<referenceBlock name="breadcrumbs" remove="true"/>

The remove="true" attribute on <referenceBlock> prevents rendering without instantiating unnecessarily. The cleanest approach is to override the parent layout and simply not include the block in the first place.

5. `_prepareLayout()` Anti-Patterns

Blocks that execute expensive logic in _prepareLayout() run during layout building, before any output is generated. This is particularly bad because _prepareLayout() runs even if the block's output is cached.

// Bad: runs on every page even if block output is cached
protected function _prepareLayout()
{
    $this->productCollection = $this->collectionFactory->create()
        ->addAttributeToSelect('*')
        ->setPageSize(10)
        ->load(); // Full collection load in _prepareLayout!
    return parent::_prepareLayout();
}

// Better: lazy load in getter
public function getProducts()
{
    if ($this->productCollection === null) {
        $this->productCollection = $this->collectionFactory->create()
            ->addAttributeToSelect(['name', 'price', 'url_key'])
            ->setPageSize(10)
            ->load();
    }
    return $this->productCollection;
}

Block Caching: Your Most Powerful Tool

Magento's block cache is often the highest-leverage optimization available. If a block's output doesn't change between requests (or changes only per customer group, store, etc.), cache it.

Adding Cache to a Block

class MyBlock extends \Magento\Framework\View\Element\Template
{
    public function getCacheLifetime()
    {
        return 3600; // 1 hour
    }

    public function getCacheKeyInfo()
    {
        return [
            'MY_BLOCK',
            $this->_storeManager->getStore()->getId(),
            $this->_design->getDesignTheme()->getId(),
            $this->httpContext->getValue(\Magento\Customer\Model\Context::CONTEXT_GROUP),
        ];
    }
}

The getCacheKeyInfo() method determines cache uniqueness. Include everything that affects the block's output — store ID, theme, customer group — but nothing more.

Varnish + ESI for Partial Caching

For blocks that need to be personalized per customer but are otherwise static, consider Edge Side Includes (ESI) with Varnish. The main page is fully cached; the personalized block is fetched separately via a fast ESI request:

<!-- In your block's template -->
<esi:include src="<?= $block->getEsiUrl() ?>" />

This is especially effective for the minicart, customer welcome message, and recently viewed products — blocks that prevent FPC from caching an otherwise static page.

Reducing Block Count in Critical Pages

On high-traffic pages (homepage, category pages, product pages), aggressively audit the block tree and remove anything unnecessary.

Remove Default Magento Blocks You Don't Use

Magento's default layout includes many blocks that most stores don't need:

<!-- In your theme's default.xml -->
<page>
    <body>
        <!-- Remove if you don't use compare functionality -->
        <referenceBlock name="catalog.compare.sidebar" remove="true"/>

        <!-- Remove if you use a custom cookie notice -->
        <referenceBlock name="cookie-status-message" remove="true"/>

        <!-- Remove newsletter block if handled differently -->
        <referenceBlock name="form.subscribe" remove="true"/>
    </body>
</page>

Defer Below-the-Fold Blocks

Blocks that appear below the fold (product tabs, related products, upsells) don't need to render synchronously. Consider using lazy-loading via JavaScript:

<!-- Replace block with a container that JS will populate -->
<referenceBlock name="product.info.upsell" remove="true"/>
<!-- Add a lightweight placeholder instead -->
<referenceContainer name="product.info.main">
    <block class="Magento\Framework\View\Element\Template" name="upsell.lazy.placeholder"
           template="Your_Module::upsell-lazy.phtml" after="-"/>
</referenceContainer>

Then load the actual upsell content via AJAX after the main page has rendered. This moves the expensive collection load off the critical path entirely.

Layout XML Merge Caching

Magento caches the merged layout XML in the cache backend. If this cache is being invalidated too frequently, you'll pay the merge cost repeatedly.

# Check layout cache keys (Redis backend)
redis-cli -n 0 keys "LAYOUT_*" | wc -l

Causes of frequent layout cache invalidation:

Deploying static content without flushing properly
Extensions that call $layout->getUpdate()->addUpdate() with dynamic content
Incorrect cache_tag configuration in blocks

Ensure your deployment process flushes layout cache cleanly:

bin/magento cache:flush layout block_html full_page

Practical Checklist

Work through this list systematically on any store showing slow TTFB:

[ ] Profile with Magento Profiler — identify blocks taking >20ms
[ ] Audit default.xml across all modules for blocks with heavy constructors
[ ] Count layout handles on key page types — target under 20
[ ] Review all blocks missing getCacheLifetime() — add caching where possible
[ ] Check widget count — replace high-frequency widgets with static blocks
[ ] Audit _prepareLayout() in custom and extension blocks — move logic to lazy getters
[ ] Remove unused default Magento blocks from your theme
[ ] Verify layout cache is warming after deploys

Measuring the Impact

Use these commands before and after optimization to quantify improvements:

# TTFB measurement via curl (bypasses FPC with cache-busting header)
curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" \
  -H "Cache-Control: no-cache" https://yourstore.com/your-category

# Run 5 times and average
for i in {1..5}; do
  curl -s -o /dev/null -w "%{time_starttransfer}\n" https://yourstore.com/your-category
done | awk '{sum+=$1} END {print "Average TTFB:", sum/NR, "seconds"}'

For a well-optimized Magento 2 store on capable hardware, layout instantiation time should be under 50ms on category pages and under 30ms on CMS pages. If you're seeing 200ms+, there's almost certainly a block with an expensive constructor loading on the default handle.

Conclusion

Layout XML performance is invisible until it isn't. Stores that have accumulated years of extensions — each adding a few blocks to default.xml — can find themselves spending 500ms+ just instantiating blocks before a single line of HTML is rendered.

The good news is that layout optimizations are highly leveraged: fixing one slow block in default.xml improves every single page on your store. Start with the profiler, identify your top offenders, and work through the checklist above. Combined with proper block caching and FPC, a well-tuned layout XML configuration can shave hundreds of milliseconds off your TTFB without touching a single line of business logic.

Magento 2 Checkout Performance Optimization: Reduce Drop-offs and Speed Up Conversions

Magevanta — Thu, 07 May 2026 09:03:52 +0000

Checkout is the most critical page in any Magento 2 store. A one-second delay at this stage can cost you significantly more than the same delay on a product page — studies consistently show that conversion rates drop 7% for every second of checkout load time. Yet the Magento 2 checkout is notoriously heavy: it loads dozens of JavaScript components, makes multiple AJAX calls, and queries several database tables on every step.

This guide walks through the most impactful optimizations you can make to speed up your checkout — from quick wins to deep infrastructure changes.

Why Is Magento 2 Checkout So Slow?

Before optimizing, it helps to understand the bottlenecks:

KnockoutJS + RequireJS overhead — The checkout is built on KnockoutJS with dozens of UI components, each requiring its own module load via RequireJS.
Multiple AJAX requests on page load — Shipping methods, totals, customer data, and cart summaries are all fetched asynchronously.
Full Page Cache exclusion — The checkout is not cacheable by FPC, so every request hits the application stack directly.
Third-party payment/shipping extensions — These often add their own JS, CSS, and AJAX calls, compounding the overhead.
Quote recalculation — Every time a customer changes address, coupon, or shipping method, Magento recalculates the entire quote.

1. Enable and Tune Full Page Cache (Even for Checkout)

While the checkout page itself cannot be fully cached, there are adjacent pages that can dramatically affect perceived checkout speed:

The cart page should load instantly. Ensure it is FPC-cached.
The minicart data can be warmed and stored in browser localStorage to prevent repeated AJAX calls.
Use Varnish + ESI (Edge Side Includes) to cache static parts of checkout-adjacent pages.

More importantly, ensure FPC is enabled and warm for the rest of your store, because a fast product → cart → checkout funnel depends on each step being optimized.

# Verify FPC is enabled
bin/magento cache:status | grep full_page

# Flush and warm FPC
bin/magento cache:flush full_page
bin/magento cache:warm:fpc

2. JavaScript Optimization for Checkout

The checkout page is JavaScript-heavy by nature. The goal is to reduce parse time and eliminate blocking resources.

Merge and Bundle JS

Enable JS merging in Admin > Stores > Configuration > Advanced > Developer > JavaScript Settings:

Merge JavaScript Files: Yes
Enable JavaScript Bundling: Yes
Minify JavaScript Files: Yes

For production, use the built-in bundling or switch to a more advanced bundler:

bin/magento setup:static-content:deploy -f --jobs 4

Use Advanced JS Bundling

Magento's default bundling is often suboptimal. Consider using the Magento Advanced Bundling approach with Grunt, which creates page-type-specific bundles so the checkout only loads what it needs.

Alternatively, community tools like Mirasvit JS Bundle or Yireo JS Bundler provide more sophisticated dependency graph analysis and can reduce initial checkout JS payload by 40–60%.

Defer Non-Critical Scripts

Move non-critical third-party scripts (analytics, chat widgets, social pixels) to load after the checkout has initialized:

<!-- layout/checkout_index_index.xml -->
<page>
    <body>
        <block name="your.analytics" template="..." after="-">
            <!-- Load after checkout init -->
        </block>
    </body>
</page>

3. Reduce AJAX Calls During Checkout

Every AJAX call in checkout adds latency. Here's how to minimize them:

Customer Data Sections

Magento's "sections" system (customer data, cart, etc.) makes AJAX calls to /customer/section/load/ on various triggers. Audit which sections are being reloaded unnecessarily:

# Check which sections are defined
grep -r "sections" vendor/magento/module-customer/etc/frontend/sections.xml

Remove or merge section dependencies from custom modules that trigger unnecessary invalidations:

<!-- Your module's etc/frontend/sections.xml -->
<config>
    <action name="your/controller/action">
        <section name="cart"/>
        <!-- Only include sections you actually modify -->
    </action>
</config>

Preload Shipping Rates

If your store has a predictable default shipping address (e.g., country-level), pre-populate the shipping estimator with defaults to avoid an extra round trip when the customer first opens checkout:

// Plugin on ShippingInformationManagement
public function afterSaveAddressInformation($subject, $result, $cartId, $addressInformation)
{
    // Cache shipping rates per region/country for faster subsequent loads
}

GraphQL for Checkout (Hyva / PWA)

If you're running Hyva Checkout or a PWA frontend, the GraphQL-based checkout is significantly faster than the default KnockoutJS checkout because it eliminates the RequireJS overhead entirely. Hyva Checkout reports 60–80% faster Time to Interactive compared to Luma checkout.

4. Database Optimization for Quote Operations

The quote and quote_item tables are write-heavy and often the source of checkout slowness.

Index Maintenance

Ensure these tables are regularly optimized:

-- Check table fragmentation
SELECT table_name, data_free, data_length
FROM information_schema.tables
WHERE table_schema = 'your_db'
AND table_name IN ('quote', 'quote_item', 'quote_address', 'quote_address_rate');

-- Optimize fragmented tables
OPTIMIZE TABLE quote, quote_item, quote_address;

Clean Up Expired Quotes

Old quotes bloat these tables and slow down queries. Set up a cron to purge them:

bin/magento cron:run --group index

Configure quote lifetime in Admin > Stores > Configuration > Sales > Checkout > Shopping Cart > Quote Lifetime (days). A value of 30 days is usually sufficient.

Add Missing Indexes

Some Magento installations are missing useful composite indexes on quote-related tables. Add them via a data patch:

$this->moduleDataSetup->getConnection()->addIndex(
    $this->moduleDataSetup->getTable('quote'),
    $this->moduleDataSetup->getIdxName('quote', ['customer_id', 'is_active']),
    ['customer_id', 'is_active']
);

5. Payment Method Optimization

Payment methods are one of the biggest hidden performance killers in checkout.

Audit Third-Party Payment Extensions

Every payment provider adds its own JS SDK to the checkout. Audit what's loading:

# Check which payment methods are active
bin/magento config:show payment | grep active

Disable payment methods you don't use. Each inactive-but-installed method still loads its configuration in checkout.

Load Payment SDKs Lazily

Payment SDKs (Stripe, PayPal, Mollie, etc.) should be loaded only when the customer reaches the payment step, not on initial page load. Most modern payment extensions support this — check your provider's configuration for "lazy load" or "defer script loading" options.

For PayPal specifically:

<!-- Disable PayPal in-context checkout if not needed -->
<config>
    <default>
        <paypal>
            <wpp_usuk>
                <in_context>0</in_context>
            </wpp_usuk>
        </paypal>
    </default>
</config>

6. Server-Side Configuration

PHP Session Storage

Checkout is session-heavy. Storing sessions in files (the default) creates I/O contention under load. Move sessions to Redis:

// app/etc/env.php
'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => '6379',
        'password' => '',
        'timeout' => '2.5',
        'persistent_identifier' => '',
        'database' => '2',
        'compression_threshold' => '2048',
        'compression_library' => 'gzip',
        'log_level' => '1',
        'max_concurrency' => '6',
        'break_after_frontend' => '5',
        'break_after_adminhtml' => '30',
        'first_lifetime' => '600',
        'bot_first_lifetime' => '60',
        'bot_lifetime' => '7200',
        'disable_locking' => '0',
        'min_lifetime' => '60',
        'max_lifetime' => '2592000'
    ]
]

Enable HTTP/2

HTTP/2 multiplexing significantly reduces the overhead of multiple concurrent AJAX requests during checkout. Ensure your Nginx/Apache configuration has HTTP/2 enabled:

listen 443 ssl http2;

7. Measure Before and After

Don't optimize blindly. Use these tools to benchmark:

Chrome DevTools → Network tab — Record a checkout flow and analyze waterfall
WebPageTest.org — Test from different locations with filmstrip view
New Relic / Blackfire — Profile server-side checkout AJAX endpoints (/shipping-information, /payment-information)
Magento Profiler — Enable with bin/magento dev:profiler:enable in staging

Key metrics to track:

Time to First Byte (TTFB) on checkout page load
Time to Interactive (TTI) — when the customer can actually interact
Total JS payload on checkout
Number of AJAX calls during a full checkout flow

Quick Wins Checklist

Before diving into complex optimizations, run through these quick wins:

[ ] JS/CSS merging and minification enabled
[ ] Expired quotes cleaned up (quote table < 500k rows)
[ ] Sessions stored in Redis, not files
[ ] Unused payment methods disabled
[ ] FPC enabled and warming regularly
[ ] HTTP/2 enabled on your server
[ ] PHP OPcache configured correctly (see our OPcache guide)
[ ] Third-party checkout extensions audited for JS bloat

Conclusion

Checkout performance is not a one-time fix — it's an ongoing practice. As you add payment providers, shipping integrations, and promotional logic, each one can quietly degrade the experience for your customers.

Start with the measurement, identify your biggest bottleneck (usually JS payload or AJAX calls), and work systematically down the list. Even a 30% improvement in checkout speed can meaningfully impact your conversion rate and revenue.

For stores on Hyva or PWA frontends, the path is even clearer: the component-based architecture makes it far easier to lazy-load and defer non-critical checkout functionality. If you're still on Luma and dealing with severe checkout slowness, migrating to Hyva Checkout is worth serious consideration.

MySQL Query Cache vs Magento Cache: What's the Difference and When to Use Each

Magevanta — Wed, 06 May 2026 09:03:01 +0000

Caching is one of the most effective levers you have for speeding up a Magento 2 store. But "caching" is not a single thing — it's a stack of overlapping layers, each operating at a different level of your infrastructure. Two layers that often cause confusion are MySQL's query cache and Magento's built-in cache. They sound similar, they both exist to serve data faster, but they work in completely different ways and serve completely different purposes.

This post breaks down exactly what each one does, where they overlap, where they don't, and how to configure them properly for a production Magento 2 environment.

What Is MySQL Query Cache?

MySQL's query cache is a server-level feature that stores the result set of a SELECT query alongside the raw SQL string. If the exact same query comes in again — character for character — MySQL returns the cached result without re-executing the query against the tables.

It sounds like a win, but the reality is more nuanced.

How it works

A SELECT query arrives at MySQL.
MySQL hashes the query string and checks the query cache.
If there's a hit, the result is returned immediately.
If there's a miss, the query executes, and the result is stored in the cache.

The key problem: any write to a table invalidates all cached queries that reference that table. In a busy Magento store, tables like sales_order, catalog_product_entity, quote, and cataloginventory_stock_item are written to constantly. Every new order, every cart update, every stock decrement — all of these flush cached query results.

MySQL 8.0 removed it entirely

MySQL 8.0 deprecated and removed the query cache. The MySQL team found that in high-concurrency environments, the query cache was actually a bottleneck due to the global mutex needed to manage cache invalidation. For Magento stores running MySQL 8.0 (which is now the standard), the query cache is simply not available.

If you're still on MySQL 5.7, the query cache is present but disabled by default (query_cache_type = 0). For most Magento workloads, leaving it disabled is the right call.

What Is Magento Cache?

Magento's cache operates at the application layer, not the database layer. Rather than caching SQL results, it caches serialized PHP objects, rendered HTML blocks, configuration arrays, and more. It uses a cache backend (File, Redis, Varnish) to store and retrieve these objects.

Magento ships with several distinct cache types, each serving a specific purpose:

Cache Type	What It Stores
`config`	Merged XML configuration
`layout`	Page layout handles and block structure
`block_html`	Rendered HTML of individual blocks
`collections`	EAV collection results
`reflection`	PHP class reflection data
`db_ddl`	Database table schema metadata
`compiled_config`	DI compiled configuration
`full_page`	Complete rendered page HTML (FPC)
`translate`	Translation strings
`eav`	EAV attribute metadata

Each of these can be enabled or disabled independently:

bin/magento cache:status
bin/magento cache:enable full_page
bin/magento cache:disable block_html

The Full Page Cache

The most impactful of these is full_page — Magento's Full Page Cache (FPC). When a CMS page, category page, or product page is first rendered, the entire HTML response is stored. Subsequent requests for the same page serve the cached HTML without touching PHP or MySQL at all.

FPC can be served by:

Magento's built-in FPC (file-based or Redis-based, ~50–200ms response)
Varnish (reverse proxy, ~5–20ms response — the production-grade choice)

How They Interact

Here's the key insight: these two caching layers are almost entirely independent.

When Magento serves a cached full page, MySQL is not involved at all. When Magento's block cache is warm, it may skip several database queries entirely. Conversely, MySQL query cache (on 5.7) only kicks in when Magento actually executes a SELECT — which it tries hard to avoid by using its own cache first.

The interaction diagram looks like this:

Request
  └─► Varnish FPC hit? → Serve HTML (MySQL never touched)
        └─► Magento FPC hit? → Serve HTML (MySQL never touched)
              └─► Block cache / config cache hit? → Partial PHP execution
                    └─► MySQL query
                          └─► MySQL query cache hit? (5.7 only) → Return result
                                └─► Execute query against tables

In practice, a warm Magento cache means MySQL sees dramatically fewer queries. The MySQL query cache, when it was still available, only helped at the very bottom of this chain — for queries that escaped all of Magento's own caching layers.

Configuration Recommendations

MySQL (5.7)

If you're still on MySQL 5.7, keep the query cache disabled:

# /etc/mysql/mysql.conf.d/mysqld.cnf
query_cache_type = 0
query_cache_size = 0

The write-invalidation behavior combined with Magento's write-heavy workload makes it a net negative in most cases. Spend the memory on innodb_buffer_pool_size instead — that's where your MySQL performance gains are.

# For a server with 16GB RAM dedicated to MySQL
innodb_buffer_pool_size = 10G
innodb_buffer_pool_instances = 8

MySQL (8.0)

Nothing to configure — the query cache doesn't exist. Focus on InnoDB tuning.

Magento Cache Backend

For any production store, use Redis as the cache backend. File-based caching is fine for development but falls apart under load due to filesystem contention.

bin/magento setup:config:set \
  --cache-backend=redis \
  --cache-backend-redis-server=127.0.0.1 \
  --cache-backend-redis-port=6379 \
  --cache-backend-redis-db=0

For the session cache, use a separate Redis instance or at least a separate database index:

bin/magento setup:config:set \
  --session-save=redis \
  --session-save-redis-host=127.0.0.1 \
  --session-save-redis-port=6379 \
  --session-save-redis-db=1

Full Page Cache

In app/etc/env.php, confirm FPC is set to Redis (or Varnish if applicable):

'cache' => [
    'frontend' => [
        'full_page' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '2',
            ],
        ],
    ],
],

For high-traffic stores, put Varnish in front:

bin/magento config:set --scope=default system/full_page_cache/caching_application 2

Quick Reference: Which Cache Layer to Focus On

Situation	Recommended Action
Pages loading slowly, TTFB > 500ms	Enable Varnish or Magento FPC
MySQL CPU spiking under load	Check InnoDB buffer pool, not query cache
Slow admin panel after deploy	Run `bin/magento cache:flush`
Query cache enabled on MySQL 5.7	Disable it — likely a net negative
Dev environment with slow page loads	Enable all Magento cache types
Session-related slowness	Move sessions to Redis

Summary

MySQL query cache and Magento cache are two different tools solving different problems at different layers of the stack. For modern Magento 2 on MySQL 8.0, MySQL query cache is not a factor — it no longer exists. Your caching focus should be entirely on Magento's application cache, with Redis as the backend and Varnish (or Magento FPC) handling full-page responses.

The real performance wins in Magento come from eliminating PHP and database execution altogether — not from making individual SQL queries slightly faster. Invest in the upper layers of the cache stack first, then tune the database buffer pool, and don't waste time chasing a query cache that either doesn't exist or actively hurts you.

Magento 2 Customer Segments: The Hidden Performance Killer

Magevanta — Tue, 05 May 2026 09:03:01 +0000

If you've ever profiled a slow Magento 2 store and found mysterious database queries eating hundreds of milliseconds on every page load, customer segments are often the culprit. They're powerful. They're flexible. And they're one of the most underestimated performance drains in the entire platform.

This post dives deep into how customer segments work, why they're expensive, and what you can do about it without sacrificing the personalization they enable.

What Are Customer Segments?

Magento 2's customer segments (Commerce/Enterprise edition only) let you target specific groups of customers based on dynamic conditions — order history, cart contents, addresses, wishlists, and more. They power targeted promotions, personalized banners, and cart price rules.

Sounds great. The catch: segment membership is evaluated dynamically, often on every request.

Why Segments Kill Performance

The Evaluation Loop

When a customer logs in — or sometimes even on anonymous requests — Magento re-evaluates which segments apply to that customer. Each segment can trigger one or more SQL queries. A store with 20–30 segments can easily fire 20–30 extra queries per page load.

Run SHOW PROCESSLIST during peak traffic on an unoptimized store and you'll typically see a flood of queries like:

SELECT COUNT(*) FROM `sales_order` 
WHERE `customer_id` = ? 
AND `created_at` >= ? 
AND `status` IN (...)

These are segment condition checks. They're not cached by default. They run on every affected page.

The `magento_customersegment_customer` Table

Magento stores resolved segment memberships in magento_customersegment_customer. The problem: this table gets invalidated and repopulated aggressively. After certain events (order placed, cart updated, customer profile changed), segments are marked dirty and re-queued for recalculation.

On high-traffic stores, this table can have millions of rows — and the recalculation jobs can stack up in the cron queue.

Real-time vs. Scheduled Processing

By default, Magento evaluates segments in real-time for logged-in customers. This is the worst mode for performance.

Check your current setting:

bin/magento config:show customer/magento_customersegment/is_enabled
bin/magento config:show customer/magento_customersegment/real_time_check_if_customer_is_logged_in

If real_time_check_if_customer_is_logged_in is 1, you're paying a performance tax on every authenticated page load.

Diagnosing the Problem

Before optimizing, measure the impact on your store.

Enable Query Logging

Add to app/etc/env.php temporarily:

'db' => [
    'connection' => [
        'default' => [
            'profiler' => [
                'class'   => '\\Magento\\Framework\\DB\\Profiler',
                'enabled' => true,
            ],
        ],
    ],
],

Then analyze your logs or use a tool like New Relic, Blackfire, or even EXPLAIN on suspected queries.

Count Active Segments

SELECT COUNT(*) FROM magento_customersegment_segment WHERE is_active = 1;

More than 15–20 active segments? You're likely feeling the pain.

Check Segment Complexity

SELECT segment_id, name, conditions_serialized 
FROM magento_customersegment_segment 
WHERE is_active = 1;

Segments with deeply nested conditions or those checking order history are the most expensive. Segments checking only customer attributes (email domain, group) are cheap.

Optimization Strategies

1. Disable Real-Time Evaluation

This is the single biggest win. Switch to scheduled segment processing:

Admin → Stores → Configuration → Customers → Customer Segments

Set "Real-time Check if Customer is Logged in" to No.

Or via CLI:

bin/magento config:set customer/magento_customersegment/real_time_check_if_customer_is_logged_in 0
bin/magento cache:flush

With this off, segment membership is resolved via cron (customer_segment_match_cron) rather than on every request. There's a small lag before new customers land in segments, but for most use cases this is completely acceptable.

2. Limit Active Segments

Audit every segment. Ask: "Is this actually being used in a price rule or banner right now?"

Disable unused segments immediately. Every active segment you remove eliminates queries per page load:

-- Check which segments are attached to price rules
SELECT cs.name, cr.name as rule_name 
FROM magento_customersegment_segment cs
JOIN magento_customersegment_rule cr ON cs.segment_id = cr.segment_id
WHERE cs.is_active = 1;

Segments with no attached rules are dead weight. Disable or delete them.

3. Simplify Segment Conditions

Refactor complex segments wherever possible:

Instead of: "customer has placed more than 2 orders with total > €100 in last 90 days"
Use: A custom customer attribute (is_loyal_customer = 1) updated nightly by a cron job

Pushing complexity from runtime evaluation to a scheduled batch process is almost always faster at request time.

4. Add Database Indexes

If segments query order or quote data, make sure the relevant columns are indexed:

-- Check for missing indexes on columns used in segment conditions
SHOW INDEX FROM sales_order;
SHOW INDEX FROM quote;

Common columns worth indexing if missing:

sales_order.customer_id + created_at
sales_order.status
quote.customer_id + updated_at

5. Tune the Cron Job

The customer_segment_match_cron job processes segment recalculations. Make sure it's running regularly but not constantly re-processing the entire customer base.

Check your cron group configuration and consider moving segment processing to off-peak hours:

<!-- Custom cron schedule example -->
<group id="customer_segment">
    <schedule_generate_every>15</schedule_generate_every>
    <schedule_ahead_for>20</schedule_ahead_for>
    <schedule_lifetime>15</schedule_lifetime>
    <history_cleanup_every>10</history_cleanup_every>
    <history_success_lifetime>60</history_success_lifetime>
    <history_failure_lifetime>600</history_failure_lifetime>
    <use_separate_process>1</use_separate_process>
</group>

Running segment cron in a separate process prevents it from blocking other critical jobs.

6. Cache Segment Results Manually

For stores with custom segment conditions, consider caching the result in Redis with a TTL:

$cacheKey = 'customer_segments_' . $customerId;
$cached = $this->cache->load($cacheKey);

if (!$cached) {
    $segments = $this->segmentHelper->getCustomerSegmentIds($customer);
    $this->cache->save(
        json_encode($segments),
        $cacheKey,
        [\Magento\Customer\Model\Customer::CACHE_TAG],
        3600 // 1 hour TTL
    );
}

This is custom code but can be a lifesaver on high-traffic stores where even scheduled evaluation is too slow.

Measuring the Improvement

After applying these optimizations, benchmark the impact:

# Use siege or ab for load testing
siege -c 10 -t 30S https://yourstore.com/customer/account/

# Check slow query log
mysql -e "SHOW VARIABLES LIKE 'slow_query_log%';"

In real-world cases we've seen, disabling real-time evaluation alone reduced page load time by 200–400ms on stores with 20+ segments.

The Right Architecture

The safest pattern for customer segments at scale:

Keep real-time evaluation off — always
Batch-process memberships nightly or after major events
Use customer attributes as proxies for expensive conditions
Audit segments quarterly — disable anything that isn't earning its keep
Monitor the cron queue — a backed-up segment queue is a silent killer

Conclusion

Customer segments are not inherently bad — they're a legitimate tool for personalization and targeted promotions. But like any powerful feature, they need to be wielded carefully.

The default Magento configuration prioritizes correctness (real-time evaluation) over performance. For most stores, the opposite trade-off is better: accept a few minutes of lag in segment membership in exchange for dramatically faster page loads.

Disable real-time evaluation, prune your inactive segments, and simplify complex conditions. Your TTFB will thank you.

Running Magento on infrastructure you don't fully control? Check out our performance optimization guide for a complete picture.

Magento 2 Database Connection Pooling: Reduce Overhead and Scale Faster

Magevanta — Fri, 01 May 2026 09:02:04 +0000

Every Magento 2 page request that hits MySQL must first establish a database connection. On a busy store this sounds innocent, but at scale it becomes one of the biggest hidden bottlenecks: thousands of short-lived connections opening and closing per minute, each consuming CPU time, memory on the MySQL server, and precious milliseconds on the client side.

Database connection pooling solves this by keeping a set of connections open and reusing them across requests. In this post we'll cover exactly what that means for Magento 2, how PHP's connection handling works under the hood, and the practical steps you can take today to reduce connection overhead and improve throughput.

Why Connection Overhead Matters

When PHP opens a new MySQL connection it performs a TCP handshake, authenticates credentials, negotiates character sets, and allocates resources on both sides. On a modern server this takes roughly 1–5 ms per connection. That may sound trivial, but consider:

A Magento page that fires 20 queries needs only one connection — yet without pooling it creates and destroys that connection on every single request.
Under a flash sale with 500 concurrent users, you could have 500 simultaneous connection attempts hitting MySQL at the same instant.
MySQL's default max_connections is 151. Exceed it and new requests receive Too many connections errors.

The result: degraded performance exactly when you need it most.

How Magento 2 Handles Connections

Magento 2 uses its own Magento\Framework\DB\Adapter\Pdo\Mysql which wraps PHP's PDO extension. By default, PDO opens a new connection per request and closes it when PHP's process ends. There is no built-in connection pool at the application level.

However, there are three layers where you can introduce pooling:

PHP-FPM persistent connections — simple, built into PHP
ProxySQL — a dedicated MySQL proxy with true connection pooling
MySQL connection management via wait_timeout and pool sizing

Let's look at each in detail.

Option 1: PHP Persistent Connections

PHP's PDO supports persistent connections via the PDO::ATTR_PERSISTENT attribute. When enabled, PHP-FPM reuses an existing connection from the worker process instead of opening a new one.

How to enable it in Magento 2

Open app/etc/env.php and add persistent to your database configuration:

'db' => [
    'table_prefix' => '',
    'connection' => [
        'default' => [
            'host' => 'localhost',
            'dbname' => 'magento',
            'username' => 'magento',
            'password' => 'secret',
            'model' => 'mysql4',
            'engine' => 'innodb',
            'initStatements' => 'SET NAMES utf8;',
            'active' => '1',
            'persistent' => true,   // <-- add this
        ],
    ],
],

The trade-offs

Pros:

Zero infrastructure change required
Connection overhead drops significantly for long-running PHP-FPM workers

Cons:

Each PHP-FPM worker holds one persistent connection. With 50 workers you have 50 permanent connections to MySQL.
Transactions left open by a crashed worker can block subsequent requests on that same worker.
Not suitable for multi-tenant setups or setups with frequent SET statements that alter session state.

Verdict: Good for small-to-medium stores on a single server. Not recommended for large clusters without careful testing.

Option 2: ProxySQL — True Connection Pooling

ProxySQL is an open-source, high-performance MySQL proxy. It sits between Magento and MySQL and maintains a pool of backend connections that it multiplexes across incoming application connections.

Architecture

Magento (PHP-FPM) → ProxySQL (:6033) → MySQL (:3306)

Magento connects to ProxySQL on port 6033. ProxySQL holds, say, 50 persistent connections to MySQL and distributes Magento's queries across them — even when 500 PHP workers are making requests simultaneously.

Installing ProxySQL on Ubuntu

wget https://github.com/sysown/proxysql/releases/latest/download/proxysql_2.7.1-ubuntu24_amd64.deb
dpkg -i proxysql_2.7.1-ubuntu24_amd64.deb
systemctl enable proxysql && systemctl start proxysql

Basic ProxySQL configuration

-- Connect to ProxySQL admin
mysql -u admin -padmin -h 127.0.0.1 -P6032

-- Add your MySQL backend
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (1, '127.0.0.1', 3306);

-- Add Magento user
INSERT INTO mysql_users(username, password, default_hostgroup) VALUES ('magento', 'secret', 1);

-- Configure connection pool size
UPDATE global_variables SET variable_value='50' WHERE variable_name='mysql-max_connections';
UPDATE global_variables SET variable_value='12000' WHERE variable_name='mysql-wait_timeout';

LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;
LOAD MYSQL USERS TO RUNTIME;   SAVE MYSQL USERS TO DISK;
LOAD MYSQL VARIABLES TO RUNTIME; SAVE MYSQL VARIABLES TO DISK;

Point Magento at ProxySQL

Update app/etc/env.php:

'host' => '127.0.0.1',
'port' => '6033',  // ProxySQL port

What ProxySQL adds on top

Connection multiplexing — 500 PHP workers sharing 50 MySQL connections
Read/write split — route SELECT queries to replicas automatically
Query routing rules — send heavy analytical queries to a separate backend
Query mirroring — test new backend without affecting production
Statistics — per-query latency, error rates, connection pool stats

Performance impact

In benchmarks on a Magento 2 store with ~300 concurrent users:

Metric	Without ProxySQL	With ProxySQL
Avg response time	420 ms	310 ms
MySQL `SHOW PROCESSLIST` connections	280+	48
Requests/sec	180	260

Connection count dropped by 83% and throughput increased by 44%.

Option 3: MySQL-Side Tuning

Even without a proxy, proper MySQL configuration reduces the pain of many connections:

`wait_timeout` and `interactive_timeout`

By default MySQL keeps idle connections open for 8 hours (wait_timeout = 28800). Lower this to reclaim resources:

# /etc/mysql/mysql.conf.d/mysqld.cnf
wait_timeout = 60
interactive_timeout = 60

`max_connections`

Size this based on your actual peak concurrency, not guesswork:

max_connections = 200

Too low: connection errors under load. Too high: MySQL allocates memory for each potential connection upfront, wasting RAM.

Thread pool plugin

On MySQL Enterprise or Percona Server, enable the thread pool to limit simultaneous query execution even when many connections are open:

plugin-load-add = thread_pool.so
thread_pool_size = 16  # typically equal to CPU cores

This dramatically reduces context-switching overhead under burst traffic.

Combining the Layers

The best production setup layers all three approaches:

PHP-FPM (persistent=false) → ProxySQL (pool of 50) → MySQL (max_connections=100, thread_pool)

Use persistent connections only if you cannot deploy ProxySQL. If you have ProxySQL, disable PHP-level persistence — ProxySQL does it better and more safely.

Monitoring Connection Health

Always instrument after making changes.

MySQL connection stats

SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Connection_errors%';
SHOW STATUS LIKE 'Max_used_connections';

ProxySQL dashboard query

SELECT hostgroup, srv_host, status, ConnUsed, ConnFree, ConnOK, ConnERR
FROM stats_mysql_connection_pool;

New Relic / Datadog

If you use APM, watch the Database connection wait time metric. A healthy store should spend < 1 ms waiting for a connection. Anything above 5 ms means your pool is undersized or MySQL is overloaded.

Practical Recommendations

Store Size	Recommendation
< 50 req/s	PHP persistent connections, tune `wait_timeout`
50–300 req/s	ProxySQL with pool size 20–50
300+ req/s	ProxySQL + read replicas + thread pool

Start simple. Enable persistent connections first, benchmark with a tool like k6 or Apache Bench, then add ProxySQL if you still see connection contention.

Summary

Database connection overhead is a silent killer of Magento 2 performance at scale. The fix isn't complicated, but it requires understanding the layers:

PHP persistent connections give quick wins with no infrastructure changes
ProxySQL is the production-grade solution that truly pools and multiplexes connections
MySQL tuning (wait_timeout, max_connections, thread pool) reduces server-side pressure

Pick the right level for your current scale, instrument properly, and you'll find that response times drop and MySQL stays calm even during your busiest sales days.

Magento 2 Logging Best Practices: Keep Your Logs Clean and Actionable

Magevanta — Thu, 30 Apr 2026 09:02:13 +0000

Logs are your first line of defense when something goes wrong in production. But in a default Magento 2 installation, the logging setup is often either too noisy — filled with warnings that don't matter — or too quiet, missing the errors that actually need attention. Getting logging right is a force multiplier for your whole operations workflow.

This guide covers how Magento 2 logging works under the hood, what you should configure, what to ignore, and how to build a lean, actionable logging setup.

How Magento 2 Logging Works

Magento uses Monolog as its logging library. Log channels are defined as virtual types in di.xml, and each module can register its own logger instance. By default, most logging goes to var/log/system.log and var/log/exception.log, but individual modules write to their own files:

var/log/system.log — general system messages
var/log/exception.log — PHP exceptions caught by Magento
var/log/debug.log — debug-level messages (should be disabled in production)
var/log/cron.log — cron job execution
var/log/payment.log — payment-related activity
var/log/shipping.log — shipping carrier requests and responses

Each of these can grow very large, very fast on a busy store.

Step 1: Disable Debug Logging in Production

This one is critical. Magento's debug mode logs an enormous amount of data — request parameters, SQL queries, observer calls — and it should never be enabled in production.

Check your current setting:

php bin/magento config:show dev/debug/debug_logging

Disable it:

php bin/magento config:set dev/debug/debug_logging 0
php bin/magento cache:flush

Also check var/log/debug.log — if it exists and is growing, that's your culprit. On a high-traffic store this file can reach several GB within hours.

Step 2: Implement Log Rotation

Magento does not rotate logs automatically. Without rotation, log files will grow indefinitely until your disk fills up — and that will take your store down.

Use logrotate on Linux. Create /etc/logrotate.d/magento:

/var/www/html/var/log/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 664 www-data www-data
    sharedscripts
    postrotate
        /usr/bin/find /var/www/html/var/log -name "*.log" -mtime +14 -delete
    endscript
}

Adjust the path and user to match your setup. This keeps 14 days of compressed logs and removes anything older.

You can also clean old logs via Magento's built-in cron task. Check app/etc/crontab.xml — the log_clean job runs and cleans database logs (customer log, quote log), but not file-based logs in var/log/. That's still your responsibility.

Step 3: Fix Third-Party Module Log Spam

A very common problem: a third-party module logs aggressively at WARNING or INFO level for things that aren't actually problems. These entries flood your logs and make it hard to spot real issues.

To identify noisy modules, look at what's filling your system.log:

grep -oP 'main\.\w+' var/log/system.log | sort | uniq -c | sort -rn | head -20

Or check by log level:

grep -c 'WARNING' var/log/system.log
grep -c 'ERROR' var/log/system.log
grep -c 'CRITICAL' var/log/system.log

If WARNING vastly outnumbers ERROR and CRITICAL, you have log spam. Track it to the source:

grep 'WARNING' var/log/system.log | grep -oP 'in .*\.php' | sort | uniq -c | sort -rn | head -10

Once identified, you have two options:

Raise the minimum log level for that module's handler in di.xml
Open a support ticket with the extension vendor — this is their bug, not yours

Step 4: Set Minimum Log Level Per Handler

You can configure the minimum severity level for Magento's default log handlers via di.xml. Add this to your module or app/etc/di.xml:

<type name="Magento\Framework\Logger\Handler\System">
    <arguments>
        <argument name="fileName" xsi:type="string">/var/log/system.log</argument>
        <argument name="loggerType" xsi:type="number">400</argument>
    </arguments>
</type>

The loggerType corresponds to Monolog levels:

100 = DEBUG
200 = INFO
250 = NOTICE
300 = WARNING
400 = ERROR
500 = CRITICAL

Setting 400 (ERROR) means WARNING and below will be ignored. This is a reasonable production default for system.log.

Step 5: Write Better Custom Logs

If you're developing a custom module, follow these guidelines to write logs that are actually useful:

Use the right level:

$this->logger->debug('Processing item', ['id' => $itemId]);    // dev only
$this->logger->info('Order exported', ['order' => $orderId]);  // informational
$this->logger->warning('Fallback used', ['reason' => $msg]);   // worth noting
$this->logger->error('Export failed', ['exception' => $e]);    // needs attention
$this->logger->critical('Payment gateway down', [...]);         // wake someone up

Always include context:

// Bad
$this->logger->error('Failed to process order');

// Good
$this->logger->error('Failed to process order', [
    'order_id'  => $order->getIncrementId(),
    'exception' => $e->getMessage(),
    'trace'     => $e->getTraceAsString(),
]);

Context arrays are serialized to JSON in the log line, making them searchable and parseable by log aggregators.

Use a dedicated log channel for your module:

<!-- di.xml -->
<virtualType name="MyModule\Logger\Handler" type="Magento\Framework\Logger\Handler\Base">
    <arguments>
        <argument name="fileName" xsi:type="string">/var/log/mymodule.log</argument>
    </arguments>
</virtualType>
<virtualType name="MyModule\Logger\Logger" type="Magento\Framework\Logger\Monolog">
    <arguments>
        <argument name="name" xsi:type="string">mymodule</argument>
        <argument name="handlers" xsi:type="array">
            <item name="system" xsi:type="object">MyModule\Logger\Handler</item>
        </argument>
    </arguments>
</virtualType>

This keeps your logs isolated from Magento core logs and makes debugging much faster.

Step 6: Monitor Critical Logs

Logging is only useful if someone reads the logs. In production, set up alerting:

Simple option: Use a cron job that runs grep -c CRITICAL var/log/system.log and sends an alert if the count increases
Better option: Ship logs to a centralized service like Papertrail, Logtail, Datadog, or Elasticsearch + Kibana
Best option: Use structured JSON logging so your log aggregator can parse fields properly

For JSON logging in Magento, you can replace the default formatter:

<type name="Magento\Framework\Logger\Handler\System">
    <arguments>
        <argument name="formatter" xsi:type="object">Monolog\Formatter\JsonFormatter</argument>
    </arguments>
</type>

JSON logs are harder to read manually but much easier to query, filter, and alert on.

Step 7: Don't Log Sensitive Data

This sounds obvious but it happens — especially with payment modules. Never log:

Credit card numbers or CVV codes
Full customer passwords or tokens
API keys or secrets
Full HTTP request bodies from payment endpoints

If you need to log payment-related activity for debugging, log only order IDs, masked card data (last 4 digits), and response codes. Many PCI DSS compliance failures originate in log files.

Quick Wins Checklist

[ ] dev/debug/debug_logging = 0 in production
[ ] logrotate configured for var/log/*.log
[ ] var/log/debug.log doesn't exist or is empty
[ ] System log filtered to ERROR level minimum
[ ] Third-party log spam identified and addressed
[ ] Critical log monitoring / alerting in place
[ ] No sensitive data in any log file

Conclusion

Good logging discipline makes the difference between a 5-minute incident response and a 5-hour debugging session. On Magento 2, the defaults are not production-ready — you need to actively configure log levels, implement rotation, suppress noise, and make sure critical errors reach the right people.

Invest 30 minutes into your logging setup now and you'll save hours when something inevitably goes wrong.

Magento 2 Multistore Performance: Architecture & Optimization Guide

Magevanta — Wed, 29 Apr 2026 09:04:54 +0000

Running multiple stores, websites, or store views on a single Magento 2 instance is one of the platform's biggest strengths. One codebase, one admin, one database — shared infrastructure for multiple brands, languages, or regions.

But multistore setups come with hidden performance traps. The same features that make them flexible — scoped configuration, separate price rules, store-specific catalog data — can silently murder your response times if you're not careful.

This guide covers the architecture decisions and practical optimizations that keep a multistore Magento 2 installation running fast.

How Magento 2 Resolves Store Context

Before optimizing, you need to understand the performance cost of store resolution itself.

Every request, Magento determines the current store via one of these mechanisms:

Server Name — the default and recommended approach (each store on its own domain/subdomain)
URL prefix — store code in the URL path (/uk/, /de/)
Cookie — least performant, not recommended for production

The MAGE_RUN_CODE and MAGE_RUN_TYPE environment variables (set in Nginx or .htaccess) tell Magento which store to bootstrap. Getting this wrong — or relying on runtime detection — adds unnecessary overhead to every single request.

Set it at the web server level, not in PHP:

# Nginx example: domain-based store routing
server {
    server_name store-uk.example.com;
    fastcgi_param MAGE_RUN_CODE uk_store;
    fastcgi_param MAGE_RUN_TYPE store;
}

server {
    server_name store-de.example.com;
    fastcgi_param MAGE_RUN_CODE de_store;
    fastcgi_param MAGE_RUN_TYPE store;
}

This avoids the \Magento\Store\Model\StoreResolver doing expensive database lookups on every request.

Cache Segmentation: The Biggest Pitfall

By default, Magento stores cache entries with a cache key that includes the store context. But if you're not careful about cache tags, pages from one store can bleed into another — or worse, the cache hit rate tanks because every store generates separate entries for largely identical content.

Full Page Cache (FPC) Strategy

Each store view should have a clean FPC namespace. With Varnish, this means:

sub vcl_hash {
    hash_data(req.url);
    if (req.http.host) {
        hash_data(req.http.host);
    } else {
        hash_data(server.ip);
    }
    return (lookup);
}

The req.http.host inclusion ensures store A's cached homepage doesn't serve as store B's cache. Without it, you'll get cross-store cache pollution.

Redis Cache Separation

If you're running Redis for caching (and you should be), use separate Redis databases per logical cache type — but don't over-segment by store. Magento's cache keys already include store scope:

// app/etc/env.php
'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'database' => '0',
            ],
        ],
        'page_cache' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'database' => '1',
            ],
        ],
    ],
],

Separating default and page_cache into different Redis databases prevents FPC flushes from wiping your config/block cache.

Configuration Scoping & Database Queries

Magento's EAV-based configuration system is scope-aware. Every core_config_data value can exist at global, website, or store level — and Magento merges them at runtime.

In a multistore setup, this merge process runs on every request (unless cached). With 5 stores × hundreds of config keys, you're looking at significant overhead.

Profile it:

bin/magento dev:query-log:enable
# Run a few pages, then inspect var/debug/db.log
grep "core_config_data" var/debug/db.log | wc -l

Mitigate it:

Keep config values at the global scope whenever possible. Only override at store level when genuinely necessary.
Avoid creating store-specific config values "just in case" — every scope override adds to the merge cost.
Make sure config cache type is always enabled in production.

Indexer Load in Multistore Environments

Indexers are one of the biggest hidden costs in multistore Magento. The catalog price indexer, in particular, generates a price row for every product × customer group × website combination.

With 3 websites, 4 customer groups, and 50,000 products:

3 × 4 × 50,000 = 600,000 rows in catalog_product_index_price

Compare that to a single-store setup: 4 × 50,000 = 200,000 rows. You've tripled the index size just by adding two more websites.

Strategies to reduce indexer bloat:

1. Limit Customer Groups

Every extra customer group multiplies your price index. Audit and remove unused groups via:

SELECT cg.customer_group_id, cg.customer_group_code, COUNT(c.entity_id) as customers
FROM customer_group cg
LEFT JOIN customer_entity c ON c.group_id = cg.customer_group_id
GROUP BY cg.customer_group_id
ORDER BY customers ASC;

Groups with zero customers are candidates for removal.

2. Use Shared Catalogs Carefully

B2B shared catalogs create additional price index entries. If you don't need per-company pricing, a simpler tier price setup is more performant.

3. Schedule Indexers Wisely

In multistore setups, indexer runs take longer. Use Update by Schedule mode but stagger your cron windows so the price indexer doesn't fire simultaneously across all websites:

# bin/magento indexer:set-mode schedule catalog_product_price
# Then customize mview cron schedule in a custom module

Store-Specific vs. Shared Catalog Data

One of the biggest architectural decisions in multistore Magento is how much catalog data you share vs. scope.

Shared (global scope) — fast:

Product names, descriptions, prices (if not localized)
Categories with same URL structure

Store-scoped — slower:

Translated attribute values (name, description per store)
Store-specific URL rewrites
Custom prices per website

Every store-scoped attribute value multiplies your EAV table size. A product with 10 text attributes across 5 store views = 50 rows in catalog_product_entity_varchar vs. 10 for a single-store setup.

Practical rule: Only create store-scoped overrides when there's a real business requirement. "We might translate this later" is not a reason to scope everything to store level today.

URL Rewrite Management

URL rewrites are a notorious performance bottleneck, and it gets worse with multiple stores. Magento generates a URL rewrite record for every product × store view × category path combination.

Check your current rewrite count:

SELECT store_id, COUNT(*) as rewrites 
FROM url_rewrite 
GROUP BY store_id 
ORDER BY rewrites DESC;

If you see millions of rows, you have a problem. Common causes:

Categories nested too deeply — URL paths include all parent categories, so moving a category regenerates thousands of rewrites
Unnecessary store views — disabled store views still have URL rewrites generated for them
Product-category rewrites enabled — the most common culprit

Disable product-category URL rewrites if you don't need them:

Stores → Configuration → Catalog → Search Engine Optimization
→ Use Categories Path for Product URLs → No

This single change can reduce your url_rewrite table by 60-80% in large catalogs.

Session Storage for Multiple Stores

With multiple stores (especially across domains), session handling needs extra attention.

Use Redis for sessions — never filesystem sessions at scale
If stores are on different domains, you cannot share sessions via cookie — each domain needs its own session namespace
Set path and domain in session config per store if needed

// app/etc/env.php
'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => '6379',
        'database' => '2',
        'disable_locking' => '1',
    ],
],

disable_locking => 1 is important for performance — default session locking serializes concurrent requests from the same user.

Monitoring Multistore Performance

Set up per-store performance baselines. A single slow store can be hard to detect in aggregate metrics.

New Relic / Datadog: tag transactions with store code. In Magento, you can do this via a plugin on \Magento\Store\Model\StoreManagerInterface::getStore().

Simple approach — separate log files per store:

access_log /var/log/nginx/store_uk_access.log combined;

Then track TTFB per store with a log parser. A sudden increase in one store's TTFB while others stay flat tells you exactly where to dig.

Quick Wins Checklist

Before diving into deep architecture changes, confirm these basics:

[ ] MAGE_RUN_CODE / MAGE_RUN_TYPE set at Nginx level, not PHP
[ ] Separate Redis databases for default and page_cache
[ ] All cache types enabled: bin/magento cache:status
[ ] Product-category URL rewrites disabled if not needed
[ ] Unused customer groups removed
[ ] Indexers in "Update by Schedule" mode
[ ] Config values at global scope where possible
[ ] Session locking disabled in Redis session config
[ ] Each domain resolves via server_name, not URL prefix

Conclusion

Multistore Magento is not inherently slow — but it amplifies every architectural mistake. The same configuration bloat, indexer inefficiency, or cache misconfiguration that causes minor issues on a single store becomes a serious problem at 3× or 5× scale.

The good news: most of the wins are configuration changes, not code. Set your store resolution at the web server level, keep your config scope lean, manage your URL rewrites, and keep an eye on indexer growth as your catalog scales.

Get these right and a multistore Magento setup can serve millions of requests efficiently — no extra infrastructure required.

Magento 2 Flat Catalog: Performance Impact & When to Enable It

Magevanta — Tue, 28 Apr 2026 09:04:10 +0000

The Magento 2 flat catalog sits in Stores → Configuration → Catalog → Storefront as two innocent toggles: Use Flat Catalog Category and Use Flat Catalog Product. Many store owners enable both and call it a day, assuming more flat = more fast. The reality is more nuanced — and getting it wrong can actively slow down your store.

This post explains what the flat catalog actually does, the specific conditions where it helps, and a practical checklist for deciding whether to enable it on your store.

What the Flat Catalog Actually Does

Magento's default EAV (Entity–Attribute–Value) model stores product and category data across many tables: catalog_product_entity, catalog_product_entity_varchar, catalog_product_entity_int, catalog_product_entity_decimal, and so on. Loading a single product can require joining dozens of tables.

The flat catalog denormalizes all of that into a single table per store view:

catalog_product_flat_1 (for store view ID 1)
catalog_category_flat_store_1

Instead of 20+ joins, Magento reads one row from one table. Sounds great on paper.

The catch: that flat table must be rebuilt every time product data changes. And the rebuild is expensive.

When Flat Catalog Helps

The flat catalog genuinely shines in a specific scenario:

Large catalogs with mostly static data, heavy frontend traffic, and infrequent updates.

If you have:

50,000+ active products
Multiple store views (one flat table per store view = optimized per-locale queries)
Product data that changes weekly, not hourly
A frontend-heavy workload (no headless/API-first architecture)

…then flat catalog can noticeably reduce query time on category pages and product listing pages.

Benchmarks on large catalogs (100k+ products) commonly show 20–40% faster category page render times when flat catalog is enabled and the index is fresh.

When Flat Catalog Hurts

1. Frequent product updates

Every time a product attribute changes — price update, stock level, description edit — Magento has to re-flatten that data. If you're running price updates every few minutes (dynamic pricing, external ERP sync), you're constantly invalidating and rebuilding the flat index.

During a full reindex, Magento falls back to EAV queries. Worse, a partial index lock can cause frontend errors if catalog_product_flat_1 is being swapped.

2. Small to medium catalogs

For stores with under 10,000 products, the flat catalog overhead — index maintenance, table size, reindex time — rarely justifies itself. Modern MySQL with proper indexing handles EAV joins for small catalogs without breaking a sweat. Redis + full-page cache masks most of the remaining overhead anyway.

3. Headless / API-first stores

If your frontend hits Magento via GraphQL or REST, the flat catalog is largely irrelevant. GraphQL resolvers in Magento 2 use the product collection layer which has its own query optimization. The flat catalog was designed for the PHP-rendered Luma frontend.

4. B2B stores with shared catalogs

Magento's shared catalog (B2B module) adds per-company pricing and catalog visibility. Shared catalog relies heavily on the EAV layer and custom price indexing. Enabling flat catalog alongside shared catalog can cause subtle data inconsistencies, particularly with tier prices and customer group prices.

The Hidden Cost: Index Table Size

Let's talk storage. A standard EAV product table for 100,000 products might be 800MB across all attribute tables. The flat table for the same catalog, across four store views, can easily reach 2–4GB.

This matters for:

InnoDB buffer pool efficiency (can your flat tables fit in RAM?)
Backup duration and storage cost
Replication lag on read replicas

Check your current flat table sizes:

SELECT 
    table_name,
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name LIKE 'catalog_%flat%'
ORDER BY size_mb DESC;

If those tables are larger than your InnoDB buffer pool allows to cache, you're doing disk I/O on every category page load — slower than EAV with a warm query cache.

How to Measure the Impact

Before making a decision, benchmark your actual store. Here's a simple before/after approach:

Step 1: Capture baseline

# Enable slow query log temporarily
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow-baseline.log';

Load 10–20 representative category pages via curl or a tool like wrk:

wrk -t4 -c20 -d30s https://yourstore.com/category-url.html

Step 2: Enable flat catalog

Stores → Configuration → Catalog → Storefront
→ Use Flat Catalog Category: Yes
→ Use Flat Catalog Product: Yes

Then reindex:

bin/magento indexer:reindex catalog_category_flat catalog_product_flat
bin/magento cache:flush

Step 3: Re-run your benchmark

Compare slow query counts, average response times, and MySQL CPU usage. If you see a >15% improvement, flat catalog is worth it for your setup. If the numbers barely move, stick with EAV.

Flat Catalog & Magento Indexers

The flat catalog depends on two indexers:

Indexer	Mode recommendation
`catalog_category_flat`	Schedule
`catalog_product_flat`	Schedule

Never run these in realtime mode unless you enjoy frontend slowdowns during product saves. Schedule mode batches the updates and runs them via cron, keeping your frontend serving fresh-enough data without locking tables mid-request.

Configure via:

bin/magento indexer:set-mode schedule catalog_category_flat catalog_product_flat

And make sure your Magento cron is healthy:

bin/magento cron:status

Recommended Configuration Matrix

Store type	Category flat	Product flat
Small store (<10k products)	❌ Disable	❌ Disable
Medium store (10k–50k), Luma frontend	✅ Enable	⚠️ Test first
Large store (50k+), static prices	✅ Enable	✅ Enable
Headless / GraphQL frontend	❌ Disable	❌ Disable
B2B with shared catalog	❌ Disable	❌ Disable
High-frequency price updates	❌ Disable	❌ Disable

Disabling Flat Catalog Safely

If you're currently running flat catalog and want to test without it:

# Disable via CLI (faster than UI)
bin/magento config:set catalog/frontend/flat_catalog_category 0
bin/magento config:set catalog/frontend/flat_catalog_product 0
bin/magento cache:flush

Magento will automatically fall back to EAV queries. You don't need to drop the flat tables immediately — they'll just sit unused until you decide to re-enable or clean them up:

-- Only after confirming flat is disabled and you don't need rollback
DROP TABLE IF EXISTS catalog_product_flat_1;
DROP TABLE IF EXISTS catalog_category_flat_store_1;
-- Repeat for each store view ID

The Real Performance Lever: Full-Page Cache

Here's the honest truth that many performance guides skip: with full-page cache (FPC) properly configured, the flat catalog vs. EAV difference becomes almost irrelevant for most stores.

FPC (Varnish or Magento's built-in cache) caches the entire rendered HTML page. That means the first request after a cache miss triggers the EAV or flat query — and every subsequent request until the cache expires serves static HTML without hitting the database at all.

The flat catalog matters most in two scenarios:

Cache miss rate is high (logged-in customers, personalized content)
Your cron-based FPC warming can't keep up with catalog changes

Before spending time tuning flat catalog, verify your FPC hit rate:

# Check Varnish hit rate
varnishstat -1 | grep cache_hit

A healthy store should have >90% FPC hit rate. If you're below that, fix your caching strategy first — it will have 10x the impact of any flat catalog configuration.

Summary

The flat catalog is a legitimate performance tool with a narrow sweet spot. Enable it when you have a large, stable Luma-frontend catalog. Disable it (or skip it entirely) for headless setups, B2B stores, high-frequency update pipelines, and small catalogs where the overhead isn't justified.

Most importantly: measure before and after. Performance decisions made on assumptions rather than data are how stores end up with configurations that were optimal in 2015 and actively harmful today.

The best Magento performance stack in 2026 is still: proper indexing + Redis for cache/session + Varnish FPC + a well-tuned InnoDB buffer pool. The flat catalog is a complementary optimization, not a foundation.

Magento 2 CDN Configuration: Faster Assets, Global Performance

Magevanta — Mon, 27 Apr 2026 09:02:19 +0000

A CDN (Content Delivery Network) is one of the highest-leverage performance improvements you can make to a Magento 2 store. Instead of every visitor downloading images, CSS, and JavaScript from your origin server, those assets are served from an edge node geographically close to them. The result: dramatically lower latency, reduced origin load, and better Core Web Vitals scores.

This guide walks through the full CDN setup for Magento 2 — from choosing a provider to configuring static content URLs, media, and cache invalidation.

Why Magento 2 Needs a CDN

A typical Magento 2 page request involves dozens of static asset fetches:

CSS bundles (merged or per-module)
JavaScript files (RequireJS modules, bundles)
Product images and banners
Fonts, icons, and SVGs

Without a CDN, every one of those requests hits your origin server. For a store with international customers, a visitor in Sydney hitting a server in Frankfurt adds 200–300 ms of network latency per asset. Multiply that by 40–60 assets and you're looking at seconds of avoidable delay.

A CDN solves this by caching assets at edge nodes around the world after the first request. Subsequent requests from nearby visitors are served at local network speeds.

Choosing a CDN Provider

Magento 2 works with any CDN that supports:

Custom origin pull (fetches from your server on cache miss)
Custom hostname / CNAME support
Cache-Control header respect

Popular choices:

Provider	Notes
Cloudflare	Free tier, excellent DDoS protection, easy setup
Fastly	Used by Adobe Commerce Cloud, very fast purge API
AWS CloudFront	Great if already on AWS, flexible but more complex
BunnyCDN	Cheap, fast, straightforward pricing
KeyCDN	Pay-as-you-go, simple configuration

For most self-hosted stores, Cloudflare or BunnyCDN offer the best price/performance ratio.

Step 1 — Set Up a CDN Subdomain

Create a dedicated subdomain that points to your CDN, for example:

cdn.yourdomain.com

In your CDN provider, configure this hostname as a "pull zone" or "distribution" with your Magento origin as the source:

Origin: https://yourdomain.com
CDN hostname: cdn.yourdomain.com

The CDN will pull files from your origin on the first request and cache them at the edge for subsequent requests.

Step 2 — Configure Magento 2 to Use the CDN URL

In the Magento Admin, navigate to:

Stores → Configuration → General → Web

Under Base URLs, set:

Base URL for Static View Files: https://cdn.yourdomain.com/
Base URL for User Media Files: https://cdn.yourdomain.com/

Save the config and flush the Magento cache:

bin/magento cache:flush

You can also set this via CLI, which is useful for automated deployments:

bin/magento config:set web/unsecure/base_static_url https://cdn.yourdomain.com/
bin/magento config:set web/unsecure/base_media_url https://cdn.yourdomain.com/
bin/magento config:set web/secure/base_static_url https://cdn.yourdomain.com/
bin/magento config:set web/secure/base_media_url https://cdn.yourdomain.com/

After this change, all references to static and media files in Magento's HTML output will point to your CDN URL instead of the origin.

Step 3 — Verify Static Content Deployment

Before pushing to production, make sure your static content is deployed and accessible:

bin/magento setup:static-content:deploy -f

Then visit a frontend page and inspect the asset URLs in your browser's network tab. You should see requests going to cdn.yourdomain.com for CSS, JS, and images.

Step 4 — Configure Cache Headers on the Origin

For the CDN to cache assets effectively, your origin server needs to send proper Cache-Control headers. Magento's static assets are versioned by hash, so they can be cached aggressively.

In Nginx, add this to your server block:

location ~* \.(jpg|jpeg|png|gif|ico|webp|svg|css|js|woff|woff2|ttf|eot)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    add_header Vary "Accept-Encoding";
}

For media files (product images), a shorter TTL is safer since they can change:

location /media/ {
    expires 7d;
    add_header Cache-Control "public";
}

Step 5 — CDN Cache Invalidation

When you deploy new static content (new theme, module update), the CDN needs to serve fresh files. There are two approaches:

Option A — Version-based URLs (Recommended)

Magento uses content hashes in static asset URLs by default (e.g., version1234567890/). When you redeploy static content, the hash changes, so the CDN automatically fetches the new files. No manual invalidation needed.

Make sure this is enabled:

bin/magento config:set dev/static/sign 1

Option B — Manual CDN Purge

If you need to force a purge (e.g., after updating media images), most CDN providers offer an API or CLI:

Cloudflare:

curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything":true}'

BunnyCDN:

curl -X POST "https://api.bunny.net/pullzone/{zone_id}/purgeCache" \
  -H "AccessKey: {api_key}"

For Fastly (used in Adobe Commerce Cloud pipelines), Magento has built-in Fastly integration with automatic purge on cache flush.

Step 6 — Handle Secure vs Non-Secure URLs

If your store runs on HTTPS (it should), make sure your CDN subdomain also has a valid TLS certificate. Most CDN providers issue free certificates automatically for custom domains.

Also ensure both secure and non-secure base URLs are set in Magento (even if you redirect all HTTP to HTTPS):

bin/magento config:set web/unsecure/base_static_url https://cdn.yourdomain.com/
bin/magento config:set web/secure/base_static_url https://cdn.yourdomain.com/

Step 7 — Exclude Dynamic Requests from the CDN

Your CDN should only cache static assets, not Magento's dynamic pages (cart, checkout, customer account). Configure your CDN to not cache requests matching:

Paths containing session cookies (PHPSESSID, mage-cache-sessid)
/checkout/
/customer/
/sales/
Any request with a Set-Cookie response header

In Cloudflare, use a Page Rule:

URL: yourdomain.com/checkout/*
Cache Level: Bypass

For Fastly/VCL, configure pass for these paths in the vcl_recv subroutine.

Performance Impact — What to Expect

After a proper CDN setup, typical improvements:

Metric	Before CDN	After CDN
TTFB for static assets	80–300 ms	5–30 ms
LCP (Largest Contentful Paint)	3.5–6s	1.5–2.5s
Origin bandwidth usage	Baseline	−60–80%
Server load during traffic spikes	High	Significantly reduced

The bandwidth reduction alone can meaningfully lower hosting costs, especially for image-heavy catalogs.

Common Pitfalls

Mixed content warnings: If your CDN URL uses HTTPS but Magento generates some HTTP URLs, browsers will block the mixed content. Always use HTTPS for both origin and CDN.

Wrong path structure: The CDN pull zone must serve Magento's full path structure, including /pub/ if your webroot is configured to use it. Test a few asset URLs manually before going live.

Forgot to flush config cache: After changing base URLs in the admin, always run bin/magento cache:flush — stale config cache will cause the old URLs to persist.

CDN caching HTML: If you accidentally route your main domain through the CDN without bypassing dynamic requests, customers will see cached versions of each other's carts. Always double-check your bypass rules.

Putting It All Together

A CDN is one of the few Magento performance improvements with near-zero downside. Setup takes an hour, the cache miss penalty is invisible to users, and the gains are immediate and measurable.

The recommended flow for a new store:

Pick a CDN provider (Cloudflare for simplicity, BunnyCDN for cost efficiency)
Create a cdn.yourdomain.com pull zone pointing to your origin
Set the Magento base static/media URLs
Configure aggressive cache headers in Nginx
Enable signed static URLs for automatic versioning
Test asset URLs on staging first, then deploy to production

Once it's running, you'll wonder why you didn't set it up on day one.

Magento 2 CI/CD with GitHub Actions: A Production-Ready Deploy Pipeline

Magevanta — Sun, 26 Apr 2026 09:02:02 +0000

Deploying Magento 2 manually is a recipe for mistakes — missed setup:upgrade, forgotten cache flushes, or a static content deploy that never ran. GitHub Actions lets you automate every step, enforce consistency, and ship with confidence. In this guide we build a production-ready CI/CD pipeline from scratch.

Why GitHub Actions for Magento 2?

Magento deployments have a lot of moving parts:

Composer install (with auth.json for Magento repo)
Database schema + data migrations (setup:upgrade)
Dependency injection compilation (setup:di:compile)
Static content deploy (setup:static-content:deploy)
Cache flush
Potentially a maintenance window

One missed step can take your store down. Automating it removes human error and makes every deployment reproducible.

Repository Structure

Before setting up the pipeline, your repo should follow this layout:

magento-root/
├── app/
├── composer.json
├── composer.lock
├── .github/
│   └── workflows/
│       └── deploy.yml
└── ...

Keep auth.json out of version control — we'll inject it via secrets.

Setting Up GitHub Secrets

Go to your repo → Settings → Secrets and variables → Actions and add:

Secret	Value
`SSH_PRIVATE_KEY`	Private key for your server
`SSH_HOST`	Server IP or hostname
`SSH_USER`	Deploy user (e.g. `magento`)
`MAGENTO_REPO_PUBLIC`	Magento Marketplace public key
`MAGENTO_REPO_PRIVATE`	Magento Marketplace private key
`DEPLOY_PATH`	Absolute path on server (e.g. `/var/www/magento`)

The Workflow File

Create .github/workflows/deploy.yml:

name: Deploy Magento 2

on:
  push:
    branches:
      - main

jobs:
  deploy:
    name: Deploy to Production
    runs-on: ubuntu-latest
    timeout-minutes: 30

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          extensions: bcmath, ctype, curl, dom, gd, intl, mbstring, openssl, pdo_mysql, simplexml, soap, xsl, zip
          tools: composer:v2

      - name: Configure Magento Composer auth
        run: |
          composer config -g http-basic.repo.magento.com \
            ${{ secrets.MAGENTO_REPO_PUBLIC }} \
            ${{ secrets.MAGENTO_REPO_PRIVATE }}

      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader --no-interaction

      - name: Setup SSH
        uses: webfactory/ssh-agent@v0.9.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Add server to known hosts
        run: |
          ssh-keyscan -H ${{ secrets.SSH_HOST }} >> ~/.ssh/known_hosts

      - name: Sync files to server
        run: |
          rsync -az --delete \
            --exclude='.git' \
            --exclude='.github' \
            --exclude='var/' \
            --exclude='pub/media/' \
            --exclude='app/etc/env.php' \
            ./ ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }}:${{ secrets.DEPLOY_PATH }}/

      - name: Run Magento deploy commands
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} << 'EOF'
            set -e
            cd ${{ secrets.DEPLOY_PATH }}

            # Enable maintenance mode
            php bin/magento maintenance:enable

            # Run upgrades
            php bin/magento setup:upgrade --keep-generated

            # Compile DI
            php bin/magento setup:di:compile

            # Deploy static content (adjust locales as needed)
            php bin/magento setup:static-content:deploy en_US nl_NL -f

            # Flush cache
            php bin/magento cache:flush

            # Disable maintenance
            php bin/magento maintenance:disable

            echo "Deploy complete ✓"
          EOF

Optimizing the Pipeline

Cache Composer Dependencies

Composer installs can take several minutes. Use GitHub's cache action to speed things up:

      - name: Cache Composer packages
        uses: actions/cache@v4
        with:
          path: ~/.composer/cache
          key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
          restore-keys: |
            ${{ runner.os }}-composer-

Add this step before composer install. On cache hit, installs drop from ~4 minutes to under 30 seconds.

Parallel Static Content Deploy

For stores with multiple locales, parallelize the static content deploy:

php bin/magento setup:static-content:deploy en_US nl_NL de_DE fr_FR -f --jobs=$(nproc)

The --jobs flag uses multiple CPU cores. On a 4-core server this roughly cuts deploy time in half.

Skip Compilation When Unnecessary

If your push only changes templates or CMS content, running setup:di:compile wastes 3–5 minutes. Use path filters:

on:
  push:
    branches:
      - main
    paths-ignore:
      - 'app/design/**'
      - '**.md'

Or use a more granular approach with conditional steps:

      - name: Check if PHP changed
        id: php_changed
        run: |
          git diff --name-only HEAD~1 HEAD | grep -qE '\.php$' && echo "changed=true" >> $GITHUB_OUTPUT || echo "changed=false" >> $GITHUB_OUTPUT

      - name: Compile DI
        if: steps.php_changed.outputs.changed == 'true'
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} \
            "cd ${{ secrets.DEPLOY_PATH }} && php bin/magento setup:di:compile"

Zero-Downtime with Symlink Strategy

The maintenance window approach works, but causes downtime. A symlink-based blue/green strategy eliminates it:

/var/www/
├── releases/
│   ├── 20260426_110000/   ← new release
│   └── 20260420_090000/   ← previous
├── shared/
│   ├── env.php
│   ├── var/
│   └── pub/media/
└── current -> releases/20260426_110000  ← symlink, Nginx points here

Update your deploy step to:

      - name: Deploy with symlink swap
        run: |
          ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} << 'EOF'
            set -e
            RELEASE_DIR="${{ secrets.DEPLOY_PATH }}/releases/$(date +%Y%m%d_%H%M%S)"
            SHARED_DIR="${{ secrets.DEPLOY_PATH }}/shared"
            CURRENT="${{ secrets.DEPLOY_PATH }}/current"

            mkdir -p $RELEASE_DIR

            # Copy files (already rsynced to a staging dir in previous step)
            rsync -a ${{ secrets.DEPLOY_PATH }}/staging/ $RELEASE_DIR/

            # Link shared files
            ln -sfn $SHARED_DIR/env.php $RELEASE_DIR/app/etc/env.php
            ln -sfn $SHARED_DIR/var $RELEASE_DIR/var
            ln -sfn $SHARED_DIR/pub/media $RELEASE_DIR/pub/media

            cd $RELEASE_DIR
            php bin/magento setup:upgrade --keep-generated
            php bin/magento setup:di:compile
            php bin/magento setup:static-content:deploy en_US -f
            php bin/magento cache:flush

            # Atomic swap — no downtime
            ln -sfn $RELEASE_DIR $CURRENT

            # Keep last 5 releases
            ls -dt ${{ secrets.DEPLOY_PATH }}/releases/*/ | tail -n +6 | xargs rm -rf
          EOF

Nginx points to /var/www/current and the symlink swap is atomic — visitors never see a broken state.

Rollback

With the releases directory, rollback is trivial:

# List releases
ls /var/www/releases/

# Roll back to previous
ln -sfn /var/www/releases/20260420_090000 /var/www/current
php bin/magento cache:flush

Add a manual rollback workflow in .github/workflows/rollback.yml with workflow_dispatch trigger so you can trigger it from the GitHub UI with one click.

Notifications

Add a Slack or Telegram notification at the end of the job:

      - name: Notify on success
        if: success()
        run: |
          curl -s -X POST https://api.telegram.org/bot${{ secrets.TG_BOT_TOKEN }}/sendMessage \
            -d chat_id=${{ secrets.TG_CHAT_ID }} \
            -d text="✅ Magento deploy succeeded on $(date)"

      - name: Notify on failure
        if: failure()
        run: |
          curl -s -X POST https://api.telegram.org/bot${{ secrets.TG_BOT_TOKEN }}/sendMessage \
            -d chat_id=${{ secrets.TG_CHAT_ID }} \
            -d text="❌ Magento deploy FAILED — check GitHub Actions"

Security Considerations

Never commit auth.json or app/etc/env.php. Add them to .gitignore.
Use a dedicated deploy user on the server with minimal permissions — no sudo, only write access to the web root.
Rotate SSH keys periodically and use GitHub's secret rotation reminders.
Consider branch protection rules: require PRs to merge into main, so deploys always go through review.

Complete Pipeline at a Glance

Step	Time (estimate)
Checkout + PHP setup	~20s
Composer install (cached)	~30s
Rsync to server	~15s
`setup:upgrade`	~30s
`setup:di:compile`	~90s
Static content deploy	~60s
Cache flush	~5s
Total	~4 minutes

Four minutes from git push to live — with zero manual steps and full rollback capability.

Summary

A solid Magento 2 CI/CD pipeline with GitHub Actions gives you:

Repeatability — every deploy follows the same steps
Speed — cached dependencies and parallel jobs
Safety — atomic symlink swaps eliminate downtime
Observability — notifications on every deploy
Recovery — instant rollback to any previous release

Start with the basic workflow, then layer in the symlink strategy and parallelization as your store grows. Your future self will thank you at 2 AM when a deploy goes sideways and rollback takes 10 seconds instead of 45 minutes.

Magento 2 JavaScript Bundling & RequireJS Optimization

Magevanta — Sat, 25 Apr 2026 09:02:04 +0000

JavaScript is one of the biggest culprits behind slow Magento 2 storefronts. A default installation can easily generate 100+ individual JS file requests per page. Each one adds latency, blocks rendering, and hammers your Time to First Byte (TTFB). In this guide, we'll walk through Magento's built-in bundling system, how RequireJS works under the hood, and the concrete steps you can take to dramatically reduce JS overhead.

Why Magento 2 JS is Slow by Default

Magento 2 uses RequireJS (AMD module format) to load JavaScript dependencies on demand. This is a flexible system, but it comes with a significant downside in production: the browser has to make a waterfall of individual HTTP requests to resolve the dependency graph at runtime.

On a typical category page you'll see:

requirejs/require.js
requirejs-config.js
Dozens of individual *.js modules loaded on demand

Even with HTTP/2 multiplexing, this many round trips add up — especially on mobile or high-latency connections.

Step 1: Enable Production Mode

Before any JS optimisation makes sense, make sure you're running in production mode. Development mode intentionally skips most optimizations.

bin/magento deploy:mode:set production

In production mode Magento automatically:

Merges and minifies CSS
Deploys static assets to pub/static/
Enables RequireJS optimizer output

Run the full static content deploy after switching:

bin/magento setup:static-content:deploy -f en_US nl_NL

Step 2: Enable JavaScript Merging and Minification

In the Admin under Stores → Configuration → Advanced → Developer → JavaScript Settings, enable:

Setting	Value
Merge JavaScript Files	Yes
Enable JavaScript Bundling	Yes
Minify JavaScript Files	Yes

Or via CLI:

bin/magento config:set dev/js/merge_files 1
bin/magento config:set dev/js/enable_js_bundling 1
bin/magento config:set dev/js/minify_files 1
bin/magento cache:flush

⚠️ Note: Magento's built-in bundling creates a single large bundle per page type (homepage, category, product, etc.). This reduces request count dramatically but can increase initial payload size. Measure the impact with Lighthouse before and after.

Step 3: Understand the RequireJS Build System

Magento ships with an r.js optimizer workflow. When you run setup:static-content:deploy, Magento processes your requirejs-config.js files and can produce optimised bundles.

The key file is requirejs-config.js — each module can contribute to it via view/frontend/requirejs-config.js. Badly written third-party configs are often the source of JS bloat.

Check for conflicts or redundant map entries:

# Inspect the merged requirejs config for a theme
cat pub/static/frontend/Magento/luma/en_US/requirejs-config.js | python3 -m json.tool | grep -i "map\|paths\|shim" | wc -l

A healthy store should have a focused, clean config. If you're seeing hundreds of entries, a third-party module is likely over-declaring dependencies.

Step 4: Identify Your Heaviest JavaScript Files

Before blindly bundling, know what you're dealing with:

# Find the largest JS files in your static deploy
find pub/static/frontend -name "*.js" -not -name "*.min.js" \
  | xargs wc -c \
  | sort -rn \
  | head -20

Common heavy hitters:

jquery.js / jquery-ui.js — often loaded even when not needed on a page
mage/validation.js — heavy, only needed on checkout/forms
Magento_Catalog/js/product/view/ bundle — large on PDPs

Step 5: Use Advanced JS Bundling (Grunt-based)

Magento's default bundling is coarse-grained. For finer control, use the official Advanced JS Bundling approach with Grunt.

Install dependencies in the Magento root:

npm install
npm install -g grunt-cli

Create a bundle config targeting page types:

// Example: split bundles by page type
bundles: {
  'bundles/default': {
    include: [
      'jquery',
      'jquery/ui',
      'mage/apply/main',
      'mage/apply/scripts',
      'mage/common',
      'mage/dataPost',
      'mage/bootstrap'
    ],
    exclude: [],
    create: true
  },
  'bundles/catalog': {
    include: [
      'Magento_Catalog/js/view/compare',
      'Magento_Catalog/js/price-box',
      'Magento_Catalog/js/product/view/product.types.config'
    ],
    exclude: ['bundles/default'],
    create: true
  }
}

Run the bundling:

grunt exec:mage-build

This produces smaller, page-type-specific bundles so visitors only download what they need per page type.

Step 6: Defer Non-Critical JavaScript

Not all JS needs to block rendering. Use Magento's layout XML to defer scripts that don't need to run at parse time.

In your theme's default.xml:

<block class="Magento\Framework\View\Element\Html\Head\Script" name="my.deferred.script">
    <arguments>
        <argument name="file" xsi:type="string">js/my-script.js</argument>
        <argument name="attributes" xsi:type="string">defer</argument>
    </arguments>
</block>

For third-party blocks loaded in the footer, adding defer or async can shave hundreds of milliseconds off your Largest Contentful Paint (LCP).

Step 7: Lazy-Load Heavy Widgets

RequireJS's require() call is already lazy by nature, but make sure you're not eagerly loading heavy modules on every page. Audit your requirejs-config.js for deps entries — these are loaded eagerly on every page load regardless of whether the functionality is used.

// BAD — loads on every page
var config = {
    deps: ['Magento_SomeModule/js/heavy-widget']
};

// GOOD — only load when the DOM element exists
var config = {
    map: {
        '*': {
            'heavyWidget': 'Magento_SomeModule/js/heavy-widget'
        }
    }
};

Then trigger the load conditionally in your template:

require(['heavyWidget'], function(widget) {
    // Only runs when explicitly required
});

Step 8: Remove Unused Modules' JS

If you've disabled frontend modules (checkout steps, wishlists, product comparison), make sure their JavaScript isn't still being loaded. Use layout XML to remove blocks:

<referenceBlock name="some.js.block" remove="true"/>

Or disable the output of entire modules:

bin/magento module:disable Magento_Wishlist

Every module you disable removes its RequireJS config contributions and associated JS files from the dependency graph.

Measuring the Results

Use these tools to validate your work:

# Count JS requests on a page
curl -s https://yourstore.com/ | grep -o 'src="[^"]*\.js"' | wc -l

# Or use Lighthouse CI
npm install -g @lhci/cli
lhci autorun --collect.url=https://yourstore.com

Target metrics after optimization:

JS request count: < 10 (down from 80–120)
Total JS transfer size: < 300KB gzipped for above-the-fold
Time to Interactive (TTI): < 3.5s on 4G

Common Pitfalls

Bundling breaks checkout: Magento's checkout is notoriously sensitive. Always test the full checkout flow after enabling bundling. If you see JavaScript errors, a module is likely missing from the bundle config.

Cache must be flushed after every config change:

bin/magento cache:flush config full_page block_html

Static deploy must be re-run after any requirejs-config.js change — the merged config is written to pub/static/ at deploy time, not runtime.

Summary

Optimization	Impact	Effort
Production mode	High	Low
Merge + minify	High	Low
Built-in bundling	High	Low
Advanced Grunt bundling	Very High	Medium
Defer non-critical scripts	Medium	Low
Remove unused module JS	Medium	Medium
Lazy-load heavy widgets	Medium	Medium

JavaScript performance in Magento 2 isn't about one silver bullet — it's about layering these optimizations. Start with production mode and built-in bundling for immediate wins, then invest in advanced Grunt-based page-type bundling for the biggest long-term payoff.

Every millisecond you shave off JS execution translates directly to better conversion rates. Google's own data shows a 0.1s improvement in load time correlates with an 8% improvement in conversion. That's not a rounding error — that's real revenue.

DEV Community: Magevanta

Magento 2 Async Operations and Message Queues: A Performance Deep Dive

What Is the Message Queue Framework?

What Magento Already Uses Message Queues For

Architecture Overview

Setting Up RabbitMQ

Installation

Magento Configuration

Verify the Connection

Building a Custom Async Operation

Step 1: Define the Topic Schema

Step 2: Configure the Publisher

Step 3: Configure Topology (RabbitMQ)

Step 4: Define the Consumer

Step 5: Implement the Handler

Step 6: Publish from Your Event Observer

Running Consumers in Production

Supervisor Configuration

Key Consumer Options

Scaling Consumers

The Async Bulk Operations API

Monitoring Queue Health

RabbitMQ Management Console

CLI Monitoring

Alert on Queue Depth

Common Pitfalls and How to Avoid Them

Pitfall 1: Not Handling Failures

Pitfall 2: Running Consumers via Cron Only

Pitfall 3: Large Message Payloads

Pitfall 4: Ignoring Memory Limits

Quick Reference: When to Use Message Queues

Conclusion

Magento 2 Layout XML Performance: Trim Blocks, Speed Up Rendering

How Magento 2 Layout XML Works

Auditing Your Layout Tree

Enable Layout Debug Output

Use the Profiler

Programmatic Block Tree Inspection

The Top Performance Offenders

1. Blocks in default.xml with Heavy Constructors

2. Excessive Layout Handles

3. Widget Instances

4. Unnecessary <remove> Calls

5. _prepareLayout() Anti-Patterns

Block Caching: Your Most Powerful Tool

Adding Cache to a Block

Varnish + ESI for Partial Caching

Reducing Block Count in Critical Pages

Remove Default Magento Blocks You Don't Use

Defer Below-the-Fold Blocks

Layout XML Merge Caching

Practical Checklist

Measuring the Impact

Conclusion

Magento 2 Checkout Performance Optimization: Reduce Drop-offs and Speed Up Conversions

Why Is Magento 2 Checkout So Slow?

1. Enable and Tune Full Page Cache (Even for Checkout)

2. JavaScript Optimization for Checkout

Merge and Bundle JS

Use Advanced JS Bundling

Defer Non-Critical Scripts

3. Reduce AJAX Calls During Checkout

Customer Data Sections

Preload Shipping Rates

GraphQL for Checkout (Hyva / PWA)

4. Database Optimization for Quote Operations

Index Maintenance

Clean Up Expired Quotes

Add Missing Indexes

5. Payment Method Optimization

Audit Third-Party Payment Extensions

Load Payment SDKs Lazily

6. Server-Side Configuration

PHP Session Storage

Enable HTTP/2

7. Measure Before and After

Quick Wins Checklist

Conclusion

MySQL Query Cache vs Magento Cache: What's the Difference and When to Use Each

What Is MySQL Query Cache?

1. Blocks in `default.xml` with Heavy Constructors

4. Unnecessary `<remove>` Calls

5. `_prepareLayout()` Anti-Patterns

The `magento_customersegment_customer` Table

`wait_timeout` and `interactive_timeout`

`max_connections`