标签：#magento

Every Magento 2 team has the same nightmare: a flash sale goes live, traffic triples, and the site turns into a spinning wheel of death. The store survives — barely — but orders drop, support tickets explode, and the post-mortem reveals the same sentence: "We didn't know it would break at that load." You can know. Load testing is the difference between guessing your limits and measuring them. This article covers the full loop: designing realistic tests, generating load that actually resembles your shoppers, reading the results to find the real bottleneck, and turning those numbers into capacity decisions. Why Load Testing Is Not Regression Testing If you've read our article on automated performance regression testing in CI , you know that's about catching slowdowns between deploys — a few requests, tight budgets, fail the build if TTFB climbs. Load testing answers a different question: how much traffic can this system handle before it degrades or dies? One focuses on change detection; the other on absolute capacity. You need both. Regression testing keeps you from getting slower; load testing tells you where the cliff is, and whether one node survives a flash sale or you need five. Define What "Good" Means Before You Start A load test without acceptance criteria is just a benchmark with anxiety. Define SLOs first, ideally from real traffic data: p95 Time To First Byte (TTFB) under load — e.g., under 800ms Error rate — under 0.5% (502s, timeouts, checkout failures) Throughput — X requests/second sustainable for 30+ minutes Business metrics — successful checkout completion rate over 99% Then define the shape of traffic. Magento 2 is not a static site: different pages cost wildly different amounts. A realistic mix for a typical store looks something like: 40% category/product listing pages (PHP + FPC + Elasticsearch aggregations) 30% product detail pages (heavily cached, cheap when warm) 15% home + CMS pages (nearly free with FPC) 10% cart + checkout actions (uncached,

Next time a client asks "why is my reindex slow?", the answer is almost always the price index . It's the indexer that scales worst with catalog size, the one that chokes on webshops, B2B stores, configurable-heavy catalogs and (counter-intuitively) gets more painful the more you try to "fix" it with raw SQL. Yet most developers treat it like a black box. In this guide I'll pull back the curtain on how Magento actually stores and computes prices, why the price index behaves the way it does, and — crucially — the strategies that actually move the needle. How Magento stores prices (the part nobody reads) Prices do not live on the product table. When you save a product, Magento stores the raw price on catalog_product_entity_decimal — one row per product, attribute, store and scope. But the moment you add any of the following, the "true" price stops being a simple column lookup: Tier prices ( catalog_product_entity_tier_price ) Special price scheduling ( special_from_date / special_to_date ) Catalog price rules ( catalogrule , applied via rules engine) Group prices (customer groups) Bundle/grouped product composite pricing Configurable products with per-option price adjustments Staging updates (Content Staging, Magento Commerce) Because the effective price depends on time, customer group and rules, Magento has to precompute it. That precomputation is the price index. When it works, page requests just read a flat, pre-joined set of rows instead of re-evaluating every rule on every request. When it's stale or under-built, you either serve wrong prices or you trigger expensive on-the-fly calculation. What the price index actually is The price indexer writes to the catalog_product_index_price table (plus _idx / _tmp variants and the catalog_product_index_price_final_tmp intermediate tables). A reindex runs in phases: Reindex all products into the _tmp table with their base price. Apply tax , tier , special , group and rule adjustments. Handle composite products (bundle's mi

If you're running Magento 2 with MSI (Multi-Source Inventory) enabled — and since Magento 2.4 it's the default — you have a silent performance killer lurking in your database. The inventory_reservation table grows without bound, and every single cart operation hits it. This post walks through why this table becomes a bottleneck, how to measure the impact, and concrete steps to fix it. How Inventory Reservations Work When a customer adds a product to their cart, Magento doesn't immediately decrement stock. Instead, it creates a reservation — a record in inventory_reservation that says "this quantity is tentatively reserved for this order." The actual stock deduction happens later, when the order is placed and the shipment is processed. The flow looks like this: Add to cart → placeReservation writes a negative reservation record Place order → reservation is linked to the order Ship order → inventory_source_item is decremented, reservation should be compensated Compensation reservation → a positive record that cancels out the original negative one In theory, reservations are transient. They exist to bridge the gap between cart and shipment. In practice, they accumulate forever. The Problem: Unbounded Growth Here's what happens in production: Orders that are canceled leave orphaned negative reservations Orders that fail during checkout leave reservations that are never compensated Partial shipments create partial compensation records Quote conversions that error out mid-process leave dangling reservations Re-indexing, re-stocking, and admin edits can create duplicate records After 6–12 months of moderate traffic, the inventory_reservation table routinely hits several million rows . I've seen tables with 10M+ rows on stores doing 200 orders/day. SELECT COUNT ( * ) FROM inventory_reservation ; -- 4,872,341 rows on a store running 8 months SELECT COUNT ( * ) FROM inventory_reservation WHERE created_at < DATE_SUB ( NOW (), INTERVAL 30 DAY ); -- 4,710,882 — 96.7% of rows are

Magento 2's full page cache is one of its strongest performance features — when it works. But every week, we see stores where a simple product save triggers a 30-second Varnish flush and subsequent cache stampede. The culprit is almost never Varnish itself. It's cache tags. This post covers how Magento 2 cache tags work, why broad tags destroy performance, and exactly how to audit and fix them. How Cache Tags Work in Magento 2 Every cached page, block, and data fragment in Magento is tagged with identifiers. When a product changes, Magento invalidates all cache entries tagged with that product's ID. The tag system is hierarchical: cat_p_123 — specific product cat_p — all products cat_c_5 — specific category cat_c — all categories cms_b_about_us — a CMS block cms_p — all CMS pages These tags are stored alongside cached content and used during invalidation. When you call $cache->clean(["cat_p_123"]) , every cache entry tagged with cat_p_123 is removed. This is elegant until someone tags a global block with cat_p , and saving any product flushes half your store. The Invalidation Storm Problem Here's what happens during a storm: Admin saves a simple product update (price change) Magento generates the invalidation list: cat_p_456 , cat_c (because the product is in categories), cat_p (from a badly written block) cat_p is too broad — it matches the product list page, layered navigation, homepage widgets, and every product detail page Varnish receives 50,000 BAN requests Store goes from sub-100ms response times to 2-5 seconds for the next 10 minutes while the cache rebuilds We've seen this on a store with 80,000 SKUs. A single product save dropped cache hit rate from 94% to 12%. Diagnosing Bad Cache Tags Check Your Current Tags Add this to any block template to inspect what tags are being applied: $block -> getCacheKeyInfo (); // Or for the full page: $block -> getIdentities (); For a full audit, intercept cache writes in development: // In di.xml: < type name = "Magento\Fr

Magento 2 Customer Data Sections & localStorage Performance Optimization Every Magento 2 storefront uses customer data sections — the mechanism behind the mini-cart, customer name display, wishlist counters, and checkout summaries. It looks seamless to shoppers, but under the hood it can silently murder your page load performance. If you've ever wondered why your pages fire an extra AJAX request immediately after the initial load, or why your localStorage balloons to several megabytes, this post is for you. What Are Customer Data Sections? Magento 2 splits page rendering into two phases: server-side (Astro/Varnish/FPC) and client-side (JavaScript). Because full-page cache serves the same HTML to every visitor, personalized data — cart contents, logged-in customer name, wishlist count — cannot be rendered server-side for cached pages. Enter sections.xml and the Customer Data JS API : <!-- Vendor_Module/etc/frontend/sections.xml --> <?xml version="1.0"?> <config xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation= "urn:magento:module:Magento_Customer:etc/sections.xsd" > <action name= "checkout/cart/add" > <section name= "cart" /> <section name= "checkout-data" /> </action> </config> This file tells Magento: "When the checkout/cart/add action runs, invalidate the cart and checkout-data sections." On the next page load, JavaScript detects these invalidated sections and fetches fresh data via customer/section/load/ AJAX. The Data Flow Page loads from FPC/Varnish (no personalization) JS initializes Magento_Customer/js/customer-data localStorage is checked for cached section data (by sectionLoadUrl + storeId key) Invalidated sections trigger POST /customer/section/load/ with section names Response updates localStorage, ko.observables, and UI (mini-cart, messages, etc.) This sounds efficient, but it has three major performance traps . Performance Trap #1: The "Sections Hell" AJAX Request Out of the box, Magento 2's customer-data module calls

When a Magento store feels slow, merchants usually notice it first on the homepage. When revenue actually slips, we usually find the damage deeper in the funnel. That was the case on a recent mid-market Magento 2 build we inherited. Product pages were acceptable. Search worked. But checkout analytics told a different story. Mobile users were stalling after address entry, re-clicking shipping methods, and abandoning before payment finished rendering. The merchant described it in business terms: "traffic is fine, but checkout feels fragile." They were right. The store was running a fairly typical Magento checkout stack: Luma fallback checkout, several shipping customizations, two payment methods, tax recalculation on step changes, and a handful of third-party scripts that had quietly accumulated over time. Together, they created a familiar Magento problem: too much JavaScript, too many render passes, and too much waiting on the highest-stakes route in the store. Over a 90-day measurement window after launch, checkout completion improved by 34%. Mobile completion improved by 39%. Lab metrics got much better immediately, and field metrics followed. This article covers why we chose React instead of Hyva Checkout, how we implemented the frontend, what moved the numbers, and what we would do differently next time. The problem with Magento's default checkout Magento's default Luma checkout is functional, but performance is rarely its strength. The architecture was designed around Knockout.js components, RequireJS modules, and a lot of UI behavior being layered in over time. Once a real merchant adds shipping estimation, fraud tooling, tax logic, payment widgets, analytics, and address validation, the route becomes busy in all the wrong ways. In this project, our baseline looked like this on a throttled mobile profile: Metric Before (Luma checkout) After (React checkout) Initial checkout route payload 1.8 MB transferred 486 KB transferred LCP 4.2s 1.1s INP 280ms 92ms CLS 0.1

We've been a Magento agency in Chicago since 2008. When Hyvä Themes hit the ecosystem, we were skeptical—another theme promise. Then we measured Core Web Vitals on client stores and the case became obvious: Hyvä is the most practical path to a fast Magento storefront without a full replatform. This is the migration framework we use at Towering Media for US and Canadian merchants moving off Luma (or aged custom frontends) onto Hyvä. Why Hyvä now (not next year) Google's CWV thresholds affect ad quality and organic visibility. Luma checkout and catalog pages often ship 1.5–2+ MB of JavaScript before you add analytics, chat, and personalization. Hyvä replaces Knockout/RequireJS on the storefront with Alpine.js and Tailwind. Typical results on our projects: 50–70% less frontend JS on category and product pages LCP improvements of 1–3 seconds on mobile field data (highly variable by hosting and images) Lower maintenance — fewer JS conflicts between theme and extensions Delaying migration means paying for performance twice: once in emergency fixes, again in the eventual theme project. Phase 1: Discovery (1–2 weeks) Extension audit List every module that touches the frontend: bin/magento module:status | grep -v "Module is disabled" Flag anything with view/frontend , RequireJS , or Knockout in: Layered navigation and search Checkout and cart Page Builder widgets Blog and CMS enhancements Hyvä maintains a compatibility module ecosystem; unsupported extensions need replacements or custom Hyvä templates. Towering Media includes extension compatibility mapping in every Hyvä migration engagement. CWV baseline Capture before metrics from: Google PageSpeed Insights (origin-level) Chrome UX Report for key templates: home, category, product, cart Real-user monitoring if the client has it (GA4, SpeedCurve, etc.) Store screenshots. Stakeholders forget how slow the old site felt. Business constraints Document: Peak seasons (do not launch in November without war room

Magento's default Luma checkout loads a heavy Knockout.js stack, dozens of RequireJS modules, and payment iframes that fight for the main thread. For merchants where checkout is the conversion bottleneck, shaving seconds off load and interaction time pays back faster than another homepage hero image. We rebuilt checkout in React— React Checkout Pro —for Magento 2 and Hyvä stores that needed Shopify-like speed without leaving Adobe Commerce. Here is what we measured, what surprised us, and what we would do differently. The problem: checkout is where Core Web Vitals go to die Homepage optimizations are table stakes. Checkout is different: More JavaScript. Payment methods, validators, shipping step observers, and third-party scripts stack on one route. More layout shift. Address suggestions, shipping method lists, and tax updates re-render large DOM regions. More input delay. Autocomplete plugins, reCAPTCHA, and BNPL widgets compete on keydown handlers. On a representative Luma checkout (mid-size US retailer, ~80 SKUs in catalog, 4 payment methods), lab tests before migration showed: Metric Luma checkout (before) React checkout (after) LCP (lab, 4G) 4.8s 2.1s INP (field interaction) 320ms 95ms CLS (full flow) 0.18 0.04 JS transferred (checkout route) ~1.9 MB ~420 KB Time to interactive (est.) 6.2s 2.8s Field data from CrUX lagged lab wins by 4–6 weeks but trended the same direction once cache and CDN rules settled. Your numbers will differ. The pattern we see repeatedly: the biggest win is shipping less JavaScript to checkout , not micro-optimizing the JavaScript you keep. Architecture: React island, Magento brain We did not headless the entire storefront. Magento still owns: Quote totals and tax calculation Shipping rate requests Payment tokenization and order placement APIs Customer session and cart persistence React owns the UI layer: step navigation, form state, validation UX, and optimistic updates while Magento APIs catch up. High-level flow: Browser → React Chec

Google launched Universal Cart at I/O 2026 last week. An intelligent cart that follows users across Search, Gemini, YouTube, and Gmail. ALM Corp published the list of named early checkout merchants on May 20: Nike, Sephora, Target, Ulta Beauty, Walmart, Wayfair, and Shopify brands. I read that list twice looking for a Magento store. None. That's the article. Below: the five-protocol stack you'd otherwise have to read five different specs to understand, the one decision your existing payment processor has already made for you, and a thirty-day Magento-specific playbook to ship before agent-routed traffic starts flowing past your store. If your store runs on Magento or Adobe Commerce, agent-routed traffic is going to flow past you - first in the US, then Canada and Australia "in the coming months," then the UK. The agent layer isn't going to wait for Adobe Commerce to ship native UCP support. The merchants in the first cohort had thirty days of head-start. Most of that window is already gone. Here's what to ship before the rest of it closes. The five-protocol stack, compressed Four protocols define how an AI agent buys something on behalf of a user. A fifth ties payments together. UCP - the discovery layer. Your store publishes a manifest at /.well-known/ucp declaring its capabilities, transports, and payment handlers. MCP - the transport layer. Agents dispatch your commerce tool calls over MCP messages. ACP - OpenAI and Stripe's checkout protocol. Stripe-led coalition. AP2 - Google's payment-authorization protocol. Sixty-plus partners signed at launch: Adyen, American Express, Mastercard, PayPal, Coinbase, Revolut, Worldpay, and more. MPP - Stripe's machine-payments protocol. Same family as ACP. Benji Fisher's synthesis post on dev.to is the sharpest framing I've read: UCP discovers, MCP transports, ACP and AP2 authorize. Read it if you haven't. The UCP spec itself is densifying fast. A loyalty extension landed on May 19 ( #340 ). A schema-validated documentation har