AI agents for eCommerce now arrive with the platform itself: Shopify and BigCommerce both include an AI assistant in the store admin at no extra cost, and both apply a change only after someone on your team approves it. An AI agent is software that carries out a task in your store after you ask, such as answering a customer or updating an order.

That leaves a store team with two decisions: which jobs to hand to an agent, and which agent fits each job on your platform. The job sets the access: an agent that answers a shopper’s question reads your catalog, while one that edits your theme changes your code, and each needs its own review step. Every price and platform list here was read on the vendor’s own site on November 2, 2026.

What AI agents for eCommerce do for a store team

AI agents for eCommerce are software a store team gives a task in plain words, and the agent carries it out in the store’s systems. They answer customers, help shoppers choose, build campaigns, write catalog content and make store changes. Each job needs different access, from reading orders to editing the theme, so choose agents by job.

Agents that buy for shoppers are covered in our guide to agentic commerce, and companies that build custom agents in our list of AI agent development companies. The table lists the eleven eCommerce AI agents below by job, with the platforms each one runs on.

Prices as listed on each vendor’s site on November 2, 2026.

Customer service AI agents

A customer service agent answers customers in chat, email or other channels and takes actions such as checking an order’s status, cancelling an order or starting a return. It works inside your helpdesk and reads your store’s order data. Most charge per resolved conversation, so the bill grows with the share of tickets the agent closes.

1. Fin by Intercom

Fin answers customers in chat, email, voice and social channels, and takes actions such as refunds and partial or full cancellations once it has verified the order. Fin Voice covers calls, for stores that want an AI voice agent for eCommerce support.

Best for: stores with a busy support inbox that want the agent inside the helpdesk they already use.

Key features:

• Runs in Intercom’s helpdesk or in Salesforce, Zendesk, HubSpot, Freshdesk and others
• Shopify app that reads order status and tracking, plus no-code connectors for other systems with an API
• Invalid order IDs and orders that need attention go to your team
• A testing suite before you set changes live

Price (November 2, 2026): $0.99 per outcome, at most once per conversation. With another helpdesk, a $49 a month minimum that includes 50 outcomes. On Intercom, $19 per seat a month plus outcomes. Fin Voice is $1.99 per voice outcome, through sales.

Works with: Shopify through its app, other systems through data connectors.

2. Gorgias AI Agent

Gorgias AI Agent answers support questions, chats with shoppers before they buy, and handles returns and order tracking. On Shopify it can cancel an order, edit the shipping address, remove or replace an item, reship an order for free and add an order note.

Best for: Shopify, BigCommerce or Magento (Adobe Commerce) stores that want support and pre-sale chat in one helpdesk.

Key features:

• Asks the shopper to confirm an address change or item removal before it makes it
• Checks that an order is unfulfilled before it cancels or edits it
• Hands the ticket to your team when a replacement raises the order total
• Cancellations don’t reach third-party logistics apps

Price (November 2, 2026): on every Gorgias plan, at $0.90 per automated interaction on an annual contract or $1.00 monthly, then $1.50 past the plan’s limit, on top of a helpdesk plan priced separately.

Works with: Shopify, BigCommerce, Magento, WooCommerce.

Shopping assistant agents for your storefront

A shopping assistant agent talks to shoppers on your storefront before they buy. It answers product questions from your catalog, recommends items and, on some platforms, takes the shopper through checkout in the chat. Assistants built by the commerce platform use its catalog and order data directly, while helpdesk tools add shopping chat to their support agent.

For the types of AI shopping assistants and what each costs per conversation, see our guide to AI shopping assistants.

3. Shopify Inbox

Shopify Inbox is Shopify’s free chat app, and it gives shoppers an AI sales associate: “Buyers can ask questions and get help finding the right products from your catalog.” It is a quick way to add an AI agent for your website’s storefront chat.

Best for: Shopify stores that want to try an AI shopping assistant before paying for one.

Key features:

• Product recommendations
• Replies that use preferences and purchase history for shoppers signed in with Shop
• Live chat and chat assignment for your team

Price (November 2, 2026): free.

Works with: Shopify.

4. Salesforce Agentforce Commerce Shopper Agent

The Agentforce Commerce Shopper Agent is Salesforce’s storefront agent. In Salesforce’s words, it “carries the customer conversation from discovery through checkout and into service” in your brand’s voice, and Salesforce made it generally available in June 2026.

Best for: brands on Salesforce Commerce Cloud that want one agent from product discovery to after-sale service.

Key features:

• Visual product search and answers to store and product questions
• Checkout in the chat with Apple Pay or Google Pay
• Connected to the catalog, inventory and orders

Price (November 2, 2026): Salesforce lists Agentforce at $2 per conversation for customer-facing agents, or by Flex Credits. Commerce Cloud editions are priced on request.

Works with: Salesforce Commerce Cloud.

AI marketing agents

A marketing agent builds campaigns from a goal you describe. It picks the audience, drafts the emails or messages and plans the send, using your customer and sales data. Klaviyo’s Composer, the example below, builds campaigns, flows and segments inside Klaviyo and lets your team review customer-facing work before it goes live.

5. Klaviyo Composer

Klaviyo Composer is Klaviyo’s AI marketing agent. You give it a goal, and it builds campaigns, flows, messages and segments inside Klaviyo from your own customer data.

Best for: teams that already send email or SMS from Klaviyo and want campaigns drafted from their own customer data.

Key features:

• Builds and refines segments and audiences
• Gives your team “the opportunity to review customer-facing work before it goes live”
• Klaviyo also sells a Customer Agent for order tracking, returns and recommendations

Price (November 2, 2026): free and paid access, depending on your account and usage. The free plan includes $5 of Composer usage a month.

Works with: Klaviyo, which connects to Shopify, BigCommerce, Magento, Salesforce Commerce Cloud, WooCommerce and Wix. Our Klaviyo vs Mailchimp comparison covers the email platform itself.

Catalog and product content agents

A catalog agent writes and fixes product data: titles, descriptions, attributes, categories and sort orders, often for thousands of products at once. Some work inside the commerce platform and edit the catalog directly. Others work in a separate product content tool and send the results to your store. Read a sample before you run one on the whole catalog.

Catalog agents do more than an AI product description generator, because they also fill attributes and sort products, and teams that keep product data in PIM software can run them there.

6. Salesforce Agentforce Commerce Merchant Agent

The Agentforce Commerce Merchant Agent runs the back office side of Salesforce Commerce Cloud: your team organizes catalogs, sorts products and responds to trends by describing what they want in plain language instead of clicking through admin menus. Salesforce made it generally available in June 2026.

Best for: Salesforce Commerce Cloud merchandisers who spend hours on catalog rules and sort orders in admin menus.

Key features:

• Rules for which products rise or drop in results
• Category sort orders
• Related Agentforce Merchandising features write product descriptions and SEO metadata, including in local languages

Price (November 2, 2026): not published. Commerce Cloud is priced on request.

Works with: Salesforce Commerce Cloud.

7. Hypotenuse AI

Hypotenuse AI is an AI product information platform with “Specialized AI agents for catalog work, alongside your team”. It writes titles and descriptions in your brand voice, fills missing attributes and edits the catalog in bulk.

Best for: large catalogs that sell on a store and on marketplaces and need consistent product data in many languages.

Key features:

• Bulk generation of titles and descriptions
• Fills attribute gaps from the web, UPC data, spec sheets and product images
• 40+ languages
• Custom integrations with PIM, ERP and eCommerce platforms on the Enterprise plan

Price (November 2, 2026): custom quote for both plans.

Works with: Shopify, BigCommerce, Salesforce Commerce Cloud, Akeneo and other PIMs, plus an API.

8. Magefan Magento 2 AI Agent

Magefan Magento 2 AI Agent adds an AI chat to the Magento admin that can “View, create, update and delete store entities”, including products, categories, orders, cart price rules, CMS pages and blocks, and customers.

Best for: Magento admin users who want catalog edits, lookups and routine admin work done by asking in chat.

Key features:

• Respects each user’s admin permissions (ACL), with an option to limit the AI further
• Also handles invoices, shipments, credit memos and newsletter subscribers, plus cache and indexer actions
• Uses the Claude API
• Compatible with the Hyvä theme

Price (November 2, 2026): €134 one-time, with 365 days of updates and support.

Works with: Magento 2.3.0 to 2.4.9 (Open Source, Adobe Commerce, Adobe Commerce Cloud, B2B).

Agents that change the store itself

A store-change agent changes the store itself from a chat: settings, orders, pages, theme code or extensions. Shopify and BigCommerce include admin assistants that apply a change only after you approve it. Magento (Adobe Commerce) stores add third-party agents, from admin chat extensions to agents that build code changes on a copy of the store for a person to release.

9. Agent for Magento (Ari) by scandiweb

Ari, the AI agent for Magento, takes store changes you describe in chat and builds them on a copy of the store with customer data removed. Your team checks each change on a preview store, and a person approves it and releases it as a pull request.

Best for: Magento Open Source and Adobe Commerce teams with frontend, backend and extension work waiting for a developer.

Key features:

• Frontend and backend changes, extension installs and conflict fixes
• Magento version upgrades and security patches
• ERP, PIM and carrier integrations
• Hyvä theme and checkout rebuilds

Ari’s security page sets out what Ari can and can’t access: no access to the live store, the servers or customers’ data, approval only by your team, and no training on the data sent to the OpenAI and Anthropic services it uses.

Price (November 2, 2026): from €99 a month per store, unlimited seats. Ari Agency (€299 a month) adds Ari engineers for review and release, and Enterprise plans are on request.

Works with: Magento Open Source and Adobe Commerce.

10. Shopify Sidekick

Shopify Sidekick is the Shopify AI agent included in every Shopify admin. Shopify rebuilt it on October 28, 2026 so it can write code, with the merchant approving its changes. Our post on what Sidekick can and can’t do covers that release.

Best for: Shopify merchants who want theme, checkout and admin changes drafted in chat and reviewed before they go live.

Key features:

• Stages storefront changes in a draft and tests them with AI-simulated shoppers
• Customizes checkout and customer account settings
• Builds Shopify Flow automations and writes product descriptions
• Shopify says it “can’t change your live store without your approval” and doesn’t talk to your customers

Price (November 2, 2026): included with your Shopify plan, with features and usage limits that vary by plan.

Works with: Shopify, within each staff member’s admin permissions.

11. BigCommerce Companion

BigCommerce Companion is the AI assistant inside the BigCommerce control panel. It answers how-to questions, shows store data as charts, takes you to any admin page and makes changes, such as marking an order fulfilled or issuing a store credit.

Best for: BigCommerce teams that want answers and routine admin updates without leaving the control panel.

Key features:

• “Companion does not apply a change without your approval.”
• Rechecks an order before it updates it
• Works only within the signed-in user’s permissions
• Built for your team, with shopper chat left to App Marketplace apps

Price (November 2, 2026): included with every BigCommerce store, on free trials and paid plans.

Works with: BigCommerce.

Adobe Commerce developers also have Adobe’s Commerce Developer Agent, which writes App Builder extension code from a plan a developer approves first. Adobe calls it “a starting-point generator, not a fully autonomous developer.”

What to check before an AI agent acts on your store

Before an AI agent acts on your store, check what it can change without a person, who approves the rest, how the price grows with volume and where your store data goes. Start with one action or read-only access, test it on real cases from your store, and widen the permissions only after the results hold up.

Here is what to look for in an eCommerce AI agent before you compare prices.

1. What it can do without a person. Gorgias AI Agent can cancel an unfulfilled Shopify order or edit its shipping address, and it asks the shopper to confirm address changes and item removals first. Fin can issue a refund once it has verified the order. Decide which actions you allow before launch, and switch them on one at a time.
2. Who approves the rest, and where. Klaviyo lets your team review customer-facing work before it goes live. Shopify Sidekick drafts store changes for you to review and publish, and BigCommerce Companion applies a change only after you approve it. An agent that changes code should build each change away from the live store and leave the release to a person.
3. How the price grows with volume. Per-outcome and per-conversation prices, as with Fin, Gorgias and Agentforce, rise with traffic. Estimate a peak month before you compare them with tools included in your platform or with flat subscriptions.
4. Where your store data goes. Every AI agent for eCommerce sends questions, orders or code to an AI provider. Ask which provider that is, whether it trains models on your data, and how much customer data the agent can read.

How to choose AI agents for eCommerce by job

Choose AI agents for eCommerce by the job that costs your team the most time. A full support inbox calls for a customer service agent, unanswered product questions for a shopping assistant, slow campaigns for a marketing agent, thin product data for a catalog agent, and a backlog of small fixes for a store-change agent. Start with one job.

Which eCommerce AI agent to pick within a group then follows from your platform.

Choose a customer service agent if:

• Your support inbox fills with “where is my order” and return requests.
• You already run a helpdesk and want the agent to answer inside it.

Choose a shopping assistant if:

• Shoppers ask product-fit questions before they buy and leave without an answer.
• You want answers that come from your own catalog, in a chat on your storefront.

Choose a marketing agent if:

• Your campaign calendar slips because building segments and emails takes days.
• You want campaign drafts your team reviews before anything reaches customers.

Choose a catalog and content agent if:

• Hundreds of products have thin descriptions or missing attributes.
• You sell in several languages or regions and need product copy in each one.

Choose a store-change agent if:

• Small storefront and admin changes wait weeks for a developer.
• You want every change drafted, previewed and approved by a person before it goes live.

Frequently asked questions about AI agents for eCommerce

Which AI agents are best for eCommerce?

The best AI agent for eCommerce depends on the job. Fin and Gorgias AI Agent answer customers, Shopify Inbox and Salesforce’s Shopper Agent help shoppers choose, Klaviyo Composer builds campaigns, and catalog agents such as Hypotenuse AI write product content. For store changes, start with what your platform includes, such as Shopify Sidekick or BigCommerce Companion.

What is the difference between an AI agent and a chatbot?

A chatbot answers questions in a conversation, often from fixed scripts. An AI agent also takes actions: it looks up an order and issues the refund, drafts a campaign or updates a product page, using the systems you connect it to. That is why an agent needs permissions and an approval step, while a scripted chatbot mostly needs good answers.

How much do AI agents for eCommerce cost?

Prices follow the job. Customer service agents charge per resolved conversation: $0.99 per outcome for Fin, and $0.90 to $1.00 per automated interaction for Gorgias AI Agent. Salesforce lists Agentforce at $2 per conversation for customer-facing agents. Shopify Sidekick, Shopify Inbox and BigCommerce Companion come with the platform, and the rest are subscriptions, one-time licenses or quoted plans.

Can an AI agent change my online store without my approval?

It depends on the agent and your settings. Shopify says Sidekick can’t change your live store without your approval, and BigCommerce says Companion does not apply a change without it. Support agents can act on orders by themselves within the rules you set, so test each action, such as a cancellation or a refund, before you switch it on.

Do AI agents for eCommerce work with Magento (Adobe Commerce)?

Yes. Gorgias and Klaviyo both connect to Magento, so their agents can answer customers and build campaigns for a Magento store. In the admin, Magefan’s Magento 2 AI Agent creates and updates products, categories and CMS content from a chat, within each user’s admin role. For code and theme changes, look for agents built for Magento Open Source and Adobe Commerce.

Should we build our own AI agent or buy one?

Buy first if an existing agent covers the job, because it comes with integrations, testing tools and a price you can check today. Build when the work depends on your own rules and systems, such as B2B price lists or a custom catalog. A custom agent connects an AI model to your store through APIs or the Model Context Protocol, a standard way for AI tools to use other systems.

Are AI agents safe to use with customer data?

They can be, if you check before launch which AI provider processes your store’s data and whether that provider trains its models on it. Then give each agent only the access its job needs: a support agent needs order data, while a store-change agent needs your code, and neither should see more customer data than the task requires.

Where to start with AI agents for eCommerce

AI agents for eCommerce pay off when each one has one job and clear limits. Pick the job that takes your team the most hours today, choose an agent built for your platform, test it on real work with the narrowest access it needs, and add the next agent once the first one works the way you expect.

Prices and platform lists change, so open the vendor page again before you sign. For help deciding which jobs to hand to agents first, and how to connect them to your store with the right limits, talk to scandiweb about AI strategy consulting for eCommerce.

Tell us which job piles up first on your team, and we'll say which agent type fits it and what access it would need on your store.

The post AI Agents for eCommerce: What They Do and Which Ones Store Teams Use appeared first on scandiweb.

On October 13, 2026, Adobe published security bulletin APSB26-153 for Magento (Adobe Commerce), with fixes for 11 security holes, and the worst of them scored 10.0 out of 10 for severity. A security bulletin is Adobe’s public notice of what it fixed and which versions get the fix, and each fix reaches your store as a patch: a small file of code changes that closes the hole without a full version upgrade. Adobe’s notes for the October patch also warn that it leaves out September’s emergency fix for a flaw attackers were already using. So which Magento security patch does your store need, and is it already installed?

Every command below comes from Adobe’s own documentation, checked on November 2, 2026, and the Adobe Commerce Cloud differences are marked where they apply.

What is a Magento security patch?

A Magento security patch is a code change from Adobe that closes known security holes in Magento Open Source or Adobe Commerce without adding features. Most arrive in two forms: a security patch release such as 2.4.8-p5, and smaller monthly isolated patch files in between. A flaw that attackers already use gets an emergency hotfix.

Adobe uses the word patch for four different things, and the table shows how each one arrives and how you apply it.

The security patch release is the base, and it installs through Composer, the tool that manages Magento’s code packages. Adobe’s release policy requires the latest -p release for your line before any monthly isolated file goes on.

Every monthly file is then folded into the next security patch release, so a store that moves to the next -p release picks up the months it missed. Each fix carries a CVE, the public ID number a security hole gets, and each bulletin lists the CVEs it closes along with the fixed versions, whether it announces a Magento patch release or a hotfix.

Which Magento security patches does your store need?

Your store needs the latest security patch release for its version line, then every monthly isolated patch Adobe has published since, in release order, plus any hotfix announced on top. Which files exist depends on your version and edition: in October 2026, Adobe’s isolated patch files for Magento Open Source started at 2.4.7.

Adobe’s most recent files, from bulletin APSB26-153 in October 2026, show the pattern for each line.

Whatever your line, check for a hotfix announced since your last patch: it is not part of the monthly file.

Find your Magento version and edition

The version shows in the bottom-right corner of any Admin page. If it is hidden, run bin/magento --version.

Note the edition as well, because Magento Open Source and Adobe Commerce get different files. If you run 2.4.8 or older and the version has no -p suffix, you are behind the latest Magento 2 security patch release, since every line from 2.4.4 to 2.4.8 has one.

Read the bulletin’s affected and fixed versions

Each Adobe Commerce security bulletin has two tables. The first lists the affected versions, the second lists the fixed ones. A label such as 2.4.8-2026-sep means a 2.4.8 store patched through September, and 2.4.8-2026-oct means the same store with October’s file applied.

The October bulletin lists Magento Open Source 2.4.6 as affected, and its fixed versions for Open Source start at 2.4.7, which is why the edition matters. New bulletins are published in the Adobe Trust Center, so bookmark that page rather than Adobe’s older HelpX page.

How to check which Magento security patches are installed

To check which Magento security patches are installed, run Adobe’s Commerce Version Tool from the project root with php vendor/bin/patch-status. It lists applied and missing patches and marks each CVE as PROTECTED, VULNERABLE or UNKNOWN. The tool came with the July 2026 isolated patch, so if the command is missing, apply that file first.

Missing one patch is a common gap: in a scandiweb check of 13,000 Magento 1 stores, published in 2019, 14.82% were open to major breaches, mostly because a single patch was missing.

php vendor/bin/patch-status --version
php vendor/bin/patch-status

Read two lists in the output. applied_patches should hold every monthly file since your -p release, and missing_patches should be empty, with each CVE marked PROTECTED. The output is machine-readable, so you can run it automatically as part of continuous integration (CI) and report on it.

On Adobe Commerce Cloud, check both the patch files and the Cloud Patches package, Adobe’s bundle of required fixes that Cloud applies at deployment.

vendor/bin/magento-patches -n status | grep "248p5-2026-10-001-CE\|Status"
php ./vendor/bin/ece-patches status

The first command shows whether one monthly file is applied, and the second is Adobe’s status check for Cloud Patches for Commerce.

How to apply a Magento security patch, step by step

To apply a Magento security patch, back up the store and work on a staging copy first. Move to the latest -p release for your version, then apply each isolated patch file from the Magento root with patch -p1, oldest month first and CE before EE. Refresh the cache, confirm the result with patch-status, test the store, and release.

1. Back up the store and copy it to staging. Adobe strongly recommends applying and testing every patch on a staging or integration environment first, and keeping a recent backup.

1. Move to the latest -p release for your line. The commands below are for Magento Open Source. On Adobe Commerce, replace magento/product-community-edition with magento/product-enterprise-edition. The full routine, with maintenance mode and compilation, is in our guide on how to upgrade Magento.

composer require-commerce magento/product-community-edition 2.4.8-p5 --no-update
composer update
bin/magento setup:upgrade

1. Download the month’s patch files. Open the bulletin’s knowledge base article, which for October is Adobe’s October 2026 patch article, download the ZIP for your line, and unzip it. Adobe Commerce 2.4.6 or earlier asks for your Composer keys before the download.

1. Apply each file from the Magento root. Apply any missed month first, then CE before EE, then B2B if you run it. CE is the Open Source code and EE the Adobe Commerce code, and Adobe’s order within a month is the CE file, then the EE file. Adobe’s isolated patch guide describes this as how to install a Magento patch file on-premises and on Magento Open Source.

patch -p1 < 248p5-2026-10-001-CE.patch

If that fails, try -p2 instead.

patch -p2 < 248p5-2026-10-001-CE.patch

1. Refresh the cache. In the Admin, open System > Cache Management and refresh it there.

1. Check the result. Run php vendor/bin/patch-status again. The month’s patches should appear under applied_patches, with nothing in missing_patches.

1. Test on staging, then release. Run your usual checkout and admin checks. Then apply the same files in production through your normal deployment. Adobe’s guide says you can apply a patch locally with the same command, then commit and push it as usual.

On a store that skipped several months, repeat step 4 for each month, oldest first: each file assumes the earlier ones are in place, and patch-status lists a skipped month as missing.

How to apply an emergency hotfix

A hotfix arrives on its own, with its own bulletin, as a Composer patch file. Adobe’s October article says September’s hotfix for CVE-2026-75650 is not included in the October isolated file and must be applied separately. Upload it to the Magento root and run the same patch command, then refresh the cache.

patch -p1 < %patch_name%.composer.patch

On Cloud, copy the file to the m2-hotfixes folder in your project, commit, and push. Apply a hotfix as soon as it passes staging. September’s hotfix also meant rotating every exposed credential, which our StyleSmuggler patch guide covers step by step.

How to undo a patch

Quality patches have a revert command. Run ./vendor/bin/magento-patches revert <PATCH-ID> for one patch or ./vendor/bin/magento-patches revert --all for all of them, then ./bin/magento cache:clean. On Cloud, delete a custom patch file from m2-hotfixes and push.

Isolated monthly files have no documented revert command. When Adobe revised October’s 2.4.8-p5 file, it told merchants to reverse the original by using their established patch-management process. So commit each patch file on its own, and roll back that commit if testing fails.

Magento patch tools: Quality Patches Tool or Composer patches?

Use the Quality Patches Tool for Adobe’s official patches and Composer patches for your own fixes. Adobe’s documentation says it does not support applying official, Adobe-provided patches with the cweagans/composer-patches plugin. Monthly isolated security patches are a separate case: they come as patch files, applied with the patch command or, on Cloud, through Cloud Patches for Commerce.

The Quality Patches Tool needs Git or the patch utility installed and writes a log to var/log/patch.log. Adobe’s documentation for the tool warns that applying many patches makes the next upgrade harder, so apply a quality patch only for a bug your store has.

The command-line method in Adobe’s patch guide is the one for the monthly files. For what a Composer patch looks like and how to write your own, see how Composer patches work.

How patching works on Adobe Commerce Cloud

On Adobe Commerce Cloud, the Cloud Patches for Commerce package applies required security fixes during your next deployment, through ECE-Tools. Check your installed Cloud Patches version before adding a monthly isolated file, because applying a fix that is already in place can make the install fail. Your own patch files go in the m2-hotfixes folder.

During a deployment, ECE-Tools, the deployment toolset for Adobe Commerce Cloud, applies patches in a fixed order, with the required patches from Cloud Patches for Commerce first, then the optional quality patches you selected, then your own files in m2-hotfixes in alphabetical order. You select quality patches in .magento.env.yaml, the Cloud project’s configuration file, using the IDs that magento-patches status shows for your store, in place of Adobe’s example IDs below.

stage:
  build:
    QUALITY_PATCHES:
      - MCTEST-1002
      - MCTEST-1003

Your own patch files, and any Adobe Commerce security patch you apply by hand, go into m2-hotfixes. Copy the .patch file into the folder, then commit and push, and check the result with ece-patches status.

mkdir m2-hotfixes
git add m2-hotfixes/
git commit -m "Apply 248p5-2026-10-001-CE.patch patch"
git push origin <branch-name>
php ./vendor/bin/ece-patches status

Adobe’s Cloud patching guide covers the packages and the order.

What to do when your Magento version no longer gets patches

When Adobe stops publishing patches for your version, plan the upgrade to a supported line. Adobe Commerce 2.4.4 and 2.4.5 get isolated security fixes only until May 31, 2027, and Adobe’s October 2026 files for Magento Open Source covered 2.4.7 and later. Until the upgrade is live, backported fixes and close monitoring lower the risk.

Under Adobe’s lifecycle policy, the security-only period for 2.4.4 and 2.4.5 brings isolated security fixes and no quality fixes, and 2.4.7 has standard support until the same May 31, 2027 date. Adobe Commerce 2.4.6 has extended support until August 31, 2027, and security-only fixes until May 31, 2028. Every line’s dates are in our list of Magento end of life dates.

If the upgrade is the real fix, scandiweb’s Magento upgrade services can plan it from your current version. For one critical flaw on an old release, a backport can buy time: our StyleSmuggler fix for older Magento versions covers 41 releases from 2.2.0 to 2.4.3-p3. Keep the Security Scan Tool running in the meantime.

How to keep up with Adobe’s monthly patches

Adobe publishes isolated security patches every month on Patch Tuesday, the second Tuesday of the month, and may release extra patches between them. Subscribe to Adobe’s free security notifications and keep a fixed monthly slot for testing and applying the new files. Agree in advance who applies an emergency hotfix, because those can’t wait for the slot.

Two Adobe pages carry the schedule. Adobe’s monthly patching policy sets out the Patch Tuesday cadence and the order rules, and Adobe’s security notification service emails you each new bulletin for free. Since bulletins moved to the Trust Center in September 2026, the email is the easiest way to hear about a hotfix, because a hotfix comes with its own bulletin on its own day.

Magento patches close the holes in the core. Magento 2 security also depends on the extensions and custom code around it, and Adobe’s enforcement policy puts auditing third-party extensions and securing custom code on the merchant, alongside applying the patches.

Put Patch Tuesday in the calendar

Patch Tuesday is the second Tuesday of the month, and the next one is November 10, 2026. Book a staging slot for the days after it, with the person who applies the files and the person who tests checkout.

Read your extension vendors’ changelogs in the same slot. In November it comes right before the Black Friday code freeze, so book it early.

Decide who applies the patches

A developer on your team can do it with server access and a staging copy. The job is the seven steps above once a month, plus a hotfix now and then. To budget for it, see what a Magento developer costs per hour and on a retainer.

A support partner applies them on a schedule and runs the same staging test, which suits a store with no developer of its own.

A third option is Ari, the AI agent for Magento built by scandiweb. Your team asks for the month’s patch in chat. Ari applies and checks it on a copy of the store with customer data removed, the team reviews the result on a preview store, and a person approves it and releases it as a pull request. Ari has no access to the live store, its servers, or the live database. See how Ari can apply Magento security patches for your store.

Frequently asked questions about Magento security patches

Are Magento security patches cumulative?

Security patch releases are cumulative: each -p release includes the security and quality fixes of the patch release before it. Monthly isolated patch files are not. Adobe calls them non-cumulative, standalone files, so you apply every month’s file in release order on top of the latest -p release for your version line.

Can I skip a month of Magento security patches?

No. Adobe builds each monthly isolated patch on top of the previous month’s, so a store that missed September has to apply September’s files before October’s. Within a month, apply the CE file first, then EE, then the matching B2B file if you run B2B. Run php vendor/bin/patch-status afterward to check that nothing is missing.

Do I still need a hotfix if I install the monthly patch?

Yes. Adobe’s October 2026 knowledge base article says the hotfix for CVE-2026-75650 from bulletin APSB26-146 is not included in the October isolated patch file and must be applied separately. Adobe also reported that this flaw was exploited in the wild, and its notice asks merchants to rotate the encryption key and every exposed credential.

Can I apply Magento security patches with Composer?

Partly. Security patch releases such as 2.4.8-p5 install with Composer, using composer require-commerce and composer update. Monthly isolated patch files are not Composer packages, so you apply them with the patch command. Adobe also says it does not support applying its official patches through the cweagans/composer-patches plugin, which is meant for your own fixes.

Does Magento Open Source get security patches?

Yes, for supported versions. Adobe’s monthly isolated patches cover Magento Open Source as well as Adobe Commerce, but the October 2026 files for Open Source were available only for 2.4.7 and later. Bulletin APSB26-153 lists Open Source 2.4.6 as affected without a fixed version, so 2.4.6 stores need an upgrade plan.

Is the Magento Security Scan Tool free?

Yes. Adobe’s Security Scan Tool is free from the dashboard of your Commerce or Magento account, for both Adobe Commerce and Magento Open Source. It runs more than 21,000 security tests, watches for security risks and malware, and can run weekly, daily or on demand. A Magento security scan checks the live site from the outside, so pair it with patch-status, which reads the code. See Adobe’s Security Scan Tool guide.

Keep every Magento security patch on schedule

A Magento security patch is only done when the files for every month since your last -p release are applied in order and patch-status shows no missing patches. Check your version and edition today, read the latest bulletin, test the files on a staging copy, and book the next Patch Tuesday in the team calendar.

Whoever applies them, the staging test before release is the step that protects checkout. If nobody on your team owns the monthly patch slot, scandiweb’s Magento support and maintenance plans apply Adobe security patches on schedule, tested before release.

If you want a second pair of eyes on your patch status, talk to our Magento support team.

The post How to Apply a Magento Security Patch (and Know Which Ones You Need) appeared first on scandiweb.

Setting up Varnish, the caching server Adobe recommends in front of every live Magento 2 (Adobe Commerce) store, usually takes an afternoon. It keeps finished copies of your pages and hands them to shoppers, so Magento doesn’t have to build each page again. You install it, switch the store over in the admin, load the file Magento generates, and restart. A test page comes back from the cache at once, and at the time, the Magento 2 Varnish configuration looks finished.

Then the odd problems start: a price change that doesn’t show, a homepage that loses its styling after a release, error pages that come and go.

The admin setting only tells Magento that Varnish exists. What Varnish keeps, for how long, and what it drops when a product changes is set in the VCL, the file of rules Varnish runs. Even then, some requests go on to Magento, where the shopper waits for the page build.

What a Magento 2 Varnish configuration includes

A Magento 2 Varnish configuration has four parts: Varnish itself, at a version Adobe supports and with enough memory, the Full Page Cache setting in the Magento admin, the VCL file that Magento generates and Varnish runs, and the purge hosts in Magento’s env.php file, which let Magento clear pages from Varnish when content changes.

In production, Varnish is the full page cache. How a page is cached, keyed and purged is covered in that guide, so this one stays on the Varnish side.

VCL stands for Varnish Configuration Language. The file Magento generates is a starting point, and once you edit it, it is yours: keep your changes in version control and reapply them after each re-export, because a new export doesn’t carry them.

Which Varnish version does Magento 2 support?

Magento 2.4.9 supports Varnish 8, according to Adobe’s system requirements, and so does the latest 2.4.8 patch, 2.4.8-p5. Our Magento 2 system requirements guide lists the other versions each release needs. Earlier 2.4.8 releases list Varnish 7.x, and Adobe’s table gives a version for each older patch line as well. Magento’s VCL generator includes templates for Varnish 6 and 7 only, so on Varnish 8, generate the Varnish 7 file and test it on staging first.

Supported Varnish versions and the VCL templates each Magento release includes. The 2.4.7 line and older have no Varnish 7 template, even where Adobe lists Varnish 8 for their latest patch.

The template number is the lowest Varnish version it supports. On 2.4.9 the Varnish 6 and Varnish 7 files are identical apart from two comment lines, so either one gives the same rules, and nothing in them uses the functions that the Varnish 8.0 upgrade notes list as removed. Adobe hasn’t published a Varnish 8 template, so compile the file with varnishd -C -f default.vcl on your Varnish 8 build and run a purge on staging before it goes live.

Varnish 8 and the Vinyl Cache name

Varnish is still in use, and Adobe still strongly recommends it in production. The open-source project behind it is now called Vinyl Cache. Varnish Cache 8.0, released in September 2025, was its last release line under the old name, and Vinyl Cache 9.0 followed in March 2026. Varnish Software continues a separate distribution that keeps the Varnish Cache name. Adobe’s table says Varnish 8, so install the newest 8.0.x package, 8.0.2 at the time of writing, and check it with varnishd -V before you generate the VCL. The September 2026 advisory VSV00020 covers 8.0.2, but only for VCL that calls the .upper() or .lower() string methods, and the file Magento generates calls neither.

How to configure Varnish for Magento 2, step by step

To configure Varnish for Magento 2:

1. Put Varnish on port 80 and move the web server to port 8080.
2. Set Caching Application to Varnish Cache in the admin.
3. Generate the VCL with bin/magento varnish:vcl:generate --export-version=7.
4. Check the health check URL.
5. Allow Magento to purge.
6. Set memory and header limits, then restart.

These steps assume Magento on-premises. On Adobe Commerce Cloud, skip to the last section.

1. Put Varnish in front of the web server

Varnish listens on port 80 and the web server, nginx or Apache, moves to port 8080, as in Adobe’s guide to configuring nginx for Varnish. Use an IP address or hostname for the backend rather than localhost, even on one machine. For HTTPS, a TLS terminator in front of Varnish passes X-Forwarded-Proto: https, the header Magento’s VCL expects by default, so HTTP and HTTPS copies of a page stay apart.

2. Switch Magento to Varnish and generate the VCL

In the admin’s Full Page Cache section, set Caching Application to Varnish Cache (Recommended), fill in the access list, backend host and port, and grace period, then use the export button for your Varnish version. On 2.4.9 there are buttons for Varnish 6 and Varnish 7. The command line does the same with bin/magento varnish:vcl:generate and the options in Adobe’s CLI reference. Two traps: the default --export-version is still 6, and --access-list takes one IP per flag. Back up /etc/varnish/default.vcl before you replace it, then restart Varnish.

A starting point. Replace the IPs with your own servers.

bin/magento varnish:vcl:generate \
  --export-version=7 \
  --backend-host=192.0.2.20 \
  --backend-port=8080 \
  --access-list=192.0.2.20 \
  --access-list=192.0.2.21 \
  --grace-period=300 \
  --output-file=/tmp/default.vcl

3. Point the health check at the right file

The probe calls health_check.php every 5 seconds with a 2-second timeout and marks the backend sick when fewer than 5 of the last 10 checks pass. The script returns 500 when MySQL or the cache storage can’t be reached. The path depends on your web root. The VCL from 2.4.7 on probes /health_check.php, which fits a web root of pub/. With the Magento folder as the web root, use the older /pub/health_check.php form, which Adobe’s advanced page still shows, because Magento keeps the script only in pub/. Open the URL from the Varnish server to confirm it answers, because a wrong path fails every check and Varnish then treats Magento as down.

From the 2.4.9 VCL. Use /pub/health_check.php if your web root is the Magento folder rather than pub/.

backend default {
    .host = "192.0.2.20";
    .port = "8080";
    .first_byte_timeout = 600s;
    .probe = {
        .url = "/health_check.php";
        .timeout = 2s;
        .interval = 5s;
        .window = 10;
        .threshold = 5;
    }
}

4. Let Magento purge Varnish

When a product, category or price changes, Magento sends a PURGE request with the cache tags to each host in http_cache_hosts. Set them with setup:config:set --http-cache-hosts. Without them, Magento purges the store’s own host name on port 80, which misses a Varnish on another port or server. Varnish accepts a purge only from an IP in acl purge and answers 405 otherwise. In most setups that means the address of every server that runs Magento, which is what the generator’s access list is for. Adobe’s page words it as the Varnish host’s IP, the same machine when the two share a server, so with a load balancer in between, check which address Varnish sees. On several web servers, as in an autoscaling setup, every node sends purges. When Magento can’t reach any purge host, it logs “No cache server(s) could be purged” in var/log/system.log. A 405 from Varnish leaves no log entry, so test each Magento server with the purge request below.

Comma-separated, no spaces. The port can be left out for port 80. The test purge bans a tag that no page carries, so it clears nothing: 200 Purged means the server is allowed, 405 means it isn’t.

bin/magento setup:config:set --http-cache-hosts=192.0.2.30:80,192.0.2.31:80

# Run on each Magento server: 200 Purged = allowed, 405 = not in acl purge
curl -i -X PURGE -H 'X-Magento-Tags-Pattern: ((^|,)no_such_tag(,|$))' http://192.0.2.30/

5. Set memory and header limits before you go live

With no storage option, Varnish starts with 100 MB, and Adobe gives no size. Give it what the server can spare and watch the eviction counter covered in the measurement section. Category pages carry one cache tag per product in the X-Magento-Tags header, and past Varnish’s 8 KB default the browser gets 503 Backend Fetch Failed. Adobe’s 503 guidance sizes http_resp_hdr_len from the largest category, product count times 21, and raises http_resp_size with it. Varnish takes the response headers from workspace_backend, 96 KB by default, which Adobe’s snippet also sets, so give it room above http_resp_size. These options live in your Varnish service file, and the path depends on the OS. Change them well before peak season and your code freeze, then retest with a load test at peak traffic.

A starting point from Adobe’s 503 guidance. Size the header limit from your largest category (products × 21), keep the workspace above the response size, and set the memory to what the server can spare.

varnishd -a :80 -f /etc/varnish/default.vcl \
  -s malloc,<size> \
  -p http_resp_hdr_len=65536 \
  -p http_resp_size=98304 \
  -p workspace_backend=131072

On Adobe Commerce Cloud, configure Fastly instead

On Adobe Commerce Cloud, full page caching uses Fastly, a Varnish-based CDN, through the Fastly CDN module that Adobe installs on Pro Staging and Production and on Starter Production. There is no default.vcl to edit, and custom rules go into Fastly custom VCL snippets. The VCL rules in the rest of this article describe what Magento expects from its cache. Fastly runs its own configuration.

What the Magento VCL does with query strings, cookies and TTLs

Magento’s VCL builds the cache key from the URL plus the X-Magento-Vary cookie, so other cookies don’t split the cache. On 2.4.9 it sorts query parameters and strips a fixed list of marketing parameters. It stores only 200 and 404 responses that aren’t marked private, and everything else goes to Magento.

The generated VCL sets what counts as the same page. The rules below are read from the VCL Magento 2.4.9 generates, and several of them changed between releases.

Query strings: sorted, and marketing parameters stripped

The 2.4.9 VCL sorts query parameters first, so ?color=red&size=m and ?size=m&color=red share one entry. Sorting is new in 2.4.9. It then removes known tracking parameters: utm_ parameters, Google and Microsoft click IDs such as gclid and msclkid, fbclid, mc_ parameters and a few more. Lists differ by release: 2.4.8 added the Google and Microsoft click IDs, and Magento’s development branch already carries a much longer list. A parameter missing from your release’s list gives every click its own cache entry. Add it to both regex lines in vcl_recv and note the change for the next re-export. Filter parameters must stay, because they change the page. The removal pattern only checks that the URL holds a tracking parameter, then cuts every match, even inside a longer name: on 2.4.9 a link to ?country_of_origin=12&utm_source=newsletter reaches Magento as ?country_of_, so the shopper lands on the unfiltered page. If a filter or other parameter name ends in a listed name, such as origin or ie, anchor the pattern to ? or &.

Cookies: only X-Magento-Vary splits the cache

X-Magento-Vary is the cookie in which Magento records the shopper’s context, such as customer group, store and currency. The VCL hashes only that value out of the Cookie header, so analytics and consent cookies don’t create extra copies of a page. It removes Set-Cookie from cacheable responses, and since 2.4.7 it won’t store a page whose response sets X-Magento-Vary when the request didn’t send it. Custom code that adds values to the context multiplies the copies of every page. Passing requests on session cookies, as some tutorials advise, adds nothing, because the hash already ignores them.

TTLs, status codes and pages Varnish won’t store

The TTL comes from Magento’s s-maxage header, set by the admin field “TTL for public content”, 86400 seconds by default. Only 200 and 404 responses that aren’t marked private are stored. A response marked no-cache or no-store gets a two-minute marker, and requests in that window go straight to Magento. The VCL comment calls the marker hit-for-pass, while Varnish 8’s reference says beresp.uncacheable produces a hit-for-miss object, so expect these requests in cache_hitmiss rather than cache_hitpass. Browsers get no-store for HTML, so the browser never holds a stale page. Static and media files pass by default, so serve them from the web server or a CDN.

Grace mode, purges and ESI in the Magento VCL

Magento’s VCL keeps every page for three days past its TTL. While the backend passes its health check, Varnish serves an expired page for the admin’s grace period, 300 seconds by default, and fetches a fresh one. If the check fails, it keeps serving stale pages. A purge from Magento, sent as a ban by cache tag, removes pages outright.

Grace mode keeps expired pages for three days

The VCL keeps every object three days past its TTL. While the backend passes its health check, Varnish serves an expired copy for up to the admin’s grace period, 300 seconds by default, and refreshes it in the background. After that, the request waits for a fresh build. When the health check fails, Varnish keeps serving what it has, which keeps a store up through a short outage, as Adobe’s advanced Varnish page describes. A Grace header on hits shows which case applied: “none” for a copy within its TTL, “normal (healthy server)” or “unlimited (unhealthy server)”. A page removed by a purge is not served in grace.

Purges are bans by cache tag

Magento sends tags rather than URLs, so one product save can clear the product page, its categories and any block that shows it. Varnish turns each purge into a ban on X-Magento-Tags, which applies to every stored object with a matching tag. These are obj.* bans, so Varnish’s background ban lurker can clean them up. The next shopper gets a miss, unless a cache warmer requests the page first. Count bans in MAIN.bans: a number that climbs all day points to imports, cron jobs or mass saves.

ESI blocks are cached on their own

ESI stands for Edge Side Includes, a way for Varnish to assemble a page from separately cached pieces. With Varnish selected, a layout block with its own ttl, such as the default theme’s top menu, becomes an ESI include that points at page_cache/block/esi and is cached with its own TTL and tags. The admin field “Handles params size” caps how many layout handles the include passes, 100 by default, and Magento’s own comment advises 50–100. Watch MAIN.esi_errors.

How to measure and raise your Varnish hit rate

To measure your Varnish hit rate in Magento 2:

1. Read the X-Magento-Cache-Debug header: HIT, MISS or UNCACHEABLE.
2. Compare MAIN.cache_hit with MAIN.cache_miss in varnishstat.
3. Group requests by URL and result with varnishncsa.
4. Trace one slow URL with varnishlog.
5. Watch MAIN.n_lru_nuked for evictions and MAIN.bans for purges.

Varnish answers hits. Every miss and pass goes to Magento, so the hit rate sets how much of your traffic waits for PHP.

Read the cache headers

The VCL sets X-Magento-Cache-Debug on every response: HIT, MISS, or UNCACHEABLE on 2.4.7 and later. UNCACHEABLE means Magento told Varnish to skip the page. It’s there in production mode too, although Adobe’s verification page says to switch to developer mode to see the headers. Developer mode only adds X-Magento-Cache-Control and keeps Age. If the debug header is missing, the response didn’t pass through Magento’s VCL, so check that Varnish loaded the new file and that no proxy or CDN in front removes the header. If the header says HIT and the page is still slow, the wait is elsewhere: see why a Magento site gets slow.

Count hits and misses with varnishstat

varnishstat is Varnish’s live counter tool. The Varnish 8 counters that matter: cache_hit (which includes grace hits, counted separately in cache_hit_grace), cache_miss, cache_hitpass and cache_hitmiss for the “don’t cache” markers, s_pass for passes, n_lru_nuked for objects evicted to make room, and bans. A practical hit rate is hits divided by hits plus misses plus passes, measured over a busy day and per page type where you can. No published target fits every store, so measure your own.

Find the URLs that miss with varnishncsa and varnishlog

varnishncsa writes one line per request. Log ten minutes or a busy day with the handling value and URL path, then group the lines to see which page types miss or pass. varnishlog follows one URL through Varnish and its backend request. Then time the pages that miss, as you would when you audit your store page type by page type, because misses show up in field data as slow server response time.

Run on the Varnish server. Counters are totals since Varnish started.

# Hits, misses, passes, evictions and bans since Varnish started
varnishstat -1 | grep -E 'MAIN\.(cache_hit|cache_hit_grace|cache_miss|cache_hitpass|cache_hitmiss|s_pass|n_lru_nuked|bans) '

# Ten minutes of requests: how Varnish handled each URL path
timeout 600 varnishncsa -F '%{Varnish:handling}x %U' > /tmp/handling.txt
sort /tmp/handling.txt | uniq -c | sort -rn | head -30

# Follow one URL through Varnish and Magento
varnishlog -g request -q 'ReqURL ~ "^/women/tops"'

Fix what keeps the hit rate low

Match what the log shows to the change that fixes it.

1. Many pass or hitmiss lines on catalog pages: find what sends Cache-Control: private, no-cache or a block marked cacheable="false".
2. Misses on the same URLs again and again, with MAIN.bans climbing: move imports and mass saves off-peak, and stop flushing the cache on every deploy.
3. Misses with n_lru_nuked climbing: Varnish is evicting pages to make room, so give it more memory.
4. Many one-off URLs: strip the extra tracking parameters, and accept that layered navigation filters and rare searches miss more often.
5. 503 errors: raise the header limits and check the health check URL, as in the setup steps.

What still reaches PHP when Varnish is tuned

Even with a tuned VCL, Varnish passes every POST, cart, checkout and account request to Magento. It also misses the first request after each purge, rare filter and search URLs, and each customer group’s first view of a page. Those shoppers wait while Magento builds the page in PHP, so the build speed sets their response time. A miss also runs the database queries behind each block, covered in our Magento MySQL optimization guide. Server response on uncached pages is also where Magento trails most other platforms, as our fastest eCommerce platforms research shows.

A pass or a miss costs a full page build in PHP, and that build is the time those shoppers wait. Cache settings move requests between the two groups, and for the second group only the build speed counts.

Expedio, scandiweb’s software for the server-side page build, works on exactly those requests. It speeds up how Magento builds each page by applying Liquid, the open-source template language created at Shopify, and its core is open source. It runs on Magento 2 Open Source, Adobe Commerce and Commerce Cloud, with Luma, Hyvä or a custom theme and on any hosting, and it leaves the theme, design, data, admin, catalog, prices, checkout and orders as they are. Pages that reach Magento are built at least 2x faster, and the same server handles 3x the traffic before response times start to rise.

In a benchmark on one merchant’s Hyvä store, measured as server response time with no full page cache, category pages opened with all caches empty took a median of 57 ms instead of 181 ms. The method and caveats are in the Expedio benchmark.

Frequently asked questions about Magento 2 Varnish configuration

Which Varnish version should I use with Magento 2.4.9?

Use Varnish 8. Adobe’s system requirements list Varnish 8 for Magento 2.4.9 and 2.4.8-p5, and give a version for each older patch line. Magento’s VCL generator has no Varnish 8 template, so generate the Varnish 7 file with --export-version=7, then test it on staging before it goes to production.

How do I generate the Varnish VCL for Magento 2 from the command line?

Run bin/magento varnish:vcl:generate. It prints the VCL, or writes it to a file with --output-file. Set --export-version to 7 for Varnish 7 or 8, because the default is still 6, and pass the backend host and port, the grace period, and each IP allowed to purge with --access-list. Then replace /etc/varnish/default.vcl and restart Varnish.

Why does Varnish return 503 Backend Fetch Failed on Magento?

One common cause is response headers that are bigger than Varnish allows. Category pages carry a cache tag for each product in the X-Magento-Tags header, and Varnish’s default limit is 8 KB. Adobe suggests setting http_resp_hdr_len to your largest category’s product count times 21, for example 65536, and raising http_resp_size above it.

Why are Magento pages not being purged from Varnish?

Magento sends a PURGE request to every host in http_cache_hosts, and Varnish answers 405 unless the sender’s IP is in the VCL’s acl purge list. Set the hosts with bin/magento setup:config:set --http-cache-hosts, add each Magento server’s IP to acl purge, then send a test PURGE from each one: 200 means Varnish accepts it, 405 means the IP is missing. Magento logs “No cache server(s) could be purged” only when it can’t reach any host.

What is the difference between Varnish and Redis caches?

Varnish caches whole pages in front of the web server, so a cache hit never reaches Magento. Redis, or Valkey on Magento 2.4.9, holds Magento’s own cache data and sessions in memory, which speeds up the work Magento does when Varnish misses. Most production stores run both: Varnish for pages, Valkey or Redis for the rest.

Is Varnish used on Adobe Commerce Cloud?

No. On Adobe Commerce Cloud, full page caching uses Fastly, a Varnish-based CDN, instead of a Varnish server you run yourself. Adobe installs the Fastly CDN module for Magento 2 on Pro Staging and Production and on Starter Production. Custom caching rules go into Fastly custom VCL snippets rather than a default.vcl file.

Magento 2 Varnish configuration: what to check after every upgrade

A Magento 2 Varnish configuration is done when you can show three things: the VCL matches your Magento and Varnish versions, Magento’s purges reach every Varnish host, and you know your hit rate by page type. Check all three after every upgrade. Then make the requests Varnish sends on to Magento faster.

The version table, the health check path and the marketing parameter list are the three things that change most often between releases, so re-export the VCL after each upgrade and diff it against the one in production. Where the two differ, carry your own changes into the new file, and keep a Magento 2 Varnish check on the release checklist. For the layers around Varnish, from PHP to the browser, see how to speed up Magento layer by layer.

If you're moving to Varnish 8 for Magento 2.4.9, or your hit rate is lower than you expected, talk to our Magento team about a review of your VCL and purge setup.

The post Magento 2 Varnish Configuration: Setup, VCL Tuning, and Hit-Rate Fixes appeared first on scandiweb.

Installing an extension in Magento 2 (Adobe Commerce), an add-on that brings a feature such as a blog or a one-page checkout, takes a handful of commands. Most vendors print them right on the download page.

What goes wrong is everything around those commands. The extension may need a newer version of PHP, the programming language Magento runs on, than your server has. Or a second extension you already run may change the same part of checkout. Neither problem shows up while you type. You find out when a page fails to load or checkout stops taking orders, and if the install ran on the live store, your customers find out at the same moment.

What you need before you install a Magento 2 extension

Before you install an extension in Magento 2, you need command-line access to the server as the file system owner, the extension’s Composer name and version, and access keys from the Adobe Commerce Marketplace if you bought it there. You also need a staging copy of the store and a fresh database backup.

The file system owner is the server user that owns the Magento files. On shared hosting, Adobe says this is the user your provider gives you to log in. Staging is a private copy of the store that matches the live one, and every command in this guide runs there first.

Access keys for Adobe Commerce Marketplace extensions

To install a Magento 2 extension from the Marketplace, you need a pair of access keys. Magento extensions bought on the Adobe Commerce Marketplace, the former Magento Marketplace, download from repo.magento.com, which asks for them. You create access keys in the Marketplace under your account name > My Profile > Access Keys > Create a New Access Key. The public key is the username and the private key is the password.

Use the keys of the account that installed the store. Adobe says a key from another user or a shared account cannot be used. Check that your composer.json lists https://repo.magento.com/ under repositories. An extension bought from a vendor’s own site comes with the vendor’s own repository or a ZIP file instead.

An extension that matches your Magento and PHP versions

Open the extension’s composer.json and read its require block, or check the vendor’s listing, for the Magento and PHP versions it supports. Adobe’s advice for Cloud projects, to check the required PHP version before you begin, applies to every store.

If the extension needs a newer Magento release than yours, the install turns into an upgrade first: see how to upgrade Magento, and check the Magento version support dates to see whether your release still gets security patches. If your storefront runs on Hyvä, a theme that replaces Magento’s default Luma storefront, check now whether a compatibility module exists. The conflicts section below explains why.

A staging copy and a backup you can restore

We’ve written about why staging and rollback matter for every extension, so two practical points are enough here.

Run every command on a copy of the store that matches production first. And take a database backup you can restore, with your host’s snapshot or a dump tool. Magento’s built-in backup command has been deprecated since 2.3.0 and is off by default, and Adobe points to other tools such as Percona XtraBackup.

How to install an extension in Magento 2 with Composer

To install an extension in Magento 2 with Composer, turn on maintenance mode and run composer require with the extension’s name and version. Then enable it with bin/magento module:enable and run setup:upgrade, setup:di:compile, and, in production mode, setup:static-content:deploy. Clean the cache, turn maintenance mode off, and configure the extension in the admin.

1. Turn on maintenance mode: bin/magento maintenance:enable (add --ip= and your IP address to keep your own access).
2. Add the extension: composer require vendor/module-name:version, for example Adobe’s composer require j2t/module-payplug:2.0.2. If Composer asks for a username and password, enter your public key as the username and your private key as the password. Wait until Composer finishes without errors.
3. Check that it arrived: bin/magento module:status Vendor_ModuleName. The module name differs from the Composer name, and a new extension usually shows as disabled.
4. Enable it: bin/magento module:enable Vendor_ModuleName --clear-static-content
5. Register it: bin/magento setup:upgrade
6. Compile the code: bin/magento setup:di:compile
7. In production mode, deploy static files: bin/magento setup:static-content:deploy (add your store’s locale codes, such as en_US de_DE, if it runs more than one language).
8. Clean the cache: bin/magento cache:clean
9. Turn maintenance mode off with bin/magento maintenance:disable, then configure the extension in the admin.

The order follows Adobe’s guide to third-party extensions, with the static content deployment added for production mode. Composer is the PHP package manager Magento uses to download and track extensions. For what it does behind each command, our developer guide to installing a Composer package goes one level deeper.

Developer mode or production mode: what changes

Check the mode with bin/magento deploy:mode:show. In production mode, Magento doesn’t generate static files such as CSS and JavaScript on its own, so step 7 is required. You may also be asked to rerun the compile command, and errors go to log files, never to the visitor’s screen.

In developer mode, Magento compiles automatically and builds static files when a page asks for them, but Adobe still says to clean the old ones when you enable a module, which the --clear-static-content option in step 4 does. Errors display in the browser. Developer mode is not supported on Adobe Commerce Cloud.

How to install a Magento 2 extension manually from a ZIP file

To install a Magento 2 extension from a ZIP file, unpack it into app/code/Vendor/Module so that registration.php is in the root of that folder. Then run the same commands as a Composer install: module:enable, setup:upgrade, setup:di:compile, static content deployment in production mode, and cache:clean. Composer remains the safer route for updates and removal.

Composer puts modules in the vendor folder. A module you unpack yourself goes in app/code, where Adobe recommends keeping a store’s own code.

1. Unpack the archive into app/code/Vendor/Module, with the vendor and module folder names from the package. Check that registration.php is directly in that folder: every module needs one in its root.
2. If the vendor includes a shared base module, unpack that too. Mageplaza’s ZIP route, for example, has you download its Mageplaza_Core module separately, because a ZIP doesn’t pull in other packages the way Composer does.
3. Run every command as the file system owner, the server user that owns the Magento files (on shared hosting, the user your provider gives you to log in).
4. Turn on maintenance mode on a live store, then run steps 3 to 9 of the Composer list: module:status, module:enable, setup:upgrade, setup:di:compile, static content deployment in production mode, cache:clean.

Why Composer is the safer route

The commands after a ZIP install are identical. Composer earns its place in what happens afterwards.

• composer.lock records the exact version of every package, so staging and production run identical code once you commit it.
• An update is one command, composer update vendor/module-name, followed by the usual upgrade and deploy steps.
• Adobe’s module:uninstall command works only for Composer packages. A ZIP install has to be removed by hand.
• Composer checks the extension’s PHP requirement against the PHP version on your server before anything is installed.

A ZIP into app/code is still the right place for a custom module built for your own store.

How to check the install and spot extension conflicts

Run bin/magento module:status with the module name to confirm the extension is enabled, then test every page it touches. If something breaks, bin/magento dev:di:info lists the plugins and the preference that change a class, so you can see whether two extensions modify the same code. On a Hyvä storefront, also check for a compatibility module.

After you install an extension in Magento 2, three checks tell you whether it is safe to release.

Confirm the extension is enabled

Run bin/magento module:status Vendor_ModuleName and look for “Module is enabled”. Then open the extension’s settings in the admin and load the storefront pages it changes. If the storefront shows errors, Adobe’s tip is bin/magento cache:flush. In production mode, errors go to the log files, so a blank or broken page means a trip to the logs.

Plugins and preferences: when two extensions change the same code

A plugin runs extra code before, after, or around a Magento function. When several plugins target the same function, Magento runs them in the order set by each plugin’s sortOrder, and Adobe says this approach reduces conflicts among extensions that change the same class. A preference replaces a whole Magento class with the extension’s own class, and two extensions that replace the same class can clash. Magefan, an extension vendor, says rewriting existing classes often leads to conflicts.

To see what already changes a class, run bin/magento dev:di:info "Magento\Checkout\Block\Onepage\Success", swapping in the class you care about (this one is Adobe’s own example, the checkout success block). The command prints the preference and the plugins on that class. Run it for the classes the new extension touches, before and after the install, and compare. Vendors can also declare known conflicts in the conflict field of composer.json, and Magento then won’t enable both modules at the same time.

Hyvä compatibility modules

Hyvä is a lighter storefront theme that replaces Magento’s default Luma theme. Extensions built for Luma or the blank theme need a compatibility module, which re-implements the parts that don’t work on a Hyvä storefront. The Hyvä docs on Hyvä compatibility modules point to the Compatibility Module Tracker, which lists the compatibility modules that exist and the state each one is in. Check it before you buy, and install the compatibility module together with the extension.

How to disable or uninstall a Magento 2 extension

To roll back an extension quickly, disable it with bin/magento module:disable and clean the cache. To remove it for good, run composer remove for a Composer install, or delete its app/code folder for a ZIP install, and take it out of config.php. Ask the vendor how to revert its database changes, and test the removal on staging first.

Adobe’s advice is to uninstall a module only if you’re certain you won’t use it again, and to disable it otherwise.

• Roll back fast: bin/magento module:disable Vendor_ModuleName --clear-static-content, then clean the cache (recompile with setup:di:compile in production mode). Disabling keeps the code and data, so you can turn it back on.
• Remove a Composer install: Adobe’s module:uninstall command, bin/magento module:uninstall Vendor_ModuleName, works for Composer packages only. It runs composer remove and handles maintenance mode itself. Add --remove-data only if you want the module’s database tables and data gone too. Or run composer remove vendor/module-name directly.
• Remove a ZIP install: rm -rf app/code/Vendor/Module, then take the module out of app/etc/config.php if that file is in source control, and run setup:upgrade.
• Database changes: ask the vendor how to revert its tables and data. Adobe says to get those instructions from the vendor.
• Order: do it on staging first and check the store works there, then repeat on production.

How extension installs work on Adobe Commerce Cloud

On Adobe Commerce Cloud, you install an extension on your own machine, in a development branch: run composer require with –no-update, then composer update, and push composer.json and composer.lock with git. The deployment enables the extension for you. Adobe says never to enable or disable an extension while logged in to a remote environment.

Adobe recommends a development branch for every extension you add. The steps, from Adobe’s Cloud extension guide:

1. On your machine, open the project folder and create or check out a development branch.
2. composer require vendor/module-name:version --no-update
3. composer update
4. git add -A, then commit with a message such as “Install vendor/module-name”.
5. git push origin <branch-name>
6. After the build and deploy finish, log in to the environment over SSH and run bin/magento module:status Vendor_ModuleName.

Two things differ from a self-hosted store. Buy Marketplace extensions with the same account (MAGEID) that owns the Cloud project, which Adobe says avoids installation issues. And the deployment puts the site in maintenance mode by itself.

The push must include composer.lock, because the remote environment reads it to install the same versions you tested. If you enable a module locally, run ./vendor/bin/ece-tools module:refresh and commit app/etc/config.php.

How to install a Magento 2 extension without the command line

Magento 2.4 can’t install extensions from the admin: Adobe removed the Web Setup Wizard in 2.4.0, so every install runs from the command line. If you don’t have command-line access, someone else has to run the commands for you, either a developer with access to your server or an AI agent that works on a copy of your store.

The first route is a developer with access to your server, from your agency, your host, or a freelancer, who runs the Composer steps above on staging first. Ask for the module:status output and a test of the pages the extension changes before the production release.

Ari, the AI agent for Magento built by scandiweb, is one way to do it from a chat. Its marketplace lists ready-made extensions from vendors including Amasty, Mageplaza, MagePal, Magefan, WeltPixel, and Yireo, and Ari works with 1,000+ extensions, custom ones included. Ari installs the free version on a copy of your store with customer data removed, checks it against your theme and the modules you already run, and shows you how to set it up.

Your live store doesn’t change until a person approves the release, which arrives as a pull request. Paid versions are bought from the vendor, and Ari plans start from €99 a month per store. You can browse the marketplace and install Magento extensions in chat.

For the other kinds of AI tools a Magento store can use, see our guide to Magento AI.

Frequently asked questions about installing Magento 2 extensions

What is the difference between a Magento extension and a module?

A Magento extension is packaged code that adds to or changes what Magento does. Adobe counts three kinds: modules add features, themes change how the storefront and admin look, and language packages translate them. Most extensions sold on marketplaces are modules, so in everyday use the two words mean the same thing.

Is the Magento Marketplace the same as the Adobe Commerce Marketplace?

Yes. The old Magento Marketplace address, marketplace.magento.com, now redirects to commercemarketplace.adobe.com, Adobe’s store for free and paid extensions. Adobe says every extension listed there passes its Extension Quality Program, an automated check plus a manual review. To install one, you need the access keys from your Marketplace profile.

Why doesn’t my new extension show up in the Magento admin?

Usually the extension is still disabled or the cache is out of date. Run bin/magento module:status with the module name, because Adobe notes a new extension is probably disabled after composer require. Enable it, run setup:upgrade and setup:di:compile, then clean the cache. If the storefront shows errors, run bin/magento cache:flush.

Do I need maintenance mode to install a Magento extension?

Adobe lists it as optional, but it is the safer choice on a live store. bin/magento maintenance:enable shows visitors a 503 maintenance page while the commands run, and the --ip option lets your own IP address through. On Adobe Commerce Cloud, the deployment switches maintenance mode on by itself.

Do I need to run setup:static-content:deploy after installing an extension?

Only in production mode. There, Magento doesn’t generate CSS, JavaScript, and image files on demand, so a new extension’s files don’t appear until you deploy them with setup:static-content:deploy. In developer mode, Magento builds those files when a page asks for them, so clearing the old ones with --clear-static-content is enough.

How do I update a Magento 2 extension?

For a Composer install, run composer update vendor/module-name, or composer require vendor/module-name with the new version. Then run bin/magento setup:upgrade --keep-generated, setup:static-content:deploy, and cache:clean, as in Adobe’s guide. Check the new version’s Magento and PHP requirements before you start, and run the update on staging first.

Before your next Magento 2 extension install

Installing an extension in Magento 2 takes a few commands, and Adobe documents each one. The work that protects your store happens around them: the version check, the conflict check, the staging run, and the rollback plan. Do them in that order, on a copy of the store, before the extension reaches production.

Prefer Composer where the vendor offers it, since it records the exact version and makes updates and removal one command. A ZIP into app/code still works for a module built for your own store. If nobody on your side has command-line access, hand the job to a developer or to an agent that works on a copy, so the live store changes only when you say so. If you’d rather not run installs and rollbacks yourself, talk to scandiweb’s Magento support team.

If you'd like a second pair of eyes before the next install, send us the extension name and your Magento version.

The post How to Install an Extension in Magento 2: Composer, ZIP, and a No-Code Option appeared first on scandiweb.

When a Magento (Adobe Commerce) store slows down, the conversation about it tends to follow a script: the host blames the code, the developers blame the server, and someone asks whether clearing the cache would help. All three are guesses, because nobody in that conversation can see what Magento does while it builds a page.

A Magento profiler lets you see it. It’s a tool that times each step Magento takes to build one page and shows which steps used the time. Magento comes with a basic one. New Relic, a monitoring service that records timings from every request on a live store, and Blackfire, a profiler you aim at one request at a time, go further. Which tool you pick, and which page you point it at, decides whether the result names a real culprit or sends you after the wrong one.

What is a Magento profiler?

A Magento profiler is a tool that times each step Magento takes to build a page: matching the URL to a controller, loading the layout, rendering blocks and templates, running extension code and querying the database. It lists every step with its time and how often it ran, so you can see where one page spends its time.

Two kinds of tool do this. Magento’s own profiler, Blackfire and Xdebug time one request in detail. New Relic, an APM (application performance monitoring), watches every request on the live store. They answer different questions.

What a profile of one page shows

Take one page Magento has to build from scratch. It finds the controller for the URL (routers_match), loads and merges the layout, the XML instructions that say which blocks go on the page (LAYOUT), and builds the page structure (generate_elements). A block is one piece of the page, such as a product list, and its template is the file that turns the block’s data into HTML. Each template is rendered in turn (TEMPLATE: plus the file name). Along the way, Magento runs observers, extension code that responds to its events (OBSERVER:), and plugins, extension code wrapped around one of its own functions.

Each block’s data comes from the database, so a block that runs once per product multiplies its queries. Magento’s own profiler has no timers for plugins or single queries. New Relic and Blackfire show both.

Profile a page the cache doesn’t serve

Most stores run a full page cache, usually Varnish, a cache that keeps finished pages and sends them without asking Magento to build them again. A page served from Varnish never reaches Magento, so there is nothing to profile. Logged-in, filtered and search pages are cached too, per customer group and per search term. They just miss more often, which is why shoppers feel them. For what the cache keeps and when it misses, read how Magento’s full page cache works.

On a staging copy (a copy of the store for testing, with production data and settings), switch the page cache off with bin/magento cache:disable full_page so Magento builds every page, and turn it back on with cache:enable full_page afterwards. With html output, the profiler table appears only on a page Magento built, so no table means the page came from a cache.

To see which page types are slow before you profile, time them from the cache and uncached, as our guide on how to audit Magento performance shows.

How to enable the Magento 2 profiler

To enable the Magento 2 profiler:

1. Use a staging or local copy.
2. In the Magento root, run bin/magento dev:profiler:enable html (or csvfile).
3. Load the page you want to measure.
4. Read the table at the bottom of the page, or var/log/profiler.csv.
5. Run bin/magento dev:profiler:disable when done.

# Magento root, staging or local copy, as the file system owner
bin/magento dev:profiler:enable html      # table printed below each page Magento builds
bin/magento dev:profiler:enable csvfile   # or: timings written to var/log/profiler.csv
bin/magento dev:profiler:disable          # removes var/profiler.flag

The command writes var/profiler.flag with the output type, and disabling deletes it. The MAGE_PROFILER bootstrap variable does the same job, set as Adobe’s profiling page describes. Set to 2, it also prints dependency graphs, which list objects Magento created but never used.

One warning from the code: Magento checks only that the flag exists and that the request asks for an HTML page. It doesn’t check the store’s mode, so on a live server every page Magento builds would carry the table, and the CSV would hold whichever request ran last. Staging or a local copy only, and disable it when you finish. Because of that HTML check, the profiler times browser page loads only. API and AJAX calls need New Relic or Blackfire.

How to read the profiler table

The caption shows the memory the request used. Under it, there is one row per timer: Time in seconds, Avg, Cnt (how many times it ran), Emalloc and RealMem (memory). Nested timers are indented under their parent, so start from magento, the whole request, and follow the biggest child down. Read Cnt next to Time: a template rendered once per product in a list shows a high count. To compare two runs, open two csvfile outputs in a spreadsheet.

Count queries with the database profiler

Magento’s database profiler lists every query a page sends, with its time and parameters, and the total count. It is switched on in app/etc/env.php, Magento’s main settings file for the server.

// app/etc/env.php, inside 'db' => ['connection' => ['default' => [ ... ]]]
'profiler' => [
    'class' => '\Magento\Framework\DB\Profiler',
    'enabled' => true,
],

Adobe’s database profiler page has the short snippet that prints the result, which goes into pub/index.php after the $bootstrap->run($app) line. It prints the queries into the page, so staging only, and remove both when you finish. Read the total count first, then look for queries that repeat with only the ID changing, which points to a block or plugin that loads data one item at a time. When a few queries are slow rather than many being quick, the next step is the MySQL slow query log, covered in our guide to Magento MySQL optimization.

Magento 2 New Relic integration

Magento 2 connects to New Relic through New Relic’s PHP agent, which runs inside PHP on the web server and sends timing data for every request to your New Relic account. New Relic lists Magento 2 among the frameworks the agent supports. On Adobe Commerce Cloud, New Relic APM is already included for Production and Staging.

The PHP agent is a PHP add-on that sends timing data to New Relic. There, requests are grouped into transactions, such as category or product views, ranked by the time they take, with code-level and database query traces for individual requests. This is Magento performance monitoring, and it runs all the time on the live store.

New Relic on Adobe Commerce Cloud

Every Adobe Commerce on cloud infrastructure project includes New Relic APM, on Pro and Starter, for Production and Staging, with the software and the license key. There is nothing to buy or install. Pro adds New Relic Infrastructure and Log Management. Two limits, from Adobe’s New Relic service page: other New Relic features aren’t available, and you can’t send data from servers outside the project. Read “Most time consuming” in the APM summary first. In Adobe’s example, product and category views sit at the top, and a customer account page that suddenly ranks high has a call or a query dragging it down.

New Relic on your own servers

Install New Relic’s PHP agent on each web server: the agent runs inside PHP and records timings, and a daemon forwards the data to New Relic. New Relic lists Magento 2 as a supported framework on its PHP agent compatibility page. Check the agent version after a PHP upgrade: PHP 8.5, which Magento 2.4.9 runs on, needs agent 12.4.0.29 or later. For the PHP version of each release, see the Magento 2 system requirements. Keep New Relic running during a Magento load test, so you can see which requests slow down first as traffic climbs.

The New Relic Reporting module in Magento 2

Magento includes a module called New Relic Reporting, and it isn’t the profiler. The timing data still comes from the PHP agent, and the module needs that agent installed to do anything. What it adds is store events in your New Relic account: deployments, cache flushes, product saves, orders, and logged-in admins and customers. The settings are under Stores > Settings > Configuration > General > New Relic Reporting, and on 2.4.9 you can choose the newer NerdGraph API for deployment markers. Marking a release is optional:

# Needs the New Relic Reporting settings filled in
bin/magento newrelic:create:deploy-marker "Release 2026-11-04" "Checkout fixes" "deploy-bot"

Adobe removed the module’s documentation in September 2025 and calls the feature deprecated, though the module still comes with 2.4.9, in the module’s folder on GitHub.

Blackfire and Xdebug: profile one request in depth

Blackfire is a PHP profiler that records one request in full: each function call, the time it took and what called it, shown as a call graph and a timeline. Its maker says profiling HTTP requests has no impact for other visitors. Xdebug’s profiler gives similar detail on a developer’s own copy of the store.

A call graph is a map of which function called which, with the time each took.

Blackfire on Adobe Commerce Cloud and other hosting

You start a Blackfire profile of one request from the browser or the command line. Blackfire records the calls per function, which function called which, wall time and I/O time, as a call graph or a timeline. Blackfire says Magento stores can be profiled on demand in production, staging, integration and development, and on premise an optional Magento add-on gives Magento-specific recommendations, per Blackfire’s Magento page.

On Adobe Commerce Cloud, Adobe stopped including free Blackfire access on April 11, 2020, for Pro and Starter, so you buy a license from Blackfire. Its Cloud guide notes that the Fastly bypass it needs is set by default there. Plans are called Development and Production, with no free trial.

Xdebug for profiling on a developer’s machine

Xdebug is a PHP extension developers use for debugging and profiling. Three settings turn its profiler on:

; php.ini or 99-xdebug.ini on a developer's machine
xdebug.mode = profile
xdebug.start_with_request = trigger   ; only requests that carry XDEBUG_TRIGGER
xdebug.output_dir = /tmp              ; the default, files named cachegrind.out.<process ID>

Xdebug writes one Cachegrind file per profiled process, named cachegrind.out. plus the process ID, in /tmp by default and compressed. Open it in KCacheGrind, in QCacheGrind on Windows (turn compression off with xdebug.use_compression) or in PhpStorm, as the Xdebug profiler docs describe. Trigger mode limits profiling to the requests you choose. Keep Xdebug on a developer’s own copy.

Which Magento profiling tool should you use?

Use New Relic to find which pages and requests are slow on the live store, over days of real traffic. Use Magento’s built-in profiler on staging for a quick breakdown of one page, and its database profiler to count that page’s queries. Use Blackfire or Xdebug when you need the exact functions that make one request slow.

If you haven’t narrowed the slowness to the page build yet, start with why a Magento site gets slow.

Most teams use two, New Relic to find the slow page on the live store and a profiler to explain it on staging.

What to fix once the profile points somewhere

Fix the step that takes the most time, then profile the same page again under the same conditions. In the Magento profiles our developers read, the time usually goes to extension code that runs on every request, blocks that load data once per product, or a page build that sends hundreds of database queries.

Extension code on every request shows up as an observer or a plugin high in the list. Disable it on staging and profile again. If the time drops, remove, replace or fix it. If the slow step is your own code, a Magento code audit reviews it with security and code quality.

A block that loads data once per product shows as a template or a query with a high count. Load the data once for the whole list, or cache the block’s output if it is the same for every shopper.

Sometimes the profile names no culprit. The time is spread across layout, blocks and hundreds of small queries, and the cost is how Magento builds the page itself.

For that pattern there’s Expedio, scandiweb’s software for Magento, with an open-source core. It changes how Magento builds each page on the server, using Liquid, the open-source template language Shopify created, and the build runs at least 2x faster. Expedio works with Magento Open Source, Adobe Commerce and Commerce Cloud, on Luma, Hyvä or custom themes and any hosting, and your theme, catalog, prices, admin and checkout stay as they are. On the same server, it handles 3x the traffic before response times start to rise.

Our CTO put it this way after measuring stock Magento: most of the time goes into building the page itself, “and much of that is spent fetching data piece by piece.” In a benchmark on one merchant’s Hyvä store, measured as server response time, stock Magento ran 604 database queries to build the homepage and 655 for a full category page, with no full page cache on either copy. With Expedio, the same pages ran 11 and 30. The Expedio benchmark covers the method and its limits.

Frequently asked questions about the Magento profiler

Can you run the Magento profiler on a live store?

Not safely. The built-in profiler switches on through a flag file, var/profiler.flag, that covers every browser page request on that server in any mode. In HTML mode, every page Magento builds would carry the timing table, and the CSV file keeps only whichever request ran last. Profile on a staging copy with production data and settings. On the live store, use an APM such as New Relic.

Where does the Magento 2 profiler output go?

With the html type, Magento prints the profiler table when the request ends, below the page it built, so you scroll to the bottom to read it. With csvfile, it writes var/log/profiler.csv in the Magento root, and Adobe notes the file is overwritten on each page refresh. Dependency graphs, turned on with MAGE_PROFILER set to 2, also show at the bottom of the page.

Is New Relic included with Adobe Commerce Cloud?

Yes. Every Adobe Commerce on cloud infrastructure project includes New Relic APM, on Pro and Starter plans, for the Production and Staging environments, with the software and license key provided. Pro projects also get New Relic Infrastructure and Log Management. Adobe notes that other New Relic features aren’t available and that you can’t send data from servers outside the Cloud project.

Is profiling the same as Magento performance monitoring?

No. Performance monitoring watches the live store all the time and shows which pages, requests or servers are slow, and when. Profiling takes one request and breaks it into the steps and functions that used its time. A monitoring tool such as New Relic tells you where to look, and a profiler shows why that request is slow.

Is Blackfire still included with Adobe Commerce Cloud?

No. Adobe stopped including free Blackfire access in Adobe Commerce on cloud infrastructure Pro and Starter subscriptions on April 11, 2020. You can still use Blackfire on a Cloud project by buying a license from Blackfire directly and following its setup guide for Adobe Commerce Cloud. Blackfire sells Development and Production plans and doesn’t offer a free trial.

Does New Relic have a free plan for Magento stores?

Yes. New Relic’s free tier includes 100 GB of data ingest a month and one full platform user, with no credit card required. If a month’s data goes over 100 GB, ingest stops until you upgrade or the next month starts. Paid editions are Standard, Pro and Enterprise. On Adobe Commerce Cloud you don’t need it, because New Relic APM comes with the project.

Where to start with the Magento profiler

Start with the Magento profiler on a staging copy, aimed at one page your shoppers wait for, with the cache out of the way. If you first need to know which pages are slow on the live store, New Relic answers that, and Blackfire or Xdebug take you down to the function that costs the time.

Once a profile has put the problem on the server, our guide to speed up Magento lists the other fixes in order, from hosting to the browser. If you’d like someone to read the profile with you, our Magento performance audit profiles your custom code and slow queries and returns a prioritized report.

Not sure which page to profile first? Tell us which pages feel slow and we'll help you pick one.

The post Magento Profiler: Find What’s Slowing Your Store with New Relic and Blackfire appeared first on scandiweb.

Your Magento (Adobe Commerce) store has slowed down, someone checked the server, and the answer came back: the database is working too hard. That’s MySQL, or its close relative MariaDB, the software that holds every product, price, customer and order and serves them each time Magento builds a page. The verdict is often right. It just doesn’t say what to fix.

Magento 2 MySQL optimization means finding where the database time goes, then fixing that first. Magento stores a product’s details in separate tables by type of value (text, whole numbers, prices, dates), a design called EAV (entity-attribute-value). As a result, Adobe’s documentation says, its “SQL queries are sometimes long and complex.” A query is one request for data, written in SQL, the database’s language. On a slow store, the time usually goes to one of four places, and each one needs a different fix.

What is Magento 2 MySQL optimization?

Magento 2 MySQL optimization is the work of making the database behind a Magento store answer faster and less often. It covers four jobs: finding and fixing slow queries, cutting the number of queries each page sends, keeping fast-growing tables in check, and setting MySQL or MariaDB the way Adobe advises for Magento.

Magento talks to the database whenever it builds a page the cache doesn’t hold: logged-in views, filtered category pages, search results, cart and checkout. The admin, product imports and background jobs query it too. So database trouble shows up first on uncached pages and on busy admin days, when someone is editing the catalog or running an import.

Why a Magento page sends so many queries

Under EAV, each product attribute is stored by its type of value rather than in one row per product. Adobe’s developer documentation says objects that use EAV attributes typically store values in several MySQL tables, and that the Catalog and Customer modules are the main ones. For products, the values are kept in one table per type: catalog_product_entity_varchar, _int, _decimal, _text and _datetime. Each table is a separate lookup, so a page that lists many products reads many tables.

Magento offsets this with indexers, background jobs that precompute data into ready-made tables. Without them, Adobe says, the application would have to calculate the price of every product on the fly, taking cart price rules, bundle pricing and discounts into account. Flat tables were the older answer, one wide row per product, and Adobe no longer recommends them. Our explainer on Magento’s EAV model walks through every attribute type and table.

Where Magento database time goes

Time in a slow Magento database usually goes to one of four patterns:

1. Slow queries: a few requests take seconds each.
2. Too many queries: each request is quick, but every uncached page sends a long run of them.
3. Locks: queries wait for others to finish, often during reindexing or imports.
4. Bloated tables: logs and old records pile up in tables the store uses every day.

A busy database doesn’t say which pattern you have, so measure first: when you audit Magento performance, you time each page type from the cache and uncached, which shows whether the slow pages are the ones the database builds.

If the database stays quiet while pages are slow, the cause is somewhere else, and our guide to why a Magento store gets slow matches symptoms to causes.

How to find slow queries in Magento

To find slow queries in Magento, turn on the MySQL slow query log, which records every query that runs longer than a time you set. Rank the log with pt-query-digest to see which queries cost the most in total, then run EXPLAIN on the worst ones to see whether MySQL reads a whole table where an index would do.

Turn on the MySQL slow query log

The slow query log is a file where MySQL writes down every query that takes longer than a time you choose. It’s off by default, and the default threshold is 10 seconds, far too high to catch the queries shoppers feel.

# my.cnf, [mysqld] section. A starting point: agree the threshold with your host or DBA.
slow_query_log      = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time     = 1    # example value, in seconds. MySQL's default is 10

On Adobe Commerce Cloud, the log is already written to /var/log/mysql/mysql-slow.log. Run it on production during your busiest days, since that’s where the real traffic is, and agree the threshold with your host or DBA before you change it.

Rank the worst queries with pt-query-digest

pt-query-digest is a free Percona tool that groups the log by query shape and ranks the groups by total time, slowest first.

pt-query-digest /var/log/mysql/mysql-slow.log > slow-query-report.txt

Read the top of the report first. A query that is moderately slow but runs thousands of times can cost more than one very slow query that runs once an hour. Adobe names this tool in its database playbook for Commerce Cloud Pro.

Read the query plan with EXPLAIN

An index is a sorted lookup list, like the index at the back of a book, that lets MySQL find rows without reading the whole table. Adobe’s database performance guidance says to run EXPLAIN (or EXPLAIN ANALYZE on MySQL) on each top query to find out what makes it slow, and a full table read where an index would do is the usual answer.

In a Magento store, the typical causes are a custom or extension table with no index on the column it’s filtered by, an extension query that runs once per product, and a report or export run during trading hours. Add a missing index through the module’s db_schema.xml, the declarative schema, so the change survives the next deploy. Adobe advises against running schema changes by hand on production, and core tables are best left alone.

How to make Magento run fewer database queries

The fastest database query is the one Magento never sends. Serve as many pages as possible from the full page cache, which answers without reaching Magento or the database, keep indexers on Update by Schedule so heavy recalculation runs in the background, and lighten the page build, which decides how many queries every uncached page sends.

Count before you tune. Magento’s database profiler, switched on in a staging copy, shows how many queries one page sends, so you can tell a 50-query page from a 600-query one before changing anything.

Serve more pages from the full page cache

Varnish is a caching server placed in front of Magento that keeps finished pages and sends them without building them again. Adobe’s Varnish guidance notes that requests Varnish answers never reach the web server, so a cached page sends no database queries at all. Logged-in, filtered and search pages are cached too, per customer group and per search term, they just miss more often. Fewer cache variants means more hits.

Keep indexers on Update by Schedule

Indexers precompute catalog data such as final prices into ready-made tables, and cron is Magento’s scheduler, which runs background jobs every minute. On Update on Save, every admin save triggers a recalculation, and Adobe says that on large stores with frequent updates this degrades database performance. On Update by Schedule, database triggers note what changed in changelog tables ending in _cl, cron applies the changes every minute, and a separate job clears processed rows every 5 minutes.

Two warnings. Adobe’s database configuration playbook says switching modes creates triggers through DDL statements that can lock tables, so do it in maintenance mode with cron off. And don’t add custom triggers of your own, which Adobe doesn’t support. If an indexer is stuck or keeps falling behind, our list of known indexer problems and their fixes covers the usual causes.

Make each page build ask for less

The remaining queries come from building each uncached page: the layout, its blocks and the data every block loads. Profile one slow page with a tool such as New Relic or Blackfire, then remove or replace the blocks and modules that query the most. Our Magento profiler guide shows how to read a profile of one slow page. Extensions that load data they never show are a common find.

Expedio, scandiweb’s Magento module with an open-source core, works on this part. It speeds up how Magento builds each page on the server by applying Liquid, the open-source template language created at Shopify, and makes that build at least 2x faster. It runs on Magento Open Source, Adobe Commerce and Commerce Cloud, with Luma, Hyvä or a custom theme, on any hosting, and leaves the theme, data, admin and checkout as they are.

Our CTO’s benchmark found that in stock Magento, most of the time goes into building the page itself, “and much of that is spent fetching data piece by piece.” In a benchmark on one merchant’s Hyvä store, measured as server response time, a full category page ran 30 database queries with Expedio instead of 655, and the homepage ran 11 instead of 604. Both copies of the store ran on the same server with no full page cache, so Magento built every request. The same server also handled 3x the traffic before response times started to rise. The Expedio benchmark has the full method and its limits.

Magento database maintenance: keep big tables in check

Magento database maintenance means keeping the tables that grow every day at a steady size: cron history, abandoned carts, visitor records, report events and indexer changelogs. Magento has a setting or a cron job for each of them, so most of the work is making sure cron runs and the settings fit your store.

The tables that grow every day

Some tables get a new row for every visit, every cart and every scheduled job, so they grow whether or not the store sells anything.

Everything in that table depends on cron running, which Adobe’s cron settings page describes, and none of it touches orders. Before you delete anything yourself, back up the database, test on a staging copy and run it outside peak hours.

To see which tables need attention, list the largest ones. This query is adapted from the size check in Adobe’s database playbook, reads only, and is safe on production.

-- The 20 largest tables in the store's database, in MB
SELECT table_name,
       ROUND((data_length + index_length) / 1024 / 1024) AS size_mb
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 20;

Large database tables are a standard line in our store health checks, and the same few kinds of table come up again and again.

Three structural checks

Adobe’s playbook also lists three checks on how tables are built, each a quick query away.

• Every table on InnoDB. Extensions sometimes add tables in the older MyISAM format, which Adobe says to convert.
• Every table with a primary key. Without one, InnoDB adds a hidden 6-byte key shared across all such tables, which can cause contention when several writes land at once.
• No duplicate indexes. Each extra index is one more thing MySQL updates on every write, and a duplicate adds nothing to reads.

Which MySQL settings matter for Magento?

The MySQL settings that matter most for Magento are the InnoDB buffer pool, sized to keep Magento’s index tables in memory, max_connections, matched to the number of PHP workers, and the temporary table limits that indexers need. Run a database version Adobe lists for your release: MySQL 8.4 or MariaDB 12.3 for Magento 2.4.9.

Supported MySQL and MariaDB versions

Adobe’s system requirements list the database versions for each release.

MySQL 8.0 reached end of support on April 30, 2026, and Adobe supports only the combinations it lists. For PHP, search and cache versions too, see our Magento 2 system requirements guide. Upgrade the database before Magento when moving to 2.4.9. Adobe’s own wording is to upgrade to MariaDB 12.3 before you upgrade to 2.4.9.

The settings Adobe calls out

The InnoDB buffer pool is the memory where MySQL keeps the tables and indexes it reads most. Adobe doesn’t publish a full tuning guide, because each store and environment is different, but its general MySQL guidelines and software recommendations name a few settings.

MySQL 8.4 already starts max_allowed_packet at 64 MB, so check the current value with SHOW VARIABLES LIKE 'max_allowed_packet' before changing it. The values below are starting points, with verified sources only.

# my.cnf, [mysqld] section. Starting points from Adobe's MySQL guidance.
# Size innodb_buffer_pool_size to your own server, then test on staging.
explicit_defaults_for_timestamp = ON
tmp_table_size                  = 64M    # Adobe's example value for indexers
max_heap_table_size             = 64M
max_connections                 = 300    # Adobe: about 300 small, 1,000 medium. Match your PHP threads

# MariaDB 10.4 or 10.6 only, where reindexing runs slower
optimizer_switch                    = 'rowid_filter=off'
optimizer_use_condition_selectivity = 1

Commerce Cloud Pro customers can’t change some of these themselves, so open a ticket with Adobe support.

Read replicas and split databases

A replica is a read-only copy of the database. Adobe’s MySQL configuration best practices recommend a read-only connection (MYSQL_USE_SLAVE_CONNECTION) on Commerce Cloud Pro when you expect high database load. On your own servers, replication must be row-based. Don’t start a split database, which Adobe deprecated in 2.4.2. In our view, a replica takes reads off the main server and does nothing for slow queries or locks.

Frequently asked questions about Magento MySQL optimization

What MySQL version does Magento 2.4.9 support?

Magento 2.4.9 supports MySQL 8.4 and MariaDB 12.3 on-premises, and Adobe Commerce Cloud runs it on MariaDB 12.3 (recommended) or 11.8. Release 2.4.8 supports MySQL 8.4 and MariaDB 11.4, plus 11.8 from patch 2.4.8-p5. MySQL 8.0 reached end of support on April 30, 2026, and neither 2.4.8 nor 2.4.9 lists it.

How much memory should MySQL get on a Magento server?

Give the InnoDB buffer pool, the memory where MySQL keeps table and index data, enough room to hold Magento’s index tables, as Adobe advises. The MySQL manual notes that on a dedicated database server, up to 80% of physical memory often goes to the buffer pool. The default is 128 MB, so check that someone changed it, and split the pool so each instance gets at least 1 GB.

Should you use the flat catalog in Magento 2?

No. Adobe no longer recommends flat catalogs and says continued use is known to cause performance degradation and other indexing issues, on 2.3.x and later. Flat tables copied each product into one wide row to avoid EAV lookups, and current Magento relies on its indexers and search engine instead. Before you switch them off, check whether any extension still depends on flat tables, as Adobe warns.

How do you clean up a Magento database safely?

Back up the database, test on a staging copy, and let Magento’s own settings and cron jobs do most of the work: cron history lifetimes, the quote lifetime, report settings and changelog cleanup. Never delete orders, invoices or other sales records, and don’t empty indexer changelog tables by hand. For tables an extension writes, use the extension’s own cleanup option or ask its vendor.

Should a Magento store run MySQL or MariaDB?

Either works if the version is one Adobe lists for your Magento release, because Adobe supports only the combinations it lists. Adobe Commerce Cloud runs MariaDB. If you’re on MariaDB 10.4 or 10.6 with an older release, Adobe recommends optimizer_switch='rowid_filter=off' and optimizer_use_condition_selectivity = 1, because reindexing runs slower on those versions.

Can a read-only database replica speed up Magento?

It can take read traffic off the main database. On Adobe Commerce Cloud Pro, Adobe recommends turning on MYSQL_USE_SLAVE_CONNECTION when you expect high database load, so read-only traffic goes to a read-only node. On your own servers, replication must be row-based, because Adobe doesn’t support statement-based replication. Don’t plan a split database: Adobe deprecated that feature in version 2.4.2.

Where to start with Magento 2 MySQL optimization

Magento 2 MySQL optimization starts with finding where the database time goes, and only then changing settings or servers. Find the slow queries, cut the queries each page sends, keep the fast-growing tables in check, and set the configuration to Adobe’s guidance, in that order.

A bigger database server is the last step on that list, because a store that sends 600 queries to build one page will keep the new server busy too. The slow query log and the database profiler take an afternoon to set up and tell you which of the four patterns you have. Our Magento support team runs these checks in every store health check. The database is one layer of a Magento store, and to work through the others, from hosting to the browser, use our guide to speed up Magento.

If you're not sure which of the four patterns your store has, tell us what you're seeing and we'll help you find where the database time goes.

The post Magento 2 MySQL Optimization: Slow Queries, Indexes, and Configuration appeared first on scandiweb.

You’re planning a Magento (Adobe Commerce) upgrade or a move to a new host, and the first page of the plan is Adobe’s list of required software: PHP (the programming language Magento runs on), the database, the search engine, the cache, the web server. It looks like half the plan is done. Then the next question on the same page asks how much processing power, memory and storage the new server should have, and nothing on the list answers it.

The Magento 2 system requirements tell you which software versions a release runs on. How big the server must be is a separate question, and it’s the one with a price tag: the hosting bill every month, and the orders you lose if pages slow down in the busiest hour of a sale.

What are the Magento 2 system requirements?

Magento 2.4.9, the latest release, needs PHP 8.5, MySQL 8.4 or MariaDB 12.3, OpenSearch 3, Valkey 9, Varnish 8, nginx 1.30, RabbitMQ 4.3 or ActiveMQ Artemis 2, and Composer 2.10, on 64-bit Linux. Adobe supports only the combinations in its table, and each patch release can change them.

Adobe publishes one table per release line and updates it with every patch release, most recently on October 13, 2026. It supports only the combinations in Adobe’s table, so a stack that is close enough can mean Adobe Support asks you to change a version before it investigates a problem.

On-premises Magento 2 system requirements for the latest patch of each supported release line, from Adobe’s table updated October 13, 2026. Support dates from Adobe’s lifecycle policy. Extended support applies to Adobe Commerce.

These are the Magento 2 requirements for the latest patch of each line, and the Magento version requirements change with every patch, so read the column for the patch you run. Each line also has an end date, and our list of Magento end of life dates covers the support periods and patches in detail. End of life applies to each release line, and the platform itself has no end date.

Magento PHP version by release

Magento 2.4.9 needs PHP 8.5. Adobe allows PHP 8.4 only while you upgrade and dropped PHP 8.2 and 8.3 for this release, per the 2.4.9 release notes. Magento 2.4.8 runs on PHP 8.3 or 8.4, 2.4.7 on 8.2 or 8.3, and 2.4.6 on 8.1 or 8.2.

The Magento PHP requirements also follow PHP’s own calendar. PHP 8.2 stops receiving security fixes on December 31, 2026, per the PHP supported versions list, so a 2.4.6 or 2.4.7 store on 8.2 has to move before then.

Install the PHP extensions on Adobe’s list, among them bcmath, intl, mbstring, pdo_mysql and sodium. Keep OPcache on, PHP’s built-in cache of compiled code, and apply the same PHP settings to the command line and the web server, since cron and deploys run from the command line.

Database, search and cache versions

MySQL and MariaDB are two compatible database servers, and Magento runs on either. Magento 2.4.9 lists MySQL 8.4 or MariaDB 12.3. MySQL 8.0 reached end of support on April 30, 2026, and Adobe’s tables for 2.4.6 and 2.4.7 now list MariaDB only.

OpenSearch is the search engine behind catalog search and layered navigation filters. Adobe lists OpenSearch 3 for 2.4.8 and 2.4.9, and 2.19 or 3 for 2.4.6 and 2.4.7. Elasticsearch 7.17 reached end of support on January 15, 2026, and Elasticsearch 8 stays listed for 2.4.7 and 2.4.8 only.

Valkey is an open-source data store that works like Redis and holds Magento’s cache and sessions. Varnish is a page cache that runs in front of the web server. Adobe lists Valkey 9 for 2.4.9, and Redis is no longer supported as the cache on current patches, per Adobe’s Valkey and Redis guidance. Varnish 8 appears in every latest-patch column. For setup, see our Magento 2 Varnish configuration guide. For the message queue, Adobe lists RabbitMQ 4.3 or ActiveMQ Artemis 2, and names Artemis as the long-term broker.

Web server, operating system and other requirements

Every current table lists nginx 1.30 with PHP-FPM, the process manager that runs PHP for the web server. Apache 2.4 last appears in Adobe’s tables for 2.4.8-p2, 2.4.7-p6 and 2.4.6-p11. Magento runs on 64-bit Linux only, such as Red Hat Enterprise Linux, Ubuntu or Debian.

You also need a valid SSL certificate (self-signed ones are not supported), TLS 1.2 or later for PayPal and repo.magento.com, a mail server, and Composer 2.10 (2.2.26 or later on 2.4.6). Keep Xdebug on development machines only: Adobe says the module alone can add up to 30% to response time even with no debug session running.

Adobe Commerce system requirements on Cloud

Adobe Commerce on Cloud has its own table. For 2.4.9 it lists PHP 8.5, MariaDB 12.3 (recommended) or 11.8, OpenSearch 3, Valkey 9, RabbitMQ 4.3, ActiveMQ Artemis 2 and nginx 1.30, with Fastly as the page cache in place of Varnish. Magento Open Source has no separate table, so self-hosted stores check the on-premises one.

On Cloud, Adobe sets the services and their versions in the project’s services.yaml file. The Pro production environment runs three virtual machines behind a load balancer, and each one carries the whole stack: Fastly, nginx with PHP-FPM, Valkey or Redis, OpenSearch and one node of a Galera MariaDB cluster, as Adobe’s Pro architecture page describes. When capacity goes up, the three machines are resized one at a time, so the site stays up.

From the Pro 48 cluster up, a project can move to the scaled architecture: at least six nodes, three for the database and services and three for the web server. The service tier grows only by making its servers bigger, while the web tier grows by adding servers.

Magento Open Source has no table of its own. Adobe lists its PHP extensions on the same requirements page, so a self-hosted Open Source store uses the on-premises table above. Stores on Adobe Commerce as a Cloud Service, Adobe’s fully managed version, don’t run this stack themselves: Adobe manages the infrastructure, patching and upgrades.

Magento server requirements vs the capacity your traffic needs

Magento server requirements list the software versions a release runs on. Capacity is how many requests a server can answer before pages slow down, and it depends on four things: traffic at your busiest hour, how many pages come from the cache, how long Magento takes to build the rest, and background jobs such as indexing.

A server can meet every line of Adobe’s table and still slow down at the first sale, because the Magento 2 server requirements say nothing about how many shoppers arrive at once.

What decides how much server a Magento store needs

Four numbers decide it, and only the first one shows up in a marketing calendar.

• Peak traffic: requests in the busiest hour, the number that sizes the server. A monthly visitor count hides it.
• Cache hit rate: the share of pages served ready-made by Varnish, or by Fastly on Cloud. Those requests never reach the web server.
• Build time: how long Magento takes to build a page the cache doesn’t have. It grows with catalog size, extensions, filters and search.
• Background work: cron jobs, indexing, imports and the admin, which use the same CPU and memory as shoppers do.

Adobe’s hardware recommendations put the first two together in one sentence: “Commerce web nodes serve all requests that are not cached or cannot be cached through the application.”

Why cache misses set the size of the web tier

The full page cache keeps a separate copy of a page per customer group, store, currency and language, and a separate copy of search results per search term. So logged-in shoppers, filtered category pages and searches miss far more often than a plain category page does. Cart, checkout and account pages, plus anything sent as a form submission, always go to Magento. After a deploy or a cache flush, every page misses until shoppers or a cache warmer refill it.

Each miss keeps a CPU core busy for as long as Magento takes to build the page, while hits barely touch the web servers. That is why the web tier is sized for misses, and why the hit rate matters as much as the traffic figure. Our guide to the Magento full page cache explains which pages miss and how to cut the misses.

How to size a Magento server for your traffic

To size a Magento server:

1. Measure requests at your busiest hour and your cache hit rate.
2. Count CPU cores with Adobe’s formula, expected requests divided by two plus cron processes.
3. Size memory for PHP, the database and the caches.
4. Give each tier its own servers and plan for peaks.
5. Load test at that size.

The five steps turn your own numbers into the right server for Magento 2, in terms a host or a developer can quote against.

1. Measure peak requests and the cache hit rate

From your hosting dashboard, your CDN or New Relic, a monitoring service that records every request, take two numbers: requests per second in the busiest hour of your busiest day, and the share of them served from the cache. Monthly visitor counts don’t show the peak, and the peak is what the server has to survive.

Before we size a server for a store we host, we ask for visit counts, requests, cache usage, media size and database size. Then time how long uncached pages take to build, one page type at a time. Our guide on how to audit Magento performance walks through it. As a sanity check first, Adobe expects any page with cacheable blocks to load in under 150 ms when Varnish is working.

2. Count CPU cores with Adobe’s formula

Adobe’s rule of thumb is that “One CPU core can serve around two (sometimes up to four) Commerce requests effectively.” Its formula for the web tier:

cores = (expected requests / 2) + cron processes

“Expected requests” means requests reaching Magento at the same moment, so only cache misses count. The hit rate from step 1 turns peak traffic into that number.

As an example, say your monitoring shows about 20 requests reaching Magento at the same moment at peak, and the server runs 4 cron processes. The formula gives 20 divided by 2, plus 4: 14 cores across the web servers, before any headroom.

Add headroom above the peak you measured, and keep cron’s share in the sum. Indexing and imports compete with shoppers for the same cores, and a reindex that lands in the busiest hour shows up as slow pages.

3. Size memory for PHP, the database and the caches

Adobe publishes no single RAM figure for a production store. It gives memory per PHP process instead, and the figure depends on what the process does.

PHP memory per process, from Adobe’s hardware recommendations. Multiply by the PHP workers you run at peak.

Total PHP memory is arithmetic: memory per process times the PHP workers you run at peak. Adobe’s PHP settings page sets the limit at 1G for compiling and deploying and 2G for debugging.

The database should get memory close to half the size of its data, by Adobe’s guidance, so its indexes stay in memory. Our guide to Magento MySQL optimization covers the database settings in detail. Varnish needs enough to hold your most popular pages. Valkey (or Redis on older releases) holds all other caches, and the block cache grows with SKUs times store views, so a large catalog with many store views needs more. Keep sessions in their own instance. Upgrades can need up to 2 GB of RAM, and Adobe says to add a swap file on a server with less.

4. Give each tier its own servers and plan for peaks

A tier is a group of servers that does one job: web, database, search or cache. Adobe’s guidance is to install Varnish on a separate server in front of the web tier. Keep staging on its own resources too, so test runs and imports don’t take CPU from shoppers.

For short peaks, server autoscaling in Magento 2 adds web servers while traffic is high and removes them afterward. On Commerce Cloud, Adobe’s auto scaling adds web nodes when CPUs across the web tier run at 75% for a minute while traffic climbs 20% for five minutes, within your contracted limits, and a planned upsize needs 48 business hours’ notice.

If you’d rather not run the tiers yourself, these are the Magento hosting requirements our team provisions for every store we host.

5. Load test at the size you plan to run

Run one round with the full page cache on and one with it off, to see what the server can build on a bad day. Raise the load in steps and note where response times bend: that point is your capacity. Adobe enables Cloud auto scaling on production only after load testing on staging, and that order holds anywhere. Our Black Friday load-testing plan sets the target, the traffic mix and the pass criteria. Our guide to Magento load testing covers the tools and the run, step by step.

How faster page builds change the server you need

Every page the cache doesn’t serve keeps a CPU core busy while Magento builds it, so a faster build lets the same server answer more requests before response times rise. Our fastest eCommerce platform research shows how Magento’s server response compares with other platforms. Adding servers also raises capacity, yet each uncached page still takes just as long to build, and every extra server adds to the monthly bill. A Magento profiler shows which steps of that build take the time.

This is the part Expedio works on. Expedio is scandiweb’s Magento module with an open-source core. It speeds up how Magento builds each page on the server by applying Liquid, the open-source template language created at Shopify, and makes that build at least 2x faster. It runs on Magento Open Source, Adobe Commerce and Commerce Cloud, with Luma, Hyvä or a custom theme, on any hosting, and leaves the theme, data, admin and checkout as they are.

Faster builds show up as capacity. In a benchmark on one merchant’s Hyvä store, measured as server response time, two copies of the store ran side by side on one server with the same data and no full page cache, so Magento built every request. With Expedio, the same server handled 3x the traffic before response times started to rise, and the homepage ran 11 database queries instead of 604. The Expedio benchmark covers the method and what it didn’t test, including cart and checkout.

Server size is one layer of a fast store. To work through the others, from caching to the browser, use our guide to speed up Magento.

Frequently asked questions about Magento 2 system requirements

What PHP version does Magento 2.4.9 need?

Magento 2.4.9 needs PHP 8.5 in production. Adobe allows PHP 8.4 only while you upgrade and dropped PHP 8.2 and 8.3 for this release. Magento 2.4.8 runs on PHP 8.3 or 8.4, and 2.4.7 on 8.2 or 8.3. PHP 8.2 stops receiving security fixes on December 31, 2026, so plan any move off it before then.

How much RAM does a Magento 2 server need?

Adobe publishes no single RAM figure for a production Magento server. It gives memory per PHP process instead: 256 MB for a web server that only serves the storefront, 1 GB for admin work on a large catalog, and 2 GB for a single-server store. Multiply that by the PHP workers you run at peak, then add the database, search and caches.

How many CPU cores does a Magento store need?

Adobe’s rule of thumb is that one CPU core can serve around two Magento requests effectively, sometimes up to four. Its formula is the number of expected requests divided by two, plus the number of cron processes. Count only the requests that reach Magento, because pages served from Varnish, or Fastly on Commerce Cloud, never reach the web server.

Does Magento 2.4.9 still support Redis?

No. Adobe doesn’t support Redis as the cache for Adobe Commerce 2.4.9, or for patch releases after 2.4.5-p16, 2.4.6-p14, 2.4.7-p9 and 2.4.8-p4. Use Valkey instead, an open-source data store that works like Redis. Version 9 is listed for 2.4.9, and Adobe recommends separate instances for sessions, the cache and the full page cache.

Does Magento 2 run on nginx or Apache?

Adobe’s current requirement tables list nginx 1.30 as the web server for every supported release line, with PHP running through PHP-FPM. Apache 2.4 last appears for 2.4.8-p2, 2.4.7-p6 and 2.4.6-p11 in Adobe’s older tables. Adobe supports only the combinations it lists, so nginx is the safe choice for a new or upgraded store.

Can you run Magento 2 on Windows or macOS?

Not in production. Adobe supports Magento 2 only on 64-bit Linux, such as Red Hat Enterprise Linux, Ubuntu or Debian, and says Microsoft Windows and macOS are not supported. For local development on Windows or a Mac, run Magento inside a Linux container or virtual machine, so your setup matches the server it will run on.

Check the Magento 2 system requirements, then size for your peak

The Magento 2 system requirements are the fixed part of the job: one table per release, checked against your exact patch. The server size is the part only your store can answer, from its peak traffic, its cache hit rate and how long its pages take to build. Measure those first, then buy the server.

Adobe’s table changed on October 13, 2026, and patch releases keep changing it, so read it again before every upgrade. Re-run the sizing before each sale season too, because catalog size, extensions and the cache hit rate drift from one year to the next. If the numbers point to a new host, compare Magento hosting providers against them before you sign.

Planning an upgrade or a move and want a second opinion on the numbers? Send us your peak traffic and current setup, and we'll help you size the server.

The post Magento 2 System Requirements: Server Sizing for Real Traffic appeared first on scandiweb.

Every eCommerce platform says it’s fast, and every vendor has a demo store that loads in a blink. A demo can’t show how a platform performs across thousands of real stores, with real catalogs, real hosting and real shoppers on their phones. That’s usually the question behind a search for the fastest eCommerce platform: before you choose a platform, or blame the one you run, you want to know how fast stores on it really are.

scandiweb looked at the first thing every shopper waits for: time to first byte (TTFB), how long a store’s server takes to start sending a page. Until that first byte arrives, the screen stays blank. We compared 12 eCommerce platforms on the Chrome UX Report, Google’s dataset of real visits from Chrome users, for September 2026, and checked whether the differences hold for sites of the same size, in different countries and over the past three years.

Key findings

Seven numbers summarize the study. Each one comes from scandiweb’s analysis of Chrome UX Report data, served through the HTTP Archive Tech Report, for September 2026 and for the three Septembers before it. Unless a finding says otherwise, every figure is the share of sites whose 75th-percentile mobile time to first byte was 800 ms or less.

• scandiweb’s analysis of Chrome UX Report data for September 2026 found that 83.8% of Shopify sites (n = 430,634) gave mobile visitors a good time to first byte, the highest share of the 12 eCommerce platforms compared.
• In the same September 2026 data, 23.0% of Magento sites (n = 31,799) had a good mobile time to first byte, ranking Magento 10th of 12 platforms, ahead of WooCommerce (12.1%, n = 519,794) and VTEX (4.8%, n = 3,198).
• The median Magento site’s 75th-percentile mobile time to first byte fell between 1,200 and 1,299 ms in September 2026, more than twice the 500–599 ms of the median Shopify site, according to scandiweb’s analysis.
• Among the 100,000 most visited sites, 23.0% of Magento sites (n = 739) had a good mobile time to first byte in September 2026, against 78.9% of Shopify sites (n = 1,829), scandiweb found.
• Magento sites built with the Hyvä theme passed all three Core Web Vitals on mobile 66.4% of the time in September 2026 (n = 4,593), against 44.6% for Magento overall, but their good time-to-first-byte share was 23.2%, almost the same as Magento’s 23.0%.
• Between September 2023 and September 2026, the share of Magento sites with a good mobile time to first byte rose from 16.1% to 23.0%, while Shopify’s rose from 78.1% to 83.8%, scandiweb’s trend analysis of Chrome UX Report data shows.
• For visitors in the United States in September 2026, 13.7% of Magento sites had a good mobile time to first byte, against 88.9% of Shopify sites, the widest gap of the three countries scandiweb checked.

How scandiweb measured eCommerce platform speed

scandiweb pulled Chrome UX Report field data for 12 eCommerce platforms and for all websites from the HTTP Archive Tech Report API on October 29, 2026. September 2026 is the snapshot month, and September 2023 to September 2026 is the trend. The main measure is the share of sites whose 75th-percentile time to first byte was 800 ms or less, with mobile and desktop counted separately.

The 12 platforms are Shopify, Webflow, Squarespace, Wix, BigCommerce, SAP Commerce Cloud, Shopware, Salesforce Commerce Cloud, PrestaShop, Magento, WooCommerce and VTEX. Magento sites running the Hyvä theme appear as a separate row, and “All websites” is the reference row for every site with Chrome data.

The instrument is the HTTP Archive Tech Report. It serves Chrome UX Report field data aggregated per technology, where the technology is detected by HTTP Archive’s monthly crawl using Wappalyzer rules. The API is public and needs no key, and its methodology is documented on GitHub. The pull took 104 calls with 0 failures.

Each site counts once, by its 75th-percentile value over a 28-day window. A site has a good time to first byte when that value is 800 ms or less, which means the server started responding within 0.8 seconds on at least three out of four visits. Google’s TTFB guidance calls 0.8 seconds or less good and more than 1.8 seconds poor.

A site passes Core Web Vitals when its 75th-percentile Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift are all good. The Web Vitals thresholds are 2.5 seconds, 200 milliseconds and 0.1. In the Chrome UX Report methodology, TTFB is listed as an experimental metric and is only collected on full page loads.

Popularity tiers use the Chrome UX Report rank: the top 1 million, 100,000, 10,000 and 1,000 origins. Where a tier has a small sample, its n is reported next to the figure. Cells with fewer than 20 sites are shown as counts rather than percentages.

Country means where the visitor was, as recorded by Chrome. It says nothing about where the store is hosted.

Which eCommerce platform is fastest?

Shopify, Webflow, Squarespace and Wix lead on server response. In September 2026, 83.8% of Shopify sites gave mobile visitors a good time to first byte, followed by Webflow at 77.5%, Squarespace at 76.6% and Wix at 73.1%. Magento ranks 10th of 12 at 23.0%, and only WooCommerce (12.1%) and VTEX (4.8%) are lower. The figure for all websites with Chrome data is 45.9%.

The four leaders have one thing in common. Shopify, Webflow, Squarespace and Wix all run every store on the vendor’s own infrastructure, so the merchant never picks a host, a cache or a server size. That is an observation, and the data doesn’t show that it is the cause. Hosting, CDN use and the size of a typical store all differ between platforms, and this study can’t separate those factors.

Desktop numbers follow the same order with higher values. 92.6% of Shopify sites and 94.1% of Webflow sites have a good desktop time to first byte, against 22.7% of Magento sites. Wix is the exception, with a lower desktop share (67.7%) than mobile (73.1%).

Magento’s position is specific. It is 10th of 12, and the data doesn’t support calling it the slowest. WooCommerce, which includes hundreds of thousands of small sites, and VTEX are both lower. If the platform choice itself is on the table, our comparison of Magento and Shopify beyond speed covers catalog size, B2B needs and customization.

Does the gap hold for sites of the same size?

Yes. Among the 1 million most visited sites, 20.5% of Magento sites (n = 7,956) had a good mobile time to first byte, against 85.7% of Shopify sites (n = 47,951). Among the top 100,000, the figures are 23.0% for Magento (n = 739) and 78.9% for Shopify (n = 1,829). Only in the top 10,000 does the gap narrow, and that cell holds 29 Magento sites.

The popularity cut was the main test of whether the ranking is an artifact of site size. A platform full of small hobby stores could look slow because of its sites, and a platform full of large stores could look fast for the same reason. Comparing sites of similar popularity removes much of that.

The gap survived the test. For all websites, the good-TTFB share rises with popularity, from 45.9% overall to 54.9% in the top 1 million and 61.6% in the top 100,000. Magento does not follow that curve until the top 10,000, where it reaches 37.9% against Shopify’s 64.3%, a gap of 26.4 points.

BigCommerce is the one platform where the popularity cut changes the picture. Its overall share is 59.7%, but among the top 100,000 sites it reaches 81.1% (n = 53), above Shopify’s 78.9% in the same tier.

How long does a typical store take to respond?

The median Magento site’s 75th-percentile mobile time to first byte fell in the 1,200–1,299 ms bucket in September 2026. The median Shopify site fell in 500–599 ms, so Magento’s figure is more than twice as long. The median for all websites was 800–899 ms, just outside the 800 ms line that counts as good.

These are ranges because the Chrome UX Report publishes TTFB as a histogram in 100 ms buckets. The median is the bucket that the middle site falls into, so a Magento store at the median had a 75th-percentile TTFB somewhere between 1,200 and 1,299 ms. The exact millisecond isn’t available.

The shape matters as much as the median. Four hosted platforms share the 500–599 ms bucket on mobile. Magento, PrestaShop and Hyvä stores cluster above one second, and WooCommerce and VTEX medians are above 1.7 seconds, close to the 1.8 second line that Google calls poor.

Site size changes the median for some platforms and not for Magento. Among the top 100,000 sites, the median WooCommerce store improves to 1,000–1,099 ms and BigCommerce to 400–499 ms. The median Magento store stays at 1,200–1,299 ms, the same bucket as across all sites.

Why do some platforms pass Core Web Vitals with a slow server?

Because Core Web Vitals and time to first byte measure different things. Shopware sites pass all three Core Web Vitals most often of the 12 platforms, at 84.0%, yet only 44.0% of them have a good time to first byte. Magento sites on Hyvä pass Core Web Vitals 66.4% of the time, against 44.6% for Magento overall, while their good-TTFB share is 23.2%, almost identical to Magento’s 23.0%.

TTFB isn’t a Core Web Vital. Google’s TTFB article states that because it isn’t one of the three, a site doesn’t have to meet the good threshold to pass. The three vitals measure what the shopper sees and feels after the first byte arrives: how fast the largest element paints, how quickly taps get a response, and how much the layout jumps.

The Hyvä rows show what that split means for a Magento store. Hyvä is a frontend theme, and the frontend work moved the Core Web Vitals pass rate from 44.6% to 66.4% and left server response where it was. The same pattern holds for Lighthouse, where the median Hyvä store scores 48 against 35 for Magento overall. If a Hyvä project is on your plan, our guide on how to work with Hyvä covers what it changes and what it doesn’t.

The JavaScript column makes the same point from the other direction. The median Shopify site loads 2,288 KB of JavaScript on mobile, the most of the 12 platforms, and still has the best time to first byte. TTFB is measured before any script runs, so the amount of JavaScript a page carries has no effect on it.

Shopware is the opposite case. Its median page carries 606 KB of JavaScript, the least of the 12, which fits its 84.0% Core Web Vitals pass rate. Its server response is close to the all-websites average.

Has Magento’s server response improved since 2023?

Yes, mostly in the last year. The share of Magento sites with a good mobile time to first byte was 16.1% in September 2023, 16.7% in 2024, 16.6% in 2025 and 23.0% in 2026. Magento’s Core Web Vitals pass rate doubled over the same period, from 22.2% to 44.6%. Shopify went from 78.1% to 83.8%, so the gap between the two stayed close to 60 points.

The gap to Shopify was 62.0 points in September 2023 and 60.8 points in September 2026. Magento gained 6.9 points on server response over three years, and Shopify gained 5.7, so the distance between them barely moved. All websites gained 4.7 points over the same period.

The Core Web Vitals trend is different. Magento’s pass rate rose every year, from 22.2% to 26.4%, 39.2% and 44.6%. Most of that came from the browser side, which is the same pattern the Hyvä rows show in a single snapshot.

Two hosted platforms made large jumps in a single year. Webflow went from 40.1% to 77.5% between September 2025 and September 2026, and BigCommerce from 13.2% to 58.6% between 2023 and 2024. The data records the change and doesn’t say what caused it.

The adoption figures in Table 6 are context, and they are detection counts rather than market share. HTTP Archive detected Magento on 52,651 mobile origins in September 2023 and 32,588 in September 2026, a drop of 38.1%. Over the same period, Hyvä detections rose from 1,158 to 4,696, about four times as many, and Shopify from 323,755 to 452,270, up 39.7%.

Those counts depend on which sites have enough Chrome traffic to be included and on what the crawl can detect from a homepage. A store that moved to a headless frontend usually stops being detected as Magento even though the backend hasn’t changed.

Does the gap change by country?

The size of the gap changes, and the direction doesn’t. For visitors in the United States, 13.7% of Magento sites had a good mobile time to first byte against 88.9% of Shopify sites. In the United Kingdom the figures are 26.7% and 94.1%, and in Germany 33.0% and 91.9%. Magento’s best country in the set, Germany, still trails Shopify’s weakest country, the United States, by 55.9 points.

The country in this table is where the visitor was, as Chrome recorded it. It is a cut of the same sites by who visited them, so a store with shoppers in several countries appears in more than one column.

Distance is part of time to first byte. TTFB includes the DNS lookup, the connection, the TLS handshake and the trip between the visitor and the server, so a store hosted far from its shoppers pays for that distance on every page view before the server has done any work.

Shopware is the clearest case in the table. For visitors in Germany, 49.4% of Shopware sites respond fast, against 6.2% for visitors in the United States. The data doesn’t record where those sites are hosted, but the pattern is what distance would produce.

For Magento the spread is smaller. Its best figure, 33.0% in Germany, is still below the all-websites average in every column, so distance alone doesn’t explain where Magento stands.

What this means for Magento stores

The rest of this section is interpretation. The data shows which sites respond fast, and the reasoning about why, and about what to do, is ours. On Magento, most of the gap to the hosted platforms is server response, the part of the wait that happens before the browser has received anything to draw.

Frontend projects lift Core Web Vitals and don’t move TTFB. The Hyvä rows show it in a snapshot, and Magento’s trend shows it over three years: the Core Web Vitals pass rate doubled while the share with good server response moved 6.9 points. A theme changes what the browser does once the page arrives.

Server response moves with server work. The levers are how much of your traffic the full page cache covers, where and how the store is hosted, and how long Magento takes to build a page the cache doesn’t hold. The last one is where most Magento stores still lose time, because logged-in customers, filtered category pages, search results and the first visit after a deploy all miss the cache more often. Our guide to why a Magento site gets slow covers the other causes.

Expedio is scandiweb’s module that speeds up how Magento builds each page on the server. The page build is at least 2x faster, so the same server handles 3x the traffic before response times start to rise. It works with Luma, Hyvä or a custom theme and leaves the theme and the data as they are. How we measured that is in the Expedio benchmark.

A faster page build doesn’t close the whole gap to Shopify on its own. TTFB also includes network time, from the DNS lookup to the distance between the visitor and the server, and no module changes that. Hosting location, a CDN in front of the store and the cache hit rate each decide part of the number.

If you want to work through the layers in order, our guide on how to speed up Magento covers server, caching, database and frontend fixes, and our post on how to reduce initial server response time covers the diagnostics. Auditing your store’s performance measures where your store’s time goes before you commission any of it.

What we expected and did not find

Two expectations didn’t hold. We expected Hyvä stores to show some server-side gain, and they don’t. We expected the gap to Shopify to disappear among the 10,000 most visited sites, and it narrows without closing. Both results point the same way: server response on Magento depends on server work, and neither a newer frontend nor a larger site changes that on its own.

The Hyvä expectation came from how those stores are built. Hyvä stores tend to be newer builds, often on newer hosting, so some server-side gain seemed likely. The data shows 23.2% with a good mobile time to first byte against 23.0% for Magento overall, and the median Hyvä store responds one bucket faster, at 1,100–1,199 ms against 1,200–1,299 ms.

The top-tier expectation came from the all-websites curve, where the share of fast sites rises with popularity. Among the top 10,000 sites, 37.9% of Magento stores (n = 29) respond fast against 64.3% of Shopify stores (n = 42). That is a gap of 26.4 points on a small sample, and it is still a gap.

Limitations

This study describes which sites respond fast in Chrome’s field data. It doesn’t explain why, and it doesn’t prove that the platform causes the difference. The six limitations below apply to every number in this article, and each one should be read before any figure is quoted.

Chrome only

The Chrome UX Report covers real Chrome users who opted in to usage statistics, and only origins with enough traffic to be included. Safari and Firefox visits aren’t in it, and a store whose shoppers are mostly on iPhones is represented by its Chrome visitors alone.

Origin level, homepage detection

Each site counts once, by its 75th-percentile time to first byte over a 28-day window. Platforms are detected by HTTP Archive’s crawl, using Wappalyzer rules, from the homepage. Some stores may be misclassified. Headless storefronts usually aren’t detected as their backend platform. “Magento” includes both Magento Open Source and Adobe Commerce.

TTFB covers more than the platform

Time to first byte includes redirects, the DNS lookup, the connection, the TLS handshake, network distance and the server’s work. The data shows which sites are fast. It doesn’t show why, and it doesn’t prove the platform causes the difference. Hosting, CDN use, the visitor’s location and site size all vary by platform. This is correlation only.

Samples differ in size

WooCommerce includes hundreds of thousands of small sites, and Shopify more than 430,000. SAP Commerce Cloud has 1,850 origins and Magento with Hyvä 4,593. Some cells in the top tiers are small, and their n is reported next to the figure. Cells under n = 20 are shown as counts.

Moderate originality

Each platform’s numbers can be looked up one technology at a time on HTTP Archive’s site. This study’s contribution is the 12-platform comparison, the popularity-tier control, the split between time to first byte and Core Web Vitals, the country cut and the three-year trend in one place. The annual re-run makes it a series.

Medians in buckets

Median time to first byte comes from 100 ms histogram buckets, so it’s reported as a range. A median of 1,200–1,299 ms means the middle site fell somewhere in that bucket. The data doesn’t give a single millisecond value.

What we will measure next

Three additions are planned. scandiweb will re-run this analysis every September, so the trend in Table 4 gains a column each year on the same instrument and the same definitions. The next edition will also split desktop and mobile by country, and it will add uncached page build times measured directly on a sample of stores.

The annual re-run is the main one. The 2023 to 2026 trend already shows that Magento’s server response moved mostly in the last year, and a yearly series will show whether that continues.

The desktop-by-country cut tests the distance explanation. If the country pattern in Table 5 comes from where stores are hosted, it should appear on desktop too, and the mobile and desktop columns should move together.

The uncached build measurement addresses the biggest limitation. Chrome’s field data can’t separate network time from server work, and measuring how long Magento takes to build a page with the cache empty, on a sample of real stores, is the only way to see how much of the gap the server itself accounts for.

Frequently asked questions

Which eCommerce platform is the fastest?

On server response in September 2026, Shopify. According to scandiweb’s analysis of Chrome UX Report data, 83.8% of Shopify sites gave mobile visitors a good time to first byte, followed by Webflow at 77.5%, Squarespace at 76.6% and Wix at 73.1%. All four run every store on the vendor’s own infrastructure. The ranking covers server response only, and Shopware leads on Core Web Vitals at 84.0%.

Is Magento slower than Shopify?

On server response, yes, for most stores. In September 2026, 23.0% of Magento sites had a good mobile time to first byte against 83.8% of Shopify sites, and the median Magento store responded in 1,200–1,299 ms against 500–599 ms. The gap holds among sites of similar popularity and in all three countries checked. The data doesn’t show whether the platform itself is the cause.

What is a good TTFB for an online store?

800 ms or less at the 75th percentile, which means the server starts responding within 0.8 seconds on at least three out of four visits. Google’s TTFB guidance calls that good and more than 1.8 seconds poor. In September 2026, 45.9% of all websites with Chrome data met the good threshold on mobile, and the median site fell in the 800–899 ms bucket.

Does Hyvä make Magento faster?

In the browser, yes. Magento sites running Hyvä passed all three Core Web Vitals on mobile 66.4% of the time in September 2026, against 44.6% for Magento overall, and their median Lighthouse score was 48 against 35. On the server, no. Their good time-to-first-byte share was 23.2%, almost the same as Magento’s 23.0%, because a theme changes what the browser does after the first byte arrives.

Is TTFB a Core Web Vital?

No. The three Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Google’s TTFB guidance says that because TTFB isn’t one of them, a site doesn’t have to meet the good threshold to pass. The Chrome UX Report lists it as an experimental metric collected on full page loads only. A store can pass Core Web Vitals with a slow server, as Shopware’s numbers show.

Why are hosted platforms faster on server response?

The data doesn’t say. The four leaders on time to first byte all run every store on the vendor’s own infrastructure, so the merchant never picks a host, a cache or a server size, and that is an observation rather than a proven cause. Hosting, CDN use, the visitor’s location and the size of a typical store all vary by platform, and this study measures correlation only.

Cite this research

• Title: “The Fastest eCommerce Platform? Server Response Times for 12 Platforms”
• Author: scandiweb
• Published: November 3, 2026
• URL: https://scandiweb.com/blog/fastest-ecommerce-platform/
• Data: Chrome UX Report via HTTP Archive Tech Report, September 2026.

Press and analyst enquiries about the dataset or the method can go to our team.

Where the fastest eCommerce platform wins, and what Magento can do

The fastest eCommerce platform on server response in September 2026 was Shopify, with 83.8% of sites giving mobile visitors a good time to first byte, and Magento ranked 10th of 12 at 23.0%. The gap held among sites of similar popularity, in the United States, the United Kingdom and Germany, and across three years of data. Magento gained seven points since 2023 while Shopify gained almost six, so the distance between them stayed close to 60 points.

The Hyvä numbers carry the practical lesson. A frontend theme lifted the Core Web Vitals pass rate from 44.6% to 66.4% and left server response at 23.2%, almost the same as Magento overall. Browser work and server work are separate projects, and most Magento stores have done more of the first than the second.

Time to first byte is where a Magento store can still gain the most, and it is also the number most stores haven’t measured on their own.

To find out where your store falls on these charts, ask us to measure your server response before you commission anything else.

The post The Fastest eCommerce Platform? Server Response Times for 12 Platforms appeared first on scandiweb.

You can find out how much traffic your Magento (Adobe Commerce) store can take before a big sale, while there is still time to fix what breaks. That is the job of Magento load testing: a tool sends the store a crowd of simulated shoppers, adds more of them step by step, and records the point where pages start to slow down.

Magento used to come with that test built in. Up to version 2.4.5, every install carried scripts for JMeter, a free load-testing program, in a folder called the Magento Performance Toolkit. Adobe removed the scripts in version 2.4.6, released in March 2023. The folder now does one job: it fills a test copy of your store with products, customers and orders. The traffic comes from a tool you pick, such as JMeter or k6, another free tool, aimed at a copy of the store that matches the live one.

What is Magento load testing?

Magento load testing sends a copy of your store many simulated shoppers at once and raises the traffic in steps while it measures three numbers: requests per second, response time and errors. The result is your store’s capacity, the traffic level where response times start to climb, which you then compare with your real peak.

Three numbers describe each step of the test. Requests per second is how many requests, mostly page loads, the server answers each second. Response time at the 95th percentile, or p95, is the time that 95 out of every 100 requests beat, so a few slow pages can’t hide behind a good average. Single-page server timing is covered in our guide to reducing server response time. Error rate is the share of requests that fail or time out.

Plot p95 against traffic and the line stays nearly flat, then bends upward as the server runs short of something: CPU, PHP workers or database connections. The bend is the store’s capacity.

Load testing is one part of Magento performance testing, and timing single pages for one visitor comes first. The load test tells you how long those timings hold once the crowd arrives.

Load test vs stress test

Adobe’s testing guidance for Commerce on Cloud separates the two. A load test measures response times and errors under the load you expect, for example a set number of concurrent users who each complete a set number of transactions in a set time, and it shows the response time of the transactions that matter to the business. A stress test pushes past that, to see whether the system still performs “when the current load goes well above the expected maximum”. Run the load test first, then keep raising the traffic into a stress test to see what breaks first.

What the Magento Performance Toolkit does today

The Magento Performance Toolkit is a folder that comes with Magento 2 at setup/performance-toolkit. Today it generates test data: one command fills a store with products, categories, customers and orders in one of five sizes, from small to extra large. Up to Magento 2.4.5, it also held JMeter load-test scripts, which Adobe has since removed.

It gives you half of a load test: a store full of data. The traffic comes from somewhere else.

The five profiles and what they generate

Each profile is an XML file that sets how much of everything the generator creates. Adobe’s profile table gives these values:

Source: Adobe’s profile table. Configurable products have 24 options each, except 79 of the medium multi-site ones, which have 200.

Pick the profile closest to your catalog: medium has 24,000 simple products, large has 300,000, and medium multi-site suits a store that runs many websites and store views from one install. A sanitized copy of your own data is better when you can use it, because your own attributes and extensions shape the work Magento does on every page.

How to generate the test data

bin/magento setup:performance:generate-fixtures -s setup/performance-toolkit/profiles/ce/medium.xml
bin/magento indexer:reindex

Use profiles/ee on Adobe Commerce. Disable cron jobs before you start.

Adobe’s instructions say to disable all cron jobs before the generator runs and to reindex when it finishes. The -s option skips the reindex, so the generator needs fewer resources, though the total time doesn’t drop. Adobe’s docs write the command as setup:perf:generate-fixtures, the same command in its short form.

The toolkit’s README for 2.4.5 said the large profile can take up to 4 hours, and that medium or large may need MySQL tmp_table_size and max_heap_table_size of 512 MB or more and a PHP memory_limit of 1 GB or more. Run it on a throwaway copy, never on production, since it writes products, customers and orders into whatever database it points at.

What happened to the JMeter scripts

Up to Magento 2.4.5, the folder also held two JMeter scripts, benchmark.jmx and benchmark_2015.jmx, that imitated shoppers browsing, searching, adding to cart and checking out, plus admin users. Adobe removed both in August 2022, and Magento 2.4.6, released in March 2023, was the first release without them. Some guides still describe them as part of every install.

The 2.4.5 versions are still in the 2.4.5 toolkit folder on GitHub, with a README that explains each setting, so they work as a template. They were written for older releases, so check every request against your store before you trust a result.

Load testing tools for Magento: JMeter, k6, Gatling and Locust

The common load testing tools for Magento are JMeter, k6, Gatling and Locust. All four are free and open source. They differ mainly in how you write the test: JMeter in a visual editor, k6 in JavaScript, Gatling in Java or JavaScript, and Locust in Python. Pick the one your developers already read and can maintain.

The install steps are on the home pages of Apache JMeter, Grafana k6, Gatling and Locust. Adobe’s Cloud testing guide also lists Siege, and New Relic, which watches the server while a load tool sends traffic. The two answer different questions: the load tool shows when the store slows down, and monitoring shows why.

Set the load in requests per second

Most tools start a number of virtual shoppers, and each one waits for a page before asking for the next. When the store slows down, each of them asks less often, so the test eases off exactly when it should push. k6’s documentation on open and closed models puts it plainly: when the system under test starts to respond more slowly, a closed-model test waits.

The fix is an open model. Requests start at the rate you set, whatever the store’s response time, so a struggling store gets the same traffic as a healthy one. In k6 that is the ramping-arrival-rate executor. Other tools may offer something similar, so check your tool’s documentation for an open model or an arrival rate. Read your results in requests per second, the unit the Expedio benchmark below also reports.

How to run a Magento server load test, step by step

To run a Magento server load test:

1. Build a test copy that matches production.
2. Pick the pages and journeys to test.
3. Measure a baseline at low traffic.
4. Raise the requests per second in steps.
5. Find the step where response times bend upward.
6. Change one thing and run the same test again.

1. Build a test copy that matches production

Match production on server size and count, Magento version, extensions, theme, PHP version, cache setup (Varnish, and Valkey or Redis) and search engine. Check the versions against the Magento 2 system requirements for your release. For data, use a sanitized copy of production with personal data removed, or the Performance Toolkit profile closest to your catalog size. Run the load tool from a separate machine, so it doesn’t compete with the store for CPU. If production adds servers when traffic rises, as with server autoscaling in Magento 2, decide whether the test copy should do the same: with it on you measure the cluster, with it off you measure one server.

2. Pick the pages and the cache setting

Use real URLs from your catalog: category pages, filtered categories, product pages, searches and the cart. Add logged-in journeys, since each customer group gets its own cache copies, so logged-in pages miss the cache more often. Run once with the Magento full page cache on, the way shoppers get the store, and once with it off, to see what the server can build on its own, which is the load it faces after a deploy or a cache flush. On Adobe Commerce Cloud, Fastly is the full page cache. On your own servers, the Varnish configuration decides which pages the cache can serve.

The old toolkit script’s cache-hit setting defaulted to 100%, so out of the box it measured a store where every page came from the cache. For a sale, the target, the traffic mix and the pass criteria are in our Black Friday load-testing plan.

3. Measure a baseline at low traffic

Run one or two requests per second for a few minutes and record p95 per page type. At this level, your numbers should match the single-page timings you get when you audit Magento performance. If the cache is on, refill the top pages first with a cache warmer or a scripted crawl, or the first minutes measure an empty cache. As a sanity check, Adobe says that with Varnish working, cacheable pages load in less than 150 ms.

4. Raise the load in steps

Increase the rate in steps, doubling it each time for example, and hold each step for a few minutes, long enough for the numbers to settle. At each step record the requests per second the store actually answered, p95, the error rate, and CPU and database load from your monitoring, whether that is New Relic or the host’s dashboards. In k6, the ramping-arrival-rate executor steps the rate up on a schedule you set.

5. Find the step where response times bend

Capacity is the last step before p95 rises faster than the traffic, or before errors appear. Write it down in requests per second, and note what ran out first, CPU, PHP workers or the database, because that tells you whether the fix is more servers or cheaper requests. To see which code uses that time, profile the slow page. If the database ran out first, our guide to Magento MySQL optimization covers slow queries and indexes. Then compare the number with your real peak, and the gap between the two is what the next few weeks need to close.

6. Change one thing and run it again

Same copy, same data, same script, same steps, and the cache reset the same way before each run. Repeat each step several times and compare the medians, so one noisy run can’t decide the result. One change per comparison: a PHP upgrade, a new server size or a module, never all three at once.

What a fair load test looks like, with a worked example

A fair load test compares two versions of a store under identical conditions: the same server, the same data, the same cache settings and the same traffic, with one change between them. Repeating each run many times keeps one noisy result from deciding the outcome. Our Expedio benchmark followed that setup.

Expedio is scandiweb’s Magento module with an open-source core. It speeds up how Magento builds each page on the server by applying Liquid, the open-source template language created at Shopify, and makes that build at least 2x faster. It runs on Magento Open Source, Adobe Commerce and Commerce Cloud, with Luma, Hyvä or a custom theme, on any hosting, and leaves the theme, data, admin and checkout as they are.

To measure it, we ran the kind of fair test this guide describes. In a benchmark on one merchant’s Hyvä store, measured as server response time, two copies of the store ran side by side on one server, one as it runs today and one on Expedio, with the same data, the same hardware and no full-page cache on either, so Magento had to build every page. The test covered eight page types in 162 runs and 487,115 requests. Stock Magento’s category page climbed to 400 ms at 20 requests per second, the point where it began to struggle. With Expedio, the same server handles 3x the traffic before response times start to rise. The Expedio benchmark has the full method and its limits.

What to copy from it, whatever you are comparing:

• One round with the full page cache off, to see the build capacity rather than the cache’s.
• Page types tested one at a time as well as mixed, so one slow template can’t hide in an average.
• The benchmark’s own rule: “if an optimization would help both stores equally, we didn’t make it”. Every change in a comparison has to belong to the thing you are testing.

How to load test Adobe Commerce Cloud

On Adobe Commerce Cloud, open a support ticket before you load test, naming the environments, the tools and the time frame. Adobe’s testing guide covers load tests on Staging and Production before launch, and asks you to add results to the ticket and to note, with a date and time, when testing is complete.

Adobe’s Staging and Production testing guide lists the tools it expects: JMeter for spiked traffic such as flash sales, Siege, and New Relic, which comes with Cloud projects and finds the processes that slow down. It also asks you to review the Performance Toolkit before launch. The toolkit’s data generator works on Cloud projects, since Adobe marks it for on-premises and Cloud (PaaS) projects, and not for Adobe Commerce as a Cloud Service.

If your peak will run on a temporarily upsized cluster, book the upsize first and test at that size. Adobe’s temporary upsize request page says non-emergency requests need 48 business hours’ notice, and the Holiday Surge option is offered only from October to December. Adobe doesn’t connect the upsize to load testing. We do, because a test on the smaller cluster tells you about a server you won’t be running on peak day.

Frequently asked questions about Magento load testing

Is the Magento Performance Toolkit still part of Magento 2.4?

Partly. The setup/performance-toolkit folder still comes with Magento 2.4, and its five profiles still generate test data with bin/magento setup:performance:generate-fixtures. The JMeter load-test scripts that used to sit beside them, benchmark.jmx and benchmark_2015.jmx, were removed, and Magento 2.4.6 was the first release without them. Today you pair the toolkit’s data with a load-testing tool of your choice.

How long does it take to generate Performance Toolkit data?

It depends on the profile and the server. Adobe’s notes for the toolkit said the large profile, with 300,000 simple products, can take up to 4 hours to generate. To use fewer resources, run the generator with the -s option to skip indexing, then run bin/magento indexer:reindex when it finishes. Disable cron jobs before you start, as Adobe’s instructions require.

Which tool is best for Magento load testing?

The best tool is the one your developers can maintain. JMeter has the longest Magento history, since Adobe’s old toolkit scripts were JMeter files. k6 suits teams that write JavaScript and can hold a fixed rate of requests per second. Gatling suits Java teams, and Locust suits Python teams. All four are free and open source.

How many users should a Magento load test simulate?

Work from your own analytics. Take the traffic of your busiest past peak, express it as requests per second, and test past it in steps until response times rise. A user count on its own says little, because a simulated shopper who pauses between pages sends far fewer requests than one who doesn’t. The old toolkit’s default of 100 users was only a starting value.

What is the difference between load testing and stress testing?

A load test measures how fast the store responds under the traffic you expect. Adobe describes it as testing a number of concurrent users who each perform a set number of transactions in a set time. A stress test goes past that, to see whether the system still performs when the load goes well above the expected maximum. Run the load test first, then push on into a stress test.

Can you load test a store on Adobe Commerce Cloud?

Yes. Open a support ticket first, naming the environments you will test, the tools you will use and the time frame. Adobe’s testing guide covers load tests on Staging and Production before launch. Add your results to the ticket as you go, and when you finish, note in the ticket that testing is complete, with a date and time stamp.

Run your Magento load test before the next peak

Magento load testing answers one question before every peak: how much traffic your store takes before response times start to rise. The Performance Toolkit supplies the test data, a tool such as JMeter or k6 supplies the traffic, and a fair setup, one change at a time on the same server, makes the result something you can act on.

When the test shows a limit you need to raise, our guide on how to speed up Magento puts 15 fixes in order, from the server to the browser. Run the first test now, while there are still weeks to act on what it finds, and keep the script. The same test after each change is what turns a guess about capacity into a number you can plan a sale around.

If you want us to review your load-test setup or your results before the next peak, get in touch with our team.

The post Magento Load Testing: How to Benchmark Your Store for Peak Traffic appeared first on scandiweb.

If you’ve ever tested your store in Google PageSpeed Insights, or in Lighthouse, the audit tool built into Chrome, and seen the warning “Reduce initial server response time”, your server took too long to start sending the page. The check fails when the first bytes of the page’s HTML take more than 600 ms to arrive. Since October 2025, the same check appears under a new name, “Server responded slowly”, in the Document request latency section of PageSpeed Insights.

Google also measures that moment on real visits, as time to first byte (TTFB). It counts a page as good when 75% of visits get the first byte within 800 ms. So a store can fail the test in PageSpeed Insights and still pass on real visits, or the other way round.

Homepage TTFB is one of the first numbers we look at in our store health checks, and the warning never says which part of the setup is slow. The host, the platform, the theme and the code all get blamed in turn, and each fix only works if it targets the step that is slow on your store.

What does “reduce initial server response time” mean?

Reduce initial server response time is the Lighthouse warning for a slow main document. It appears when the browser waits more than 600 ms for the server to start sending a page’s HTML. Lighthouse 13 moved the check into the Document request latency insight, which now reports it as “Server responded slowly” next to redirect and compression checks.

The main document matters more than any other request because everything else waits for it. Until the HTML arrives, the browser has no list of stylesheets, scripts or images to fetch, so a slow initial server response time delays everything that follows.

Where the warning went in Lighthouse 13

Since Lighthouse 13, published on October 10, 2025 and in PageSpeed Insights within a week, the server response check is grouped with the redirect and compression checks in the Document request latency insight. The insight shows three lines, each with a pass and a fail version:

• “Avoids redirects” or “Had redirects (N redirects, +X ms)”
• “Server responds quickly (observed X ms)” or “Server responded slowly (observed X ms)”
• “Applies text compression” or “No compression applied”

The threshold stayed at 600 ms, and the performance score didn’t change, because scoring is based on the metrics rather than the audits. Google’s Document request latency page lists the three failure conditions and the fix for each.

What is a good server response time?

A good server response time is under 600 ms in a Lighthouse test and 800 ms or less for real users at the 75th percentile, as measured by the Chrome UX Report (CrUX). The two numbers measure different things, which is why the same store can pass one and fail the other.

What is TTFB, and what makes up time to first byte?

Time to first byte (TTFB) measures how long a page takes from the start of navigation until the first byte of its response arrives. Google’s web.dev splits it into five phases: redirect time, service worker startup, DNS lookup, connection and TLS negotiation, and the request itself. That last phase is where the server builds the page.

Here are the five phases in order, as web.dev defines TTFB:

1. Redirect time. Any hop before the final URL, such as http to https or a trailing-slash fix.
2. Service worker startup time. Only counts if the site registers a service worker.
3. DNS lookup. Turning the hostname into an IP address.
4. Connection and TLS negotiation. The TCP handshake and the TLS handshake.
5. The request itself, until the first byte of the response arrives. This is the phase where the server runs your application and builds the page.

Field TTFB from CrUX includes all five phases. Lighthouse’s server response check isolates the last one and leaves DNS and redirect time out. That difference explains most cases where the lab number and the field number disagree. It also means a redirect chain can push a store over the 800 ms field line while the lab check passes, because the lab never saw the redirect.

Web.dev adds that TTFB comes before every other loading metric. A slow first byte pushes back First Contentful Paint and Largest Contentful Paint by the same amount, which is why a server fix often moves the rendering metrics too.

How to measure TTFB: lab data vs field data

Measure TTFB in two places. Field data from the Chrome UX Report, shown in PageSpeed Insights, tells you what real Chrome users got at the 75th percentile over the last 28 days. Lab tools such as Lighthouse, Chrome DevTools and curl time one request at a time, so you can compare a cached page with an uncached one.

Field data: PageSpeed Insights and the Chrome UX Report

Field TTFB is what real Chrome users got, at the 75th percentile, over the last 28 days. PageSpeed Insights labels it an experimental metric and shows it in the field section next to the Core Web Vitals. A page with little traffic may have no field data at all, and then the lab is all you have. Our older guide to lab and field data in PageSpeed Insights explains how the two sections are built.

Lab data: Lighthouse and Chrome DevTools

Lighthouse times one simulated load and checks the server’s response against 600 ms, with DNS and redirect time left out. To check TTFB in Chrome yourself, open DevTools, go to the Network panel, click the document request and open the Timing tab. Read the DNS Lookup, Initial connection and Waiting (TTFB) rows. Then do it twice: once on a page the cache has already served, and once on a page it hasn’t, such as a category URL with a filter combination nobody has used. The gap between the two Waiting (TTFB) values is the first clue about where the time goes.

How to check server response time with curl

curl’s write-out timings show each phase from the command line, with no browser cache in the way. This command prints every phase as a cumulative time from the start of the request:

curl -s -o /dev/null -L -w "dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nredirects %{time_redirect}\nfirst byte %{time_starttransfer}\ntotal %{time_total}\n" "https://www.example.com/"

time_starttransfer is the time until the first byte was received, and curl’s documentation notes that it includes the time the server needed to calculate the result. time_redirect is the cost of every redirect step before the final request started. Run the command twice: once as it is, and once with a throwaway query parameter such as ?nocache=1234 on the URL, which makes most caches treat it as a new page. The difference between the two first byte values is the cost of an uncached page build.

Split server time with the Server-Timing header

The Server-Timing response header lets your backend report where its own time went on each request. web.dev’s example looks like this:

Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2

The values appear in the Timing tab of Chrome DevTools next to the network phases, and you can collect them from real users through the Navigation Timing API’s serverTiming property. That turns “the server is slow” into “the database took 121 ms”. MDN’s Server-Timing reference adds a warning: the header can expose application and infrastructure details, so send it only to your own team or to authenticated users.

How to reduce server response time, cause by cause

To reduce server response time, find the slow phase first, then fix that layer. Remove redirects, put a CDN in front to cut DNS, connection and TLS time, cache full pages at the server or edge, give the store enough dedicated hosting, fix slow database queries, and speed up the code that builds each page.

Anyone searching for how to reduce initial server response time gets the same six fixes in a fixed order. The order that works is the one your measurements set, because each symptom points at a different layer. Our guide on how to audit Magento performance shows how to take those measurements for each page type.

Remove redirects before the real page

Link straight to the final URL. Same-origin redirects are the ones you control: http to https, a missing or extra trailing slash, a hop to a country store. Cross-origin redirects from ad platforms, link shorteners and newsletter tools are often outside your control, so give partners the final URL from the start. Add a Strict-Transport-Security header so returning visitors skip the http hop, and submit the domain to the HSTS preload list to remove it on the first visit too. PageSpeed Insights reports leftover hops as “Had redirects” with their cost in ms.

Cut DNS, connection and TLS time with a CDN

Put a CDN in front of the store so shoppers connect to an edge server near them. CDN providers usually offer very fast DNS resolution, and they support HTTP/2 or HTTP/3 and current TLS versions, which shortens the connection and TLS phases. Lighthouse lists “Use a CDN to reduce network latency” among its own fixes for this audit. Without HTML caching at the edge, the CDN still forwards every page request to the origin and waits for it, so the server phase of TTFB doesn’t move at all.

Cache full pages at the server or the edge

Cache full pages so the application doesn’t run for most requests. Set Cache-Control headers so the CDN can hold the HTML at the edge, and use a server-side page cache for the rest. Caching can hide a slow backend, and every cache has misses: the first request after a deploy, every request after you flush the whole cache, URLs nobody has asked for yet, and pages with many variants, such as one entry per customer group or per search term. A cache warmer refills the top pages after a deploy, though it can’t cover every URL. Those pages still go through the cache. They hit it less often.

Give the store enough dedicated hosting

Give the application enough CPU and memory, keep the backend stack updated, and move off crowded shared hosting, which is generally slower. On larger stores, split the tiers. Adobe’s own guidance for Magento (Adobe Commerce) is to install Varnish on a separate server in front of the web tier. Server autoscaling adds capacity when traffic peaks, which keeps response times from climbing under load. It leaves a single request exactly as fast as before, so a slow page build needs a different fix.

Fix slow database queries

Find the slow queries first. They show up as a large db value in Server-Timing or as entries in the database’s slow query log. Index the columns your filters and sorts use, and keep the database’s max_connections setting in line with the number of PHP threads in the application server, as Adobe recommends. Platforms with flexible attribute models are query-heavy by design, and Magento’s EAV model is the one most eCommerce teams meet, so query count matters there as much as query speed.

Speed up the code that builds each page

Lighthouse’s doc for this audit, “Reduce server response times”, puts application logic first: optimize it to prepare pages faster. Profile the templates, loops, extensions and apps that run on a slow page and remove what doesn’t earn its time. On Magento, our Magento profiler guide shows how to do that with New Relic or Blackfire. 103 Early Hints can start asset downloads while the server is still working, and web.dev recommends it when backend work is significant, but it can mask a slow backend, so keep measuring real server time with Server-Timing. Which code to profile depends on the platform: the Magento page build, the Shopify theme’s Liquid, or the renderer on a headless frontend. The next three sections take them in turn.

How to reduce TTFB on Magento and Adobe Commerce

Magento stores fail TTFB far more often than Shopify stores. In HTTP Archive’s September 2026 data, 23% of Magento sites had a good TTFB, against 84% (mobile) to 93% (desktop) of Shopify sites. The fixes are Varnish for cached pages, a tuned server stack, and a faster page build for every request the cache can’t answer. How Magento compares with other platforms on this metric is in our fastest eCommerce platform research.

Those figures come from HTTP Archive’s technology report, which counts the share of sites with a field TTFB of 800 ms or less at the 75th percentile. The Magento share is improving, from 16.6% on mobile in September 2025 to 23.0% a year later. The dataset holds about 13 times more Shopify sites than Magento sites, and HTTP Archive itself warns that correlation doesn’t equal causation.

Cached pages: Varnish and a tuned server stack

Lighthouse’s whole Magento advice for this audit is one line: “Use the Varnish integration.” Adobe says the same with more force. It strongly recommends Varnish in production and calls the built-in full page cache, which writes to the file system or database, much slower. Our Magento 2 Varnish configuration guide covers the setup step by step. Once Varnish answers the cached pages, the rest of the stack decides how fast the remaining requests are:

• Valkey for cache and sessions on 2.4.9, since Redis cache isn’t supported there, with cache and sessions kept separate.
• Production mode, because default mode isn’t optimized for production due to how it handles static files.
• A supported PHP version (8.5 on 2.4.9, 8.4 or 8.3 on 2.4.8) with OPcache sized for the codebase, for example opcache.memory_consumption=512 and opcache.max_accelerated_files=60000.
• Indexers set to Update on Schedule, with cron running so the schedule is honored.

The full list of fixes is in our guide to speed up Magento.

Uncached pages: a faster page build with Expedio

Every request the cache can’t answer goes to PHP: the first request after a deploy or a cache flush, URL combinations no shopper has opened yet, and any page with one cacheable="false" block, which makes the whole page uncacheable. Catalog pages for logged-in customers and search results are cached too, one entry per customer group or search term, but those entries miss far more often than the homepage does, and a flush empties them all. Our guide to the Magento full page cache shows which requests miss and why.

For the requests your cache can’t answer, Expedio makes the server build each Magento page at least 2x faster, measured as TTFB, and lets the same server handle 3x the traffic before response times start to rise. It is scandiweb’s software for the page build itself. It applies Liquid, the open-source template language created at Shopify, and its core is open source. In a benchmark on one merchant’s Hyvä store, measured as server response time, pages built with all caches empty took a median of 57 ms instead of 181 ms, and a full category page made 30 database queries instead of 655. Expedio works on Magento Open Source, Adobe Commerce and Commerce Cloud, with any theme and any host, and comes built into ReadyMage hosting. It doesn’t change the theme, the data, the checkout or the admin.

Why a new theme leaves TTFB where it was

A new theme fixes what the browser does, and the server’s first byte needs server work. HTTP Archive’s September 2026 data makes the split visible: 23.2% of Hyvä sites had a good TTFB on mobile, the same share as Magento overall at 23.0%, while 66.4% of them passed all Core Web Vitals on mobile, against 44.6% for Magento overall. The theme moved the rendering metrics and left the first byte alone. A store can run both: a Hyvä frontend for the browser side and a faster page build on the server.

How to improve TTFB on Shopify

To improve TTFB on Shopify, start with the theme’s Liquid code. Shopify renders Liquid on the server for every page request, and its developer docs say most of a storefront’s response time is Liquid rendering. Nested loops over products, variants or options are the most common cause, and Shopify Theme Inspector shows which lines are slow.

Shopify’s TTFB is good for most stores. In September 2026, 83.8% of Shopify sites had a good TTFB on mobile and 92.6% on desktop, so when a Shopify store fails the check, the theme is the first place to look.

Install the Shopify Theme Inspector for Chrome, a browser plugin that shows Liquid render profiling data as a flame graph for your own store or any store where you have collaborator access. Load the slow page and read the graph from the widest bars down. Shopify’s theme performance guidance names the patterns to look for: loops nested across products, variants or options, which grow quadratically with catalog size, iterating all variants of a product, which forces expensive database queries, and metafield access inside loops.

Hosting isn’t a lever here. Shopify runs the platform on a global CDN backed by Cloudflare, and theme assets get HTTP/3, Brotli and edge caching without any setup on your side. Redirects are still worth a check: apps that add their own redirect chains show up in the “Had redirects” line, and the curl command above puts a number on them. For the browser-side work that comes after the first byte, our guide to speed up a Shopify store covers apps, images and scripts.

Server response time on headless storefronts

On a headless storefront, TTFB depends on how the frontend server renders HTML. Cache rendered pages at the CDN edge, render pages that need no personalization ahead of time, stream server-rendered HTML so the first bytes leave early, and start API calls in parallel. Server-Timing headers show whether rendering or data fetching is the slow part.

In a headless setup the HTML comes from the frontend’s own server, a Node or edge runtime, which calls the commerce platform’s APIs and then renders the page. Server response time is rendering time plus API time, and the fixes follow from that split.

• Cache rendered HTML at the CDN edge with Cache-Control headers for pages that look the same to every shopper.
• Use static rendering for pages that need no personalization, so they are built ahead of time and served as files.
• Stream server-rendered HTML where the runtime supports it, so the first bytes leave before the whole page is ready. Google’s guide to optimizing TTFB covers both options.
• Start API requests in parallel. In Next.js, for example, one slow data request blocks the whole route, so start the requests together and await them with Promise.all.

Add a Server-Timing header with ssr and api or db entries so you can see whether rendering or data fetching is the slow part. One caveat from web.dev: a server-rendered page can show a higher TTFB than a client-rendered one and still paint content sooner, with a better FCP and LCP, because the browser receives finished HTML. Judge a headless storefront on all three metrics, with TTFB as the one you fix first.

Frequently asked questions about reducing initial server response time

Is a 100 ms server response time good?

Yes. A 100 ms server response time is very fast. Lighthouse calculates its estimated savings against a 100 ms target and fails the check only above 600 ms, and Google rates field TTFB of 800 ms or less as good. The 200 ms target still quoted online comes from an old PageSpeed Insights rule written for API version 4, which Google shut down in May 2019.

Is TTFB a Core Web Vital?

No. The Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, and web.dev says plainly that TTFB isn’t one of them. It still matters because it comes before every other loading metric. A slow first byte pushes back First Contentful Paint and LCP, which leaves less time for everything else on the page.

Why is my TTFB so high?

High TTFB usually comes from one of four places: redirects before the real page, a long network path to a distant server, a cache miss that makes the server build the page from scratch, or slow code and database queries during that build. Time the same URL with and without the cache to see which one applies to your store.

What does “Waiting (TTFB)” mean in Chrome DevTools?

Waiting (TTFB) is a row in the Timing tab of the Chrome DevTools Network panel. It covers the time when the browser is waiting for the first byte of the response, after the request is sent. DNS lookup and initial connection appear as separate rows above it, so a long Waiting (TTFB) bar points at the server.

Does a CDN reduce initial server response time?

Yes, in two ways. A CDN shortens DNS, connection and TLS time because shoppers connect to a nearby edge server, and when it caches HTML, those pages never wait on the origin. It can’t speed up pages it doesn’t cache, such as the cart, checkout or customer account pages, which still depend on how fast the origin server builds them.

Why does PageSpeed Insights show a different TTFB than my own test?

PageSpeed Insights shows two different measurements. The field TTFB comes from real Chrome users over the last 28 days and includes redirects, DNS and connection time. The Lighthouse lab check times one simulated load and leaves DNS and redirect time out. Your own test adds its own location, network and cache state, so the three numbers rarely match.

Where to start when you need to reduce initial server response time

To reduce initial server response time, measure before you fix. Check field TTFB in PageSpeed Insights, then time a cached and an uncached page with curl or DevTools to find the slow phase. Redirects and distance are quick wins. A slow page build needs work on caching, hosting, the database or the application code. On Magento, our list of causes of a slow Magento store helps match the symptom to the layer.

On Magento, the page build is the layer Expedio speeds up. On Shopify or a headless frontend, profile the Liquid or the renderer.

If one of your store's pages keeps failing the server response check, send it to scandiweb and we'll tell you which layer is slow.

The post Reduce Initial Server Response Time: A Guide for eCommerce Stores appeared first on scandiweb.