DEV Community: Magevanta

How to Reduce Magento 2 Bootstrap Time by 30%

Magevanta — Sun, 19 Apr 2026 18:04:04 +0000

Every time Magento handles a request, it loads hundreds of PHP classes, registers thousands of event observers, and wires up a plugin chain across the entire framework. Most of this work is for modules you never use.

The fix is straightforward in theory: remove unused modules. In practice, it requires care — Magento's dependency graph is complex, and removing the wrong module can break things silently.

Here's how to do it safely.

Why module count matters

A standard Magento 2.4.x installation ships with approximately 420 modules. A typical B2C store actively uses 80–120 of them.

The remaining 300 modules still have a cost:

Autoloader pressure — PHP's autoloader registers class paths for every enabled module. More modules = more paths to check on every class load.
Observer overhead — every enabled module can register event observers. Magento dispatches events on every request; each observer adds overhead.
Plugin chains — interceptors (plugins) wrap core methods. Each plugin adds a function call. Deep plugin chains on hot code paths (like Magento\Framework\App\Http::launch) measurably slow bootstrap.
DI compilation — more modules = larger generated DI configuration = slower di:compile and more memory during compilation.

Which modules are safe to remove?

Generally safe to disable on a standard B2C store:

B2B modules (if you don't use B2B features):

Magento_Company, Magento_SharedCatalog, Magento_NegotiableQuote
Magento_PurchaseOrder, Magento_Requisition

Unused payment methods:

Any Magento_Paypal*, Magento_Braintree, Magento_Authorizenet modules for providers you don't use

Unused shipping methods:

Magento_Fedex, Magento_Ups, Magento_Usps, Magento_Dhl if you use a third-party shipping module

Sample data (if installed):

Magento_CatalogSampleData, Magento_CustomerSampleData, etc.

Staging & Preview (if not on Commerce):

All Magento_*Staging modules

The dependency problem

You can't just disable a module — you need to check if anything depends on it first.

# Check what depends on a module before disabling
bin/magento module:status --show-list | grep -i "Magento_Braintree"

Disabling a module that something else depends on causes cryptic errors. Always check the full dependency tree.

Step-by-step: safe module removal

1. Create a full backup first. Always. No exceptions.

2. Analyze your current module set:

bin/magento module:status > modules-before.txt

3. Identify candidates:

Look for modules in vendor/magento/ that your store doesn't use
Cross-reference with composer.json to see which are explicitly required

4. Test in staging first:

bin/magento module:disable Magento_Braintree --clear-static-content
bin/magento setup:upgrade
bin/magento cache:flush

5. Run your test suite. If you don't have one, manually test checkout, catalog browsing, admin functions.

6. Measure the difference:

# Before
time curl -s https://your-store.com/ > /dev/null

# After disabling modules
time curl -s https://your-store.com/ > /dev/null

7. If all good, repeat in production.

Expected results

Results vary by store configuration, but typical outcomes:

Metric	Before	After (30 modules removed)
Bootstrap time	180ms	130ms
PHP memory peak	28MB	22MB
DI compile time	4m 20s	3m 10s
Observer count	1,840	1,320

A 20–40% bootstrap improvement is realistic on most stores.

Automating this safely

Manual module analysis is tedious and error-prone. The BetterMagento Turbo Core module provides an interactive CLI wizard that:

Builds the complete dependency graph for your installation
Identifies modules with no dependents that aren't actively used
Shows you the safe removal candidates ranked by impact
Lets you preview changes before applying them
Generates a rollback script so you can undo any change

# Analyze your installation
bin/magento bm:turbo:analyze

# Preview what would be removed
bin/magento bm:turbo:optimize --dry-run

# Apply with automatic rollback script generation
bin/magento bm:turbo:optimize --generate-rollback

Important caveats

Always test in staging before production
Re-run analysis after major Magento upgrades
Some modules appear unused but are required by custom code — the analyzer checks for this
Magento updates may re-enable disabled modules; check after upgrades

The performance gains are real and compound with other optimizations. Combined with Redis caching, query optimization, and edge delivery, you can cut total request time by 60%+ on a well-tuned store.

Originally published on magevanta.com

Magento 2 Deployment: Zero-Downtime Production Deployments

Magevanta — Sun, 19 Apr 2026 18:03:28 +0000

Magento deployments done wrong mean minutes of downtime, broken shopping carts, and unhappy customers. Done right, they're invisible — customers never notice. Here's how to get there.

Why Magento deployments are hard

A typical Magento deployment touches:

PHP files (application code)
Generated code (var/generation/, generated/)
Static files (pub/static/)
Database schema and data
Cache (must be flushed)

The challenge: each of these operations takes time, and during that time your store is in an inconsistent state. New code referencing old database schema. New static files not yet deployed. Old cached content serving.

The naive approach (and why it fails)

# Bad: everything happens in-place
git pull origin main
composer install
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy
php bin/magento cache:flush

During setup:di:compile (2–5 minutes), your store serves requests without compiled DI — intermittent 500 errors. During setup:static-content:deploy, JS/CSS files may be missing. Classic downtime.

Approach 1: Maintenance mode (simple, has downtime)

php bin/magento maintenance:enable --ip=YOUR_IP

git pull origin main
composer install --no-dev --optimize-autoloader
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy -f en_US
php bin/magento cache:flush

php bin/magento maintenance:disable

Maintenance mode shows a "temporarily unavailable" page. Downtime: 3–10 minutes depending on catalog size. Acceptable for small stores, not for high-traffic production.

Approach 2: Atomic symlink deployment (zero downtime)

The industry-standard approach: deploy to a new directory, then atomically switch the webserver symlink.

Directory structure:

/var/www/
├── releases/
│   ├── 20260419_143000/    ← current deployment
│   └── 20260419_120000/    ← previous deployment
├── shared/
│   ├── pub/media/          ← shared across deployments
│   ├── var/                ← shared var directory
│   └── app/etc/env.php     ← shared config
└── current -> releases/20260419_143000/  ← symlink

Deployment script:

#!/bin/bash
set -e

RELEASE_DIR="/var/www/releases/$(date +%Y%m%d_%H%M%S)"
SHARED_DIR="/var/www/shared"
CURRENT_LINK="/var/www/current"

# 1. Create new release directory
mkdir -p "$RELEASE_DIR"
git clone --depth=1 git@github.com:yourorg/magento-store.git "$RELEASE_DIR"
cd "$RELEASE_DIR"

# 2. Install dependencies
composer install --no-dev --optimize-autoloader --no-interaction

# 3. Link shared directories
rm -rf pub/media var app/etc/env.php
ln -s "$SHARED_DIR/pub/media" pub/media
ln -s "$SHARED_DIR/var" var
ln -s "$SHARED_DIR/app/etc/env.php" app/etc/env.php

# 4. Build static assets and DI (while old release is still live)
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy -f en_US de_DE

# 5. Run database upgrades (safe to run before switch)
php bin/magento setup:upgrade --keep-generated

# 6. ATOMIC SWITCH — this is instant
ln -sfn "$RELEASE_DIR" "$CURRENT_LINK"

# 7. Flush caches (new code is now live)
php bin/magento cache:flush

# 8. Clean up old releases (keep last 3)
ls -t /var/www/releases | tail -n +4 | xargs -I{} rm -rf "/var/www/releases/{}"

echo "Deployment complete: $RELEASE_DIR"

The key is step 6: ln -sfn is an atomic operation on Linux. The webserver symlink switches from old to new in a single filesystem operation — no window where the symlink is broken.

Approach 3: Blue-green deployment

For maximum safety: run two identical environments (blue and green), load balancer switches between them.

Load Balancer
├── Blue environment (magento-blue.internal)  ← currently live
└── Green environment (magento-green.internal) ← deploy here

Process:

Deploy to green while blue serves traffic
Run smoke tests on green
Switch load balancer to green (instant, no downtime)
Blue becomes the new staging environment

Works best with containerized deployments (Docker/Kubernetes) or if your hosting provider supports it (AWS, GCP, Azure).

Database migrations without downtime

setup:upgrade runs database migrations. Running migrations while the store is live risks:

Old code reading new schema columns that don't exist yet
New code failing on old schema

Backward-compatible migration pattern:

Phase 1 (current deployment): add new column as nullable with default

ALTER TABLE sales_order ADD COLUMN new_field VARCHAR(255) DEFAULT NULL;

Phase 2 (next deployment): make the column required, backfill data

UPDATE sales_order SET new_field = 'default_value' WHERE new_field IS NULL;
ALTER TABLE sales_order MODIFY COLUMN new_field VARCHAR(255) NOT NULL DEFAULT '';

Phase 3 (later): remove old compatibility code

This "expand and contract" pattern lets you run migrations without the risk of old code breaking on new schema.

CI/CD pipeline example (GitHub Actions)

name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy via SSH
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.PROD_HOST }}
          username: deploy
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /var/www
            ./scripts/deploy.sh

      - name: Smoke test
        run: |
          sleep 10
          curl -f https://your-store.com/ || exit 1
          curl -f https://your-store.com/catalog/product/view/id/1 || exit 1

Post-deployment checklist

# Verify indexers aren't invalid
bin/magento indexer:status

# Verify caches are warmed
curl -s -o /dev/null -w "%{http_code} %{time_total}s" https://your-store.com/

# Check error logs
tail -50 var/log/system.log | grep -i error
tail -50 var/log/exception.log

# Verify static files deployed
curl -I https://your-store.com/static/frontend/Magento/luma/en_US/requirejs/require.js

Zero-downtime deployments require upfront setup but pay off immediately — no more stress about deployment windows, no more customer complaints during releases.

Originally published on magevanta.com

Magento 2 Varnish Configuration: The Production-Ready Setup

Magevanta — Sun, 19 Apr 2026 17:55:22 +0000

Varnish is the gold standard for full-page caching in front of Magento. Configured correctly, it serves the vast majority of your traffic without touching PHP at all — response times under 5ms. Configured incorrectly, it creates subtle bugs and a false sense of security.

Here's the production-ready setup.

Why Varnish over Magento's built-in FPC

Magento ships with a built-in full page cache (backed by filesystem or Redis). Varnish is better for high-traffic stores because:

It sits in front of PHP entirely — Varnish serves cached responses without starting PHP-FPM at all
Massive throughput — Varnish can serve tens of thousands of requests per second on modest hardware
ESI support — Edge Side Includes let you cache most of a page while keeping dynamic fragments fresh
Sophisticated TTL control — per-URL, per-content-type, per-header rules

For stores under ~10k daily visits, Redis FPC is often sufficient. Above that, Varnish pays for itself.

Installing and wiring up Varnish

Install Varnish 7.x on Ubuntu/Debian:

apt-get install varnish

Configure Varnish to listen on port 80, proxy to your web server on port 8080:

/etc/varnish/default.vcl

Tell Magento to use Varnish:

bin/magento config:set system/full_page_cache/caching_application 2
bin/magento config:set system/full_page_cache/varnish/access_list "127.0.0.1"
bin/magento config:set system/full_page_cache/varnish/backend_host "127.0.0.1"
bin/magento config:set system/full_page_cache/varnish/backend_port "8080"

Generate the Magento-recommended VCL:

bin/magento varnish:vcl:generate --export-version=7 > /etc/varnish/default.vcl
service varnish restart

The critical VCL settings most guides miss

1. Normalize Accept-Encoding headers

Without this, Varnish caches separate entries for gzip, deflate, and uncompressed responses — tripling your cache size:

sub vcl_recv {
    if (req.http.Accept-Encoding) {
        if (req.url ~ "\.(jpg|jpeg|png|gif|gz|tgz|bz2|ico|mp4|ogg|swf|flv)$") {
            unset req.http.Accept-Encoding;
        } elsif (req.http.Accept-Encoding ~ "gzip") {
            set req.http.Accept-Encoding = "gzip";
        } else {
            unset req.http.Accept-Encoding;
        }
    }
}

2. Strip marketing query parameters

?utm_source=google&utm_campaign=spring creates separate cache entries for every ad campaign click. Strip them:

sub vcl_recv {
    set req.url = regsuball(req.url, "[?&](utm_source|utm_medium|utm_campaign|utm_content|gclid|fbclid)=[^&]+", "");
    set req.url = regsub(req.url, "^([^?]*)\?$", "\1");
}

3. Never cache logged-in sessions

Magento sets a X-Magento-Vary cookie for logged-in users. Ensure Varnish passes these through:

sub vcl_recv {
    if (req.http.cookie ~ "PHPSESSID" || req.http.cookie ~ "frontend") {
        return (pass);
    }
}

ESI for dynamic content

ESI (Edge Side Includes) lets you cache 95% of a page in Varnish while keeping specific fragments dynamic — like the cart count, customer name, or "recently viewed" widget.

In your layout XML:

<block class="Magento\PageCache\Block\Esi" name="cart.count">
    <arguments>
        <argument name="handles" xsi:type="array">
            <item name="default" xsi:type="string">default</item>
        </argument>
        <argument name="ttl" xsi:type="string">600</argument>
    </arguments>
</block>

Varnish assembles the final page by fetching the ESI fragment separately (served from a shorter-TTL cache or PHP directly).

Enable ESI in Varnish:

sub vcl_backend_response {
    set beresp.do_esi = true;
}

Cache purging on content updates

When a product is updated, Magento sends a BAN request to Varnish to invalidate affected cache entries. Your VCL must handle this:

acl purge {
    "127.0.0.1";
}

sub vcl_recv {
    if (req.method == "PURGE") {
        if (!client.ip ~ purge) {
            return (synth(403, "Not allowed"));
        }
        return (purge);
    }

    if (req.method == "BAN") {
        if (!client.ip ~ purge) {
            return (synth(403, "Not allowed"));
        }
        ban("obj.http.X-Magento-Tags ~ " + req.http.X-Magento-Tags-Pattern);
        return (synth(200, "Banned"));
    }
}

This enables Magento's tag-based Varnish purging — only pages containing the updated product/category are invalidated, not your entire cache.

Monitoring Varnish

Key metrics to watch:

# Overall hit rate
varnishstat -1 -f "MAIN.cache_hit" -f "MAIN.cache_miss"

# Current request rate
varnishstat -1 -f "MAIN.client_req"

# Live request log
varnishlog -i ReqURL -q "ReqMethod eq 'GET'"

# Objects in cache
varnishstat -1 -f "MAIN.n_object"

Target hit rate: > 85% for anonymous traffic. If you're below this, check:

Are you stripping UTM parameters? (cache fragmentation)
Are logged-in user requests being passed correctly?
Are your TTLs too short?

Common mistakes

Mistake	Symptom	Fix
Not stripping UTM params	Low hit rate	Add regex filter in vcl_recv
Caching 404 pages	Cache pollution	Set short TTL for non-2xx responses
Not normalizing Accept-Encoding	3× cache size	Strip and re-set header
Missing BAN ACL	Cache never purges	Add purge ACL and handler
ESI not enabled	Dynamic content cached	Set `beresp.do_esi = true`

Varnish + tag-based purging + ESI for dynamic fragments is the fastest Magento caching architecture available. Get the configuration right and you'll serve millions of requests without breaking a sweat.

Originally published on magevanta.com

Magento 2 Slow Queries: How to Find and Fix Them

Magevanta — Sun, 19 Apr 2026 17:54:46 +0000

If your Magento store is slow, the database is almost always the first place to look. A single unoptimized query running on every page load can add hundreds of milliseconds to your response time — and on a store with thousands of products, slow queries are almost inevitable.

Here's the complete playbook.

Step 1: Enable the slow query log

MySQL and MariaDB have a built-in slow query log. Enable it on your server:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow-queries.log';
SET GLOBAL log_queries_not_using_indexes = 'ON';

Set long_query_time to 1 second as a starting threshold. Once you've fixed the worst offenders, lower it to 0.5 or even 0.1.

For permanent configuration, add to my.cnf:

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow-queries.log
long_query_time = 1
log_queries_not_using_indexes = 1

Step 2: Analyze the slow query log

After collecting a few hours of data, use mysqldumpslow to summarize:

mysqldumpslow -s t -t 20 /var/log/mysql/slow-queries.log

This shows your 20 slowest queries sorted by total execution time. You'll typically find a handful of queries responsible for 80%+ of your database load.

Step 3: Run EXPLAIN on slow queries

For each slow query, run EXPLAIN to understand what MySQL is doing:

EXPLAIN SELECT e.entity_id, a1.value AS name
FROM catalog_product_entity e
LEFT JOIN catalog_product_entity_varchar a1
  ON e.entity_id = a1.entity_id AND a1.attribute_id = 73
WHERE e.entity_id IN (1, 2, 3, 4, 5);

Key things to look for in the output:

Column	Bad sign	Good sign
`type`	`ALL` (full table scan)	`ref`, `eq_ref`, `const`
`key`	`NULL` (no index used)	Index name
`rows`	High number	Low number
`Extra`	`Using filesort`, `Using temporary`	`Using index`

A type: ALL with rows: 500000 means MySQL is scanning your entire products table for every request. That's a critical fix.

Step 4: Add missing indexes

Once you've identified a query doing a full table scan, check if an index would help:

-- Check existing indexes
SHOW INDEX FROM catalog_product_entity_varchar;

-- Add an index if missing
ALTER TABLE catalog_product_entity_varchar
ADD INDEX idx_entity_attribute (entity_id, attribute_id);

Warning: Adding indexes on large tables takes time and locks the table. Use ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE on MySQL 5.7+ or run during a maintenance window.

Step 5: Common Magento slow query patterns

EAV overload — too many attribute joins:

Magento's EAV architecture means product data is spread across multiple tables. A single product load can generate 20–30 joins. The fix: use flat catalog tables or selectively index frequently-accessed attributes.

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

Unindexed product collection filters:

Custom collection filters on non-indexed attributes cause full scans. Always check if the attribute has Used in Search or a proper index.

ORDER BY on non-indexed columns:

Sorting on columns without indexes causes Using filesort — MySQL sorts in memory or on disk instead of using an index.

-- Add a composite index for common sort patterns
ALTER TABLE sales_order ADD INDEX idx_created_status (created_at, status);

N+1 queries in loops:

// Bad: 1 query per product
foreach ($products as $product) {
    $category = $product->getCategory(); // new query each iteration
}

// Good: load all at once
$productIds = $products->getAllIds();
$categories = $categoryRepository->getListByProductIds($productIds);

Step 6: Query result caching

Some queries are inherently expensive but don't change often — complex reports, faceted navigation counts, bestseller calculations. Cache their results:

$cacheKey = 'category_product_count_' . $categoryId;
$result = $this->cache->load($cacheKey);

if (!$result) {
    $result = $this->runExpensiveQuery($categoryId);
    $this->cache->save(serialize($result), $cacheKey, ['category_' . $categoryId], 3600);
}

Automating the process

Manual slow query analysis works but doesn't scale. The BetterMagento Query Optimizer automates the entire workflow:

Continuously monitors your slow query log
Runs EXPLAIN analysis automatically
Suggests specific indexes with the exact ALTER TABLE statements to run
Tracks query performance over time
Alerts you when new slow queries appear

For most stores, it finds 5–15 high-impact indexes that can be added in under an hour — often cutting total database query time by 40–60%.

Summary checklist

[ ] Enable slow query log (threshold: 1s)
[ ] Analyze with mysqldumpslow weekly
[ ] Run EXPLAIN on top 10 slow queries
[ ] Add missing indexes
[ ] Enable flat catalog tables
[ ] Cache results of expensive but stable queries
[ ] Set up automated monitoring

Originally published on magevanta.com

Magento 2 Security Hardening: A Production Checklist for 2026

Magevanta — Sun, 19 Apr 2026 17:49:00 +0000

Magento stores are high-value targets. They process payments, store customer data, and often run on shared infrastructure. A compromised store means payment card theft, data breaches, and regulatory fines.

This checklist covers the most impactful security hardening steps for a production Magento 2 store.

1. Change the admin URL

The default admin URL /admin is targeted by automated scanners within hours of a store going live. Change it to something non-obvious:

bin/magento setup:config:set --backend-frontname="your_secret_admin_path"
bin/magento cache:flush

Or in app/etc/env.php:

'backend' => ['frontName' => 'your_secret_path'],

Use something random and non-guessable. Not /manager, /backend, or /store-admin.

2. Enable two-factor authentication

Magento 2.4+ ships with 2FA built in. Enable it and enforce it for all admin users:

bin/magento module:enable Magento_TwoFactorAuth
bin/magento setup:upgrade

Supported authenticators: Google Authenticator, Authy, Duo Security, U2F.

For headless admin access (API), whitelist specific IPs instead of disabling 2FA:

bin/magento config:set twofactorauth/general/force_providers "google"

3. File permissions

Magento's recommended file permissions:

# Directories
find var generated vendor pub/static pub/media app/etc -type d -exec chmod 770 {} +

# Files  
find var generated vendor pub/static pub/media app/etc -type f -exec chmod 660 {} +

# bin/magento
chmod 770 bin/magento

# Never allow write on app/code
find app/code -type f -exec chmod 640 {} +
find app/code -type d -exec chmod 750 {} +

Critical: app/etc/env.php contains database credentials. Ensure it's not world-readable:

chmod 640 app/etc/env.php

4. Disable directory listing

In your nginx config:

autoindex off;

Or in Apache .htaccess:

Options -Indexes

Directory listing exposes your file structure to attackers.

5. Content Security Policy headers

Magento 2.4+ has CSP support. Enable report-only mode first to find violations without breaking your store:

bin/magento config:set csp/mode/storefront/report_only 1
bin/magento config:set csp/mode/admin/report_only 1

Configure your CSP whitelist in Admin → Security → Content Security Policy. Add your analytics, payment processor, and CDN domains.

Once violations are resolved, switch to enforce mode:

bin/magento config:set csp/mode/storefront/report_only 0

6. Security headers

Add these to your nginx config:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

# Only once CSP is configured
# add_header Content-Security-Policy "..." always;

7. Keep Magento patched

Magento releases security patches regularly. Subscribe to the Magento security alert RSS feed and the Adobe security bulletin.

# Check current version
bin/magento --version

# Check for available updates
composer outdated magento/*

Apply security patches within 2 weeks of release. Critical patches within 48 hours.

8. Restrict admin access by IP

If your team accesses admin from predictable IPs, whitelist them at the nginx level:

location ~* ^/your_admin_path {
    allow 1.2.3.4;  # office IP
    allow 5.6.7.8;  # developer IP
    deny all;

    try_files $uri $uri/ /index.php$is_args$args;
}

This stops brute-force admin attacks even if the attacker knows your admin URL.

9. Disable unused payment methods and modules

Every enabled payment method is potential attack surface. Disable anything you don't use:

bin/magento module:disable Magento_Paypal
bin/magento module:disable Magento_Braintree
# etc.
bin/magento setup:upgrade

10. Monitor for malware

Magento stores are targeted by card-skimming malware (Magecart attacks). Malware is typically injected into:

JavaScript files in pub/static/
PHP files in app/code/ or templates
Database (inline scripts in CMS blocks or product descriptions)

Set up file integrity monitoring:

# Create a baseline hash of all PHP files
find app/code vendor/magento -name "*.php" -exec md5sum {} \; > /var/integrity/baseline.txt

# Run daily and alert on changes
find app/code vendor/magento -name "*.php" -exec md5sum {} \; | diff /var/integrity/baseline.txt - | grep "^>"

For database-injected malware, scan CMS blocks and product descriptions weekly:

SELECT * FROM cms_block WHERE content LIKE '%<script%' AND content NOT LIKE '%requirejs%';

11. Secure env.php

app/etc/env.php contains your database password, Redis password, and encryption key. Never commit it to version control:

echo "app/etc/env.php" >> .gitignore

Use environment variables or a secrets manager for CI/CD pipelines:

export DB_PASSWORD=$(aws secretsmanager get-secret-value --secret-id prod/magento/db --query SecretString --output text | jq -r .password)

Security audit checklist

[ ] Admin URL changed from /admin
[ ] 2FA enabled for all admin users
[ ] File permissions set correctly
[ ] env.php not world-readable, not in git
[ ] Directory listing disabled
[ ] Security headers configured (X-Frame-Options, X-Content-Type)
[ ] CSP in report-only mode (working toward enforce)
[ ] Admin IP restriction (if team has static IPs)
[ ] Unused modules and payment methods disabled
[ ] File integrity monitoring running
[ ] On latest Magento security patch
[ ] SSL/TLS 1.3 enabled, TLS 1.0/1.1 disabled

Security is never "done" — it's an ongoing process. Schedule a quarterly security review against this checklist.

Originally published on magevanta.com

Magento 2 Redis Configuration: The Complete Guide for 2026

Magevanta — Sun, 19 Apr 2026 17:48:24 +0000

Redis is table stakes for any production Magento store. But "just install Redis" is not enough — the default configuration leaves significant performance on the table. Here's how to configure it correctly.

Why separate Redis instances matter

Many guides tell you to point all Magento caches at a single Redis instance. Don't do this.

Magento uses Redis for three distinct workloads:

Default cache — config, layouts, translations (many small, short-lived keys)
Full Page Cache (FPC) — rendered HTML pages (large values, longer TTL)
Sessions — customer session data (medium values, must persist)

Mixing these in one instance creates problems:

FPC's large HTML values evict small config cache entries under memory pressure
A cache flush (cache:flush) wipes sessions if they share the same database
You can't tune eviction policy per workload

The right setup: 3 separate Redis instances (or at minimum, separate databases on one instance with different maxmemory settings).

`env.php` configuration

<?php
return [
    'cache' => [
        'frontend' => [
            'default' => [
                'id_prefix' => 'mage_',
                'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
                'backend_options' => [
                    'server' => '127.0.0.1',
                    'database' => '0',
                    'port' => '6379',
                    'password' => '',
                    'compress_data' => '1',
                    'compression_lib' => 'lzf',
                ],
            ],
            'page_cache' => [
                'id_prefix' => 'mage_fpc_',
                'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
                'backend_options' => [
                    'server' => '127.0.0.1',
                    'database' => '1',  // separate DB
                    'port' => '6379',
                    'compress_data' => '1',
                    'compression_lib' => 'lzf',
                ],
            ],
        ],
    ],
    'session' => [
        'save' => 'redis',
        'redis' => [
            'host' => '127.0.0.1',
            'port' => '6379',
            'password' => '',
            'timeout' => '2.5',
            'persistent_identifier' => '',
            'database' => '2',  // separate DB
            'compression_threshold' => '2048',
            'compression_library' => 'lzf',
            'log_level' => '1',
            'max_concurrency' => '6',
            'break_after_frontend' => '5',
            'break_after_adminhtml' => '30',
            'first_lifetime' => '600',
            'bot_first_lifetime' => '60',
            'bot_lifetime' => '7200',
            'disable_locking' => '0',
            'min_lifetime' => '60',
            'max_lifetime' => '2592000',
        ],
    ],
];

Redis server configuration

Tune your Redis redis.conf per workload:

For default cache (DB 0) — aggressive eviction, it's rebuildable:

maxmemory 512mb
maxmemory-policy allkeys-lru

For full page cache (DB 1) — larger allocation, LRU eviction:

maxmemory 2gb
maxmemory-policy allkeys-lru

For sessions (DB 2) — no eviction, sessions must persist:

maxmemory 256mb
maxmemory-policy noeviction

The noeviction policy for sessions is critical. Without it, Redis can evict session keys under memory pressure — silently logging customers out.

Connection pooling with PHP-FPM

Each PHP-FPM worker opens its own connection to Redis. With 100 workers and 3 Redis connections each, you're looking at 300 simultaneous connections.

Mitigate this with persistent_identifier in your session config and connection pooling via Twemproxy or Redis Cluster if you're at scale.

Compression settings

Enabling compression reduces memory usage by 40–60% for typical Magento cache values:

Library	Speed	Ratio	Best for
`lzf`	Very fast	~2x	Default cache, sessions
`lz4`	Extremely fast	~2x	High-throughput FPC
`zstd`	Fast	~3-4x	Large HTML pages in FPC

Set compression_threshold to 2048 bytes — don't compress small values, the overhead isn't worth it.

Monitoring Redis health

Check these regularly:

# Overall stats
redis-cli info stats

# Memory usage
redis-cli info memory | grep used_memory_human

# Hit rate (aim for > 95%)
redis-cli info stats | grep -E "keyspace_hits|keyspace_misses"

# Top 10 slowest commands
redis-cli slowlog get 10

# Keys by database
redis-cli info keyspace

Hit rate formula: hits / (hits + misses) * 100

If your hit rate drops below 80%, you either have a memory pressure problem (increase maxmemory) or a cache invalidation problem (too aggressive flushing).

Cache warming after deploys

After a full cache flush (e.g. post-deploy), your store will be slow until Redis warms back up. Automate warming:

#!/bin/bash
# warm-cache.sh — crawl top pages after deploy
urls=(
  "https://your-store.com/"
  "https://your-store.com/catalog/category/view/id/5"
  "https://your-store.com/catalog/product/view/id/100"
)

for url in "${urls[@]}"; do
  curl -s -o /dev/null "$url"
  echo "Warmed: $url"
done

The BetterMagento Redis Turbo module automates cache warming, monitors hit rates in the admin panel, and provides tag-based invalidation so you never have to flush the entire cache again.

Quick reference: common mistakes

Mistake	Fix
Single Redis instance for all caches	Use separate databases or instances
No compression	Enable `lzf` compression
`noeviction` on cache (not sessions)	Use `allkeys-lru` for cache
Sessions sharing DB with cache	Separate DB, `noeviction` policy
No monitoring	Track hit rate, memory, slowlog
Full flush on every deploy	Use tag-based invalidation

Originally published on magevanta.com

Redis Caching for Magento 2: Beyond the Basics

Magevanta — Sun, 19 Apr 2026 17:42:37 +0000

Redis is the standard cache backend for production Magento stores. But most setups barely scratch the surface of what Redis can do — and pay the price in unnecessary cache flushes, slow bulk writes, and missing monitoring.

Here's how to do it right.

The problem with default Magento Redis config

Magento's built-in Redis integration works. But it has significant limitations:

Full cache flushes on every save. By default, Magento flushes the entire cache when a product is saved. On a store with 100k products, that means your entire page cache is cold after every catalog update.

No pipeline batching. Each cache read/write is a separate TCP round-trip to Redis. For operations that set 50+ cache keys at once (like loading a category page), this adds up.

No cluster support. Magento's Redis adapter supports Sentinel (failover) but not Redis Cluster (horizontal scaling). On high-traffic stores, a single Redis instance becomes a bottleneck.

Tag-based cache invalidation

The fix for full cache flushes: tag every cache entry with the entities it depends on.

// Store cache entry with tags
$cache->save($data, 'product_detail_123', ['product_123', 'category_5']);

// Later: flush only entries tagged with product_123
$cache->clean(\Zend_Cache::CLEANING_MODE_MATCHING_TAG, ['product_123']);

When product 123 is updated, only the pages that display that product are invalidated — not your entire cache.

The challenge: Magento's cache adapter doesn't support this natively. You need a custom adapter that maintains a tag-to-key mapping in Redis.

Expected improvement: 90%+ reduction in cache misses after catalog updates.

Pipeline batching

Redis pipelines let you batch multiple commands into a single network round-trip:

// Without pipelining: 50 round-trips
foreach ($keys as $key) {
    $redis->set($key, $data[$key]);
}

// With pipelining: 1 round-trip
$pipe = $redis->pipeline();
foreach ($keys as $key) {
    $pipe->set($key, $data[$key]);
}
$pipe->execute();

For category pages that set 50–100 cache keys, pipelining reduces cache-write time from ~100ms to ~5ms.

Redis Cluster vs. Sentinel

Sentinel handles failover — if your primary Redis instance dies, Sentinel promotes a replica. You get high availability, but you're still limited to one primary node handling all writes.

Redis Cluster shards data across multiple nodes. You can scale writes horizontally by adding nodes. For stores doing millions of cache operations per hour, this matters.

Configuration for Cluster in env.php:

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'BetterMagento\RedisTurbo\Cache\Backend\RedisCluster',
            'backend_options' => [
                'cluster_nodes' => [
                    'redis-node-1:6379',
                    'redis-node-2:6379',
                    'redis-node-3:6379',
                ],
            ],
        ],
    ],
],

Session clustering

Storing PHP sessions in Redis works well — but default configuration has a gotcha: if you have multiple app servers, a user's session can be on any node. If that node goes down, they're logged out.

Sticky sessions solve this: route each user consistently to the same app server (and therefore the same Redis primary). Configure this at your load balancer level.

For extra safety, enable session compression:

'session' => [
    'save' => 'redis',
    'redis' => [
        'compression_threshold' => 2048, // compress sessions > 2KB
        'compression_library' => 'lzf',
    ],
],

Compression for large values

Redis stores data in memory. Uncompressed cache values for full pages can be 50–200KB each. At scale, this adds up to gigabytes.

Enable LZ4 or Zstandard compression for values above a threshold:

LZ4: fastest compression, ~2x ratio — best for latency-sensitive caches
Zstandard: slower compression, ~3–4x ratio — best for full page cache

Expected improvement: 30–50% reduction in Redis memory usage.

Monitoring

You can't optimize what you don't measure. Key metrics to track:

Hit rate — aim for >95% on page cache, >80% on default cache
Memory usage — alert at 80% of maxmemory
Slow commands — SLOWLOG GET 10 in redis-cli
Eviction rate — any evictions indicate memory pressure

The BetterMagento Redis Turbo module ships with an admin dashboard showing all of these in real time.

Summary

Issue	Solution	Impact
Full cache flushes	Tag-based invalidation	⭐⭐⭐⭐⭐
Slow bulk writes	Pipeline batching	⭐⭐⭐⭐
Single-node bottleneck	Redis Cluster	⭐⭐⭐
High memory usage	LZ4/Zstandard compression	⭐⭐⭐
No visibility	Admin monitoring dashboard	⭐⭐

Small config changes, massive performance gains.

Originally published on magevanta.com

Magento 2 Performance Optimization: The Complete 2026 Guide

Magevanta — Sun, 19 Apr 2026 17:42:01 +0000

Every second of load time costs you conversions. Studies consistently show a 1-second delay reduces conversions by 7%. For Magento stores, the challenge is real: Magento is a powerful platform, but out-of-the-box performance leaves room for improvement.

This guide walks through the most impactful optimizations you can make in 2026.

1. Database Query Optimization

The database is almost always the biggest bottleneck in a slow Magento store. Common culprits:

N+1 query problems — loading related data in loops instead of joins
Missing indexes — queries doing full table scans on large catalog tables
Unoptimized EAV queries — Magento's EAV structure can generate hundreds of queries per page

What to do:

Enable the MySQL slow query log and set a threshold of 1–2 seconds. Analyze the output weekly. For any slow query, run EXPLAIN to see if it's missing an index.

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

Tools like BetterMagento Query Optimizer can automate this — detecting slow queries, running EXPLAIN analysis, and suggesting indexes without manual work.

2. Redis Caching

Magento's default cache backend (filesystem) doesn't scale. Redis is the standard for production:

Full Page Cache — cache rendered HTML pages
Default cache — config, layout, translations
Session storage — distributed sessions for multi-server setups

The difference in response times is dramatic: filesystem cache typically adds 50–200ms per request, Redis brings it under 5ms.

Key configuration pitfalls:

Use separate Redis instances for FPC and default cache
Enable compression for large cache values
Use tag-based invalidation — don't flush everything on every deploy

3. API Performance for Headless Stores

If you're running a headless frontend (React, Next.js, Vue), your GraphQL/REST API performance becomes critical.

Key optimizations:

Persisted queries — store query hashes server-side, send only the hash from the client
Response compression — Brotli reduces payload size by 60–70% vs uncompressed
Field pruning — only return the fields the client actually requested
Rate limiting — protect your API from abuse without blocking legitimate traffic

4. Edge Delivery

Traditional Magento runs everything on a single origin server. Edge delivery moves rendering to CDN edge nodes close to your users — cutting latency dramatically.

For a user in Tokyo hitting a server in Frankfurt, latency alone adds 200–300ms per request. With edge delivery, that drops to under 50ms.

Platforms like Cloudflare Workers and Fastly Compute@Edge support this model today.

5. Module Bloat

A default Magento 2 installation ships with 400+ modules. Most stores use fewer than 100 of them. Every unused module adds:

PHP classes that must be autoloaded
Observers that run on every event
Plugins that wrap core methods

Safely removing unused modules can reduce bootstrap time by 20–40%. Always use a tool that checks dependencies before removing anything.

6. Core Web Vitals

Google uses Core Web Vitals as a ranking signal. For Magento stores, the most impactful metrics are:

Metric	Target	Common Magento Issue
LCP	< 2.5s	Unoptimized hero images, slow TTFB
FID/INP	< 200ms	Heavy JS bundles, third-party scripts
CLS	< 0.1	Missing image dimensions, late-loading fonts

Quick wins:

Add width and height attributes to all images
Preload your LCP image with <link rel="preload">
Defer non-critical JavaScript
Use a CDN for static assets

Putting it all together

Performance optimization is a process, not a one-time fix. The highest-impact stack for 2026:

Redis for all caching layers
Tag-based cache invalidation (not full flushes)
Database query monitoring with automated suggestions
API compression and caching for headless deployments
Edge delivery for global audiences
Module audit to remove unused Magento core modules

The BetterMagento Suite covers all of these in one package.

Originally published on magevanta.com

Magento 2 Module Development Best Practices in 2026

Magevanta — Sun, 19 Apr 2026 17:36:14 +0000

Writing Magento 2 modules that don't break stores, don't slow down performance, and survive upgrades requires discipline. After working on production Magento codebases, here are the patterns that matter most.

Service contracts: the right way to expose functionality

Never depend directly on concrete model classes. Always use interfaces (service contracts):

// Bad: depends on a concrete class
public function __construct(
    \Magento\Catalog\Model\Product $product
) {}

// Good: depends on an interface
public function __construct(
    \Magento\Catalog\Api\ProductRepositoryInterface $productRepository
) {}

Why it matters: concrete models can be replaced or overridden in customized Magento installations. Depending on interfaces makes your module resilient to those changes.

If your module exposes its own functionality, define interfaces first:

// Api/MyModuleServiceInterface.php
interface MyModuleServiceInterface
{
    public function process(int $entityId): ResultInterface;
}

// Model/MyModuleService.php
class MyModuleService implements MyModuleServiceInterface
{
    public function process(int $entityId): ResultInterface { ... }
}

Plugins vs. observers: choosing correctly

Both plugins and observers let you hook into Magento's core behavior. Choosing wrong creates bugs and performance problems.

Use observers when:

You're reacting to something that already happened (after event)
Multiple modules might observe the same event (no conflict)
You don't need to modify the return value

// Good observer usage: react to order placement
public function execute(\Magento\Framework\Event\Observer $observer): void
{
    $order = $observer->getOrder();
    $this->notificationService->notifyNewOrder($order->getId());
}

Use plugins when:

You need to modify input parameters (before plugin)
You need to modify the return value (after plugin)
You need to wrap execution (around plugin)

// Good plugin usage: add data to a repository result
public function afterGetById(
    ProductRepositoryInterface $subject,
    ProductInterface $result,
    int $productId
): ProductInterface {
    $result->setCustomData($this->getCustomData($productId));
    return $result;
}

Avoid around plugins unless necessary. Around plugins intercept the entire method call and are significantly slower than before/after plugins. They also make debugging harder.

Dependency injection done right

Magento's DI system is powerful but easy to misuse.

Use constructor injection for required dependencies:

public function __construct(
    private readonly LoggerInterface $logger,
    private readonly CacheInterface $cache,
    private readonly ProductRepositoryInterface $productRepository,
) {}

Use factories for objects you create on-the-fly:

public function __construct(
    private readonly \Magento\Catalog\Model\ProductFactory $productFactory,
) {}

public function createProduct(): Product
{
    return $this->productFactory->create();
}

Inject the ObjectManager directly: never. It bypasses DI, makes testing impossible, and creates hidden dependencies.

Performance-conscious coding

Avoid loading product/order collections in loops:

// Bad: O(n) queries
foreach ($orderIds as $orderId) {
    $order = $this->orderRepository->get($orderId); // query per iteration
    $this->process($order);
}

// Good: load all at once
$searchCriteria = $this->searchCriteriaBuilder
    ->addFilter('entity_id', $orderIds, 'in')
    ->create();
$orders = $this->orderRepository->getList($searchCriteria);
foreach ($orders->getItems() as $order) {
    $this->process($order);
}

Cache expensive operations:

public function getExpensiveData(int $id): array
{
    $cacheKey = 'my_module_data_' . $id;
    $cached = $this->cache->load($cacheKey);

    if ($cached !== false) {
        return unserialize($cached);
    }

    $data = $this->runExpensiveCalculation($id);
    $this->cache->save(serialize($data), $cacheKey, ['my_module_tag'], 3600);

    return $data;
}

Use indexers for frequently-queried derived data:

If you're computing something on every page load that could be pre-computed (like product scores, custom pricing, or aggregated stats), build an indexer. Compute once, read many times.

Testing your module

Untested Magento modules break in production. At minimum:

Unit tests for business logic:

class MyServiceTest extends TestCase
{
    public function testProcessReturnsSuccessResult(): void
    {
        $service = new MyService(
            $this->createMock(LoggerInterface::class),
            $this->createMock(CacheInterface::class),
        );

        $result = $service->process(1);

        $this->assertTrue($result->isSuccess());
    }
}

Integration tests for database operations and DI-heavy code:

class MyRepositoryTest extends \Magento\TestFramework\TestCase\AbstractController
{
    public function testSaveAndLoad(): void
    {
        $repository = $this->_objectManager->get(MyRepositoryInterface::class);
        // ...
    }
}

Aim for >60% test coverage on your business logic. Models and repositories are the most important to test.

Schema and data patches over upgrade scripts

Old-style UpgradeSchema.php and UpgradeData.php scripts are deprecated. Use declarative schema and data patches:

<!-- etc/db_schema.xml -->
<table name="my_module_entity" resource="default" engine="innodb">
    <column name="entity_id" xsi:type="int" unsigned="true" nullable="false" identity="true"/>
    <column name="name" xsi:type="varchar" length="255" nullable="false"/>
    <column name="created_at" xsi:type="timestamp" default="CURRENT_TIMESTAMP"/>
    <constraint xsi:type="primary" referenceId="PRIMARY">
        <column name="entity_id"/>
    </constraint>
</table>

// Setup/Patch/Data/AddDefaultConfiguration.php
class AddDefaultConfiguration implements DataPatchInterface
{
    public function apply(): void
    {
        $this->configWriter->save('my_module/general/enabled', '1');
    }

    public static function getDependencies(): array { return []; }
    public function getAliases(): array { return []; }
}

Patches run once and are tracked in patch_list table. No more version comparison logic.

Module structure that scales

app/code/Vendor/ModuleName/
├── Api/                    # Service contract interfaces
│   └── Data/               # Data object interfaces
├── Block/                  # View models and blocks
├── Console/                # CLI commands
├── Controller/             # HTTP controllers
├── Cron/                   # Scheduled jobs
├── Model/                  # Business logic implementations
│   └── ResourceModel/      # Database layer
├── Observer/               # Event observers
├── Plugin/                 # Interceptors
├── Setup/                  # Schema + data patches
├── Test/                   # Unit + integration tests
├── Ui/                     # UI components
├── etc/                    # Configuration
│   ├── adminhtml/          # Admin-specific config
│   ├── frontend/           # Frontend-specific config
│   ├── db_schema.xml       # Declarative schema
│   ├── di.xml              # DI configuration
│   ├── events.xml          # Event observers
│   └── module.xml          # Module declaration
├── view/                   # Templates, layouts, JS, CSS
├── composer.json
└── registration.php

This structure is predictable for any Magento developer joining your project.

Staying upgrade-safe

Prefer preference in di.xml as a last resort; use plugins when possible
Don't override core templates unless absolutely necessary
Test against the next minor Magento version in CI before it's released
Follow Magento's deprecation notices in each release's changelogs

Originally published on magevanta.com

Magento 2 Indexer Optimization: Faster Reindexing in Production

Magevanta — Sun, 19 Apr 2026 17:35:38 +0000

Magento's indexing system is one of the most misunderstood parts of the platform. Run it wrong and you get store lockups, slow admin saves, and customers seeing stale prices. Run it right and indexing becomes invisible.

What indexers actually do

Magento uses indexers to pre-compute expensive derived data and store it in flat tables optimized for reads:

Indexer	What it computes
`catalog_product_flat`	Flat product data (faster reads than EAV)
`catalog_category_flat`	Flat category data
`catalog_category_product`	Category-to-product mappings
`cataloginventory_stock`	Stock status and availability
`catalog_product_price`	Computed prices (after discounts, tier pricing)
`catalogsearch_fulltext`	Search index (Elasticsearch/OpenSearch)
`catalogrule_rule`	Catalog price rule applications

When an indexer is "invalid," Magento serves stale data from the last valid index. When it's "processing," database tables are locked.

Scheduled vs. real-time indexing

Each indexer can run in two modes:

Real-time (realtime): Reindexes automatically when data changes. Safe for small catalogs, dangerous for large ones — a single product save can trigger minutes of reindexing.

Scheduled (schedule): Queues changes and processes them in batches via cron. Much better for production.

Switch all indexers to scheduled:

bin/magento indexer:set-mode schedule

Verify:

bin/magento indexer:info

With scheduled indexing, product saves complete instantly. The cron job processes the queue periodically (every minute by default).

The indexer cron configuration

Magento's default cron runs indexers every minute. For large catalogs, this can cause cron jobs to overlap.

Check your cron is running:

bin/magento cron:run
bin/magento cron:status

For high-traffic stores, run indexers during off-peak hours:

<!-- app/code/YourVendor/CronOverride/etc/crontab.xml -->
<config>
    <group id="index">
        <job name="indexer_reindex_all_invalid" instance="Magento\Indexer\Cron\ReindexAllInvalid" method="execute">
            <schedule>*/5 * * * *</schedule>  <!-- Every 5 minutes instead of every 1 -->
        </job>
    </group>
</config>

Partial reindexing

Running a full reindex on a store with millions of products takes hours. Partial reindexing processes only the changed rows:

# Full reindex (avoid in production during business hours)
bin/magento indexer:reindex

# Check which indexers need reindexing
bin/magento indexer:status

# Reindex only a specific indexer
bin/magento indexer:reindex catalog_product_price

With scheduled mode, partial reindexing happens automatically. The mview (materialized view) system tracks changed rows in changelog tables and only processes those.

Diagnosing slow reindexing

If your indexers consistently take too long, the culprits are usually:

1. Catalog price rule complexity

Complex pricing rules with many conditions force Magento to evaluate every product against every rule. Simplify rules where possible, or use customer group pricing instead.

2. Large EAV tables without indexes

The indexer reads from EAV tables. Missing database indexes on these tables make full reindexes extremely slow.

-- Check if these indexes exist
SHOW INDEX FROM catalog_product_entity_decimal;
SHOW INDEX FROM catalog_product_entity_int;

-- If missing, add them
ALTER TABLE catalog_product_entity_decimal
  ADD INDEX IDX_ATTRIBUTE (attribute_id, store_id);

3. Elasticsearch document size

The catalogsearch_fulltext indexer pushes data to Elasticsearch/OpenSearch. If you're indexing too many attributes, documents get large and indexing slows down.

Only index attributes that users actually search on:

Admin → Stores → Attributes → Product → [attribute] → Use in Search → Yes/No

Turn off "Use in Search" for attributes like internal SKUs, supplier codes, and technical specs that customers never search for.

Monitoring indexer health

Add indexer status to your monitoring:

#!/bin/bash
# check-indexers.sh
STATUS=$(bin/magento indexer:status | grep -c "Reindex required")
if [ "$STATUS" -gt "0" ]; then
    echo "ALERT: $STATUS indexers require reindexing"
    exit 1
fi
echo "All indexers valid"

Run this in your monitoring cron every 30 minutes. Alert if any indexer has been invalid for > 15 minutes.

Before a major import

When you're importing thousands of products (e.g., catalog update from ERP), disable observers and run a full reindex after:

# Before import
bin/magento indexer:set-mode realtime cataloginventory_stock  # Keep stock live
bin/magento indexer:set-mode schedule catalog_product_flat catalog_category_flat catalog_product_price catalogsearch_fulltext

# Run import
bin/magento import:run ...

# After import - full reindex of affected indexers
bin/magento indexer:reindex catalog_product_flat catalog_category_flat catalog_product_price catalogsearch_fulltext

# Flush caches
bin/magento cache:flush

This pattern keeps your store responsive during the import and runs the reindex as a single batch operation after.

Summary

Switch all indexers to schedule mode in production
Ensure cron is running and not overlapping
Monitor indexer status — alert on invalid indexers > 15 minutes
Add database indexes to EAV tables to speed up full reindexes
Only index attributes in Elasticsearch that users actually search on
Batch large imports and reindex after, not during

Originally published on magevanta.com

Magento 2 Headless Architecture: Performance Best Practices

Magevanta — Sun, 19 Apr 2026 17:29:51 +0000

Headless Magento gives you the freedom to build a blazing-fast frontend — but only if your API layer is architected correctly. A poorly configured GraphQL endpoint will make your headless store slower than a traditional Magento theme.

Here's how to get it right.

The headless performance stack

A well-architected headless Magento setup has three layers:

Browser / App
     ↓
CDN (Cloudflare / Fastly)          ← Cache static & public API responses
     ↓
Next.js / Nuxt / Astro frontend    ← SSR + ISR for dynamic content
     ↓
Magento GraphQL API                ← With Redis caching, compression, rate limiting
     ↓
MySQL + Redis                      ← Optimized queries, tag-based cache

Each layer needs to be optimized. Most guides only cover the frontend. Let's talk about the API layer.

GraphQL vs REST for headless

For product catalog, category navigation, and CMS content: use GraphQL. It gives you:

Request exactly the fields you need (no over-fetching)
Batch multiple queries in one request
Strong typing helps frontend developers catch issues early

For cart, checkout, and customer operations: REST is often faster for simple operations (add to cart, apply coupon) because Magento's REST endpoints are more mature and have better caching support.

Server-Side Rendering vs Static Generation

Page type	Strategy	Cache TTL
Homepage	ISR (revalidate every 5 min)	CDN: 5 min
Category pages	ISR (revalidate every 10 min)	CDN: 10 min
Product detail	ISR (revalidate on price/stock change)	CDN: 1 min
Cart / Checkout	SSR (no cache)	None
CMS pages	Static (rebuild on publish)	CDN: 24h

The key insight: most of your traffic hits product and category pages. These can be statically generated or ISR-cached. Only cart and checkout need true SSR.

Caching GraphQL responses at the edge

Public GraphQL queries (product listings, category trees, CMS blocks) can be cached at the CDN edge:

Strategy: Convert POST GraphQL requests to GET using persisted queries, then cache the GET responses at CDN level.

// Next.js example: fetch with cache
const data = await fetch('https://shop.example.com/graphql', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ query: PRODUCTS_QUERY }),
  next: { revalidate: 300 }, // ISR: revalidate every 5 minutes
});

With Cloudflare, you can also cache GraphQL responses at the edge using Cache Rules based on query hash.

Invalidating the CDN on catalog updates

The hardest problem in headless Magento: when a product price changes, you need to invalidate the right CDN pages without a full cache flush.

Tag-based invalidation workflow:

Product is saved in Magento admin
Magento fires catalog_product_save_after event
Observer collects affected URLs (PDP, parent category pages, related widgets)
Calls Cloudflare API to purge those specific URLs

public function execute(\Magento\Framework\Event\Observer $observer): void
{
    $product = $observer->getProduct();
    $urls = $this->urlCollector->getAffectedUrls($product);
    $this->cloudflareClient->purgePaths($urls);
}

This is more complex to set up but essential at scale. Flushing your entire CDN on every product save destroys your cache hit rate.

Handling customer-specific content

Personalized content (prices for logged-in customers, wishlist counts, cart totals) can't be cached. But you don't have to sacrifice performance:

Shell + client-side hydration pattern:

Serve a cached shell (header, navigation, product grid) from CDN
On load, fetch customer-specific data from a dedicated API endpoint
Hydrate the shell with customer data client-side

This gives you CDN-fast page loads with accurate customer data. The perceived performance is excellent because the page structure appears immediately.

API rate limiting and abuse protection

Headless APIs are more exposed than traditional Magento installs. Without rate limiting:

Crawlers can saturate your GraphQL endpoint
Competitors can scrape your entire catalog
Checkout bots can abuse your cart API

Implement tiered rate limiting:

Unauthenticated requests: 60/minute per IP
Authenticated frontend: 600/minute per session token
Server-to-server (your Next.js backend): unlimited with a dedicated API key

Monitoring API performance

Track these metrics per endpoint:

P50/P95/P99 response times — P95 and P99 reveal tail latency that real users experience
Cache hit rate — aim for >90% on product/category endpoints
Error rate — alert at >0.1%
Payload size — track average response size, flag regressions

A 200ms P95 response time on your product API translates directly to a 200ms longer page load for 1 in 20 users.

The complete headless optimization checklist

[ ] Separate Redis instances for cache, FPC, and sessions
[ ] GraphQL response caching in Redis (by query hash + store + currency)
[ ] Brotli compression on all API responses
[ ] Persisted queries for CDN cacheability
[ ] Tag-based CDN invalidation on catalog updates
[ ] Rate limiting with tiered API keys
[ ] Shell + hydration pattern for customer-specific content
[ ] P95 response time monitoring with alerts

The BetterMagento Lightweight API module handles the Redis caching, Brotli compression, persisted queries, and rate limiting out of the box.

Originally published on magevanta.com

How to Speed Up Magento 2 GraphQL: A Developer's Guide

Magevanta — Sun, 19 Apr 2026 17:29:15 +0000

Magento 2's GraphQL API is powerful, but it's slow by default. Out of the box, every GraphQL request hits your PHP stack, executes database queries, and returns uncompressed JSON. For a headless storefront, this adds up fast.

Here's how to make it production-fast.

Why Magento GraphQL is slow by default

A few root causes:

No response caching — each request is processed from scratch
No compression — JSON responses are sent uncompressed
Over-fetching — clients receive all fields, even unused ones
No rate limiting — one misbehaving client can saturate your server

Let's fix each one.

Response Caching

The most impactful change. For public data (product listings, category pages, CMS blocks), GraphQL responses can be cached in Redis and reused across requests.

Cache key strategy matters here: you need to vary the cache by:

The query hash
The store view
The customer group (for pricing)
Currency

Tag your cache entries by entity type (product_1234, category_56) so you can invalidate precisely when data changes — not flush everything.

# Example: flush cache for a specific product
bin/magento cache:clean --type=full_page --tag=product_1234

Expected improvement: 80–95% of GraphQL requests served from cache, response time drops from 200–500ms to under 10ms.

Brotli Compression

Brotli compresses 15–25% better than gzip. For GraphQL responses (JSON), real-world compression ratios are typically 70–80%.

A 50KB product listing response becomes ~10KB with Brotli. On mobile connections, that's a 200–400ms improvement on its own.

Enable it in your nginx config:

brotli on;
brotli_comp_level 6;
brotli_types application/json text/html text/css application/javascript;

Or handle it in PHP for responses that bypass nginx caching.

Persisted Queries

Instead of sending the full GraphQL query string with every request:

POST /graphql
{ "query": "{ products(filter: { category_id: { eq: \"5\" } }) { items { id name price { regularPrice { amount { value } } } } } }" }

Store the query on the server and send only its hash:

GET /graphql?queryId=a1b2c3d4&variables={"categoryId":"5"}

Benefits:

Smaller request payloads (especially on mobile)
GET requests are cacheable by CDN/proxy
Prevents clients from executing arbitrary queries

Field Pruning

Magento's GraphQL resolvers often fetch more data than the client requested. Field pruning analyzes the incoming query, determines which fields are actually needed, and short-circuits database fetches for unused fields.

For product detail pages, this commonly eliminates 30–50% of database queries.

Rate Limiting

Without rate limiting, a single crawl bot or misbehaving integration can bring down your API. Implement token bucket rate limiting:

Free tier: 60 requests/minute per IP
Authenticated tier: 600 requests/minute per API key
Premium tier: unlimited

Return 429 Too Many Requests with Retry-After header when limits are exceeded.

Query Complexity Analysis

GraphQL allows deeply nested queries that can be extremely expensive:

{
  products {
    items {
      related_products {
        related_products {
          related_products { ... }
        }
      }
    }
  }
}

Calculate a complexity score for each query and reject those above a threshold before they hit your database.

Putting it all together

Optimization	Implementation effort	Performance gain
Response caching	Medium	⭐⭐⭐⭐⭐
Brotli compression	Low	⭐⭐⭐
Persisted queries	Medium	⭐⭐⭐
Field pruning	High	⭐⭐⭐⭐
Rate limiting	Medium	🛡️ Reliability
Complexity analysis	Medium	🛡️ Reliability

The BetterMagento Lightweight API module implements all of these in a single Composer package — no custom development required.

Originally published on magevanta.com

DEV Community: Magevanta

How to Reduce Magento 2 Bootstrap Time by 30%

Why module count matters

Which modules are safe to remove?

The dependency problem

Step-by-step: safe module removal

Expected results

Automating this safely

Important caveats

Magento 2 Deployment: Zero-Downtime Production Deployments

Why Magento deployments are hard

The naive approach (and why it fails)

Approach 1: Maintenance mode (simple, has downtime)

Approach 2: Atomic symlink deployment (zero downtime)

Approach 3: Blue-green deployment

Database migrations without downtime

CI/CD pipeline example (GitHub Actions)

Post-deployment checklist

Magento 2 Varnish Configuration: The Production-Ready Setup

Why Varnish over Magento's built-in FPC

Installing and wiring up Varnish

The critical VCL settings most guides miss

ESI for dynamic content

Cache purging on content updates

Monitoring Varnish

Common mistakes

Magento 2 Slow Queries: How to Find and Fix Them

Step 1: Enable the slow query log

Step 2: Analyze the slow query log

Step 3: Run EXPLAIN on slow queries

Step 4: Add missing indexes

Step 5: Common Magento slow query patterns

Step 6: Query result caching

Automating the process

Summary checklist

Magento 2 Security Hardening: A Production Checklist for 2026

1. Change the admin URL

2. Enable two-factor authentication

3. File permissions

4. Disable directory listing

5. Content Security Policy headers

6. Security headers

7. Keep Magento patched

8. Restrict admin access by IP

9. Disable unused payment methods and modules

10. Monitor for malware

11. Secure env.php

Security audit checklist

Magento 2 Redis Configuration: The Complete Guide for 2026

Why separate Redis instances matter

env.php configuration

Redis server configuration

Connection pooling with PHP-FPM

Compression settings

Monitoring Redis health

Cache warming after deploys

Quick reference: common mistakes

Redis Caching for Magento 2: Beyond the Basics

The problem with default Magento Redis config

Tag-based cache invalidation

Pipeline batching

Redis Cluster vs. Sentinel

Session clustering

Compression for large values

Monitoring

Summary

Magento 2 Performance Optimization: The Complete 2026 Guide

1. Database Query Optimization

2. Redis Caching

3. API Performance for Headless Stores

4. Edge Delivery

5. Module Bloat

6. Core Web Vitals

Putting it all together

Magento 2 Module Development Best Practices in 2026

Service contracts: the right way to expose functionality

Plugins vs. observers: choosing correctly

Dependency injection done right

Performance-conscious coding

Testing your module

`env.php` configuration