DEV Community: Magevanta

Magento 2 Third-Party Extension Performance Audit: Find and Fix Hidden Bottlenecks

Magevanta — Mon, 01 Jun 2026 09:03:06 +0000

Third-party extensions are a double-edged sword. They add capabilities that would take months to build in-house, but every additional module adds plugins, observers, layout blocks, and database queries to every page load. A store with 40 extensions installed could easily have 200+ extra interceptors firing on a single request — and most developers have no idea which ones are costing them.

This guide walks you through a systematic performance audit of your extension stack: how to measure the real cost of each module, what patterns cause the most damage, and how to fix (or quarantine) the worst offenders.

Why Extensions Are the #1 Performance Culprit

Before blaming infrastructure, consider that Magento's plugin (interceptor) system means any third-party module can silently wrap any public method in the entire core. When you install 10 extensions, each with 5–15 plugins, you can easily end up with:

100+ interceptors compiled into generated code
Additional database queries per request (EAV attribute loads, config reads, custom tables)
Extra layout XML blocks rendering widgets or tracking scripts
Observers attached to frequently-fired events like sales_quote_collect_totals_before

The worst part: these costs accumulate invisibly. No single extension looks bad in isolation, but together they drag TTFBs from 200ms to 2+ seconds.

Step 1: Baseline Your Current State

Before auditing anything, establish a baseline. You need hard numbers to compare against.

# Enable built-in profiler
php bin/magento dev:query-log:enable
php bin/magento cache:clean

Use a simple shell script to benchmark a representative page:

for i in {1..5}; do
  curl -s -o /dev/null -w "%{time_total}\n" \
    "https://yourstore.com/some-product.html"
done

Record your median response time for:

Homepage
Category page (with layered nav)
Product page
Checkout cart page

Also grab a database query count baseline from var/log/db.log or your APM tool. Knowing you're at 180 queries per page before the audit gives you something to beat.

Step 2: List Every Installed Extension

Get a clean list of all non-Magento modules:

php bin/magento module:status --enabled | grep -v "^Magento_" | grep -v "^List" | grep -v "^-"

For each module, note:

Vendor name and version
Last update date (stale = red flag)
Purpose (payment, shipping, analytics, CMS, etc.)
Whether it's business-critical or optional

Modules that haven't been updated in 2+ years deserve extra scrutiny. They often rely on deprecated APIs and haven't been optimized for modern PHP or Magento versions.

Step 3: Profile with Blackfire or the Built-in Profiler

The fastest way to see which extensions are expensive is to profile a real request.

Option A: Blackfire.io (Recommended)

Install the Blackfire agent and PHP probe on your staging server. Then:

blackfire curl https://yourstore.com/catalog/category/view/id/42

In the Blackfire UI, expand the call tree and look for:

Any vendor namespace taking >5% of wall time
Deep interceptor chains (Plugin > Plugin > Plugin...)
Repeated identical DB queries triggered from observers

Option B: Magento Built-in Profiler

Enable the Magento profiler in env.php:

'profiler' => [
    'class' => '\Magento\Framework\Profiler\Driver\Standard',
    'output' => 'html'
]

Or via env variable:

MAGE_PROFILER=html php -S localhost:8080 -t pub/ pub/index.php

This outputs a timing table at the bottom of each page showing which blocks, layouts, and observers are slow. It's less granular than Blackfire but zero-cost.

Option C: New Relic APM

If you have New Relic, filter transactions by slowest segments and expand to the code-level trace. Extension methods show up with their full class path, making identification trivial.

Step 4: Identify the Worst Offenders

After profiling, patterns to look for:

4.1 Plugin Chains on Critical Methods

Expensive plugin chains almost always appear on:

Magento\Catalog\Model\Product::getPrice
Magento\Quote\Model\Quote\Item\AbstractItem::calcRowTotal
Magento\Checkout\Model\Session::getQuote

If 3–4 extensions each add an around plugin to getPrice, the interception overhead compounds. Check generated/code/ for long plugin chains:

# Count plugins on a specific class
grep -r "aroundGetPrice\|beforeGetPrice\|afterGetPrice" generated/code/ | wc -l

More than 5–6 plugins on the same method is a warning sign.

4.2 Observer Storms on Quote Events

The worst offenders are often marketing/analytics extensions that attach to sales_quote_collect_totals_*, checkout_cart_product_add_after, or catalog_product_load_after. These events fire multiple times per request on the cart page.

Find all observers:

grep -r "<event name=" vendor/*/*/etc/events.xml app/code/*/etc/events.xml 2>/dev/null \
  | grep -v "Magento" \
  | awk -F: '{print $1}' | sort | uniq -c | sort -rn | head -20

This shows you which modules register the most event observers across the board.

4.3 Layout Block Injection on Every Page

Some extensions inject blocks into the default layout handle, meaning their block is instantiated on every page even if it doesn't render anything visible:

grep -r "<handle name=\"default\"" vendor/ app/code/ 2>/dev/null \
  | grep -v "Magento" | head -20

Even a block that renders nothing still triggers __construct, config reads, and occasionally DI-heavy factory calls.

4.4 Config Scoped Reads Without Cache

Look for extensions calling Magento\Framework\App\Config\ScopeConfigInterface::getValue in hot paths without memoization. Every uncached config read hits the config layer.

# Rough count of config reads per vendor
grep -r "scopeConfig->getValue" vendor/ \
  | grep -v "Magento/" \
  | awk -F/ '{print $2}' | sort | uniq -c | sort -rn | head -10

Step 5: Fix Strategies

5.1 Disable Non-Essential Modules for Testing

The fastest way to validate an extension is causing slowdown: disable it and retest.

php bin/magento module:disable Vendor_ModuleName
php bin/magento cache:flush
# benchmark again

If response time drops by >10% with a single module disabled, you've found a major culprit. You can then decide whether to:

Replace it with a lighter alternative
Optimize the specific slow path
Keep it but confine its scope

5.2 Replace `around` Plugins with `before`/`after`

If you control the extension code, around plugins are the most expensive interceptor type — they wrap the entire original method and prevent call chain optimizations. Wherever possible, convert to before or after:

// Instead of this:
public function aroundGetPrice(
    \Magento\Catalog\Model\Product $subject,
    callable $proceed
): float {
    $price = $proceed();
    return $price * $this->getMultiplier();
}

// Do this:
public function afterGetPrice(
    \Magento\Catalog\Model\Product $subject,
    float $result
): float {
    return $result * $this->getMultiplier();
}

This is especially impactful when the plugin fires in a loop (e.g., iterating over cart items).

5.3 Add Memoization to Repeated Method Calls

Many extensions calculate the same value (a config flag, a customer group check) dozens of times per request without caching the result:

class MyPlugin
{
    private ?bool $isEnabled = null;

    public function afterGetPrice(Product $subject, float $result): float
    {
        if ($this->isEnabled === null) {
            $this->isEnabled = $this->scopeConfig->isSetFlag('vendor/module/enabled');
        }
        if (!$this->isEnabled) {
            return $result;
        }
        // ... expensive logic
        return $result;
    }
}

Add a private ?type $cached = null; pattern to any value read inside a frequently-called plugin or observer.

5.4 Move Heavy Logic to Async or Cron

Analytics tracking, loyalty point calculations, and marketing syncs don't need to happen during the customer's request. Push them to a message queue:

// Instead of direct processing in observer:
public function execute(\Magento\Framework\Event\Observer $observer): void
{
    $this->messageQueue->publish('vendor.analytics.track', [
        'event' => 'product_view',
        'product_id' => $observer->getProduct()->getId(),
        'customer_id' => $this->customerSession->getCustomerId(),
    ]);
}

The queue consumer handles it asynchronously, keeping the customer-facing request lean.

5.5 Scope Layout XML to Specific Handles

If an extension's block only makes sense on the cart page, restrict it to the checkout_cart_index layout handle — not default:

<!-- vendor/Module/view/frontend/layout/checkout_cart_index.xml -->
<page xmlns:xsi="..." xsi:noNamespaceSchemaLocation="...">
    <body>
        <referenceContainer name="content">
            <block class="Vendor\Module\Block\Widget" name="vendor_widget"/>
        </referenceContainer>
    </body>
</page>

This alone can shave 10–30ms on every non-cart page.

Step 6: Ongoing Monitoring

A one-time audit isn't enough — extensions get updated, new ones get installed, and performance regressions creep in silently. Build these habits:

Benchmark on every deploy. Add a simple curl-based response time check to your CI pipeline. Alert if median TTFB increases by more than 15% on key pages.

Review the generated interceptor file on each module install. After php bin/magento setup:di:compile, check what's new in generated/code/Magento/ for your most critical classes.

Audit before you install. Before adding any extension from the Marketplace, check:

How many plugins does it register? (grep -r "type name=" etc/di.xml)
Does it modify high-traffic events?
Is it actively maintained?

Quick Reference: Audit Checklist

Check	Tool	Red Flag
Response time baseline	curl / wrk	>500ms TTFB on product page
Plugin count per critical class	grep generated/	>6 plugins on same method
Observer count per event	grep events.xml	>3 observers on quote events
Default layout injection	grep layout XML	Any non-Magento block in default
Stale extensions	composer show	Last update >2 years ago
DB queries per page	query log / Blackfire	>150 queries on category page

Wrapping Up

Third-party extension audits aren't glamorous, but they're often the highest-ROI performance work you can do on an established Magento 2 store. A single badly-written analytics plugin wrapping a core method can cost you 300ms per request across your entire catalog.

The process is straightforward: baseline, profile, identify, fix, and monitor. Start with your five slowest pages, trace the top three timing contributors in each, and work down the list. You'll likely find that 20% of your extensions are causing 80% of your extension-related overhead — and most of those issues have clean, targeted solutions.

Combine this audit with Magento's built-in profiling, Blackfire, or New Relic, and you'll have the data to make confident decisions about which extensions earn their place on your store.

Magento 2 Profiling & Performance Debugging: Find Bottlenecks Fast

Magevanta — Fri, 29 May 2026 09:02:46 +0000

Performance issues in Magento 2 are rarely obvious. A page that takes 4 seconds might be suffering from a single misconfigured plugin, a runaway EAV query, or a third-party module making 200 redundant cache reads. Without proper profiling tools, you're flying blind — guessing, commenting out code, and hoping for the best.

This guide walks through the full profiling toolkit for Magento 2: from quick built-in options to professional-grade APM tools like Blackfire and New Relic. You'll learn what to use, when to use it, and how to interpret the results.

Why Generic Profiling Isn't Enough

Magento 2 is a complex, event-driven framework with hundreds of plugins, observers, and DI-compiled classes running on every request. A standard PHP profiler shows you call stacks, but doesn't give context about why something is slow.

You need tools that understand:

The plugin/interceptor chain
DI container overhead
MySQL query patterns (N+1, full scans)
Cache hit/miss ratios
Layout XML parsing and block rendering

Let's start simple and work up to the heavy artillery.

1. Magento's Built-in Profiler

Magento ships with a lightweight built-in profiler you can enable without any extra tooling. It's ideal for quick debugging in local and staging environments.

Enable via environment variable

# In your .htaccess or nginx config
MAGE_PROFILER=html

# Or via pub/index.php temporarily
$_SERVER['MAGE_PROFILER'] = 'html';

Or set it in app/etc/env.php:

'x-frame-options' => 'SAMEORIGIN',
'MAGE_MODE' => 'developer',
'dev' => [
    'profiler' => '1'
],

Once enabled, a profiler table appears at the bottom of each page showing timer blocks, nesting levels, and call counts. Look for:

Blocks with high "Avg" time and low call counts (expensive single operations)
Blocks called hundreds of times (loop inefficiency or plugin waterfalls)

Custom profiler blocks in your own code

use Magento\Framework\Profiler;

Profiler::start('my_custom_operation');
// ... your code
Profiler::stop('my_custom_operation');

This is great for benchmarking specific methods during development without a full APM setup.

2. MySQL Query Logging

Slow queries are the most common bottleneck in Magento. Enable MySQL slow query logging to capture them:

-- In MySQL session or my.cnf
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
SET GLOBAL log_queries_not_using_indexes = 'ON';

Then analyze with mysqldumpslow or pt-query-digest:

# Group by query pattern, sort by total time
pt-query-digest /var/log/mysql/slow.log --limit 20

Magento's query log via Varien_Db

In developer mode, you can also log all queries Magento executes. Or use a custom plugin on Magento\Framework\DB\Adapter\Pdo\Mysql::query() to log slow queries with their origin (class + method).

Spotting N+1 patterns

The classic N+1 problem in Magento looks like this in your logs:

SELECT * FROM catalog_product_entity WHERE entity_id = 42
SELECT * FROM catalog_product_entity WHERE entity_id = 43
SELECT * FROM catalog_product_entity WHERE entity_id = 44
... (200 more)

Fix: use addAttributeToSelect('*') on collections and load them in bulk, or leverage the product repository with proper filtering.

3. Blackfire.io — The Gold Standard

Blackfire is the professional choice for PHP profiling. It integrates natively with Magento 2 and produces call graphs that reveal exactly where time and memory are spent.

Installation

# Install Blackfire PHP extension
curl -sS https://packages.blackfire.io/gpg.key | sudo apt-key add -
echo "deb http://packages.blackfire.io/debian any main" | sudo tee /etc/apt/sources.list.d/blackfire.list
sudo apt-get update && sudo apt-get install blackfire-php blackfire

# Configure credentials
blackfire agent:config

Add to your php.ini:

extension=blackfire.so
blackfire.agent_socket=tcp://127.0.0.1:8307

Profile a page

blackfire curl https://yourstore.local/catalog/category/view/id/5

Or use the browser extension for GUI-driven profiling with comparison between runs.

Reading the call graph

Blackfire generates an interactive flame graph. Key metrics to watch:

Metric	What it means
Wall time	Real elapsed time
CPU time	Processing time (excludes I/O waits)
I/O time	Disk/network waits (usually DB or cache)
Memory	Peak memory per call
Calls	How many times a function was invoked

Focus on nodes with high exclusive time (time spent in that function itself, not its children). A function called 1,000 times with 0.1ms each adds up to 100ms — often invisible until you see the call count.

Blackfire builds & assertions

For CI/CD pipelines, define performance budgets:

# .blackfire.yaml
tests:
  "Homepage must be fast":
    path: /
    assertions:
      - "main.wall_time < 800ms"
      - "metrics.sql.queries.count < 30"
      - "metrics.cache.read.count < 100"

This fails the build if the homepage regresses beyond your defined thresholds.

4. New Relic APM

New Relic is better suited for production monitoring and long-term trend analysis. Where Blackfire is surgical (profile this specific request), New Relic is epidemiological (what's slow across thousands of requests).

Install the PHP agent

curl -L https://download.newrelic.com/php_agent/release/newrelic-php5-*.tar.gz | tar -xz
sudo ./newrelic-install install

Configure in newrelic.ini:

newrelic.appname = "Magento Production"
newrelic.license = "YOUR_LICENSE_KEY"
newrelic.transaction_tracer.enabled = true
newrelic.transaction_tracer.threshold = 500ms
newrelic.slow_sql.enabled = true

What to watch in New Relic

Transaction traces — drill into the slowest requests over time. New Relic shows the full call stack including DB queries, external calls, and cache operations.

Apdex score — a customer satisfaction metric. Target > 0.9 for Magento stores. Anything below 0.7 needs immediate attention.

Database tab — shows the slowest SQL queries across all transactions, with execution plans and call frequency.

Custom attributes — add Magento-specific context:

if (extension_loaded('newrelic')) {
    newrelic_add_custom_parameter('customer_group', $customerGroup);
    newrelic_add_custom_parameter('store_id', $storeId);
    newrelic_add_custom_parameter('cache_hit', $cacheHit ? 'yes' : 'no');
}

5. Tideways — APM Built for PHP Frameworks

Tideways is worth mentioning as a Magento-aware alternative to New Relic. It understands Magento's MVC structure and groups transactions by controller action automatically. Setup is similar to Blackfire — install the PHP extension, configure credentials, and it starts collecting data passively.

6. The Xdebug + KCachegrind Combo (Local Only)

For deep local debugging, Xdebug's profiling mode generates Cachegrind files visualizable with KCachegrind or QCachegrind:

; php.ini
xdebug.mode = profile
xdebug.output_dir = /tmp/xdebug
xdebug.profiler_output_name = cachegrind.out.%t.%p

Trigger with: ?XDEBUG_PROFILE=1 on a request URL.

Open the .cachegrind file in KCachegrind to see a full call tree with inclusive/exclusive times.

⚠️ Never enable Xdebug profiling in production — it adds massive overhead and generates large files.

Practical Debugging Workflow

Here's a proven workflow when a Magento page is suddenly slow:

Check obvious causes first — deployment recently? New module? Config cache cleared?
Enable MySQL slow query log and check for expensive queries
Blackfire profile the slow page — look at exclusive times > 50ms
Check the plugin chain on hot paths (e.g., catalog_product_load_after observers)
Profile again with the fix — compare Blackfire runs side by side
Add a Blackfire assertion to prevent regression

Quick wins to check first

Before deep profiling, verify these common culprits:

# Check OPcache is enabled and warm
php -r "var_dump(opcache_get_status()['opcache_enabled']);"

# Check Redis connectivity and hit ratio
redis-cli INFO stats | grep keyspace

# Check if Magento caches are enabled
bin/magento cache:status

# Check for runaway cron jobs
bin/magento cron:status

Profiling in CI/CD

Automate performance regression detection with Blackfire in your pipeline:

# GitHub Actions example
- name: Run Blackfire performance tests
  run: |
    blackfire curl --json https://staging.yourstore.com/ \
      --assert "main.wall_time < 1s"

This prevents performance regressions from reaching production undetected — the same way unit tests prevent functional regressions.

Summary

Tool	Best for	Environment
Built-in Profiler	Quick timer blocks	Dev/staging
MySQL slow log	Query-level analysis	All
Blackfire	Surgical code profiling	Dev/staging/CI
New Relic	Production monitoring	Production
Xdebug + KCachegrind	Deep call graph analysis	Dev only

Profiling is a skill that compounds over time. The more you profile, the faster you'll spot patterns — that suspicious 300ms block in Magento\Catalog\Model\ResourceModel\Product\Collection::load, the plugin interceptor chain that fires 40 times per request, or the layout XML file that parses 200KB of XML on every uncached page load.

Start with the built-in profiler and MySQL logs. Graduate to Blackfire when you need precision. Use New Relic in production to catch what you missed. And always — always — profile before and after any optimization to prove it actually helped.

Magento 2 Static Content Deploy Optimization: Faster Builds, Fewer Headaches

Magevanta — Thu, 28 May 2026 09:02:32 +0000

Static content deployment is one of the most time-consuming steps in a Magento 2 release pipeline. On a large store with multiple themes, locales, and hundreds of modules, setup:static-content:deploy can take anywhere from five minutes to over thirty. That's thirty minutes of downtime risk, blocked deployments, and frustrated developers staring at a progress bar.

This guide covers every lever available to you: parallelization, scoped deploys, strategy selection, content versioning, and how to integrate all of this into a zero-downtime CI/CD pipeline.

Why Static Content Deploy Is Slow

Before optimizing, understand the problem. When you run bin/magento setup:static-content:deploy, Magento does the following for every theme/locale combination:

Resolves all Less/CSS source files, compiling them with the configured strategy
Copies or symlinks JavaScript, images, and fonts from modules and themes
Generates RequireJS configuration files
Applies translations to JS files per locale
Publishes everything to pub/static/

On a store with 3 themes × 5 locales, that's 15 combinations — each requiring full resolution of the entire asset tree. Add 200+ modules and you start to understand why it takes so long.

1. Parallelize With `-j`

The single most impactful flag is -j (jobs), which controls parallelism:

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

By default, Magento deploys each theme/locale combination sequentially. With -j 4, it runs four processes in parallel. Set this to the number of available CPU cores — or slightly above for I/O-bound operations:

# Detect CPU count and use it
CORES=$(nproc 2>/dev/null || sysctl -n hw.ncpu 2>/dev/null || echo 4)
bin/magento setup:static-content:deploy -f -j $CORES

On a 4-core server this alone can cut deploy time by 60-70%. On 8 cores, the gains compound further.

Caution: Don't blindly set -j 16 on a 4-core server. You'll swap memory and end up slower. Match cores to available resources.

2. Scope Your Deploy: Only What You Need

Deploying every theme and locale is wasteful if your store only uses a subset. Scope it explicitly:

bin/magento setup:static-content:deploy \
  -f \
  -j 4 \
  --theme Magento/luma \
  --theme Vendor/custom-theme \
  nl_BE en_US fr_BE

Pass themes with --theme and list locales as space-separated arguments at the end. This is dramatically faster than the default "everything" approach.

Pro tip: Define these in a deploy script variable so they're centrally maintained:

THEMES="--theme Vendor/custom-theme --theme Magento/backend"
LOCALES="nl_BE en_US fr_BE de_DE"

bin/magento setup:static-content:deploy -f -j 4 $THEMES $LOCALES

Never include Magento/blank in production deploys unless a theme directly extends it without adding any customizations — even then, the admin theme covers most of its use cases.

3. Choose the Right Deploy Strategy

Magento offers three static content deploy strategies, configurable via --strategy:

`quick` (default since 2.3)

bin/magento setup:static-content:deploy --strategy=quick

Deploys files once and symlinks duplicates. Fast, low disk usage. Best for most production stores.

`compact`

bin/magento setup:static-content:deploy --strategy=compact

Similar to quick but with a slightly different deduplication approach. Marginally slower but produces smaller output on disk. Use it when disk space is constrained.

`standard`

bin/magento setup:static-content:deploy --strategy=standard

Copies every file for every theme/locale combination without deduplication. Produces the largest output but is the most compatible. Only use this if you're seeing symlink-related issues with quick.

For 99% of stores, quick is the right choice. If you're still on the standard default, switching to quick alone can cut deploy time significantly.

4. Use `--no-html-minify` During Development

HTML minification of static templates adds time with minimal benefit in development contexts. Skip it:

bin/magento setup:static-content:deploy -f --no-html-minify

In production you want minification, but for staging pipelines where you're iterating on deploys, skipping it saves time.

5. Deploy Admin Separately

The Magento admin (Magento/backend) has its own asset tree. In a pipeline with a custom frontend theme, deploying admin and frontend in sequence wastes time. Structure it to run in parallel:

# Run both in parallel background processes
bin/magento setup:static-content:deploy -f -j 2 \
  --theme Vendor/custom-theme nl_BE en_US fr_BE &

bin/magento setup:static-content:deploy -f -j 2 \
  --theme Magento/backend en_US &

wait
echo "Both deploys complete"

This lets your CI server use all cores across both operations simultaneously.

6. Content Versioning Strategy

Every static content deploy generates a new version ID, which busts the browser cache. This is good for cache invalidation but means users re-download all assets after every deploy — even if nothing changed.

Check the current version:

cat pub/static/deployed_version.txt

For deployments where static assets haven't changed, you can preserve the existing version:

# Only redeploy if source files changed
if git diff HEAD~1 --name-only | grep -qE '(view/|web/|layout/)'; then
  bin/magento setup:static-content:deploy -f -j 4 $THEMES $LOCALES
else
  echo "No static asset changes — skipping deploy"
fi

This is powerful in trunk-based development where most commits are backend-only.

7. Warm `pub/static` Before Cutting Traffic

Never cut traffic to a new release before static content is deployed. Structure your pipeline correctly:

# 1. Deploy code
git pull origin main

# 2. Run database upgrades (maintenance mode on)
bin/magento maintenance:enable
bin/magento setup:upgrade --keep-generated

# 3. Deploy static content (maintenance still on)
bin/magento setup:static-content:deploy -f -j 4 $THEMES $LOCALES

# 4. Compile DI
bin/magento setup:di:compile

# 5. Disable maintenance and flush cache
bin/magento maintenance:disable
bin/magento cache:flush

The key insight: setup:static-content:deploy writes to pub/static/ which is served directly by nginx. As soon as the files are there, they're live — even before maintenance mode is disabled. This means your CDN/Varnish can start warming the new assets while the site is still in maintenance.

8. Symlink Mode for Development

On local development environments, deploying static content on every change is a workflow killer. Switch to developer mode:

bin/magento deploy:mode:set developer

In developer mode, Magento resolves static assets on-the-fly using symlinks into module view/ directories. No deploy step needed after every Less change. Use grunt watch or the built-in Less compiler to compile CSS automatically.

For a middle ground on staging — faster than full deploy but closer to production — use:

bin/magento deploy:mode:set default
bin/magento setup:static-content:deploy -f --symlink-locale $THEMES $LOCALES

9. CI/CD Integration: Build Once, Distribute Many

If your CI pipeline deploys to multiple identical servers (horizontal scaling), you don't need to run setup:static-content:deploy on each one. Run it once, tar the output, and distribute:

# On build server
bin/magento setup:static-content:deploy -f -j 8 $THEMES $LOCALES
tar -czf static-content-$(git rev-parse --short HEAD).tar.gz pub/static/

# On each web server
tar -xzf static-content-${GIT_SHA}.tar.gz

This approach:

Ensures all servers have identical static content (no race conditions)
Cuts total deploy time proportional to the number of web servers
Allows content to be pre-warmed before servers receive traffic

Store the tarball in your artifact repository (S3, GitHub Packages, Artifactory) with the commit SHA as the identifier. If a rollback is needed, fetch the previous artifact rather than rerunning the deploy.

10. Monitor Deploy Times

Track setup:static-content:deploy duration over time. A sudden spike usually signals:

A new module with a large web/ directory
A Less compilation error causing retries
An accidental addition of an extra locale
Disk I/O saturation on the build server

Add timing to your deploy scripts:

START=$(date +%s)
bin/magento setup:static-content:deploy -f -j 4 $THEMES $LOCALES
END=$(date +%s)
echo "Static deploy took $((END - START))s"

Feed these metrics into your monitoring system (Datadog, Grafana, or even a simple log file) so you can correlate deploy time growth with specific releases.

Benchmark: What to Expect

Here's a rough guide for a mid-sized store (2 themes, 3 locales, ~200 modules):

Configuration	Approximate Time
Default (sequential, standard strategy)	18–25 min
`-j 4`, `quick` strategy	6–9 min
`-j 8`, scoped locales, `quick`	3–5 min
Distributed build (tarball)	< 1 min per server

The gains from parallelization and strategy selection are real and significant. There's no reason to accept a 20-minute deploy window when the same output can be generated in under five.

Key Takeaways

Static content deployment doesn't have to be the bottleneck it is for most teams. The biggest wins:

Use -j with your core count — this alone is transformative
Scope themes and locales — don't deploy what you don't use
Use quick strategy — it's the default for a reason, but many older stores still run standard
Separate admin from frontend and run them in parallel
Build once, distribute many in horizontally-scaled environments
Skip redeploys when static assets haven't changed

Apply these together and your 20-minute deploy window shrinks to under five minutes — leaving more time for shipping features instead of waiting on build pipelines.

Magento 2 Nginx Optimization for High Traffic — Complete Server Tuning Guide

Magevanta — Wed, 27 May 2026 09:02:49 +0000

Your Magento store can have perfect PHP-FPM pools, well-tuned Redis, and optimized MySQL — and still buckle under load because Nginx is configured with defaults meant for a blog, not an ecommerce platform. Nginx is the front door to your entire stack. If it's slow, everything behind it is slow.

This guide walks through every lever worth pulling: connection handling, compression, caching headers, microcaching, SSL/TLS, and real-world configs for a Magento 2 production server.

Why Nginx Defaults Aren't Enough

Out-of-the-box Nginx ships with conservative defaults:

worker_processes 1 — single worker, ignoring your CPU cores
No gzip compression enabled
Keepalive timeouts that force reconnects
No browser cache headers
TLS handshakes that repeat work they don't need to

For a low-traffic site this doesn't matter. For Magento — which serves category pages, product pages, checkout flows, and API calls simultaneously — these defaults become bottlenecks at a few hundred concurrent users.

1. Worker Processes and Connections

Start at the top of nginx.conf:

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 4096;
    use epoll;
    multi_accept on;
}

worker_processes auto — Nginx will match the number of workers to available CPU cores. A 4-core server gets 4 workers.

worker_rlimit_nofile 65535 — raises the OS file descriptor limit per worker. Each active connection uses a file descriptor; the default of 1024 is dangerously low for production.

worker_connections 4096 — maximum connections per worker. Total concurrent connections = worker_processes × worker_connections. On a 4-core server: 16,384 concurrent connections max.

use epoll — Linux-only but highly efficient; scales better than select or poll under thousands of connections.

multi_accept on — workers accept all pending connections at once instead of one at a time.

2. Gzip Compression

Magento pages are large: HTML pages often exceed 100KB before JS and CSS. Gzip cuts transfer sizes by 60–80%:

http {
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 5;
    gzip_min_length 1000;
    gzip_types
        text/plain
        text/css
        text/xml
        text/javascript
        application/javascript
        application/x-javascript
        application/json
        application/xml
        application/xml+rss
        application/vnd.ms-fontobject
        font/eot
        font/otf
        font/ttf
        image/svg+xml;
}

gzip_comp_level 5 — the sweet spot. Level 9 uses ~30% more CPU for only ~2% better compression. Level 5 is fast and effective.

gzip_vary on — adds a Vary: Accept-Encoding header so CDNs and proxies serve the right version to each client.

gzip_min_length 1000 — don't bother compressing tiny responses; overhead outweighs benefit below ~1KB.

3. Keepalive and Timeouts

Keepalive connections let the browser reuse TCP connections for multiple requests, eliminating repeated TCP handshakes:

http {
    keepalive_timeout 65;
    keepalive_requests 100;

    # Upstream keepalive to PHP-FPM
    upstream fastcgi_backend {
        server unix:/run/php/php8.3-fpm.sock;
        keepalive 32;
    }
}

keepalive_timeout 65 — hold connections open for 65 seconds. Fine for most workloads; reduce to 15–30 on memory-constrained servers.

keepalive 32 in the upstream block — keeps up to 32 persistent connections open to PHP-FPM, avoiding socket overhead on every PHP request.

Also tune these to avoid slow clients tying up workers:

client_header_timeout 15;
client_body_timeout  15;
send_timeout         15;
reset_timedout_connection on;

4. Browser Cache Headers for Static Assets

Magento's static files (JS, CSS, images, fonts) are versioned via deploy version hashes. Set aggressive caching:

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

immutable tells supporting browsers (Chrome, Firefox) to never re-validate the file during its lifetime — eliminating conditional GET requests entirely.

access_log off for static assets reduces disk I/O significantly on busy servers.

5. Microcaching with FastCGI Cache

Full Page Cache (Varnish or Magento built-in) handles authenticated sessions poorly by design. Microcaching fills the gap: cache PHP responses for just 1–5 seconds. At 500 req/s, a 1-second cache reduces PHP hits by ~99% for repeated URLs.

Define a cache zone in nginx.conf:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=MAGENTO:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

In your server block:

set $no_cache 0;

# Don't cache POST requests
if ($request_method = POST) { set $no_cache 1; }

# Don't cache if session cookie present (logged-in users, active cart)
if ($http_cookie ~* "(PHPSESSID|frontend|adminhtml|checkout)") {
    set $no_cache 1;
}

location ~ \.php$ {
    fastcgi_cache MAGENTO;
    fastcgi_cache_valid 200 1s;
    fastcgi_cache_bypass $no_cache;
    fastcgi_no_cache $no_cache;
    add_header X-FastCGI-Cache $upstream_cache_status;

    include fastcgi_params;
    fastcgi_pass fastcgi_backend;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

The X-FastCGI-Cache header lets you verify HIT/MISS/BYPASS in response headers — essential for debugging. If you see BYPASS on every request, check that your cookie exclusions are correct.

Important: Do not use microcaching in place of proper FPC. Use it as a complement for high-burst traffic windows (flash sales, launches).

6. SSL/TLS Performance

TLS termination at Nginx is unavoidable on HTTPS-only stores. Tune it to minimize handshake overhead:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;  # Disable for perfect forward secrecy

ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

ssl_session_cache shared:SSL:10m — a 10MB shared cache holds ~40,000 sessions, allowing TLS resumption (no full handshake for returning visitors).

OCSP stapling (ssl_stapling on) — Nginx fetches and caches the certificate validity check, so your clients don't have to. Eliminates one round-trip per new connection.

TLSv1.3 — if you can drop TLSv1.2 entirely (verify your CDN and payment providers support it), TLSv1.3 does a full handshake in 1 round trip vs. 2.

7. Buffer Tuning

Large Magento responses (admin grids, product list pages) benefit from proper buffer settings:

client_body_buffer_size 128k;
client_max_body_size    64m;   # Required for media imports

proxy_buffer_size          4k;
proxy_buffers            4 32k;
proxy_busy_buffers_size  64k;

fastcgi_buffers          16 16k;
fastcgi_buffer_size      32k;

fastcgi_buffers 16 16k — 256KB total buffer per request. Enough for most Magento pages without disk buffering.

If a page exceeds fastcgi_buffers, Nginx writes the overflow to a temp file — adding disk I/O to every large response. Set this high enough to avoid it.

8. Rate Limiting for Admin and API

Protect your admin panel and REST API from brute-force and abuse:

# Define zones in http block
limit_req_zone $binary_remote_addr zone=admin:10m rate=5r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;

# Apply in server block
location /admin {
    limit_req zone=admin burst=10 nodelay;
    # ... rest of config
}

location /rest {
    limit_req zone=api burst=50 nodelay;
    # ... rest of config
}

burst allows short spikes above the rate. nodelay processes burst requests immediately instead of queuing them — important for API clients that batch requests.

9. Monitoring What You've Done

After applying changes, verify with:

# Test config before reloading
nginx -t

# Reload without dropping connections
nginx -s reload

# Watch real-time connection states
ss -s

# Check cache hit rate (tail access log with cache status)
tail -f /var/log/nginx/access.log | grep 'X-Cache'

Use ab (ApacheBench) or wrk for quick load tests before and after:

# 1000 requests, 50 concurrent
ab -n 1000 -c 50 https://your-store.com/

Putting It All Together

Nginx optimization is one of the highest-leverage things you can do for a Magento store: it affects every single request before PHP even runs. The changes above — workers, gzip, keepalive, browser cache, microcaching, TLS tuning, and buffers — consistently yield 2–4× improvement in requests-per-second capacity on the same hardware.

Start with worker_processes auto and gzip (both zero-risk changes), then profile with a load test before adding microcaching, which requires careful cookie exclusion to avoid caching user-specific content.

The full picture: Nginx handles connections and serves static files; Varnish or Magento FPC serves full pages; Redis caches sessions and blocks; PHP-FPM processes what's left. Each layer does its job. Nginx's job is to be fast and efficient at the very edge — don't let defaults undermine the rest of your stack.

Magento 2 B2B Performance Optimization: Shared Catalogs, Quotes & Company Accounts

Magevanta — Tue, 26 May 2026 09:03:16 +0000

Adobe Commerce B2B unlocks powerful functionality for wholesale and enterprise merchants — company accounts, shared catalogs, negotiable quotes, quick order, and requisition lists. But these features come with a significant performance cost if left unconfigured. In this post we dig into the most common B2B bottlenecks and how to systematically address each one.

Why B2B Is Different from B2C

Standard Magento 2 performance advice — Redis caching, Varnish, OPcache, flat tables — still applies to B2B. But B2B merchants face a set of additional challenges:

Shared catalogs create per-company product visibility rules that bypass the standard catalog cache.
Negotiable quotes generate large quote objects with complex price recalculations on every update.
Company hierarchies add permission checks to nearly every storefront request for logged-in users.
Requisition lists issue repeated save/load queries against the negotiable_quote and requisition_list tables.

The result: B2B storefronts often run 2–4× slower than equivalent B2C stores with no additional configuration.

1. Shared Catalog — The Hidden Query Bomb

Shared catalogs work by filtering product visibility per company via the shared_catalog_product_item table. Each catalog page load for a logged-in B2B customer hits this table with large JOIN queries.

What to profile

Run EXPLAIN on a category page query with shared catalogs enabled:

EXPLAIN SELECT e.entity_id, e.sku, e.name
FROM catalog_product_entity e
INNER JOIN shared_catalog_product_item sci
  ON sci.sku = e.sku AND sci.customer_group_id = 5
WHERE e.status = 1;

Missing indexes on (sku, customer_group_id) are the most common culprit.

Fixes

Add a composite index if it's missing (check your version — Adobe Commerce 2.4.5+ has this):

ALTER TABLE shared_catalog_product_item
  ADD INDEX IDX_SKU_GROUP (sku, customer_group_id);

Enable flat catalog for B2B stores with large catalogs (>50k SKUs). Despite being deprecated, flat tables still dramatically reduce EAV JOINs on category pages:

bin/magento config:set catalog/frontend/flat_catalog_product 1
bin/magento config:set catalog/frontend/flat_catalog_category 1
bin/magento indexer:reindex catalog_product_flat catalog_category_flat

Limit shared catalog depth. Every additional custom catalog multiplies reindex time and query complexity. Audit whether all catalogs are actually in use:

SELECT id, name, customer_group_id, created_at
FROM shared_catalog
ORDER BY created_at DESC;

Delete or merge unused catalogs via the Admin panel before they compound the problem.

2. Negotiable Quotes — Price Recalculation Is Expensive

Negotiable quotes are notorious for triggering full cart recalculations. Every time a sales rep adjusts a line item, Magento recalculates the entire quote: shipping estimates, tax, discounts, custom prices. On quotes with 200+ line items this can take 10–30 seconds.

Reduce recalculation triggers

In app/etc/config.php or via Admin, limit quote recalculation to explicit submit actions rather than on every save:

Stores → Configuration → B2B Features → Default B2B Payment Methods

More importantly, disable automatic quote totals recalculation on every admin edit. Patch the Magento\NegotiableQuote\Model\Quote\Totals class via a plugin to defer recalculation:

// Plugin: defer recalculation to explicit recalculate() call only
public function aroundRecalculateQuote(
    \Magento\NegotiableQuote\Model\Quote\Totals $subject,
    callable $proceed,
    bool $force = false
): void {
    if ($force) {
        $proceed($force);
    }
    // Skip automatic recalculation triggered by save events
}

Apply carefully and test pricing accuracy thoroughly.

Index and archive old quotes

The quote and negotiable_quote tables grow unbounded on active B2B stores. Queries slow down as these tables exceed millions of rows.

-- Find quotes older than 6 months that are closed/declined
SELECT COUNT(*) FROM negotiable_quote nq
INNER JOIN quote q ON q.entity_id = nq.quote_id
WHERE nq.status IN ('closed', 'declined')
  AND q.updated_at < DATE_SUB(NOW(), INTERVAL 6 MONTH);

Archive or purge stale quotes on a regular schedule using a custom cron job. Adobe Commerce does not do this automatically.

3. Company Account Permission Checks

Every request from a logged-in B2B user triggers a company permission check via Magento\Company\Model\Authorization. On storefronts with complex role hierarchies (company → division → user), this becomes expensive.

Cache company permissions

Company permission data changes rarely. Add a Redis-backed cache layer:

// In your around plugin on CompanyManagement::getByCustomerId()
$cacheKey = 'company_user_' . $customerId;
$cached = $this->cache->load($cacheKey);
if ($cached) {
    return $this->serializer->unserialize($cached);
}
$result = $proceed($customerId);
$this->cache->save(
    $this->serializer->serialize($result),
    $cacheKey,
    ['company_permissions'],
    3600
);
return $result;

Invalidate the tag company_permissions on company/role changes via an observer on company_save_after.

Minimize role tree depth

Deeply nested company structures (5+ levels) multiply permission checks. Encourage merchants to keep hierarchies flat: company → department → user (3 levels maximum). Beyond that, query count grows exponentially.

4. Requisition Lists — Silent Scalability Problem

Requisition lists seem lightweight but they issue a database read on every storefront visit for logged-in B2B users. Customers with 20+ requisition lists of 100+ items each generate dozens of queries per page.

Lazy-load requisition list counts

The storefront header displays a requisition list count. By default this is loaded synchronously. Move it to a separate AJAX call that runs after page load:

<!-- layout/default.xml -->
<block class="Magento\RequisitionList\Block\RequisitionList\Counter"
       name="requisition.list.counter"
       template="Magento_RequisitionList::counter.phtml">
    <arguments>
        <argument name="lazy_load" xsi:type="boolean">true</argument>
    </arguments>
</block>

Implement the lazy-load controller endpoint at requisition_list/ajax/count and update the template to defer via fetch().

Paginate large requisition lists

A single requisition list with 500 items forces Magento to load all items before rendering. Add server-side pagination in your custom module:

$collection = $this->requisitionListItemRepository
    ->getList($searchCriteria->setPageSize(50)->setCurrentPage($page));

This alone can reduce TTFB on the requisition list page from 4s to under 800ms for large lists.

5. B2B Indexer Performance

B2B adds several indexers that run on top of the standard Magento indexers:

shared_catalog_product_price — runs on every shared catalog change
b2b_company_structure — rebuilds company trees
negotiable_quote_grid — refreshes the admin quote grid

These indexers are not always set to Update on Schedule out of the box.

Force schedule mode for all B2B indexers

bin/magento indexer:set-mode schedule shared_catalog_product_price
bin/magento indexer:set-mode schedule b2b_company_structure
bin/magento indexer:set-mode schedule negotiable_quote_grid

Verify the result:

bin/magento indexer:status | grep -E "shared_catalog|b2b_company|negotiable"

All B2B indexers should show Update by Schedule.

6. HTTP Cache Strategy for B2B

Full-page caching is effectively disabled for logged-in B2B customers — they see personalized catalogs, prices, and credit limits. This means your origin servers absorb every B2B request.

Session-less catalog pages

For large B2B stores, build a "guest view" of catalog pages that is FPC-cacheable, with personalized data (price, availability) loaded via AJAX after page paint. This is the same technique used in B2C "hole punching" but applied more aggressively.

HTTP/2 push for critical B2B assets

B2B pages load more JavaScript (quote widget, company menu, requisition controls). Configure Nginx or your CDN to HTTP/2 push core B2B JS bundles:

location = /b2b-account {
    http2_push /pub/static/frontend/Magento/luma/en_US/Magento_NegotiableQuote/js/quote.min.js;
    http2_push /pub/static/frontend/Magento/luma/en_US/Magento_Company/js/company.min.js;
}

7. Monitoring B2B Performance

Standard APM tools miss B2B-specific slow paths. Add custom instrumentation:

// In a plugin on NegotiableQuoteManagement::send()
$startTime = microtime(true);
$result = $proceed(...$args);
$elapsed = microtime(true) - $startTime;
if ($elapsed > 2.0) {
    $this->logger->warning('Slow negotiable quote send', [
        'quote_id' => $quoteId,
        'elapsed_ms' => round($elapsed * 1000),
    ]);
}
return $result;

Track and alert on:

Negotiable quote recalculation time > 3s
Shared catalog reindex duration > 5 min
Requisition list page TTFB > 1s

Summary: B2B Performance Checklist

Area	Action	Impact
Shared catalog	Add composite index on `(sku, customer_group_id)`	High
Shared catalog	Archive unused catalogs	Medium
Negotiable quotes	Defer auto-recalculation	High
Negotiable quotes	Archive closed/declined quotes	Medium
Company permissions	Cache per-user permission data in Redis	High
Company structure	Keep hierarchy ≤ 3 levels deep	Medium
Requisition lists	Lazy-load header counter	Medium
Requisition lists	Paginate large lists	High
B2B indexers	Set all to `Update by Schedule`	High
HTTP caching	AJAX-load personalized data, cache catalog shell	High

B2B performance is not a single-fix problem — it requires work across the stack. Start with indexer modes and the shared catalog index, as those yield the highest return with the lowest risk. Then work through quote archiving and company permission caching. With these changes in place, most B2B storefronts can achieve sub-second category pages even under authenticated load.

Magento 2 Cache Warming Strategies: Keep Your Store Fast After Every Deploy

Magevanta — Sun, 24 May 2026 09:02:09 +0000

You've spent weeks tuning your Magento 2 Full Page Cache. Varnish is configured, FPC hit rates are above 90%, and your TTFB is under 200ms. Then you deploy a hotfix at 2 AM and flush the cache. Suddenly, every customer who visits gets a cold, uncached response — PHP bootstrapping, layout building, block rendering — the full stack, for every single request.

This is the cold cache problem, and it's one of the most overlooked performance gaps in Magento 2 operations. Cache warming is the solution: proactively generating cached responses before real users arrive.

Why Cache Warming Matters

Magento 2's Full Page Cache is lazy by default. A page only gets cached after the first request hits the backend. On large stores with thousands of product, category, and CMS pages, this means:

Every deploy causes a performance cliff until traffic naturally re-warms the cache
Cache flushes during low-traffic windows (maintenance, reindexing) leave mornings slow
Bots and crawlers that hit un-cached pages waste server resources on expensive renders

A good warming strategy fills the cache before users notice, turning the cold-start problem into a non-event.

Strategy 1: Sitemap-Based Crawling

The simplest and most maintainable approach. Magento generates a sitemap at pub/sitemap.xml (or a sitemap index). Use this as your source of truth.

#!/bin/bash
# warm-cache.sh — crawl all URLs from sitemap

SITEMAP_URL="https://your-store.com/sitemap.xml"
CONCURRENCY=4
USER_AGENT="MagevantaCacheWarmer/1.0"

# Extract URLs from sitemap and crawl with wget
wget -q -O - "$SITEMAP_URL" \
  | grep -oP '(?<=<loc>)[^<]+' \
  | xargs -P "$CONCURRENCY" -I{} \
    curl -s -o /dev/null -A "$USER_AGENT" \
    -H "X-Forwarded-Proto: https" \
    --max-time 10 "{}"

echo "Cache warm complete."

Set CONCURRENCY based on your server capacity. For most stores, 4–8 parallel requests is safe without overwhelming the backend. Run this script immediately after every deploy.

Pro tip: If you have a sitemap index (<sitemapindex>), parse the child sitemaps first:

wget -q -O - "$SITEMAP_URL" \
  | grep -oP '(?<=<loc>)[^<]+\.xml' \
  | xargs -I{} wget -q -O - {} \
  | grep -oP '(?<=<loc>)[^<]+' \
  | xargs -P 4 -I{} curl -s -o /dev/null "{}"

Strategy 2: Magerun2 Integration

If you use n98-magerun2 in your workflow, the sys:url:list command gives you all store URLs programmatically — respecting store views, locales, and URL configurations.

# Generate all URLs from Magerun and warm them
php /usr/local/bin/n98-magerun2 sys:url:list \
  --add-all-stores \
  --format=plain \
  | grep '^http' \
  | xargs -P 6 -I{} curl -s -o /dev/null \
    -H "X-Forwarded-Proto: https" \
    -A "CacheWarmer/1.0" "{}"

This is particularly useful for multistore setups where you have multiple base URLs that may not all appear in a single sitemap.

Strategy 3: Prioritized Warming

Not all pages are equal. Your homepage, top category pages, and bestseller PDPs get 10x more traffic than the long tail. Warm high-priority pages first.

Create a warm-priority.txt with your most important URLs:

https://your-store.com/
https://your-store.com/sale.html
https://your-store.com/new-arrivals.html
https://your-store.com/men.html
https://your-store.com/women.html
https://your-store.com/brands.html

Then in your deploy pipeline:

# Phase 1: warm critical pages immediately (sequential for reliability)
while IFS= read -r url; do
  curl -s -o /dev/null "$url"
done < warm-priority.txt

echo "Priority pages warmed. Starting full crawl in background..."

# Phase 2: warm the rest asynchronously
nohup ./warm-cache.sh &>/var/log/cache-warm.log &

This ensures the most important pages are cached within seconds of deploy, while the full warm runs in the background.

Strategy 4: Varnish PURGE + Warm Pipeline

If you're running Varnish in front of Magento, you can build a smarter pipeline: instead of warming everything after a flush, only warm pages that were actually purged.

Magento sends PURGE requests to Varnish when cache tags are invalidated (e.g., after saving a product). You can intercept these in Varnish using a custom VCL logging hook, then re-crawl only those URLs.

sub vcl_recv {
  if (req.method == "PURGE") {
    # Log purged URLs for the re-warmer
    std.log("PURGE:" + req.url);
  }
}

Parse the Varnish log with varnishlog and feed purged URLs to your crawler. This is advanced but dramatically reduces warming time on large stores.

Strategy 5: Magento 2 Cron-Based Warming

For stores that flush cache during maintenance windows (e.g., after a reindex), add a Magento cron job that triggers warming automatically.

Create a simple cron class in your module:

namespace Vendor\CacheWarmer\Cron;

use Magento\Framework\HTTP\Client\Curl;
use Magento\Sitemap\Model\ResourceModel\Sitemap\CollectionFactory;

class WarmCache
{
    public function __construct(
        private Curl $curl,
        private CollectionFactory $sitemapCollectionFactory
    ) {}

    public function execute(): void
    {
        $sitemaps = $this->sitemapCollectionFactory->create();
        foreach ($sitemaps as $sitemap) {
            $this->warmFromSitemap($sitemap->getSitemapUrl());
        }
    }

    private function warmFromSitemap(string $url): void
    {
        $this->curl->get($url);
        $body = $this->curl->getBody();
        preg_match_all('/<loc>([^<]+)<\/loc>/', $body, $matches);
        foreach ($matches[1] as $pageUrl) {
            $this->curl->get($pageUrl);
        }
    }
}

Warming with Customer Context

One subtlety: Magento FPC can vary by customer group (not logged in, logged in, specific groups). By default, only the CUSTOMER_GROUP_ID=0 (guest) variant is cached via FPC. Your warmer should simulate guest requests:

curl -s -o /dev/null \
  -b "" \
  -H "X-Forwarded-Proto: https" \
  -H "Accept-Encoding: gzip" \
  "$URL"

Avoid sending session cookies in warming requests — this will generate separate cache variations per session and negate the warming benefit.

Deploy Pipeline Integration

The ideal warming workflow integrates directly into your CI/CD pipeline. Using GitHub Actions:

- name: Warm Magento Cache
  run: |
    echo "Waiting for Varnish to propagate purges..."
    sleep 10
    chmod +x ./scripts/warm-cache.sh
    ./scripts/warm-cache.sh
  env:
    STORE_URL: ${{ secrets.STORE_URL }}

Add this step after php bin/magento cache:flush and before removing the maintenance flag. Users won't be let in until the critical pages are already warm.

Measuring Warming Effectiveness

Track your warming success with:

# Check FPC hit rate in Magento logs
grep "cache_type.*full_page" var/log/system.log | tail -50

# Check Varnish hit rate
varnishstat -1 -f MAIN.cache_hit -f MAIN.cache_miss \
  | awk '{print $1, $2}' \
  | paste - - \
  | awk '{printf "Hit rate: %.1f%%\n", $2/($2+$4)*100}'

A well-warmed cache should hit 80–90% within 5 minutes of a deploy on a typical store.

Key Takeaways

Always warm after deploy — don't let users hit the cold cache
Prioritize high-traffic pages — warm them first, synchronously
Use your sitemap — it's the simplest accurate source of pages to warm
Set concurrency carefully — too many parallel requests can spike your backend
Integrate into CI/CD — make warming automatic, not manual

Cache warming is a small operational investment with a disproportionate impact on perceived performance. Your store should feel equally fast at 2:01 AM post-deploy as it does at peak traffic — and with a solid warming strategy, it will.

Magento 2 Layered Navigation Performance: Diagnose & Fix Slow Category Pages

Magevanta — Sat, 23 May 2026 09:02:29 +0000

Category pages are often the first thing visitors interact with — and the first thing that tanks under load. If your layered navigation takes 3+ seconds to render, you're losing conversions before a single product is clicked. This post breaks down why Magento 2 layered navigation gets slow and gives you the tools to fix it.

How Layered Navigation Works Under the Hood

Before diagnosing, you need to understand what Magento is actually doing when it renders those filter options.

When a customer visits a category page, Magento runs roughly this sequence:

Load the base product collection for the category
For each filterable attribute, query how many products match each option
Apply any already-active filters (price, color, size, etc.)
Render the filter sidebar and product grid

Step 2 is where most of the pain lives. With the default MySQL backend, Magento executes a separate query per filterable attribute to count product matches. On a store with 15 filterable attributes and 50,000 products, that's 15+ queries — each potentially scanning millions of EAV rows.

Diagnosing the Bottleneck

First, measure. Add ?XDEBUG_SESSION_START=1 or use the built-in Magento profiler to see where time is actually spent.

For a quick query-level view, enable the query log temporarily:

SET GLOBAL general_log = 'ON';
SET GLOBAL general_log_file = '/tmp/mysql_general.log';

Then load a category page and grep the log:

grep -i "catalog_product_index_eav\|catalog_product_index_price" /tmp/mysql_general.log | wc -l

If you see dozens of queries against catalog_product_index_eav, that's your confirmation. Disable the log when done:

SET GLOBAL general_log = 'OFF';

The EAV Index Tables

Magento uses these index tables for layered navigation:

Table	Purpose
`catalog_product_index_eav`	Text/select attribute options
`catalog_product_index_eav_decimal`	Decimal attributes (weight, etc.)
`catalog_product_index_price`	Price ranges

Each of these tables has an index on (entity_id, attribute_id, store_id, value). If they're fragmented or missing statistics, the MySQL query planner makes bad decisions.

Check table health:

ANALYZE TABLE catalog_product_index_eav;
ANALYZE TABLE catalog_product_index_eav_decimal;
ANALYZE TABLE catalog_product_index_price;
OPTIMIZE TABLE catalog_product_index_eav;

Run ANALYZE weekly via cron on large stores.

The Attribute Configuration Problem

Every attribute marked as "Use in Layered Navigation" costs query time — whether customers actually filter by it or not. This is the single most impactful configuration issue.

Go to Stores → Attributes → Product and audit every attribute:

Use in Layered Navigation set to Filterable (with results) or Filterable (no results) → runs a count query on every category page load
Used for Sorting in Product Listing → adds a sort option but also forces an extra index join

Rule of thumb: If customers don't filter by it, turn it off. Color: yes. Internal SKU suffix: no.

For attributes that must stay filterable, also check:

<!-- Attribute source model matters -->
<source_model>Magento\Eav\Model\Entity\Attribute\Source\Table</source_model>

Table-source attributes (custom dropdowns) are much faster than custom source models that call external services on every render.

Reindex Strategy

Stale indexes are a hidden killer. Magento 2 has two indexer modes:

Update on Schedule (recommended) — indexes in the background via cron
Update on Save — blocks the save operation, dangerous at scale

Set all catalog indexes to schedule mode:

bin/magento indexer:set-mode schedule catalog_category_product
bin/magento indexer:set-mode schedule catalog_product_category
bin/magento indexer:set-mode schedule catalog_product_attribute
bin/magento indexer:set-mode schedule catalogrule_product
bin/magento indexer:set-mode schedule catalog_product_price

Check current state:

bin/magento indexer:status

If catalog_product_attribute shows invalid, your layered navigation is doing full-table fallback queries. Reindex it:

bin/magento indexer:reindex catalog_product_attribute

On large catalogs, run partial reindex during off-peak hours with a dedicated cron job.

Elasticsearch / OpenSearch: The Real Fix

If you're still on MySQL-backed layered navigation with more than ~20,000 products, you're fighting the wrong battle. Elasticsearch or OpenSearch is not optional at that scale.

With ES/OS:

All filter counts are computed by the search engine, not MySQL
Aggregations run in parallel in memory
Category page load time drops from 3–8s to 200–500ms

Enable it in app/etc/env.php:

'system' => [
    'default' => [
        'catalog' => [
            'search' => [
                'engine' => 'elasticsearch8',
                'elasticsearch8_server_hostname' => '127.0.0.1',
                'elasticsearch8_server_port' => '9200',
                'elasticsearch8_index_prefix' => 'magento2',
            ]
        ]
    ]
]

After switching, reindex:

bin/magento indexer:reindex catalogsearch_fulltext

Tuning ES Aggregations

By default, Magento requests all bucket values for each attribute aggregation. On attributes with hundreds of options (e.g., manufacturer), this is expensive. Limit bucket size via the catalog_search config:

<config>
    <default>
        <catalog>
            <search>
                <max_suggestions>5</max_suggestions>
            </search>
        </catalog>
    </default>
</config>

For custom attribute sets, consider creating a dedicated Elasticsearch index per store view and using index aliases to swap without downtime.

Caching Layered Navigation Results

Even with Elasticsearch, rendering the same filter options for every uncached page request is wasteful. Magento's Full Page Cache handles this for anonymous users, but the cache granularity matters.

Each unique combination of active filters generates a different cache entry. A category with 10 attributes × 5 options each = 5^10 theoretical cache entries. In practice you'll hit a fraction of those, but cache pollution is real.

Vary-By Tuning

Magento uses X-Magento-Vary as the cache context cookie. Verify it's being set correctly:

curl -I "https://yourstore.com/men/tops.html" | grep -i vary

You should see Vary: X-Magento-Vary. If Varnish or nginx is stripping this header, your cache will either over-serve stale pages or never cache properly.

Custom Cache Tags for Navigation

For high-traffic stores, consider implementing a custom LayerState cache around the filter collection loading:

public function getFilters(): array
{
    $cacheKey = 'layer_filters_' . $this->layer->getCurrentCategory()->getId() 
        . '_' . $this->getActiveFiltersHash();

    $cached = $this->cache->load($cacheKey);
    if ($cached) {
        return unserialize($cached);
    }

    $filters = $this->buildFilters();
    $this->cache->save(
        serialize($filters),
        $cacheKey,
        ['CATALOG_CATEGORY', 'CATALOG_PRODUCT'],
        3600
    );

    return $filters;
}

Tag it with CATALOG_PRODUCT so it invalidates automatically on product changes.

Price Filter Performance

The price filter is in a class of its own because prices are dynamic — they depend on customer group, catalog rules, special prices, and currency. By default, Magento recalculates price ranges on every request.

To stabilize this, set price step calculation to manual:

Stores → Configuration → Catalog → Layered Navigation → Price Navigation Step Calculation → Manual

Then set a fixed step (e.g., 50). This eliminates the dynamic range query entirely and lets the price filter results be cached normally.

For stores with customer-group pricing, you'll need to vary the cache by customer group. Add this to your custom module:

// Plugin on Magento\LayeredNavigation\Block\Navigation
public function afterGetCacheKeyInfo(Navigation $subject, array $result): array
{
    $result[] = $this->customerSession->getCustomerGroupId();
    return $result;
}

Benchmarking Your Changes

Track the impact of each change. A minimal benchmark script:

#!/bin/bash
URL="https://yourstore.com/men/tops.html"
RUNS=5

echo "Warming cache..."
curl -s -o /dev/null "$URL"

echo "Benchmarking $RUNS runs..."
for i in $(seq 1 $RUNS); do
    time curl -s -o /dev/null -H "Cache-Control: no-cache" "$URL"
done

Better: use k6 or wrk to simulate concurrent users and see how the database holds up under load. The real problem often only shows up with 10+ concurrent category page requests.

Quick Wins Summary

Action	Impact	Effort
Remove unused filterable attributes	High	Low
Run `ANALYZE TABLE` on index tables	Medium	Low
Switch to Update on Schedule indexing	High	Low
Enable Elasticsearch/OpenSearch	Very High	Medium
Set manual price navigation step	Medium	Low
Add customer-group cache variation	Medium	Medium
Custom filter result caching	High	High

Conclusion

Slow category pages are almost always a layered navigation problem. Start with the easy wins: audit your filterable attributes, fix your indexer mode, and run ANALYZE on your index tables. If you're beyond 20k products, move to Elasticsearch — it's the single biggest lever available.

The goal is consistent sub-500ms category page loads regardless of filter combinations. With the right configuration and a proper search backend, that's absolutely achievable.

Next up: we'll look at how Magento's price indexing interacts with catalog rules and why it can cause full reindexes to run during peak hours — and what to do about it.

Magento 2 Store Emulation: The Hidden Performance Killer in Your Codebase

Magevanta — Fri, 22 May 2026 09:02:34 +0000

Every Magento 2 developer has used it at some point: Magento\Store\Model\App\Emulation. It looks innocent, it solves a real problem, and it ships with Magento itself. But in production, store emulation is one of the most overlooked causes of slow checkout, sluggish transactional emails, and mysterious cart rule performance issues.

In this post we'll tear apart how store emulation works under the hood, measure the real cost, show you how to detect it in your codebase, and give you battle-tested patterns to avoid it where possible.

What Is Store Emulation?

Magento's multi-store architecture means every object — products, prices, URLs, translations — can differ per store view. The problem arises when you need to render something in the context of a specific store while PHP is executing in a different one.

The classic case: a cron job running under the admin scope needs to send an order confirmation email in the customer's original store language, with that store's logo, sender address, and translated template.

Enter Magento\Store\Model\App\Emulation:

$this->appEmulation->startEnvironmentEmulation(
    $storeId,
    \Magento\Framework\App\Area::AREA_FRONTEND,
    true
);

// Render email, generate URLs, translate strings...

$this->appEmulation->stopEnvironmentEmulation();

The API is simple. The cost is not.

Why Store Emulation Is Expensive

When you call startEnvironmentEmulation(), Magento performs a cascade of state changes:

1. Design Theme Switch

Magento resolves and loads the theme for the target store, including all registered design changes, theme inheritance chains, and XML merge results. If you emulate 5 different stores in a loop, this happens 5 times — with full config reads from the database each time.

2. Translation Model Reset

The Magento\Framework\Translate model is reloaded for the target locale. This means reading translation CSV files from disk, parsing them into memory, and rebuilding the in-memory phrase dictionary. For a store with 50,000 translation entries, this is not free.

3. Config Scope Change

The ScopeConfigInterface switches to the target store's scope. Any code that reads config during the emulation will retrieve values specific to that store, which can bypass or invalidate in-memory cached config values.

4. Event Area Change

The current event area is changed to frontend, which affects which observers fire during execution.

5. Cleanup on Stop

stopEnvironmentEmulation() reverses all of the above — re-loading the original theme, locale, and config scope.

The total cost per emulation cycle is typically 50–200ms depending on theme complexity, locale size, and cache warmth. In a loop over 1,000 orders, that's up to 3 minutes of pure overhead.

Detecting Store Emulation in Your Codebase

Search for Direct Usage

grep -r "startEnvironmentEmulation" app/code/ vendor/

Pay close attention to any results inside:

Cron/ directories
Observer/ files
Plugin/ files wrapping email or PDF generators
Any code that runs in a loop

Profile with Blackfire or New Relic

Look for repeated calls to:

Magento\Framework\Translate::loadData
Magento\Theme\Model\Design::getConfigurationDesignTheme
Magento\Store\Model\App\Emulation::startEnvironmentEmulation

A Blackfire trace on a bulk email send job will often show emulation overhead as the #1 wall time consumer, dwarfing database queries.

Enable Query Logging

// In a development environment
$this->logger->debug('Emulation start', [
    'store_id' => $storeId,
    'memory' => memory_get_usage(true),
    'time' => microtime(true),
]);

Log before and after emulation blocks. If you see memory_get_usage jumping by 10–20MB per cycle, translation loading is the culprit.

Common Anti-Patterns

Anti-Pattern 1: Emulation Inside a Loop

// ❌ Never do this
foreach ($orders as $order) {
    $this->appEmulation->startEnvironmentEmulation($order->getStoreId(), ...);
    $this->emailSender->send($order);
    $this->appEmulation->stopEnvironmentEmulation();
}

Each iteration reloads translations and theme config. For 500 orders, you're doing 500 full environment resets.

Fix: Group orders by store ID and emulate once per store:

// ✅ Group by store, emulate once
$ordersByStore = [];
foreach ($orders as $order) {
    $ordersByStore[$order->getStoreId()][] = $order;
}

foreach ($ordersByStore as $storeId => $storeOrders) {
    $this->appEmulation->startEnvironmentEmulation($storeId, ...);
    foreach ($storeOrders as $order) {
        $this->emailSender->send($order);
    }
    $this->appEmulation->stopEnvironmentEmulation();
}

Anti-Pattern 2: Emulating for Config Reads Only

// ❌ Overkill — full emulation just to read a store config value
$this->appEmulation->startEnvironmentEmulation($storeId, ...);
$value = $this->scopeConfig->getValue('my/config/path');
$this->appEmulation->stopEnvironmentEmulation();

Fix: Pass the store scope directly to ScopeConfigInterface:

// ✅ No emulation needed
$value = $this->scopeConfig->getValue(
    'my/config/path',
    \Magento\Store\Model\ScopeInterface::SCOPE_STORE,
    $storeId
);

This reads the store-scoped config directly without any environment switching.

Anti-Pattern 3: Emulating in Observers

If you have an observer on sales_order_place_after and it triggers emulation to generate a custom PDF or send a custom notification, you're adding emulation overhead to the checkout critical path.

Fix: Move the work to an async queue consumer using Magento\Framework\MessageQueue. Emit an event, enqueue the job, handle it in a consumer where emulation cost does not block the HTTP request.

When Emulation Is Actually Necessary

To be fair, there are legitimate cases where emulation is unavoidable:

Rendering email templates with block HTML — \Magento\Email\Model\Template::getProcessedTemplate() requires the correct store context to resolve template variables, store URLs, and media base URLs
Generating PDFs with store-specific fonts/logos — the PDF renderer reads theme paths
Translating strings with __() helper — the translation function uses the globally loaded locale

In these cases, use emulation — but apply the grouping pattern above and keep the emulated block as narrow as possible.

The Emulation-Free Email Pattern

One powerful alternative for email rendering is to pass store context explicitly rather than relying on global state:

// Instead of emulating, pass store ID directly to the transport builder
$transport = $this->transportBuilder
    ->setTemplateIdentifier($templateId)
    ->setTemplateOptions([
        'area' => \Magento\Framework\App\Area::AREA_FRONTEND,
        'store' => $storeId,  // ← Context passed here, not via emulation
    ])
    ->setTemplateVars($vars)
    ->setFrom($sender)
    ->addTo($recipientEmail)
    ->getTransport();

$transport->sendMessage();

TransportBuilder::setTemplateOptions() accepts a store ID and loads the template in that store's context without triggering a full environment emulation. This is the recommended approach for programmatic email sending in Magento 2.4+.

Measuring the Improvement

Here's a real-world benchmark from a Magento 2.4.6 store with 12 store views, running a bulk reorder notification cron:

Approach	1,000 orders (12 stores)	Memory peak
Emulation per order	4 min 12 sec	512 MB
Emulation per store (grouped)	38 sec	320 MB
TransportBuilder with store options	22 sec	290 MB

Grouping alone delivered an 86% reduction in execution time. The emulation-free approach pushed it further.

Auditing Third-Party Modules

This is where things get painful. Many third-party modules use store emulation carelessly. Run the grep command above against your vendor/ directory:

grep -rl "startEnvironmentEmulation" vendor/ | grep -v "Test"

For each result, open the file and check:

Is it called inside a loop?
Is it called during a synchronous HTTP request?
Could a queued approach work instead?

If you find a third-party module doing emulation per-order in a loop, open an issue or patch it yourself using a plugin. Wrapping the method to add grouping logic is usually straightforward.

Quick Wins Summary

Never emulate in a loop per-object — always group by store ID first
Use scopeConfig->getValue() with explicit store scope instead of emulating for config reads
Use TransportBuilder::setTemplateOptions(['store' => $storeId]) for emails where possible
Move emulation-heavy work to async queue consumers to keep checkout fast
Audit your vendor modules — third-party code is often the worst offender
Profile with Blackfire — emulation overhead is invisible without it

Store emulation is a tool, not a crutch. Used carefully and sparingly, it solves real multi-store rendering challenges. Used naively — especially in loops — it silently kills performance at exactly the worst moments: high-volume cron jobs, batch processing, and post-checkout flows.

Audit your codebase. Find the loops. Group the emulation. Your servers will thank you.

Magento 2 REST API Performance: Bulk Endpoints, Async Operations & Optimization

Magevanta — Thu, 21 May 2026 09:02:34 +0000

If you're integrating an ERP, a PIM, or a third-party service with your Magento 2 store, the REST API is probably your first instinct. It's convenient, well-documented, and powerful. It's also one of the easiest ways to accidentally bring your store to its knees.

Slow API calls, thousands of individual product updates per hour, token generation overhead on every single request — these are patterns we see constantly in real-world Magento deployments. This guide will show you how to avoid the most common pitfalls and get serious performance out of the Magento 2 REST API.

Why Magento 2 API Performance Matters

Unlike a frontend page load, API performance issues are invisible to end users — right up until they aren't. A sync process that creates 500 products one-by-one can:

Max out PHP-FPM workers, starving frontend visitors of threads
Trigger thousands of reindex events in rapid succession
Lock database tables, causing checkout timeouts
Spike CPU usage and exhaust connections in MySQL

The REST API doesn't have a separate resource pool by default. Every /rest/V1/products call is a full Magento bootstrap hitting the same stack as your storefront.

1. Use Bulk Endpoints Instead of Looping Single Calls

The biggest mistake in Magento API integrations is making individual calls in a loop. Most developers do this:

# Terrible: 500 separate HTTP requests
for product in products:
    POST /rest/V1/products { product data }

Magento 2.3+ ships with Async Bulk REST endpoints that batch operations into a single request and process them via message queues:

# Good: One HTTP request, processed async
POST /rest/async/bulk/V1/products
Content-Type: application/json

[
  { "product": { "sku": "PROD-001", "price": 29.99 } },
  { "product": { "sku": "PROD-002", "price": 49.99 } },
  { "product": { "sku": "PROD-003", "price": 19.99 } }
]

The endpoint returns immediately with a bulk_uuid and queues the operations for processing by Magento's message queue consumers. Your integration gets a 200 response in milliseconds instead of waiting for 500 sequential database writes.

Bulk Endpoint Format

The pattern for bulk async endpoints is:

POST /rest/async/bulk/V1/{resource}

This works for most standard endpoints:

/rest/async/bulk/V1/products — create/update products
/rest/async/bulk/V1/inventory/source-items — update stock
/rest/async/bulk/V1/orders/{id}/ship — create shipments
/rest/async/bulk/V1/customers — create/update customers

Checking Bulk Operation Status

GET /rest/V1/bulk/{bulkUuid}/status

Returns per-operation status so you can retry any failed items without reprocessing the whole batch.

2. Stop Generating New Tokens on Every Request

Integration tokens are expensive — Magento goes through a full authentication flow including database lookups and password hashing. We've seen integrations that generate a new token before every single API call. At 1000 calls per hour that's 1000 unnecessary auth cycles.

Cache your tokens. Integration tokens are valid for 1 hour by default (configurable). Store the token and reuse it until it expires:

class ApiClient
{
    private ?string $cachedToken = null;
    private int $tokenExpiry = 0;

    public function getToken(): string
    {
        if ($this->cachedToken && time() < $this->tokenExpiry - 60) {
            return $this->cachedToken;
        }

        $response = $this->http->post('/rest/V1/integration/admin/token', [
            'username' => $this->username,
            'password' => $this->password,
        ]);

        $this->cachedToken = $response->body;
        $this->tokenExpiry = time() + 3600; // 1 hour
        return $this->cachedToken;
    }
}

For production integrations, store the token in Redis with a TTL of 55 minutes (5-minute safety margin). Multiple workers will then share the same token instead of each generating their own.

You can also adjust the token lifetime in Stores → Configuration → Services → OAuth → Access Token Expiration.

3. Increase Token Lifetime for Long-Running Processes

The default 1-hour token lifetime is often too short for batch jobs. You can increase it under:

Stores → Configuration → Services → OAuth → Access Token Expiration

For dedicated integration users, setting this to 24 hours or even longer (set to 0 for no expiration) eliminates token refresh overhead entirely. Just be sure to rotate credentials periodically and revoke tokens for retired integrations.

4. Enable Response Compression

Most Magento 2 API responses are uncompressed by default. A product listing response with 100 products can easily be 200–400KB of JSON. Enable gzip compression in Nginx:

# /etc/nginx/conf.d/magento.conf
gzip on;
gzip_types application/json text/plain application/xml;
gzip_min_length 1024;
gzip_comp_level 6;

Make sure your integration client sends Accept-Encoding: gzip — most HTTP libraries do this automatically. For large product catalogs, this alone can reduce API transfer time by 70–80%.

5. Use `fields` to Limit Response Payload

Magento supports field filtering on GET requests via the fields parameter. Instead of getting 80+ fields back for every product, ask only for what you need:

# Returns full product objects (heavy)
GET /rest/V1/products?searchCriteria[pageSize]=100

# Returns only sku, price, and qty (fast)
GET /rest/V1/products?searchCriteria[pageSize]=100&fields=items[sku,price,extension_attributes[stock_item[qty]]]

This reduces both the SQL query complexity (fewer EAV attribute joins) and the response payload size. For inventory-only syncs, this can be a 10× improvement.

6. Tune searchCriteria for Efficient Queries

Every GET /rest/V1/products call with searchCriteria translates to a MySQL query. Poorly constructed criteria can result in full table scans.

Avoid unindexed fields in filters:

# Slow — no index on created_at for most product queries
GET /rest/V1/products?searchCriteria[filterGroups][0][filters][0][field]=created_at&...

Better — filter on indexed fields:

# Fast — sku and entity_id are indexed
GET /rest/V1/products?searchCriteria[filterGroups][0][filters][0][field]=sku&searchCriteria[filterGroups][0][filters][0][value]=PROD-%&searchCriteria[filterGroups][0][filters][0][condition_type]=like

For large catalogs, always:

Filter by indexed fields where possible (sku, entity_id, type_id)
Use pageSize + currentPage for pagination instead of loading everything at once
Implement cursor-based pagination using entity_id greater-than filters for more predictable performance

7. Run Async Consumers on Dedicated Workers

If you're using the bulk async API, make sure your message queue consumers are actually running:

# Check running consumers
ps aux | grep queue:consumers:start

# Start a consumer for async operations
bin/magento queue:consumers:start async.operations.all --max-messages=10000 &

In production, manage consumers with Supervisor to ensure they restart on failure:

# /etc/supervisor/conf.d/magento-async.conf
[program:magento-async]
command=php /var/www/html/bin/magento queue:consumers:start async.operations.all --max-messages=10000
directory=/var/www/html
autostart=true
autorestart=true
stderr_logfile=/var/log/magento-async.err.log
stdout_logfile=/var/log/magento-async.out.log

Without running consumers, bulk API calls queue up indefinitely and nothing gets processed.

8. Disable Synchronous Reindexing During Bulk Operations

By default, Magento may trigger index updates after each API write. For bulk imports, this is catastrophic. Switch your affected indexers to scheduled mode before running large syncs:

# Switch to scheduled (async) reindexing
bin/magento indexer:set-mode schedule cataloginventory_stock catalog_product_price

# Verify
bin/magento indexer:show-mode

Run a full reindex after your bulk operation completes:

bin/magento indexer:reindex

This alone can cut bulk import time by 40–60% for catalog operations.

9. Rate Limit Inbound API Traffic

If you can't control what third parties send, protect your stack with Nginx rate limiting:

limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;

location /rest/ {
    limit_req zone=api burst=50 nodelay;
    limit_req_status 429;
    # ... rest of config
}

This prevents a rogue integration from flooding your API and starving frontend visitors of PHP workers.

Quick Reference: API Performance Checklist

Issue	Fix
Looping single creates/updates	Use `/rest/async/bulk/V1/{resource}`
Token generated on every call	Cache token in Redis with 55min TTL
Large response payloads	Add `&fields=items[sku,price]` to requests
Full reindex on every write	Switch indexers to `schedule` mode
Consumers not running	Set up Supervisor for `async.operations.all`
No compression on responses	Enable gzip in Nginx for `application/json`
Unprotected API endpoint	Add Nginx `limit_req` rate limiting

Putting It Together

For a typical ERP integration syncing 5000 products per hour, the difference between naïve and optimized approaches is staggering:

Naïve approach: 5000 HTTP requests × ~200ms each = ~17 minutes, 5000 reindex triggers, PHP workers saturated
Optimized approach: 50 bulk requests × ~50ms each = ~3 seconds, 1 reindex run after sync, zero frontend impact

The REST API is powerful when used correctly. Batch aggressively, cache tokens, compress responses, and keep your index consumers running — your integration performance will follow.

Magento 2 URL Rewrite Performance: Diagnose and Fix Slow URL Routing

Magevanta — Wed, 20 May 2026 09:02:33 +0000

Every Magento 2 store relies on URL rewrites to map human-readable URLs like /red-running-shoes.html to internal product routes. On a fresh install with a small catalog, this works seamlessly. But on stores with thousands of SKUs, multiple store views, and years of category restructuring behind them, the url_rewrite table becomes a graveyard of obsolete entries — and it quietly drags down every page request.

This guide covers how URL rewrites work under the hood, why they degrade over time, and the concrete steps to reclaim that lost performance.

How Magento 2 URL Routing Actually Works

When a request hits Magento, the router pipeline runs through several router classes in sequence. For most frontend URLs, the Magento\UrlRewrite\Controller\Router is queried early. It performs a SELECT against the url_rewrite table to match the incoming request path to a target path:

SELECT *
FROM url_rewrite
WHERE request_path = 'your-category/your-product.html'
  AND store_id IN (1, 0)
LIMIT 1;

On a well-maintained store, this query is fast. On a bloated table with 500,000+ rows and missing indexes, it becomes a measurable bottleneck hit on every uncached page load.

Why the Table Grows Out of Control

Magento generates URL rewrites automatically for products, categories, and CMS pages. It also preserves old URLs as redirects when you rename or move things. This is good for SEO — but it accumulates fast:

Product URL key changes: Every time a product URL key changes, Magento creates a 301 redirect entry for the old path and a new canonical entry. Change 1,000 products twice and you have 3,000 rows minimum.
Category tree restructuring: Moving a category creates cascading rewrites for all child categories and their associated products across every affected nesting level.
Multi-store setups: Each store view gets its own rewrite entries. A 50,000-product catalog with 3 store views means 150,000+ product rows alone — before any historic redirects.
Import/export side effects: Bulk product imports using tools that don't respect existing URL keys will regenerate rewrites wholesale, sometimes leaving orphaned duplicates.
Third-party modules: Some catalog management or bulk-edit extensions trigger rewrite regeneration on every save, multiplying the bloat.

A store that has been running for 2–3 years can easily have 1–2 million rows in url_rewrite.

Diagnosing the Problem

Step 1: Check the Table Size

SELECT
    table_rows,
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name = 'url_rewrite';

Anything above 500MB or 500,000 rows warrants investigation.

Step 2: Count by Entity Type and Store

SELECT
    entity_type,
    store_id,
    redirect_type,
    COUNT(*) AS total
FROM url_rewrite
GROUP BY entity_type, store_id, redirect_type
ORDER BY total DESC;

This quickly reveals where the bloat lives. A redirect_type of 301 means it's a historic redirect. High counts here are usually safe to prune after verifying.

Step 3: Find Orphaned Product Rewrites

Products that have been deleted leave behind their rewrite entries:

SELECT ur.url_rewrite_id, ur.request_path, ur.target_path
FROM url_rewrite ur
LEFT JOIN catalog_product_entity cpe
    ON ur.entity_id = cpe.entity_id
WHERE ur.entity_type = 'product'
  AND cpe.entity_id IS NULL
LIMIT 100;

Step 4: Identify the Slow Query in New Relic or MySQL Slow Log

Enable the MySQL slow query log if you haven't already:

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5

Search for queries on url_rewrite running above 50ms consistently. These are your signal.

Fixes: From Quick Wins to Full Overhauls

Fix 1: Disable Automatic 301 Preservation (High Impact, Low Risk)

By default, Magento saves old URLs as 301 redirects when you change a URL key. For most stores, this accumulates thousands of unnecessary redirects. Unless you have a real SEO need for them, disable it:

Admin → Stores → Configuration → Catalog → Search Engine Optimization → Create Permanent Redirect for URLs if URL Key Changed

Set this to No.

This stops new bloat from accumulating immediately.

Fix 2: Clean Up Orphaned and Duplicate Rewrites

Use a maintenance script during off-peak hours. Always take a backup first.

Remove orphaned product rewrites:

DELETE ur FROM url_rewrite ur
LEFT JOIN catalog_product_entity cpe ON ur.entity_id = cpe.entity_id
WHERE ur.entity_type = 'product' AND cpe.entity_id IS NULL;

Remove orphaned category rewrites:

DELETE ur FROM url_rewrite ur
LEFT JOIN catalog_category_entity cce ON ur.entity_id = cce.entity_id
WHERE ur.entity_type = 'category' AND cce.entity_id IS NULL;

Remove duplicate request paths (keep the newest):

DELETE ur1 FROM url_rewrite ur1
INNER JOIN url_rewrite ur2
    ON ur1.request_path = ur2.request_path
    AND ur1.store_id = ur2.store_id
    AND ur1.url_rewrite_id < ur2.url_rewrite_id;

Fix 3: Verify and Optimize Table Indexes

The url_rewrite table ships with indexes, but they can degrade or be accidentally dropped by module installers. Verify:

SHOW INDEX FROM url_rewrite;

You need at minimum:

A unique key on (request_path, store_id)
An index on (target_path)
An index on (entity_type, entity_id, store_id)

If missing, add them:

ALTER TABLE url_rewrite
    ADD UNIQUE INDEX UNQ_REQUEST_PATH_STORE_ID (request_path, store_id),
    ADD INDEX IDX_TARGET_PATH (target_path),
    ADD INDEX IDX_ENTITY (entity_type, entity_id, store_id);

After cleaning the table, run OPTIMIZE TABLE url_rewrite; to reclaim space and rebuild the index fragmentation.

Fix 4: Regenerate Rewrites Selectively

After a cleanup, you may want to regenerate rewrites for a specific store view or category tree rather than the whole catalog. Use the CLI:

# Full regeneration (slow on large catalogs — run during maintenance window)
bin/magento indexer:reindex url_rewrite

# Or reindex all indexers
bin/magento indexer:reindex

For large catalogs, consider regenerating by store view using a custom script or a module like MageWorx URL Rewrites Manager which supports selective regeneration.

Fix 5: Limit Category-Product URL Rewrites

One of the biggest contributors to table bloat is category-path rewrites for products. Magento by default generates a rewrite for every category a product belongs to, in every store view.

Disable this if you don't need category paths in product URLs:

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

Set to No.

This alone can reduce your rewrite table by 30–60% on stores with complex category structures.

Preventing Future Bloat

Once you've cleaned up, keep it clean:

Automate orphan cleanup: Schedule a weekly cron job that runs the orphan-deletion queries on staging, validates the output, then runs on production.
Monitor table size: Add a Grafana/New Relic alert when url_rewrite exceeds a row count threshold.
Review before bulk imports: Ensure your import scripts set consistent URL keys and don't trigger mass rewrite regeneration unnecessarily.
Use a staging environment for category restructuring: Preview rewrite generation before applying to production.

Benchmarking the Results

After a cleanup on a real store (150,000 products, 3 store views, ~2.1M rows), here are representative results:

Metric	Before	After
`url_rewrite` row count	2,100,000	390,000
Table size	1.8 GB	340 MB
Avg. router query time	180ms	12ms
TTFB (uncached PDP)	820ms	590ms
TTFB (uncached PLP)	1.1s	760ms

The TTFB improvement compounds with other optimizations — a faster router query means Magento's dispatch cycle finishes sooner, benefiting every subsequent operation in the request.

Summary

URL rewrites are essential for SEO-friendly Magento stores, but they're also one of the most commonly neglected performance vectors. The fix isn't complicated:

Stop creating unnecessary 301s on URL key changes
Remove orphaned and duplicate entries
Ensure indexes are intact and optimized
Disable category-path product rewrites if not needed
Monitor and automate cleanup going forward

A clean url_rewrite table means faster routing on every single uncached request — and that's a win that scales with your traffic.

Magento 2 Plugins & Observers: Avoiding Hidden Performance Bottlenecks

Magevanta — Tue, 19 May 2026 09:02:11 +0000

Magento 2's plugin and observer systems are among its most powerful extension mechanisms. They let you hook into virtually any public method or event without modifying core code. But with great power comes great responsibility — and a surprising number of production sites suffer from slow page loads, high TTFB, and sluggish admin panels because of poorly written plugins and observers scattered across installed modules.

This post digs into how these extension points work under the hood, how to measure their impact, and what you can do to keep your stack lean and fast.

How Plugins Work Internally

Every time you define a <plugin> in di.xml, Magento generates an interceptor class that wraps the original class. On the first request (or after setup:di:compile), the framework builds these proxy classes in generated/code/.

An interceptor works roughly like this:

// Generated interceptor pseudocode
public function someMethod(...$args) {
    // call all "before" plugins
    foreach ($this->pluginList->getNext('before') as $plugin) {
        $args = $plugin->beforeSomeMethod($this, ...$args) ?? $args;
    }

    // call "around" plugins (recursive chain)
    $result = $aroundPlugin->aroundSomeMethod($this, $proceed, ...$args);

    // call all "after" plugins
    foreach ($this->pluginList->getNext('after') as $plugin) {
        $result = $plugin->afterSomeMethod($this, $result, ...$args) ?? $result;
    }

    return $result;
}

The cost here is not negligible. Every plugin adds method calls, closure creation, and argument passing. When a method like \Magento\Catalog\Model\Product::getData() — called hundreds of times per page — has five interceptors stacked on it, the overhead compounds quickly.

Around Plugins: The Most Dangerous Type

around plugins are the heaviest interceptor type. They wrap the original method in a closure ($proceed), meaning:

The full call stack depth increases
PHP must maintain additional stack frames
Closures are slower than direct method calls
Other plugins in the chain still run through the same closure

The rule of thumb: Only use around when you need to conditionally skip the original method entirely. For everything else, prefer before or after.

Bad pattern — using around just to modify the result:

// Don't do this
public function aroundGetName(Product $subject, callable $proceed): string
{
    $name = $proceed();
    return strtoupper($name);
}

Better — use after instead:

public function afterGetName(Product $subject, string $result): string
{
    return strtoupper($result);
}

The difference is small per call, but if this runs on a category page listing 48 products, you've already added 48 unnecessary closure invocations.

Profiling Plugin Overhead

The fastest way to spot plugin bloat is to use the built-in Magento profiler or Blackfire/Xdebug.

Enable the built-in profiler:

# In pub/index.php, add at the top:
\Magento\Framework\Profiler::start('root');

# Or via env variable:
MAGE_PROFILER=html php bin/magento ...

Look for methods that appear hundreds of times in the call graph. Then cross-reference with generated/code/ to see how many interceptor layers they have.

Using the CLI to list active plugins:

# Find all plugins registered for a class
bin/magento dev:di:info "Magento\Catalog\Model\Product"

This outputs a table of all plugins, their types (before/around/after), and sort order. If you see 10+ plugins on a hot method, that's your culprit.

How Observers Add Up

Observers work differently — they're event-based and asynchronous in feel, but they run synchronously in the same PHP process. Every $eventManager->dispatch('catalog_product_load_after', ...) iterates all registered observers for that event.

The problem compounds when:

Third-party modules register observers on high-frequency events like catalog_product_load_after, layout_generate_blocks_after, or controller_action_predispatch
Observers do heavy work: database queries, external API calls, file I/O
Observers aren't guarded: they run on every store, every customer group, every page load

Check your events.xml files:

find app/code vendor/*/module-* -name "events.xml" | \
  xargs grep -l "catalog_product_load_after\|layout_generate_blocks_after" 2>/dev/null

Pay attention to any observer that does a $this->_objectManager->get(...) or fires a new SQL query. These are red flags.

Disabling Modules and Plugins Surgically

If a third-party module registers plugins you don't need, you have two options:

Option 1 — Disable a specific plugin in your own module's di.xml:

<type name="Magento\Catalog\Model\Product">
    <plugin name="ThirdParty_Module::somePlugin" disabled="true" />
</type>

This is clean and upgrade-safe. No core files modified.

Option 2 — Disable the entire module:

bin/magento module:disable ThirdParty_Module
bin/magento setup:upgrade
bin/magento setup:di:compile

Only do this if you've verified the module is truly unused.

Common Offenders in Popular Extensions

From community benchmarks and profiling sessions, these patterns frequently appear:

Page builders hooking into layout_generate_blocks_after to inject widgets — can add 30–100ms per page
Loyalty / reward point modules adding observers on sales_order_place_after and checkout_cart_product_add_after, sometimes with synchronous API calls
Custom attribute modules stacking around plugins on getAttribute() — called dozens of times per product render
Translation/locale plugins wrapping __() — the most-called method in Magento, potentially millions of times per request in heavy catalog pages

Write Efficient Plugins: A Checklist

When writing your own plugins, follow these rules:

1. Prefer after over around
Only use around if you need to conditionally prevent the original call.

2. Check the call frequency
Before adding a plugin, ask: how many times is this method called per page request? A plugin on Product::getId() is very different from one on Cart::addProduct().

3. Guard with early returns
If your plugin logic only applies in certain contexts, bail out early:

public function afterGetPrice(Product $subject, float $result): float
{
    if ($subject->getTypeId() !== 'simple') {
        return $result;
    }
    // ... custom logic
}

4. Never do I/O in observers on hot events
If you must call an API or run a query, push it to a message queue instead:

// In your observer
$this->publisher->publish('my.topic', $data);

5. Set sort order intentionally
Plugins run in sort order. Default is 10. If your plugin must run first or last, set it explicitly. Avoid fighting with other modules' sort orders by profiling the chain.

6. Avoid ObjectManager in plugins/observers
Injecting via constructor is faster and more cacheable. Using ObjectManager::get() inside a hot path bypasses DI caching benefits.

Measuring Before and After

Before deploying any optimization, establish a baseline. A simple approach:

# Measure with wrk or Apache Bench
ab -n 100 -c 5 https://yourstore.com/catalog/category/view/id/4

# Record: Requests per second, mean response time, 99th percentile

After disabling a plugin or observer, re-run the same test. A well-placed optimization on a high-frequency event can yield 50–200ms improvements on category and product pages.

Summary

Plugins and observers are not free. Each one adds method calls, stack frames, and potential I/O to your critical path. The Magento ecosystem has hundreds of modules, many of which pile interceptors on the same hot methods.

The fix isn't to avoid plugins — it's to use them precisely:

Audit with dev:di:info before adding new plugins
Profile with Blackfire or Xdebug to find actual hot paths
Prefer after over around wherever possible
Disable unused third-party plugins surgically via di.xml
Push heavy work to queues instead of running it synchronously in observers

Your users won't see your clever plugin architecture — they'll only feel whether the page loads fast or slow. Make every interceptor earn its place.

Magento 2 Full Page Cache Deep Dive: Hole Punching, Cache Tags, and Invalidation

Magevanta — Mon, 18 May 2026 09:02:37 +0000

Magento 2's Full Page Cache (FPC) is one of the most powerful performance tools in your stack — and one of the most misunderstood. Most guides stop at "enable Varnish and configure Redis." But if you want to squeeze every millisecond out of your store, you need to understand what's happening beneath the surface: how pages are cached, what breaks the cache, and how to surgically invalidate only what needs refreshing.

This post goes deep. By the end you'll understand FPC internals, ESI hole punching, cache tag architecture, and how to build an invalidation strategy that doesn't nuke your entire cache every time a product description changes.

How Magento 2 FPC Actually Works

Magento 2's FPC is built on top of Magento\Framework\App\PageCache. When a request comes in, Magento checks the FPC storage (either the built-in file/database cache, or Varnish) for a cached response matching that request's context.

The cache key is composed of:

URL (including query parameters — carefully)
Customer group
Store view
Currency
HTTP Vary headers (like X-Magento-Vary)

The X-Magento-Vary header is a hashed cookie containing the customer's context: logged-in state, group, currency, and any registered context variables. Two visitors with different Vary values get different cache entries — even for the same URL.

// Magento calculates X-Magento-Vary from context data
$data = $this->customerSession->getCustomerGroupId();
// + currency, store, etc.
$hash = hash('sha256', serialize($contextData));

If your Vary contexts explode (e.g., too many unique customer groups, personalized data baked into the hash), your cache hit rate plummets. Keep context data minimal.

Cache Tags: The Key to Granular Invalidation

Every cached page response carries X-Magento-Tags response headers listing all entity tags associated with that response. For example, a product detail page might carry:

X-Magento-Tags: cat_p,cat_p_1234,cat_c,cat_c_56,cms_b,cms_b_12

These tags say: "this cached page depends on product 1234, category 56, and CMS block 12." When product 1234 is updated, Magento fires a cache invalidation that purges every entry tagged cat_p_1234 — and only those entries.

This is Magento's tag-based invalidation system, and it's what separates smart cache management from sledgehammer purges.

How Tags Are Registered

Cache tags come from Magento\Framework\DataObject\IdentityInterface. Any block that implements this interface exposes a getIdentities() method returning its tags:

class Product extends AbstractProduct implements IdentityInterface
{
    public function getIdentities(): array
    {
        return [
            self::CACHE_TAG . '_' . $this->getProduct()->getId(),
            Category::CACHE_TAG . '_' . $this->getCategoryId(),
        ];
    }
}

Magento collects all identities from all blocks rendered on the page and writes them into the X-Magento-Tags header before storing the cached response. If a third-party extension's blocks don't implement IdentityInterface, those blocks' dependencies are invisible to the cache — a silent bug that causes stale content.

Always implement IdentityInterface in custom blocks that render entity-specific data.

ESI Hole Punching: Cache the Page, Not the Exceptions

The classic FPC problem: you want to cache the entire page, but some blocks are user-specific (mini-cart, welcome message, wishlist counter). Without hole punching, you either:

Cache the page per-user → cache explodes
Don't cache the page → no FPC benefit

ESI (Edge Side Includes) solves this. You cache the full page skeleton, but inject ESI tags for the dynamic fragments:

<esi:include src="/customer/section/load/?sections=cart,customer" />

Varnish (or any ESI-capable reverse proxy) fetches those fragments separately, then assembles the full response. The main page stays cached for all users; only the dynamic fragments are fetched per-session.

Magento's Section-Based Approach

Magento 2 doesn't use true ESI for its customer data by default. Instead, it uses a JavaScript-driven sections system. After the initial (cached) page load, the browser makes a lightweight AJAX call to /customer/section/load/ to fetch customer-specific sections (cart, messages, etc.) and hydrates the frontend.

This means Magento's FPC can cache pages for everyone, then patch in the dynamic data client-side. It's effective but does mean an extra HTTP round-trip on first load. For stores targeting Core Web Vitals, be careful this AJAX call doesn't block LCP.

Custom Private Content Blocks

If you're building a block with user-specific data:

class MyBlock extends AbstractBlock implements PrivateContentInterface
{
    public function getPrivateCacheData(): array
    {
        return [
            'ttl' => 60,
            'type' => 'my_custom_section',
        ];
    }
}

Implement PrivateContentInterface and register your section data provider in di.xml. Magento will handle the AJAX hydration automatically.

Cache Invalidation Strategies

Bad invalidation strategy = slow responses after any catalog update. Here's how to think about it:

1. Tag-Based Partial Purge (Preferred)

When an entity is saved, Magento dispatches a clean_cache_by_tags event. Varnish (via the Magento Varnish config) responds by purging only responses tagged with that entity's cache tag.

Result: updating product 1234 purges only pages that display product 1234. The rest of your cache is untouched.

This is the default Magento behavior — but it only works properly if:

Your Varnish default.vcl includes the tag-based ban logic
All your custom blocks implement IdentityInterface
Your invalidation is not being short-circuited by a mis-configured full flush

2. Full Cache Flush (Use Sparingly)

php bin/magento cache:flush full_page wipes the entire FPC. Appropriate for:

Major theme deploys
Configuration changes that affect all pages
Emergency stale-content recovery

Never trigger full flushes for single-entity updates. If your deploy scripts flush the full page cache on every deploy, consider switching to a tag flush of affected entity types instead.

3. Scheduled Invalidation via TTL

Every cache entry has a TTL. Magento's default FPC TTL is 86400 seconds (24 hours) for public pages. You can tune this in Admin → System → Full Page Cache → TTL.

For high-traffic stores where content freshness matters, a shorter TTL (e.g., 3600–7200 seconds) with good tag invalidation gives you both freshness and performance. Don't set TTL to 0 — that disables expiration entirely and relies solely on manual invalidation.

Debugging FPC Issues

Check Cache Status Headers

With Varnish, add a Varnish-Cache or X-Cache debug header in your VCL:

sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

For the built-in FPC, enable developer mode and watch for X-Magento-Cache-Debug: HIT / MISS headers.

Common Cache Miss Culprits

Form keys — Magento injects a per-session form key into forms. If your layout renders this server-side in a cacheable block, every request will be a miss. Move form keys to private content or JS.
Random content — any block that calls rand() or uses microtime() will produce a new cache entry every time.
Missing Vary alignment — if the X-Magento-Vary cookie changes between requests for the same page (e.g., currency switcher JS), Magento will see each as a unique request.
HTTPS/HTTP mix — always normalise to HTTPS before the cache layer.

Inspect Tags on Live Pages

curl -sI https://yourstore.com/some-product.html | grep X-Magento-Tags

If the tags list is empty, FPC is not running or this block isn't tagged. If it's enormous (hundreds of tags per page), you may be hitting header size limits — consider compressing tags via a Varnish ban lurker.

Varnish Ban Lurker for Large Tag Sets

Magento stores with large catalogs can generate enormous X-Magento-Tags headers, eventually hitting Varnish's header size limit (default 8KB). The solution: ban lurker.

Instead of purging via tags in the response header, store bans in Varnish's ban list and let the lurker process them asynchronously:

sub vcl_recv {
    if (req.method == "BAN") {
        ban("obj.http.X-Magento-Tags ~ " + req.http.X-Magento-Tags);
        return(synth(200, "Banned"));
    }
}

Enable ban_lurker_sleep in your Varnish params for the lurker to clean up expired bans efficiently.

Practical Checklist

Before calling your FPC setup "production ready":

[ ] Varnish VCL matches your Magento version's template
[ ] X-Magento-Tags headers visible on cached responses
[ ] Tag-based purge tested: update a product, confirm only its pages were purged
[ ] All custom blocks implement IdentityInterface
[ ] Private content blocks use PrivateContentInterface or JS sections
[ ] Form keys removed from server-rendered cacheable blocks
[ ] TTL set to a sensible value (not 0, not 86400 for fast-changing catalogs)
[ ] FPC hit/miss headers enabled in staging for ongoing debugging

Conclusion

Magento 2's Full Page Cache is a sophisticated system — not just "cache the whole page and hope for the best." Understanding cache tags, X-Magento-Vary, ESI hole punching, and granular invalidation gives you a cache that's both fast and accurate.

The stores that get FPC right aren't the ones that flush everything on every deploy. They're the ones that understand what each page depends on, tag it correctly, and invalidate only what changed. That's the difference between a 90% cache hit rate and a 99% one — and in production traffic, that margin matters enormously.

DEV Community: Magevanta

Magento 2 Third-Party Extension Performance Audit: Find and Fix Hidden Bottlenecks

Why Extensions Are the #1 Performance Culprit

Step 1: Baseline Your Current State

Step 2: List Every Installed Extension

Step 3: Profile with Blackfire or the Built-in Profiler

Option A: Blackfire.io (Recommended)

Option B: Magento Built-in Profiler

Option C: New Relic APM

Step 4: Identify the Worst Offenders

4.1 Plugin Chains on Critical Methods

4.2 Observer Storms on Quote Events

4.3 Layout Block Injection on Every Page

4.4 Config Scoped Reads Without Cache

Step 5: Fix Strategies

5.1 Disable Non-Essential Modules for Testing

5.2 Replace around Plugins with before/after

5.3 Add Memoization to Repeated Method Calls

5.4 Move Heavy Logic to Async or Cron

5.5 Scope Layout XML to Specific Handles

Step 6: Ongoing Monitoring

Quick Reference: Audit Checklist

Wrapping Up

Magento 2 Profiling & Performance Debugging: Find Bottlenecks Fast

Why Generic Profiling Isn't Enough

1. Magento's Built-in Profiler

Enable via environment variable

Custom profiler blocks in your own code

2. MySQL Query Logging

Magento's query log via Varien_Db

Spotting N+1 patterns

3. Blackfire.io — The Gold Standard

Installation

Profile a page

Reading the call graph

Blackfire builds & assertions

4. New Relic APM

Install the PHP agent

What to watch in New Relic

5. Tideways — APM Built for PHP Frameworks

6. The Xdebug + KCachegrind Combo (Local Only)

Practical Debugging Workflow

Quick wins to check first

Profiling in CI/CD

Summary

Magento 2 Static Content Deploy Optimization: Faster Builds, Fewer Headaches

Why Static Content Deploy Is Slow

1. Parallelize With -j

2. Scope Your Deploy: Only What You Need

3. Choose the Right Deploy Strategy

quick (default since 2.3)

compact

standard

4. Use --no-html-minify During Development

5. Deploy Admin Separately

6. Content Versioning Strategy

7. Warm pub/static Before Cutting Traffic

8. Symlink Mode for Development

9. CI/CD Integration: Build Once, Distribute Many

10. Monitor Deploy Times

Benchmark: What to Expect

Key Takeaways

Magento 2 Nginx Optimization for High Traffic — Complete Server Tuning Guide

Why Nginx Defaults Aren't Enough

1. Worker Processes and Connections

2. Gzip Compression

3. Keepalive and Timeouts

4. Browser Cache Headers for Static Assets

5. Microcaching with FastCGI Cache

6. SSL/TLS Performance

7. Buffer Tuning

8. Rate Limiting for Admin and API

9. Monitoring What You've Done

Putting It All Together

Magento 2 B2B Performance Optimization: Shared Catalogs, Quotes & Company Accounts

Why B2B Is Different from B2C

1. Shared Catalog — The Hidden Query Bomb

What to profile

Fixes

2. Negotiable Quotes — Price Recalculation Is Expensive

5.2 Replace `around` Plugins with `before`/`after`

1. Parallelize With `-j`

`quick` (default since 2.3)

`compact`

`standard`

4. Use `--no-html-minify` During Development

7. Warm `pub/static` Before Cutting Traffic