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.

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. 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.

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. 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.

A speed test of your Magento homepage times one of the easiest pages your store has to serve. Most visitors arrive there logged out, so Magento (Adobe Commerce) can answer from its full page cache, a set of finished pages kept ready to send, without building anything. Shoppers wait on the pages a homepage test never reaches: a filtered category, a search nobody has run this week, the catalog a logged-in trade customer sees.

Auditing Magento performance means timing those pages as well. It measures how long the server takes to start sending each page, called time to first byte (TTFB), both from the cache and built from scratch. It also reads Google’s Core Web Vitals, three scores for loading, responsiveness and visual stability, taken from real Chrome users’ visits. In September 2026, only 23% of Magento sites had a good TTFB on mobile, against 46% of websites overall.

What does auditing Magento performance cover?

Auditing Magento performance means measuring how fast your store answers and renders for real shoppers, page type by page type, and ties each slow number to a cause. It times server response on cached and uncached pages, reads Core Web Vitals from real-user data, tests the server under rising traffic, and checks the setup behind all three.

A speed score gives you one number for one URL on one run. The audit covers six page types in four states, and every slow number in it comes with a likely cause and the team that fixes it.

Performance audit vs code audit

A code audit reads the code: security holes, coding standards, extension quality, slow database queries. A performance audit starts from measurements of what shoppers get and works back toward a cause. The two meet when the numbers point at a specific module, template or query. When they do, the next step is a Magento code audit, which reads the code behind the slow page. A general Magento audit mixes both. This checklist covers the measurement half.

The Magento performance checklist

Use this checklist for a Magento store performance check in one pass. Each row is one measurement, how to take it, and what a healthy result looks like. Run it on one URL per page type: homepage, category, filtered category, product, search results and cart, logged out and logged in.

Copy it into a spreadsheet and fill in a column per page type.

For row 11, the Admin path is Stores > Settings > Configuration > Advanced > System > Full Page Cache.

How to audit Magento performance, step by step

To audit Magento performance:

1. List one URL per page type.
2. Read Core Web Vitals and TTFB from field data.
3. Time each page from the cache.
4. Time it uncached and logged in.
5. Test the server under rising traffic.
6. Check the setup behind every page.

1. List one URL for each page type

Pick six URLs from the live store: the homepage, the first page of a busy category, the same category with two filters applied, a best-selling product, a search for a term shoppers use, and the cart with one product in it. Then add the category and product URLs again as a logged-in customer, one test account per main customer group.

Pick busy, real URLs. Google only keeps real-user data for pages with enough visitors, per the Chrome UX Report methodology, and it doesn’t say how many. A rare filter combination or a fresh search usually has no page-level field data, so you time those yourself in steps 3 and 4.

2. Read Core Web Vitals and TTFB in PageSpeed Insights

PageSpeed Insights is Google’s free speed test, and it also shows what real Chrome users experienced on the page. Its top section is that field data: the past 28 days of visits at the 75th percentile, the value three quarters of visits came in under. When a page has too few visits, PageSpeed Insights falls back to data for the whole site and says so, so check the label first. TTFB appears there marked experimental.

The lower section is one lab test on a simulated device. It helps you find causes and flags a server that took more than 600 ms to respond, but it is one run on one machine, so don’t treat it as the result.

For each page type, record LCP, INP, CLS and TTFB on mobile and on desktop against Google’s thresholds. Your Magento 2 PageSpeed Insights results for a category page and a product page will often differ more than the homepage suggests.

Search Console’s Core Web Vitals report shows the same real-user data with URLs grouped by similar experience, which often lines up with your page types, and a group takes the status of its slowest URL. For how to read both views without chasing the lab score, see what PageSpeed Insights can tell you.

3. Time each page from the cache

Load each URL twice and time the second request. From a terminal, curl prints the time to first byte and the total:

curl -s -o /dev/null -w "TTFB %{time_starttransfer}s  total %{time_total}s\n" "https://www.example.com/women/tops.html"

Without a terminal, open the page in Chrome DevTools, go to the Network tab, click the first request and read the “Waiting (TTFB)” line. Run each page 3–5 times and note the middle value. Our guide to reducing server response time covers each timing in more depth, including the Server-Timing header.

Varnish is the cache server Adobe recommends in front of Magento. Adobe’s line for a working Varnish setup is that any page with cacheable blocks should load in less than 150 ms.

To confirm the page came from the cache, check the X-Magento-Cache-Debug header: MISS on the first load, HIT on the second. The header only appears in developer mode, so do this on staging. Our guide to the Magento full page cache walks through the full check.

4. Time each page uncached and logged in

A cache hides a slow page build from every visitor it can serve, so time the page with the cache out of the way. Three ways to do that: add a made-up query parameter such as ?audit=101 and change the number on each run, so Magento sees a new URL and builds the page again. Log in as each test customer and load the category and product URLs again, since each customer group keeps its own cached copies. Search for a term nobody has used since the last cache clean, because results are cached per term.

The cart is always built by Magento, so its times are uncached by definition. If you clear the cache to force a miss, do it on staging, or at a quiet hour at worst: Adobe’s cache management guidance says to schedule flushes outside peak times. On Adobe Commerce Cloud, full page caching uses Fastly, so check how your setup handles query strings with your team.

5. Test the server under rising traffic

Magento performance testing under load shows how many shoppers at once the server handles before every page slows down. Run it on a staging copy with production data, never on the live store. With a load-testing tool such as k6, JMeter or the one your host provides, raise the requests per second step by step and note the point where response times start to climb. Compare that point with your real peak, the busiest hour of your biggest sales day in your analytics. If the two are close, the server has no headroom for the next campaign.

6. Check the setup behind every page

Five settings explain a lot of slow numbers, and a developer can check them in a few minutes: bin/magento deploy:mode:show should say production, since default mode is not optimized for production. bin/magento cache:status should show a 1 next to every cache type. Full Page Cache in the Admin should be set to Varnish, or Fastly on Commerce Cloud, because the built-in cache is much slower. bin/magento indexer:show-mode should show Update by Schedule, which moves reindexing to cron. And the PHP version should be one Adobe lists for your release in its system requirements. A wrong answer here explains slow cached pages before you look anywhere else.

What the numbers tell you, and what to fix

The pattern across your numbers points to the fix. A slow cached page points to the cache or the server setup. A fast cached page with slow uncached versions points to the page build. Good server times with poor Core Web Vitals point to the theme and the browser. Times that climb with traffic point to capacity.

These are the patterns we see most often in our store health checks, with the fix that usually comes first and who owns it.

Start with the first row that matches, because the rows combine: a store in developer mode on old PHP shows slow uncached pages too, and that row’s fix comes after the setup fix. For the causes behind each pattern, read our guide to why a Magento site gets slow.

How to fix slow uncached Magento pages

When uncached pages are slow and cached ones are fast, the time goes into building the page: running PHP code, rendering layout blocks and querying the database. You can make that happen less often, with fewer cache variants, or make it take less time, with profiling, leaner code and a faster page build.

The first route is fewer misses. Merge customer groups that exist only for reporting and share the same prices, and keep filter combinations out of crawl paths so crawlers don’t fill the cache with pages no shopper opens.

The second route is a faster build. Profile one slow page with New Relic or Blackfire, which breaks the build into layout, blocks, templates and database queries, then remove or replace the blocks and modules that take the longest.

Expedio, scandiweb’s Magento module with an open-source core, takes the second route. 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.

We tested Expedio the way this checklist tests a store. 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 no page cache, across eight page types. On 100 category pages, each opened once from cold, stock Magento took a median of 181 ms and Expedio 57 ms, and a full category page ran 30 database queries instead of 655. The same server also handled 3x the traffic before response times started to rise. The Expedio benchmark has the full method and its limits.

When to bring in a professional audit

Bring in a professional Magento performance audit when the checklist shows a problem you can’t trace, such as slow uncached pages with no obvious cause, or when you need firm numbers before a peak season, an upgrade or a hosting move. A professional audit adds code profiling, load testing on a copy of the store, and a ranked list of fixes.

Where you timed a page, a professional audit profiles it, reads the MySQL slow query log, and runs load tests on a copy of the store with your real catalog. The report ranks every finding by severity and estimated effort, with a recommended fix for each, so your developers can start at the top.

Server response time is a standard line in our store health checks, and our Magento support team can run the deeper audit with you, from profiling to a ranked list of fixes. If your peak season is close, run the audit before your Black Friday code freeze, so there is time to act on what it finds.

Frequently asked questions about auditing Magento performance

What does a Magento performance check include?

A Magento performance check includes five steps: Core Web Vitals and TTFB from real-user data, server response time for each page type from the cache, the same pages built from scratch and logged in, response times under rising traffic, and the setup behind them, such as application mode, cache configuration, indexers and PHP version. A professional audit adds code profiling and a ranked list of fixes.

How long does it take to audit Magento performance?

The checklist in this article takes a few hours: six page types, timed from the cache and without it, plus field data from PageSpeed Insights or Search Console. Load testing and code profiling take longer, because they need a staging copy of the store, a load-testing tool and application monitoring set up first. Plan that deeper work with your developer or hosting team.

What is a good TTFB for a Magento store?

For real shoppers, Google calls a TTFB of 0.8 seconds or less good and anything over 1.8 seconds poor, measured at the 75th percentile of page loads. For cached pages, Adobe says a page with cacheable blocks should load in less than 150 ms when Varnish works. Uncached pages have no official target, so compare them with your cached times and the 800 ms line.

Is PageSpeed Insights enough for a Magento speed test?

No. PageSpeed Insights tests one URL at a time, and its lab test often gets a page the cache already holds. Its real-user section is the best free field data you have, but it covers the past 28 days and falls back to data for the whole site when a page has too few visits. Add your own uncached timings by page type to see the server side.

Should you audit Magento performance on production or staging?

Use both. Field data and cached timings come from production, because that is what shoppers get. Run the disruptive steps on a staging copy with the same data: cache flushes, developer-mode header checks and load tests. Adobe advises flushing caches outside peak hours, because a flush at peak makes the server rebuild pages while shoppers are waiting for them.

How often should you audit Magento performance?

Run a full audit before each peak season and after any major change: a Magento upgrade, a new theme, a new extension or integration, or a hosting move. Between audits, watch TTFB and Core Web Vitals at the 75th percentile so you notice a slowdown before shoppers report it. Keep each audit’s numbers as the baseline for the next one.

What to do after you audit Magento performance

Auditing Magento performance turns one speed score into a set of numbers you can act on: every page type, from the cache and built from scratch, for real shoppers and under load. The pattern across those numbers tells you what to fix first and who should fix it.

Start with the first decision-table row that matches your numbers, and fix that layer before the next one. If cold pages after a deploy are the problem, a cache warmer can refill the top ones, though not every filter, search and customer group. After each fix, re-run the same URLs with the same method, cached and uncached, so you compare like with like. Most stores find that one or two rows explain most of the wait, and the first fix is often a setting a developer changes in an afternoon. When you’re ready to work through the fixes from the server to the browser, our guide on how to speed up Magento puts all 15 in order.

If your numbers point in more than one direction, share them with us and we'll help you decide what to fix first.

The post How to Audit Magento Performance: A Checklist to Measure Your Store’s Real Speed appeared first on scandiweb.

A Magento (Adobe Commerce) store keeps finished copies of its pages in a cache, so most shoppers get a page that is ready to send instead of waiting for Magento to build it. Those copies don’t last. Releasing a store update or flushing the cache deletes all of them, and catalog updates delete the pages they touch. A Magento 2 cache warmer refills the cache before shoppers notice the gap.

Without one, the first shopper to open each page after a flush waits while Magento builds it from scratch, which takes far longer than sending a saved copy. Every popular page gets rebuilt this way, one slow first visit at a time.

A warmer does that work in advance. It visits your pages automatically, usually working through the sitemap, so the first real visitor gets a saved copy. It only reaches pages it can predict, and each visit costs your server the same build a shopper would have triggered. Whether that trade pays off depends on your traffic and how often your cache empties.

What does a Magento 2 cache warmer do?

A Magento 2 cache warmer requests your store’s pages before shoppers do, so the full page cache already holds a finished copy when the first visitor arrives. It runs after a deploy, a cache flush or a catalog change, when the cache is empty and every page would otherwise be built by PHP while a shopper waits.

A cold cache is one that doesn’t hold the page a shopper asked for. Magento then builds that page from nothing: it resolves the layout, renders every block on it and runs the database queries behind them, and only then does any HTML exist. A warm cache already holds the finished page and hands it back without that work. Cache warming means filling the cache on purpose, before traffic arrives, so shoppers get the warm case rather than the cold one.

The cache a warmer fills is the full page cache. In production that should be Varnish. Adobe strongly recommends Varnish and says the built-in full page cache, which writes to the file system or the database, is much slower. In the admin, this is the Page Cache type, tagged FPC, and Flush Cache Storage removes everything in it regardless of tag.

We see the cold case after every release on the stores we support. The deploy finishes, the cache flushes, and the first request to each page carries the full build until the cache fills again. The cold cache vs warm cache question comes down to that first request against every one after it. A warmer is a program that sends those first requests itself.

How a full page cache warmer works in Magento 2

A full page cache warmer works in three steps. It builds a list of URLs from the sitemap, a URL file or page popularity, queues them, and requests each one from cron or a CLI command. Most let you cap concurrent requests, add a delay between them, and choose the store views, currencies and customer groups to warm.

Where the URL list comes from

Most warmers read your sitemap.xml, because it already lists the category, product and CMS URLs you want indexed. Some also accept a file of URLs, so you can add landing pages or leave out whole sections, and some rank pages by visits so the busiest URLs get warmed first.

Warmers come as paid and free Magento extensions, including open-source ones. Our comparison of speed optimization extensions includes the main warmers. A free Magento full page cache extension on GitHub, for example, reads sitemaps or URL files and is meant to be called from deployment scripts. Whichever you pick, the list is the whole job. A page that isn’t on it stays cold until a shopper opens it.

When the warmer runs

A Magento cache warmer runs from cron, like the rest of Magento’s background work, or from a CLI command you call by hand. The useful moment is right after a deploy or a full cache flush, when every page is cold, so most setups call the warmer from the deploy script and let cron keep the queue moving afterwards.

Adobe Commerce on Cloud has a built-in version of this. The post-deploy variables include WARM_UP_PAGES, which lists the pages to preload once the deploy finishes. Its default is index.php alone. You can add categories, CMS pages, products and store pages by pattern, provided the post-deploy hook is configured.

How it limits server load

Every request a warmer sends is a full page build, so the controls on a full page cache warmer for Magento 2 are all about pacing. Most warmers let you set how many requests run at once, add a delay between them, and cap how long a job may run. Some stop the crawl when system load passes a threshold you set. One manual puts the trade-off plainly: more threads finish the crawl sooner and increase the server load. Adobe’s WARM_UP_CONCURRENCY variable does the same job on Commerce Cloud, limiting simultaneous requests to reduce server load.

Store views, currencies and customer groups

Magento doesn’t cache one copy of a URL. It caches one copy per context, and the context travels in the X-Magento-Vary cookie: the store, the selected language and currency, the customer group, and whether the shopper is logged in. Adobe’s public content documentation lists these as the variables that make each cached URL unique.

A warmer only fills the contexts it requests, which is why most let you choose store views, currencies and customer groups. Each one you tick is another pass over the same URLs. The next section adds that up.

What a cache warmer costs your server

A cache warmer costs server time, because every URL it warms is a full uncached page build in PHP. One full pass equals your URLs multiplied by the store views, currencies and customer groups you warm. Magento also purges Varnish when products, categories, prices or promotion rules change, so the warmer keeps crawling the same pages.

Take a store the size of the one in our Expedio benchmark, with around 1,000 categories and 20,000 products. That is about 21,000 URLs before any filters or search terms. Warm them for 2 store views, 1 currency and 3 customer groups, and one full pass is 21,000 × 2 × 1 × 3 = 126,000 page builds.

This is an example, not a measurement, and your own numbers will differ. The shape holds, though: every one of those builds runs in PHP on your own server, competing with real shoppers for the same CPU. A Magento cache warmer doesn’t make a single build cheaper. It decides when the server does the work.

Why a warm cache keeps going cold

Adobe’s cache clearing with Varnish documentation lists the admin tasks that purge Varnish automatically: adding or editing categories, prices, products and promotional pricing rules. It also says that when you clean, flush or refresh the Commerce cache, Varnish purges as well.

So a store that imports prices every morning, or edits promotion rules through the day, empties the pages it just warmed, and the warmer crawls them again. The crawl in the example above isn’t a one-off after each deploy. It repeats as often as your catalog changes.

Some flushes are unavoidable. Sometimes flushing the whole cache storage is the only option, and then every page goes cold at once.

What a cache warmer can’t fix

A cache warmer can’t fix the misses it doesn’t predict. Logged-in customers get one cached copy per customer group, and each group misses until it is warmed. Filter combinations and search terms are each cached on their own, more than a crawl can list. Checkout and account pages are never cached, and purged pages wait for the next visit.

Logged-in customers and B2B customer groups

Magento caches catalog pages for logged-in customers too. The customer group and the logged-in state are part of the X-Magento-Vary context, so the cache key includes them, and each group gets its own copy of every URL. Those copies miss more often than the guest copy for a plain reason: there are more of them, and all of them are empty after a deploy or flush.

If you are working out how to go about prewarming the cache for logged-in users, the answer is per customer group. Some warmers let you pick the groups to warm, so check for that before buying, and remember that pre-warming the cache for all customer groups means one full pass over your URLs for each group. A B2B store with many groups multiplies the crawl again.

Per-customer data such as the cart or wishlist isn’t in the page cache at all. Adobe’s private content documentation explains that the browser fetches it with an AJAX request and keeps it in local storage. And /customer and /checkout URLs bypass the cache in Magento 2.4’s default Varnish configuration, so no warmer touches them.

Filtered category pages and search results

Every filter a shopper can click in layered navigation makes a URL, and filters combine, so a category with a handful of filters has far more filtered pages than plain ones. Magento 2.4 caches each combination as its own entry, and search results too: the default Varnish configuration has no bypass for the search URL, and the search results layout has no block marked uncacheable, so each search term gets its own entry.

These pages are cacheable. They miss far more often than a plain category page, because most entries are still empty when a shopper asks for them. A crawl can’t list every filter combination, and search terms depend on what shoppers type, so a warmer covers only the few it has on its list. For a store where shoppers filter and search their way to products, that is a large share of catalog traffic.

The build itself

A warmer moves the wait to a moment when no shopper is in the queue. The build takes as long as it did before, and every page outside the crawl, or purged since the crawl, still runs the full build in front of a shopper. Shoppers see that wait as slow server response time. That is the part of the problem a warmer can’t reach.

For scale, HTTP Archive’s technology report for September 2026 puts the share of Magento origins with a good time to first byte at 23.0% on mobile and 22.7% on desktop, where good means 800 ms or less at the 75th percentile. A warmer raises the share of cached responses in figures like these. It does nothing for the uncached ones.

Cache warmer vs a faster cold build

A cache warmer hides slow page builds by running them before shoppers arrive. A faster cold build shortens the build itself, so every cache miss costs less, including the ones a crawl doesn’t cover. Warmers suit guest-heavy stores with a predictable set of URLs. Faster builds suit stores with logged-in customers, heavy filtering, search and frequent catalog updates.

The two fixes work on different parts of the same problem.

Expedio is our module for making the cold build itself faster. It changes how Magento builds each page on the server by applying Liquid, the open-source template language created at Shopify, and its core is open source. It works with Magento 2 Open Source, Adobe Commerce and Commerce Cloud, with Luma, Hyvä and custom themes, on any hosting, and it leaves the theme, design, data, admin, catalog, prices, checkout and orders as they are.

In a benchmark on one merchant’s Hyvä store, measured as server response time, 100 category pages opened once from cold took a median of 57 ms with Expedio against 181 ms on stock Magento, 3.2x faster. A full category page went from 655 database queries to 30. The full numbers and method are in the benchmark write-up. Expedio is built into ReadyMage, our Magento hosting, and installs as a module on any other host.

The two can work together. A warmer on a faster build has fewer slow pages to hide, and each request it sends costs the server less.

How to run a cache warmer without slowing the store

To run a cache warmer without slowing the store, warm your busiest pages first, cap concurrent requests and pause the crawl when server load climbs. Start it from the deploy script or post-deploy hook, skip filter and sort parameters, and warm only the customer groups and currencies that bring real traffic.

These cache warming strategies keep the crawl useful and the server free for shoppers.

1. Warm the pages that earn traffic first. Rank URLs by visits and let the long tail fill on its own.
2. Start the warmer from the deploy. Call it from the deploy script, or list your top pages in WARM_UP_PAGES on Adobe Commerce Cloud.
3. Cap concurrent requests and add a delay. More threads finish sooner and load the server harder.
4. Pause the crawl when load climbs. Set a system-load threshold so shoppers always come first.
5. Skip filter, sort and search URLs. Exclude them with pattern rules, because their combinations outnumber any crawl.
6. Warm only the contexts with traffic. Pick the store views, currencies and customer groups that bring real visits.
7. Keep deploys and full flushes away from peak days. A code freeze before big sales keeps the cache warm when it matters.
8. Check the cache hit rate after every change. If misses don’t fall, the warmer is crawling the wrong pages.

Expired pages are a separate case. For those, Varnish’s grace mode already serves the stale copy while it fetches a new one, for 300 seconds by default in Adobe’s setup. A purged page is gone from the cache, so the warmer’s job is the pages emptied by flushes and purges.

Do you need a Magento 2 cache warmer? A decision framework

You need a Magento 2 cache warmer if most traffic is guests on a known set of category and product pages and you flush the cache on deploys. If revenue comes from logged-in customers, filtered pages or search, or the catalog changes all day, make the cold build faster first, then warm only your busiest pages.

Use a cache warmer if:

• You flush the full cache on deploys, and most traffic lands on a known set of category, product and CMS pages.
• Most of your shoppers browse as guests, so one cached copy per URL serves nearly all of them.
• You run few store views, currencies and customer groups, so one full crawl stays short.
• Your server has spare capacity outside peak hours to absorb a crawl after each deploy.
• Your catalog, prices and promotions change a few times a day at most, so warm pages stay warm.

Make the cold build fast instead if:

• A large share of your revenue comes from logged-in or B2B customers, whose pages are cached separately for each group.
• Your shoppers rely on layered navigation filters and site search, which produce more URLs than any crawl can cover.
• You would need to warm many store views, currencies or customer groups, and a full pass takes hours of server time.
• Catalog, price or promotion updates purge Varnish many times a day.
• Your server already runs near capacity at peak, so a crawl would compete with paying shoppers.

Do both if: you deploy often, most traffic is guests, and you also sell to logged-in or B2B customers. Speed up the cold build, then warm your top pages after each deploy.

Frequently asked questions about Magento 2 cache warmers

Does a cache warmer increase server load?

Yes, while it runs. Every URL a warmer requests is a full page build in PHP, the same work a shopper’s first visit would trigger. That is why warmers come with a concurrency limit and a delay between requests, and some pause when system load passes a threshold. Adobe describes its own post-deploy warm-up concurrency setting as a way to reduce server load.

Can you warm the Magento cache for logged-in customers?

Yes, per customer group, if the warmer supports it. Magento caches catalog pages for logged-in shoppers with one copy per context, which includes the customer group, and some warmers let you choose the groups to warm. Per-customer data such as the cart isn’t in the page cache, because Magento loads it in the browser through an AJAX request. Each group you add means another full pass over your URLs.

What is the difference between a cold cache and a warm cache?

A cold cache doesn’t hold the page a shopper asked for, so Magento builds it in PHP, runs the database queries behind it and stores the result. A warm cache already holds the finished page and returns it without running PHP. That is why the first visit to a page after a flush is slower than every visit after it, until the page expires or is purged.

How does Adobe Commerce Cloud warm the cache after a deploy?

Adobe Commerce on Cloud warms the cache in the post-deploy stage. The WARM_UP_PAGES variable in .magento.env.yaml lists the pages to preload, and its default is index.php alone. You can add categories, CMS pages, products and store pages by pattern, and WARM_UP_CONCURRENCY limits simultaneous requests to reduce server load. The post-deploy hook has to be configured for this to run.

How often should a Magento cache warmer run?

Run a cache warmer after every deploy or full cache flush, and on a schedule after that, because Magento purges Varnish whenever products, categories, prices or promotion rules change. Warmers run from cron, and one vendor’s setup guide recommends running cron every one to five minutes so the queue keeps moving. Schedule full crawls outside peak trading hours.

Do you still need a cache warmer if the cold build is fast?

Less, but a light one still helps. A faster cold build cuts what every cache miss costs, including the misses a warmer rarely covers, such as filter combinations, unusual search terms and customer groups it doesn’t warm. A small warmer for your top pages after each deploy then covers the busiest URLs, and each request it sends takes less server time because the build behind it is faster.

Before you install a Magento 2 cache warmer

Before you install a Magento 2 cache warmer, check how many page views the full page cache actually serves and where the misses come from. If most pages already come from the cache and the store still feels slow, look at why a Magento store is slow. If most misses are guests after deploys, a warmer is a quick fix. If they are logged-in customers, filters and search, speed up the cold build, because a crawl covers few of those pages.

Measure that on your own store, by context: guest sessions after a deploy, logged-in sessions, filtered URLs and search results, each on its own. The split tells you which fix you are buying. A warmer is one fix among many, and our guide to speed up Magento puts it in order with the server, database and frontend fixes.

Send us your slowest pages and how often your cache empties, and we'll tell you whether a warmer, a faster cold build or both fits your store.

The post Magento 2 Cache Warmer: Do You Need One, and What It Can’t Fix appeared first on scandiweb.

When a Magento (Adobe Commerce) store gets slow, the extension marketplace is often the first place a team looks, and dozens of modules promise faster pages and better PageSpeed scores. Each Magento speed optimization extension works on a different part of the page load: how the server builds the page, the cache that keeps finished copies of pages ready, or the images, scripts and styles the browser loads afterward. The right one depends on which part is slow on your store.

That part is often the server. In Chrome’s real-user data for September 2026, published by HTTP Archive, only 23% of Magento sites on mobile had a good server response time, meaning the server started sending pages within 0.8 seconds on three out of four visits.

Every extension here is on sale or free today. We read each vendor page or Adobe Commerce Marketplace listing on October 29, 2026, for price, Magento 2.4 support and Hyvä support. One extension per job is usually enough.

Magento speed optimization extensions compared

The best Magento speed optimization extension depends on which part of the page load is slow. Expedio speeds up how the server builds each page. Mirasvit and Magefan warmers keep the full page cache filled. Amasty, Magefan and WeltPixel optimize JavaScript and CSS, Yireo and Mageplaza handle images, and Fastly delivers pages from servers near the shopper.

Prices and versions were read on October 29, 2026.

Prices and versions as listed on each vendor page or Marketplace listing on October 29, 2026. Marketplace prices for Adobe Commerce editions are higher.

The list follows a page request from the server to the shopper’s screen, and each Magento 2 speed optimization extension is placed on the stage it works on.

Which part of your store is slow? Check before you buy

Test your slowest page in Google PageSpeed Insights before you buy an extension. If it reports “Server responded slowly”, the delay happens before the browser receives anything, so the fix belongs on the server or in the cache. If the server responds quickly but the page still loads slowly, look at images, JavaScript and CSS.

PageSpeed Insights, Google’s free page test, runs that check for you. Since Lighthouse 13, it appears under the Document request latency insight, and “Server responded slowly” means the browser waited more than 600 ms for the main request. Google calls a server response of 0.8 seconds or less good and more than 1.8 seconds poor. If yours is in the poor range, see how to reduce server response time. Our guide on how to read Google PageSpeed Insights covers the rest of the report, including the Core Web Vitals: Largest Contentful Paint, the time until the largest image or text block appears, response to taps, and layout shifts.

A theme changes only the browser side. In HTTP Archive’s September 2026 report, 66% of Hyvä sites passed all three Core Web Vitals on mobile, against 45% of Magento sites overall, while 23% of each group had a good server response time. More causes are in our post on why a Magento store is slow.

Server page build: make Magento build each page faster

A server-side speed extension shortens the time Magento spends building a page in PHP before it sends anything. That build runs on every request the full page cache can’t answer, which happens more often on filtered, search and logged-in pages. Expedio works on this layer and keeps your theme, design and data as they are.

1. Expedio by scandiweb

Expedio speeds up how Magento builds each page on the server: the PHP work of running code, querying the database and assembling the HTML before anything is sent. It applies Liquid, the open-source template language created at Shopify, underneath your theme, and the core is open source.

In a benchmark on one merchant’s Hyvä store, measured as server response time, stock Magento took a median of 181 ms to build 100 category pages with all caches empty, and Expedio took 57 ms. A full category page went from 655 database queries to 30. The setup is in the benchmark.

Best for: stores whose pages are slow before any image or script loads, with slow category, search and filtered pages, logged-in or B2B shoppers whose pages miss the cache more often, or a server that slows down at peak traffic.

Key features:

• At least 2x faster page build, and 3x the traffic on the same server before response times start to rise
• Works under Luma, Hyvä and custom themes, and keeps your design, catalog, prices, checkout, orders and data as they are
• Install the core yourself, or ask Ari, scandiweb’s agent for Magento, to install it on a copy of your store for your team to review and release

Price (October 29, 2026): Open Source free, major releases only. Supported €990 a year, with updates, compatibility fixes for Magento, Hyvä and other extensions, and support. Implementation Audit €4,900 the first year, then €990 a year. Done for you €19,900 the first year, then €990 a year, with 2x speed guaranteed by contract.

Works with: Magento 2 Open Source, Adobe Commerce and Adobe Commerce Cloud, on ReadyMage, scandiweb’s Magento hosting, or any other Magento host.

Full page cache and cache warming extensions

A cache warming extension requests your store’s pages before shoppers do, so Magento’s full page cache already holds a finished copy when someone arrives. Our guide to the Magento 2 cache warmer covers which pages a warmer refills and which it misses. It helps after deploys, cache flushes and catalog updates, which empty the cache. Each page it warms is still a full build on your server, so warmers let you limit threads and pause under load.

The Magento full page cache keeps finished copies of pages, and Magento empties them when products, categories, prices or promotion rules change, and whenever the cache is cleaned or flushed. A Magento 2 cache extension of this kind refills it before shoppers arrive.

2. Mirasvit Full Page Cache Warmer

Mirasvit Full Page Cache Warmer is a crawler that requests your pages after the cache empties, so the next shopper gets a stored copy.

Best for: stores that deploy or flush the cache often.

Key features:

• Warming sources from sitemap.xml, a CSV file or visitor behavior
• Rules and priorities by customer group, currency and page type, with presets, custom threads and a system-load threshold
• Detects flushes made outside Magento, such as a Redis or Varnish restart (release 1.11.16)

Price (October 29, 2026): $179 for the first year on the Open Source edition, $108 a year to renew. Commerce editions cost more.

Works with: Magento 2.3 to 2.4.9, Hyvä ready per the vendor. Marketplace version 1.11.16, updated October 29, 2026.

3. Magefan Full Page Cache Warmer

Magefan Full Page Cache Warmer warms the cache automatically or on a schedule, starting with the most visited pages.

Best for: stores with several store views, currencies or customer groups that want to choose which ones to warm.

Key features:

• Priority by page visits, with warmup profiles by store view, customer group and currency
• Presets, plus a setting that stops warming when system load passes a limit
• Exclusions by URL pattern, user agent or country, and reports on CPU use and cache hits

Price (October 29, 2026): €161 one-time, as shown that day, with 365 days of updates and support. Also included in Magefan’s Page Speed Optimizer Extra plan.

Works with: Magento 2.3.0 to 2.4.9, Hyvä, Breeze, Mage-OS and Adobe Commerce Cloud. Version 2.1.5.

JavaScript and CSS: Google PageSpeed optimizer extensions

JavaScript and CSS optimizers change how the browser downloads your store’s code after the HTML arrives. They minify files, defer scripts the page doesn’t need to appear, bundle JavaScript by page type and preload styles. The two all-in-one Google PageSpeed optimizers below also convert images to WebP and lazy load them.

Minify means stripping spaces and comments from code files. Defer means the browser downloads a script without pausing the page and runs it after the page is built. Bundling combines many small script files into a few, and preload tells the browser early which styles it will need. Most Magento page speed optimization on this layer comes down to those four settings. Adobe’s performance best practices call Magento’s built-in minification and bundling fallback alternatives, recommend third-party tools, advise against merging JavaScript and CSS files, and say not to bundle at all on HTTP/2.

4. Amasty Google Page Speed Optimizer Pro

Amasty Google Page Speed Optimizer Pro is one module that minifies and bundles code, converts images to WebP or AVIF, and lazy loads them. Amasty calls it a Magento PageSpeed module.

Best for: stores that want one module for code and image optimization, with a built-in diagnostic that reads PageSpeed results.

Key features:

• JavaScript bundling, defer or async loading, HTML and CSS minification
• AVIF and WebP conversion, compression, lazy loading and image preload
• Back Forward Cache

Price (October 29, 2026): $209 a year on the Community edition, $129 to extend. A free base edition covers lazy loading. Premium $629.

Works with: Magento 2.4.5-p15 to 2.4.9 as listed. Hyvä ready, with the Hyvä package on an active subscription. Image features need JPEG, PNG, GIF and WebP tools on the server. Version 3.10.0.

5. Magefan Google Page Speed Optimizer

Magefan Google Page Speed Optimizer defers and bundles JavaScript, minifies HTML and CSS, lazy loads images, and in higher plans converts images to WebP and warms the cache.

Best for: stores that want to start free and add WebP and cache warming later with one vendor.

Key features:

• JavaScript deferral and bundling, CSS merging and minification
• Image lazy loading
• WebP conversion in Plus, full page cache warming in Extra

Price (October 29, 2026): Basic listed at $0 (regular price $99), Plus $199, Extra $349, one-time, with 365 days of support and updates.

Works with: Magento 2.3.0 to 2.4.9, Hyvä, Breeze, Mage-OS and Adobe Commerce Cloud. Version 2.0.4. Also available through Ari, which installs the free version on a copy of your store.

6. WeltPixel Speed Optimization with Advanced JS Bundling

WeltPixel Advanced JS Bundling builds JavaScript bundles by page type, a shared bundle plus one per page type, moves scripts to the bottom of the page and preloads CSS. In Adobe’s test of this approach, bundling by page type made an empty homepage load twice as fast as native bundling.

Best for: stores on Magento’s default frontend that want Adobe’s recommended bundling approach without building it by hand.

Key features:

• Advanced bundling by page type
• JavaScript moved to the page bottom, CSS preloading, optimization with Terser
• CLI commands for Magento 2.4.8 CSP rules

Price (October 29, 2026): free, MIT license, 12 months of support included.

Works with: Magento 2.4.0 to 2.4.9, Open Source, Commerce and Commerce Cloud. Version 1.16.0, January 7, 2026. Hyvä support isn’t stated.

Magento image optimization extensions

Magento image optimization extensions make product and category images smaller or load them later. WebP converters serve a lighter copy of each JPEG or PNG to browsers that support it, and lazy loading waits to load images below the visible screen until the shopper scrolls. Keep the first visible image out of lazy loading so it appears without delay.

Google’s WebP data puts lossy WebP at 25 to 34% smaller than comparable JPEGs at equal quality, and lossless WebP at 26% smaller than PNG. In a 2026 web.dev case study, Nuvemshop removed lazy loading from the first above-the-fold image, along with other changes, and improved Largest Contentful Paint by 68%. Entries 4 and 5 already convert to WebP and lazy load, so don’t add a second Magento 2 image optimization extension for the same job.

7. Yireo Webp2

Yireo Webp2 converts JPEG and PNG images to WebP and serves both inside a picture tag, so browsers that support WebP get the lighter file and the rest get the original.

Best for: stores that want a Magento 2 WebP extension without a paid suite.

Key features:

• On-the-fly WebP conversion
• Picture tag with the original image as fallback
• Hyvä support built in, GraphQL through a separate module

Price (October 29, 2026): free, open source (OSL-3.0).

Works with: Magento 2.4.6 and later per the GitHub badge. Needs the Yireo_NextGenImages module.

8. Mageplaza Lazy Loading for Magento 2

Mageplaza Lazy Loading for Magento 2 is a Magento 2 lazy load extension that loads images below the visible screen only when the shopper scrolls toward them.

Best for: long category and search pages with many product images.

Key features:

• Category, product, CMS, search and checkout pages, plus related, cross-sell and up-sell blocks
• Blur, low-resolution or custom placeholders, and a threshold to start loading just before an image appears
• Exclusions by URL, CSS class or image name, which keep the first visible image out

Price (October 29, 2026): from $79 (Enterprise $279), free installation, 60-day money-back.

Works with: Magento 2.4.4 to 2.4.8 as listed. Hyvä compatibility on request, free. Version 4.0.6, April 15, 2025.

Other layers: a CDN that serves pages closer to shoppers

A content delivery network (CDN) keeps copies of your pages, images and files on servers around the world, so shoppers far from your hosting get them from a nearby location. On Adobe Commerce on Cloud, Fastly does this through the Fastly CDN module for Magento 2, and Adobe includes it at no additional cost.

Adobe’s Fastly CDN documentation describes it as a Varnish-based service that caches pages, assets and CSS, with image optimization and DDoS protection included.

9. Fastly CDN module for Magento 2

Fastly CDN module for Magento 2 connects Magento’s page cache to Fastly’s network, which keeps copies of pages, images and files on servers near shoppers.

Best for: stores on Adobe Commerce on Cloud, where Fastly is included, and stores with shoppers spread across distant countries.

Key features:

• Edge caching that extends Magento’s Varnish setup
• Image optimization at the edge
• Serve stale content on error, and soft purging

Price (October 29, 2026): the module is free and open source (BSD-3-Clause). Adobe includes the Fastly service with Adobe Commerce on cloud infrastructure at no additional cost.

Works with: Adobe Commerce on Cloud Pro and Starter production environments.

Which Magento speed optimization extension do you need?

Choose the Magento speed optimization extension that matches the slow layer. A slow server response points to the page build, so start with Expedio. Pages that are fast on a repeat visit but slow on the first one point to cache misses and a warmer. A quick server with a slow page points to JavaScript, CSS or image extensions.

Start with Expedio if:

• PageSpeed Insights flags “Document request latency” with “Server responded slowly”.
• Category, search and filtered pages are slow before any image appears.
• Logged-in or B2B customers see slower pages than guests, because their pages miss the cache more often.
• Your server slows down at peak traffic.
• Pages stay slow after every deploy or cache flush.

Add a cache warmer if:

• Pages are fast on a repeat visit and slow on the first.
• Deploys, price imports or promotion changes empty the cache during the day.
• Most of your traffic lands on a known set of category and product pages.

Add a JavaScript and CSS optimizer if:

• The server responds in well under a second, but content takes long to show.
• Your theme loads many separate script files on every page.
• You aren’t running another tool that already bundles or minifies.

Add an image extension if:

• Product and category images are still JPEG or PNG.
• Long category pages load every image at once on mobile.
• Your current optimizer doesn’t already convert to WebP or lazy load.

Add a CDN if:

• You sell in countries far from your hosting.
• You run Adobe Commerce on Cloud, where Fastly is included, and want to check it’s configured.

How to add speed extensions without slowing the store

Install one extension per job, try it on a copy of your store first, and measure the same pages before and after. Two tools that both bundle JavaScript, convert images or lazy load change the same files and can conflict. Flush the cache after installing, as Adobe advises, then compare server response time and page load again.

1. Measure the homepage, a category page and a product page before and after, noting server response time and page load.
2. Install one tool per job, on a copy of the store first.
3. Flush the cache after installing, which Adobe lists as a standing rule, then measure again.

Fewer, well-chosen modules are easier to keep fast, and our guide to the Magento 2 extensions every store needs covers how to spot redundant ones.

Frequently asked questions about Magento speed optimization extensions

What is the best Magento speed optimization extension?

It depends on which part of the page load is slow. For the server’s page build, the pick is Expedio, which makes Magento at least 2x faster without changing the theme or data. For cache misses after deploys, use a warmer such as Mirasvit’s or Magefan’s. For JavaScript, CSS and images, the Google Page Speed Optimizers from Amasty and Magefan cover the most ground in one module.

Is there a free Magento speed optimization extension?

Yes. Expedio’s open-source core is free to download and run yourself. WeltPixel’s Advanced JS Bundling module is free under the MIT license, and Yireo’s Webp2 module is open source. Amasty’s base Google Page Speed Optimizer edition costs $0 and covers lazy loading, and Magefan listed its Basic edition at $0 on October 29, 2026. Paid editions add features and support.

Can two Magento speed extensions conflict?

Yes, when they do the same job. Two modules that both bundle JavaScript, minify CSS, convert images to WebP or lazy load images change the same files and can break pages. Pick one tool per job, test it on a copy of the store, and flush the cache after installing. Extensions that work on different layers, such as a server-side module and an image optimizer, can run side by side.

Do you need a page speed extension if you use Hyvä?

Usually, for the layers a theme doesn’t touch. In HTTP Archive’s September 2026 data, 66% of Hyvä sites passed all three Core Web Vitals on mobile, against 45% of Magento sites overall, yet only 23% of each group had a good server response time. A faster theme leaves the server’s page build as it was, so server-side and image extensions still apply.

Is WebP better than JPEG for Magento product images?

For file size, yes. Google says lossy WebP images are 25 to 34% smaller than comparable JPEG images at equal quality on the SSIM index, and lossless WebP images are 26% smaller than PNGs. Smaller files download faster, which matters most on long category pages. Extensions such as Yireo’s Webp2 keep the original JPEG or PNG as a fallback inside a picture tag.

Should you use Magento’s built-in JavaScript bundling instead of an extension?

Adobe calls Magento’s built-in minification and bundling “fallback alternatives” and recommends third-party tools instead. It also advises against merging JavaScript and CSS files, and says not to merge or bundle at all if your server uses HTTP/2. In Adobe’s own test, bundling by page type made an empty homepage load twice as fast as native bundling.

Choose a Magento speed optimization extension by the slow layer

A Magento speed optimization extension works only on the layer it was built for. Measure first, then fix the slowest layer: Expedio for the server page build, a warmer for cache misses after deploys, an all-in-one optimizer for JavaScript and CSS, an image extension for heavy product photos and a CDN for distant shoppers.

Extensions are one part of the work, and our guide on how to speed up Magento puts the server, cache, database and frontend fixes in order. Prices and versions above are what the vendor pages showed on October 29, 2026, so open the vendor page again before you buy. Where a module is free, put it on a copy of the store first, and measure the same pages before and after whatever you install.

Send us the URL of your slowest page, and we'll tell you which layer is holding it back and which fix comes first.

The post The 9 Best Magento Speed Optimization Extensions in 2026 appeared first on scandiweb.

One morning, a merchant wrote to our support team that the Magento (Adobe Commerce) admin had been slow for a couple of days, and asked whether an index needed clearing. It was a reasonable guess. The cause was a large bulk job running in the background, and the admin was back to normal once the job finished. Magento performance issues often work like that. You notice the slowness in one place, and the cause is somewhere else.

Slow server response is also widespread on the platform. In HTTP Archive’s September 2026 data, 23% of Magento sites had a good time to first byte on mobile, against 46% of websites overall. That figure counts origins, so it says nothing about your store in particular. It is a reason to measure before you assume the platform is at fault.

What causes Magento performance issues?

Magento performance issues come from a short list of causes: pages that miss the cache, a cache that isn’t working, stalled cron jobs, bots, heavy extensions, setup mistakes, small servers, a bloated database, a heavy theme, and work running in the admin. The symptom points to the cause, so start from what you see.

Find the row that matches what you see, then read that cause below. These are the twelve causes we meet most in Magento support work, and the last column names who on your side usually owns the fix.

Two checks come before you pick a row. First, time the server response on a page that is almost always cached, such as the homepage while logged out, and on one that misses more often, such as a filtered category while logged in or a search term nobody has used. The gap between the two tells you whether the server or the browser is losing the time. Our guide on how to audit Magento performance turns that check into a routine for every page type. Second, list what changed in the last few weeks: deploys, modules, upgrades, traffic. Use field data where you have it, and our guide on how to read PageSpeed Insights explains why one lab score can mislead.

Is your Magento 2 site slow on only some pages?

If the homepage loads quickly but logged-in, filtered, search, or deeper category pages are slow, those pages are missing the cache, and each miss exposes a slow page build. A cache hit comes back from memory. A miss makes Magento build the page in PHP, and that build is where the time goes.

Two causes produce this pattern. The first is a page build that is too slow to survive without the cache. The second is a cache that fails to serve pages it should.

1. Pages that miss the cache take too long to build

Logged-in, filtered and search pages are cacheable. Magento keeps one copy of a logged-in catalog page per customer group and context, and one copy of a search results page per search term. These pages simply miss far more often than the homepage, and every miss sends the request to PHP.

Adobe’s public content documentation lists what goes into the cache key: customer group, selected language, selected store, selected currency, and whether the customer is logged in. Each combination is a separate copy of the page. Filter combinations from layered navigation multiply the copies again, a new search term has no copy yet, and page 2 and onward of a category are visited far less than page 1. Right after a deploy or a flush, everything misses.

In our support work, slow pagination and a slow catalog for logged-in customers are the two most common forms of this. Each miss makes Magento run the layout, render every block through its template, and query a database that spreads one product across many tables.

There are two fixes. Cut the number of variants, for example by merging customer groups that share the same prices and keeping filter combinations out of crawl paths. Or make the build itself faster.

Expedio is scandiweb’s open-source module that does this for Magento 2: it speeds up how Magento builds each page on the server, at least 2x, under Luma, Hyvä or a custom theme. It applies Liquid, the open-source template language created at Shopify, and runs on Magento Open Source, Adobe Commerce and Commerce Cloud, on any hosting, with ReadyMage shipping it built in. In a benchmark on one merchant’s Hyvä store, measured as server response time, category pages built with all caches empty took a median of 57 ms with Expedio instead of 181 ms, and a full category page ran 30 database queries instead of 655. The full method and numbers are in the Expedio benchmark.

Who fixes it: a Magento developer.

2. The full page cache isn’t serving pages it should

Load the same category URL twice while logged out. If the second load is as slow as the first, that page isn’t coming from the cache at all. The most common cause we find is a block marked cacheable="false" in a custom or third-party layout file. Adobe’s knowledge base article on non-cacheable pages spells out the effect: one uncacheable block makes the entire page uncacheable, so every visitor waits for the build every time. Compare, cart and checkout are uncacheable on purpose. A catalog page should never be, and this is worth checking on any slow store.

The other cause is the built-in file or database cache in place of Varnish, which Adobe describes as much slower. Only /customer and /checkout pages and POST requests are meant to bypass the Magento full page cache.

Fix: run Varnish (Fastly on Commerce Cloud), search the layout XML for cacheable="false" outside cart, checkout and compare, and move that block to private content. Our guide to the Magento full page cache shows how to check which pages miss it. Who fixes it: a Magento developer.

Why did my Magento site suddenly get slow?

A Magento site that was fine last month and is slow now has usually changed somewhere. The common triggers are an empty cache after a deploy or flush, a stopped cron job, a wave of bots, and a new extension, integration, or upgrade. List what changed in the last few weeks before anyone touches the server.

When a Magento site is very slow all of a sudden, the cause is usually one of the four below. Each leaves a trace somewhere: a deploy log, a cron log, a server log, or a module that wasn’t installed last month.

3. A deploy or cache flush left the cache empty

Magento has two flush buttons, and they do different things. Adobe’s cache management guide explains that Flush Magento Cache removes items according to their tags, while Flush Cache Storage removes everything regardless of tag. After a full flush or a deploy, every page has to be rebuilt by PHP until the cache fills again, and shoppers feel that for as long as it takes.

A cache instance with too little memory causes the same thing all day. Valkey evicts keys once memory use passes the maxmemory limit, so a store whose pages don’t fit never gets fully warm.

Fix: prefer Flush Magento Cache, deploy outside peak hours, give the cache enough memory, and warm the top pages after each deploy. Sometimes flushing the whole cache storage is the only option, and then the timing is what you control. Who fixes it: DevOps or the hosting team.

4. Cron stopped, so indexes fell behind

Adobe’s cron guide lists what depends on cron: reindexing, all Commerce emails, currency rate updates, sitemaps, catalog price rules and newsletters. Adobe states that Commerce will not work as expected if cron is set up badly.

With indexers on Update by Schedule, a stopped cron shows up first as stale prices, stale stock and missing new products. When cron comes back, the backlog of indexing and queued jobs hits the server at once. In our support work that is often the moment a store that was only out of date becomes slow as well.

Check it with bin/magento indexer:status and bin/magento indexer:show-mode, and look at when cron last ran. Our guide to Magento indexer issues and their fixes covers the failure modes. Fix: restart cron, keep the indexers on Update by Schedule, and repair the job that failed instead of reindexing by hand. Who fixes it: DevOps and a developer.

5. Bots and crawlers are using up server capacity

Imperva’s 2025 Bad Bot Report found that automated traffic made up 51% of all web traffic in 2024 and malicious bots 37%. That is one security vendor’s data, and it doesn’t measure server load. What we see in support work is that crawlers go after deep and filtered URLs the cache rarely holds, so each request takes a PHP worker that a shopper could have used.

The symptom is a store that is slow at odd hours with no matching spike in sales. Fix: read the server logs for the top user agents and regions, rate-limit or block the heavy ones at the CDN or WAF, and block regions you don’t sell to. The Crawl-delay line in robots.txt only helps with crawlers that follow it. Google’s robots.txt documentation says Google doesn’t support it, while Anthropic’s ClaudeBot does. Leave Googlebot and Bingbot alone, then retest TTFB once the bot load is off. Who fixes it: the hosting team or DevOps.

6. A new extension or integration adds work to every request

Every extension adds something: observers, plugins, layout blocks, JavaScript. An integration that calls an ERP or a pricing service while the page builds makes every cache miss wait for that call as well. An upgrade can bring both at once, so a store that got slow after a migration or upgrade belongs in this row as much as in row 7.

Fix: profile one slow page on staging with New Relic or Magento’s profiler, disable the suspects one at a time, and remove whatever nobody uses. If you are replacing modules rather than removing them, our list of the best Magento extensions is a starting point. Who fixes it: a Magento developer.

Why is my Magento site running slow on every page?

When every page is slow, cached pages included, and it stays slow at night with little traffic, the problem is in the layers under the store: developer mode or an old PHP version in production, a server that is too small or shared, a database that keeps growing, or cache and sessions crowded into one instance.

Rule out the four causes below before anyone changes a line of code.

7. Production runs in developer mode or on an old PHP version

bin/magento deploy:mode:show answers this in seconds. Adobe’s application modes guide says production mode serves static view files from the cache only, and that default mode is not optimized for production because of the performance cost of static files. A store left in default or developer mode pays that cost on every request.

PHP matters too. Adobe lists PHP 8.5 for 2.4.9 and PHP 8.4 or 8.3 for 2.4.8. Run the version Adobe lists for your release and size OPcache for the whole codebase. Of all the Magento 2 performance issues in this list, this one is the cheapest to check. Who fixes it: a Magento developer.

8. The server is undersized or shared

The symptom is a store that is fine at low traffic and slow at peaks, with CPU or memory at its limit. Shared hosting adds other sites’ load to yours. Adobe’s guidance separates the tiers, with Varnish on its own server in front of the web tier.

Fix: dedicated resources, separate tiers for a larger catalog, and autoscaling for peaks, which we describe in server autoscaling in Magento 2. Our managed Magento hosting, ReadyMage, runs on AWS with that tuning done and Expedio built in. More hardware helps only when hardware is the limit, which is why this row comes after the ones above it. Who fixes it: the hosting team.

9. The database has grown and slow queries pile up

Magento’s EAV model spreads one product across many tables, so catalog pages are query-heavy by design. Log and quote tables grow without limit unless someone prunes them. The symptom is slow category and search pages with high database CPU.

Fix: prune the log and quote tables, size the InnoDB buffer pool to the server’s memory, watch the slow query log, and match MySQL max_connections to the number of PHP threads, as Adobe recommends. Keep catalog search and layered navigation on OpenSearch or Elasticsearch, which Adobe has required since 2.4.4. Who fixes it: a developer or a DBA.

10. Cache and sessions share one instance

The symptom is easy to recognize. A cache flush logs every customer out, and login, add to cart and checkout slow down together at busy times. Slow add to cart at peak hours is the complaint that usually brings this one to light.

Adobe’s Valkey and Redis best practices say that separating the cache from the sessions reduces contention between cache and session traffic, and Adobe’s setup guide calls for a dedicated instance each for sessions, the Commerce cache and the full page cache. On 2.4.9, and on 2.4.8 patches after p4, use Valkey, since Redis cache isn’t supported there. Who fixes it: DevOps or the hosting team.

Why does a Magento page feel slow when the server is fast?

If the server answers quickly but the page appears late or reacts slowly to taps, the time is going in the shopper’s browser. On Magento that usually means the Luma theme’s JavaScript, large images, and third-party tags. A lighter theme such as Hyvä fixes this half of the load, and server-side work leaves it as it is.

This kind of Magento slow performance is measured in the browser, and the fix is in the theme.

11. The theme makes the browser do too much

Google’s Web Vitals thresholds are the measure here: LCP within 2.5 seconds, INP of 200 ms or less, and CLS of 0.1 or less, at the 75th percentile of visits. On Luma, the main costs are dozens of RequireJS modules, large images, and third-party tags.

Hyvä rebuilds the frontend with far less JavaScript, and our guide on how to work with Hyvä covers what the move involves. If a rebuild isn’t on the table, trim Luma instead: bundle JS by page type and never merge it, serve WebP with width and height set, lazy-load images below the fold only, and audit every third-party tag.

One check before you start. If the store already moved to Hyvä and is still slow, the remaining time is on the server, which points back to cause 1. Who fixes it: a frontend developer.

Why is the Magento admin slow?

A slow Magento admin usually comes from work the admin starts or waits on: indexers that rebuild on every save, product grids that load a large catalog, bulk imports and mass updates during office hours, and extensions that load on every admin page. Storefront fixes, Expedio included, don’t change the admin.

12. Indexing, grids and bulk jobs slow down the admin

Magento 2 admin loading slow usually traces back to work the admin itself starts. With indexers on Update on Save, every change in the admin triggers a reindex, so saving a product can stall while the indexer runs. Adobe’s configuration best practices recommend Update on Schedule instead.

Large catalogs make the product grid heavy, and Adobe recommends limiting the number of products in the grid. Two more settings on that page move work to the background: asynchronous email notifications and asynchronous order grid indexing. Bulk imports, mass updates and content jobs belong outside office hours, which is what the merchant in our intro found out the slow way. Extensions that load on every admin page add up as well.

The admin panel and the storefront are different workloads, so a fast storefront tells you nothing about a slow backend. Expedio doesn’t change the admin, and neither do Hyvä or the page cache. Who fixes it: a developer, plus the store admin who schedules the bulk jobs.

Frequently asked questions about Magento performance issues

Why is Magento so slow?

Magento does a lot of work to build each page. It runs the layout, renders every block through its template, and queries a database that spreads each product across many tables. A full page cache hides that work whenever it already holds the page. When it misses, or an extension adds to the build, shoppers wait. On well-tuned hosting stock Magento answers quickly, so most slowness comes from setup, extensions, and hosting.

Why is my Magento store still slow after moving to Hyvä?

Hyvä speeds up the browser side of a page load and leaves server response time where it was. In HTTP Archive’s September 2026 data, 66% of Hyvä sites passed all three Core Web Vitals on mobile, against 45% of all Magento sites, yet both had the same 23% share of good time to first byte. If the store is still slow after Hyvä, measure server response on pages that miss the cache.

Can bots and AI crawlers slow down a Magento store?

Yes. Crawlers often request pages the cache doesn’t hold, so each request makes Magento build a page in PHP and ties up a worker that a shopper could have used. Imperva’s 2025 Bad Bot Report found that automated traffic made up 51% of all web traffic in 2024. Check server logs for the busiest user agents, rate-limit or block heavy crawlers at the CDN, and use robots.txt for the ones that follow it.

How can I tell if the server is making my Magento site slow?

Measure time to first byte (TTFB), the wait before the first byte of the page arrives. Google’s guidance calls 0.8 seconds or less good and more than 1.8 seconds poor. Test pages that miss the cache more often, such as a filtered category page while logged in, or a new search term. If TTFB is high there and low on the cached homepage, the server’s page build is the bottleneck. Our guide to reducing server response time covers each fix.

Will a bigger server fix a slow Magento site?

Only when the server is the constraint, for example when the store slows down at peaks while CPU or memory runs at its limit. More hardware lets more pages build at the same time. It doesn’t make each page build faster, so a cache miss that is slow at night stays slow. Making the build faster helps with both. Expedio, for example, lets the same server handle 3x the traffic before response times start to rise.

What should I check first when my Magento site is slow?

Start with the checks that take minutes. Run bin/magento deploy:mode:show to confirm the store is in production mode, run bin/magento indexer:status and check that cron is running, and compare TTFB on a cached page with a filtered or logged-in page. Then list the deploys, new modules and upgrades from the last few weeks, and check the server logs for crawler traffic.

Fixing Magento performance issues starts with the symptom

Magento performance issues are quicker to fix once you know which kind you have. Start from the symptom, check what changed, and separate server time from browser time before anyone buys hardware or rebuilds a theme.

Slow on some pages only points to causes 1 and 2. A sudden change points to causes 3 to 6. Slow everywhere, all day, points to causes 7 to 10. A fast server with a page that appears late is cause 11, and a slow admin with a fine storefront is cause 12. Most stores match one or two rows, and a fix aimed at the wrong row costs money without moving the numbers.

Once you know the cause, our guide on how to speed up Magento lists all 15 fixes in the order we apply them, from the server to the browser.

If your store matches more than one row, tell us what you're seeing and we'll help you work out which cause to fix first.

The post Why Is My Magento Site So Slow? 12 Causes and How to Fix Each appeared first on scandiweb.

Magento (Adobe Commerce) builds every page from scratch: it runs PHP code, queries the database and assembles the HTML, and all of that takes time. The Magento full page cache saves a finished copy of each page and hands that copy to the next shopper, so Magento can skip the build.

Most stores keep that cache in Varnish, a caching server placed in front of Magento. Varnish answers repeat requests itself, so they never reach Magento at all, and Adobe strongly recommends it for live stores.

A saved copy only helps when one exists for that exact page and that kind of visitor, and on a busy store more requests miss it than most teams expect. Slow catalog pages for logged-in customers and slow category pagination both came up in Magento support requests we handled over the past year, and both trace back to how the cache works.

What is the Magento full page cache?

The Magento full page cache stores the finished HTML of a page so the next visitor with the same context gets it without Magento building the page again. It holds category, product and CMS pages, keyed by URL and context, for guests and logged-in shoppers alike. Cart, checkout and account pages are always built fresh.

The rest of Magento caching stores smaller pieces, such as merged configuration. The admin grid lists this one as Page Cache.

How Magento cache works on a single request

A shopper requests a category URL. Varnish, or the built-in cache, builds a key from that URL and a hash of the HTTP context: customer group, store, language, currency and whether the shopper is logged in. Magento carries that context in the X-Magento-Vary cookie, and Adobe’s page on HTTP context variables lists the full set.

If a saved page matches the key, the cache returns its HTML and Magento does not run. If nothing matches, the request goes to Magento, which builds the page in PHP: it loads the layout, renders each block and runs the database queries behind them. The finished HTML is saved with its cache tags and a TTL, then returned. The next visitor with the same URL and context gets the saved copy.

Only GET and HEAD requests can be cached. A form post goes to PHP every time.

Public and private content: hole punching in Magento 2

Everyone in the same context gets the same cached HTML, so Magento keeps personal data out of it. Public content, the page itself, is stored server side in the cache. Private content such as the customer name, cart, wishlist and address is stored client side and loads in the browser after the page arrives, from customer-data sections. A POST or PUT request invalidates those sections, so the cart updates after an add to cart without touching the cached page.

With Varnish, a block can also carry its own TTL. The top menu in the default theme is marked ttl="3600", so Varnish can cache it apart from the page through ESI and refresh it on its own schedule.

Adobe warns against adding a context variable per user. Every context variable is part of the cache key, so a per-user variable gives each user a separate copy of every page, and the cache stops sharing anything.

Magento full page cache vs Varnish

Magento’s built-in full page cache is a PHP reverse proxy that stores pages in the file system, the database or Valkey/Redis, so every hit still runs PHP. Varnish is a separate caching server in front of the web server, and a hit never reaches the web server. Adobe strongly recommends Varnish in production. Commerce Cloud uses Fastly.

The table shows where the two options differ.

The built-in option is fine on a laptop or a staging server. Production gets Varnish: a repeat request for a cacheable page costs no PHP, database or web server time, and Adobe’s Varnish configuration page calls the built-in cache much slower.

Magento Varnish is a separate HTTP cache that Magento purges by tag whenever it cleans, flushes or refreshes its own cache. The Caching Application setting is the only switch between the two.

Where Fastly fits on Adobe Commerce Cloud

On Adobe Commerce Cloud, full page caching uses Fastly instead of Varnish, so there is no Varnish to install or configure. The cache key and the private-content rules in this article still apply, because Magento sets the headers and the context cookie in the same way.

Magento cache management: cache types, clean and flush

Magento cache management happens in System > Tools > Cache Management or with bin/magento cache commands. The admin lists every cache type, such as Configuration, Layouts, Blocks HTML output and Page Cache, with its status. Refresh any type marked invalidated, clean caches after code or configuration changes, and flush the whole storage only when cleaning fails.

The cache types that matter for page speed

Five types decide most of what a shopper waits for in Magento 2 cache management.

The Cache Management grid lists more types than these, and the exact set depends on the edition and the modules installed. Adobe’s Cache Management page describes each one.

Clean vs flush: which one to run

The two buttons at the top of the grid do different things. Flush Magento Cache runs cache:clean: it removes items by their Commerce tag, from enabled types only, and leaves anything else in the storage alone. Flush Cache Storage runs cache:flush: it empties the whole storage, including files that other applications keep in the same place.

Clean after routine changes, such as a template or configuration edit. Flush only when cleaning does not fix the problem, and schedule it off-peak, because Adobe warns that clearing caches at peak can raise the load enough to take the site down until the operation completes. If you need to clear the cache in Magento 2 from the admin, refresh the affected type rather than everything, and read our post on when to flush the whole cache storage before doing it on a live store.

What “One or more of the Cache Types are invalidated” means

The red banner in the admin reads “One or more of the Cache Types are invalidated”, followed by the list of types, and asks you to go to Cache Management and refresh them. It means the stored data for those types may no longer match the database. Catalog changes are the usual cause, because an edit to one entity can affect other pages and invalidate several caches at once. Configuration saves and deploys do the same.

To fix it, open Cache Management, tick the invalidated types, set Actions to Refresh and click Submit, or run bin/magento cache:clean full_page. Reindexing does not require a cache flush, so leave the cache alone when you reindex. If the banner comes back every few minutes, find what keeps invalidating it, such as an import, a cron job or frequent product saves, instead of refreshing all day. Keeping the Magento indexers on Update on Schedule, which Adobe recommends for performance, removes one common cause.

How to enable, disable and configure full page cache in Magento 2

To enable full page cache in Magento 2:

1. Go to System > Tools > Cache Management, select Page Cache, set Actions to Enable and click Submit.
2. Or run bin/magento cache:enable full_page.
3. Under Stores > Settings > Configuration > Advanced > System > Full Page Cache, set Caching Application to Varnish Caching.
4. Save the configuration.

Enable full page cache in the admin

Go to System > Tools > Cache Management, tick Page Cache, set Actions to Enable and click Submit. Then open Stores > Settings > Configuration > Advanced > System > Full Page Cache and set Caching Application to Built-in or Varnish Caching.

If Enable and Disable are missing from the Actions dropdown, the store is in production mode. Since Magento 2.2, production mode allows enabling and disabling cache types from the command line only, so the admin offers Refresh and nothing else.

Enable or disable full page cache from the command line

Run the commands as the file system owner, from the Magento root:

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

cache:status lists every type with 1 for enabled and 0 for disabled. Enabling a type clears it, so expect the first requests after cache:enable to miss. Omitting the type applies the command to all types.

Disable full page cache in Magento 2 only to turn off the cache during development, when every change has to show at once. Never do it on a live store: every request then goes to PHP, and the server carries the full build cost for every page. Adobe’s Manage the cache page lists the remaining options.

Magento full page cache settings worth checking

All of these live under Stores > Settings > Configuration > Advanced > System > Full Page Cache.

Caching Application: Varnish Caching for production. From the CLI, run bin/magento config:set --scope=default --scope-code=0 system/full_page_cache/caching_application 2.

TTL for public content: 86400 seconds by default, the longest a page stays in the cache without a purge.

Varnish Configuration: access list and backend host (both default to localhost), backend port (8080), grace period (300 seconds, how long Varnish may serve an expired copy while Magento builds a fresh one) and handles param size (100, the most layout handles the ESI endpoint processes). Export the VCL from the same screen and install it on the Varnish host. Then set purge hosts with bin/magento setup:config:set --http-cache-hosts so Magento can purge Varnish when its own cache cleans. Varnish 8 is the version for Magento 2.4.9.

If you stay on the built-in cache, give it its own storage. Adobe recommends a dedicated instance each for sessions, the default cache and the full page cache. To use Redis for the full page cache on 2.4.8 and earlier, run bin/magento setup:config:set --page-cache=redis --page-cache-redis-server=127.0.0.1 --page-cache-redis-db=1, with a database number no other cache uses. On 2.4.9, Valkey replaced Redis in the CLI tooling, so use the Valkey options in Adobe’s CLI reference.

What the Magento full page cache can’t serve

The Magento full page cache never serves cart, checkout or customer account pages, POST requests, or any page with a block marked cacheable="false". It can hold filtered category pages, search results and customer-group versions, but each URL and context needs its own entry, so many of them miss. Every miss goes to PHP.

Requests that always skip the cache

Three groups never touch the cache. Cart, checkout and customer account pages: the default Varnish configuration that comes with Magento passes any URL containing /customer or /checkout straight to the backend, and Adobe’s own examples of uncacheable pages are cart, checkout and compare. POST and every other method besides GET and HEAD: the same VCL only caches those two, so an add to cart or a form submit always runs PHP. Any page with one block marked cacheable="false": Adobe’s rule is that one uncacheable block makes the whole page uncacheable, and that attribute often arrives in a third-party module’s layout file rather than your own code.

The first two groups are by design. The third is the one to check, because it can quietly turn a category or CMS page into one that builds in PHP on every request.

Requests the cache can hold but often misses

Four kinds of request are cacheable and still miss often.

The first request after a deploy, flush or TTL expiry. Cleaning, flushing and refreshing the Magento cache all purge Varnish too, and so does editing a category, price, product or promotional pricing rule. After each one, the first shopper on each page waits for the build and the second gets the copy.

Filtered category pages. Each filter combination is its own URL, so it gets its own cache entry, and combinations multiply with every attribute you expose in layered navigation. The default VCL strips gclid, gbraid, gclsrc and utm_ parameters, so an ad click shares the cache with a direct visit. Filter parameters stay in the key because they change the page.

Search results. In Magento 2.4 the default VCL has no bypass for search URLs and the search results layout has no uncacheable block, so results pages are cacheable, one entry per search term. Popular terms hit. Rare terms miss, and a first-time search always does.

Logged-in customers and B2B customer groups. The context hash gives each customer group, store and currency its own copy of every page. A B2B store that puts companies or price lists in separate customer groups fills many small caches rather than one big one, and a buyer in a quiet group gets a miss on pages that guests see from the cache all day.

How to find and fix full page cache misses

To fix Magento full page cache misses:

1. Confirm Page Cache is enabled and set to Varnish.
2. Check the X-Magento-Cache-Debug header for MISS, then HIT.
3. Remove cacheable="false" from catalog and CMS layouts.
4. Stop flushing caches at peak hours.
5. Warm key URLs after deploys.
6. Make the uncached page build faster.

Check whether a page came from the cache

Magento adds its debug headers in developer mode only, so run this on staging or in a short developer-mode window, never on a live production store. Request the page twice with curl -I and read two headers. X-Magento-Cache-Debug shows MISS on the first request and HIT on the second. If the Magento 2 full page cache is not working at all, it shows MISS every time. X-Magento-Cache-Control shows the TTL, for example max-age=86400, public, s-maxage=86400. Adobe’s Verify Varnish configuration page says a cacheable page should load in less than 150 ms when Varnish works, and that var/page_cache should stay empty.

Then test the miss path: log in, open a filtered category URL right after a cache clean, and run a rare search. Compare those timings with field data from PageSpeed Insights and Google’s guide of 0.8 seconds or less for a good TTFB. If a page misses that mark, our guide to reducing server response time covers the fixes. To run the same comparison on every page type, see how to audit Magento performance. If the header says HIT and the page is still slow, the wait is in the browser, in the theme, images or JavaScript, and a frontend such as Hyvä is the place to look.

Fix the misses you can remove

Work through these in order.

1. Remove cacheable="false" from blocks on catalog, product and CMS pages. Move whatever personal data the block showed into private content, so it loads in the browser.
2. Switch production from Built-in to Varnish Caching. A built-in hit still runs PHP.
3. Clean by type instead of flushing, and schedule any flush off-peak.
4. Find what keeps invalidating the cache. Imports, mass product saves and cron jobs that touch the catalog purge pages all day.
5. Keep custom cookies and context variables out of the cache key. Each new variable multiplies the number of copies.
6. Warm the top URLs after each deploy, briefly. A warmer refills the most visited pages so the first shoppers get hits, and it has done its job once the cache is full. Our guide to the Magento 2 cache warmer covers how to run one without slowing the store.

Make the uncached page build faster

Some misses stay. Rare searches, filter combinations and customer groups cannot all be warmed, because there are too many of them and the list changes every day. Our comparison of Magento speed optimization extensions sorts the options by the layer each one speeds up. For those requests, the time Magento takes to build the page is the time the shopper waits, and no cache setting changes it.

Expedio is scandiweb’s software for that part of the request. It speeds up how Magento builds each page on the server by applying Liquid, the open-source template language created at Shopify, and its core is open source. It works on Magento 2 Open Source, Adobe Commerce and Commerce Cloud, with Luma, Hyvä or a custom theme, on any hosting, and it leaves the theme, design, data, admin, catalog, prices, checkout and orders as they are. The page build gets 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, 3.2x faster. At peak traffic, filtered category pages answered 3.0x faster and search results 3.8x faster. The method and caveats are in the Expedio benchmark.

Frequently asked questions about Magento full page cache

Does the Magento full page cache work for logged-in customers?

Yes, for catalog and CMS pages. Magento keys each cached page by URL plus a context hash from the X-Magento-Vary cookie, which covers the customer group, store, currency and whether the shopper is logged in. Personal details such as the name and cart load separately in the browser. Each customer group fills its own copy, so stores with many B2B groups see more misses.

Should I use Varnish or the built-in full page cache in production?

Use Varnish. Adobe strongly recommends Varnish in production and calls the built-in full page cache, whether it writes to the file system or the database, much slower. A Varnish hit is answered without reaching the web server, while the built-in cache still runs PHP for every hit. On Adobe Commerce Cloud, Fastly does the full page caching instead.

How long does Magento keep a page in the full page cache?

For 86,400 seconds, or 24 hours, by default. That is the TTL for public content under Stores > Settings > Configuration > Advanced > System > Full Page Cache. A page can leave the cache sooner: editing a product, category, price or promotional pricing rule purges the related pages, and cleaning or flushing the Magento cache purges Varnish too.

Are search results pages cached in Magento 2?

They can be. In Magento 2.4, the default Varnish configuration does not bypass search URLs, and the search results layout has no uncacheable block. Each search term is a separate URL, though, so only repeated searches find a cached copy. A rare or first-time search misses, and Magento builds the results page in PHP.

Does flushing the Magento cache slow the store down?

For a while, yes. After a flush, PHP has to build every page again until shoppers or a cache warmer refill the cache, so server load and response times rise. Adobe advises scheduling cache flushes for non-peak times. Use cache:clean for routine changes, and keep cache:flush, which empties the whole cache storage, for cases where cleaning does not help.

Do I need a cache warmer if I already run Varnish?

A warmer helps after deploys and flushes, when Varnish starts empty. It requests your most visited URLs so the first shoppers get cached pages. It adds server load while it runs and cannot reach every filter combination, search term or customer group. For those requests, shoppers wait for the uncached page build, so its speed still matters.

Magento full page cache: what to fix first

The Magento full page cache is the first speed fix for any store with real traffic, and the order of work after turning it on matters more than any single setting. Run Varnish in production rather than the built-in cache. Remove the misses you cause yourself: uncacheable blocks that a module added, flushes at peak, imports that invalidate the cache every few minutes. Warm the pages that matter after each deploy. Then look at the requests that will always miss, filtered pages, rare searches and quiet customer groups, and make the uncached build itself faster, because that is the time those shoppers wait.

The full page cache is one layer of the work to speed up Magento, alongside the server, database and frontend.

If the cache is on and logged-in, filtered or search pages are still slow, ask our Magento team to measure which requests miss and what each one costs your store.

The post Magento Full Page Cache: How It Works, What It Can’t Cache, and How to Fix Misses appeared first on scandiweb.

If your team is still merging features in late October and someone has just asked when the code freeze starts, the answer for Black Friday 2026 is: new features stop on Monday, November 2, and the last planned deployment goes out on Friday, November 13. Black Friday falls on November 27 and Cyber Monday on November 30. Count back the time you need to load test, fix what breaks, and test again, and the window for risky changes closes in early November.

The outage you’re trying to prevent rarely comes from a big release. One of our support clients launched a large campaign on a Friday, traffic climbed, and the whole site went down. Restarts didn’t help. The cause was a product label rule meant to cover the whole catalog except five products, set up by selecting every brand, and it made the platform fetch items in a loop. Nobody had deployed code that day.

That’s why this guide treats Black Friday readiness as three engineering jobs: a code freeze that also covers configuration, a load test with a target you can defend, and an incident plan with named people on call. Marketing, merchandising, and promo planning are covered in our Black Friday and Cyber Monday checklist.

What is a code freeze, and what should it cover?

A code freeze is a period when a team stops deploying changes to production, so the live system stays in a known, tested state. For an online store before Black Friday, a code freeze should cover more than application code: configuration, extension and app updates, infrastructure changes, tracking scripts, and price or promotion rules can all take a store down, and none of them needs a developer to deploy.

Software teams use the term in two ways. Before a release, a code freeze means no new features, only bug fixes. Before a peak, it means no changes to production at all unless an agreed process approves them. Some teams call the second one a change freeze, which is the more accurate name for eCommerce, because outages like the one above start with changes that never go through a code review.

The freeze also protects your test results. A load test only describes the store you tested. Every change after it, even a small one, makes the result less true.

What the freeze allows, and what it blocks

A freeze that blocks everything gets ignored by the third day. Agree in writing which changes are allowed, who approves them, and how they’re tested.

Tag manager containers belong on the blocked list. A new marketing pixel is code running in every shopper’s browser, and a slow third-party script can hold up the checkout as effectively as a bad deploy.

When should the code freeze start for Black Friday 2026?

For Black Friday 2026, start the feature freeze on Monday, November 2, and allow no major deployments after Friday, November 13, two weeks before Black Friday. That leaves two weeks for load testing and fixes before the strict freeze, and two weeks of stable production before the peak. Keep the freeze in place through Cyber Monday, November 30, and lift it no earlier than Tuesday, December 1.

These dates match what our team has seen work for years. In a scandiweb Black Friday panel, Glebs Vrevskis described the usual pattern: “A common thing we see is code freeze starting from the first days of November, with no new features being released.” Reinis Groskops added that “the latest time to do any major deployments is probably 2 weeks before Black Friday.” The full Black Friday Q&A with our team covers the rest of their advice.

Two dates in the table are easy to miss. If you’re on Adobe Commerce on cloud infrastructure, Adobe recommends requesting a temporary compute upsize at least 10 business days before a major promotion, and finishing all patching before the code freeze. Promotions don’t count as emergencies, and Adobe notes that capacity during Black Friday and Cyber Monday is limited, so book early. If you’re still on a release line close to end of support, check our Magento end-of-life guide before the freeze, because a patch you can’t apply in November waits until December.

The other date is November 25. Our support team recommends building price and promotion rules on staging, testing them there, and switching them on the evening before the sale, without a customer email going out at the same moment. On high-load stores, that gives the platform a night to reindex before the traffic arrives, and any problem shows up while there’s still time to fix it. It’s the lesson from the outage in the introduction: once the rule was rebuilt to exclude five SKUs, it applied in two to three minutes instead of taking the site down for about an hour, and the fix was worth $500,000 in extra sales for that client.

Read more: How scandiweb Support Saved a Client’s Sales Event

If your sales start earlier, as many now do, move the whole calendar back by the same number of days. Date the freeze from the first day of heavy traffic, whatever the banner says.

Black Friday load testing: targets, scenarios, and pass criteria

eCommerce load testing for Black Friday means simulating your expected peak traffic, measured at the busiest minute, on an environment sized like production, and checking that shoppers can still search, add to cart, and pay within agreed response times. Set the target from your own data, script the full buying journey including checkout, and run at least two rounds with fixes in between.

Can the site take 5× traffic?

It depends on what the 5 multiplies. Five times an average day is often below a real Black Friday peak. On one Black Friday we supported, visits were up 10,955% on an average day, and concurrent visitors went from a couple of hundred to more than 17,000 as the first campaigns went out.

Build the target from numbers you already have:

1. Find last year’s peak minute. Take the busiest hour from GA4 or your server logs, then look for the minute-level spikes inside it. Email sends and campaign launches create bursts that an hourly average hides.
2. Apply this year’s forecast. Multiply by the growth the business expects and add any new traffic sources, such as a bigger email list or paid budget.
3. Translate it into load. Express the target as concurrent sessions, page requests per second, and orders per minute. Orders per minute is the number that matters most, because checkout is the most expensive journey to serve.
4. Add headroom. Test at the forecast peak, then at double it, then keep raising the load until something breaks, so you know where the ceiling is and what fails first.

Black Friday traffic is also different from normal traffic. Most days, shoppers browse cached category pages. After the last deploy before the freeze, warm the cache for your top pages so peak traffic doesn’t start on cold ones. On Black Friday, they add to cart and check out, and those pages aren’t cached, so the same number of visitors puts far more load on the application and the database.

Which scenarios to test

A test that hammers the homepage measures your CDN, and not much else. Script the journeys that make money and the background jobs that run at the same time:

Point payments at a sandbox or a stub. A load test that sends thousands of real authorizations to your payment provider may trip its fraud checks, and nobody wants to explain that on November 20.

Pass criteria that make the result useful

Agree the pass criteria before the first run, so the result is a clear pass or fail. The thresholds below are a starting point to adapt, not a standard:

The last row is the one teams forget. On the Black Friday above, the servers held, but orders arrived faster than the order queue could process them, and confirmation emails would have been delayed by days. The fix was a script that moved orders into separate batches on a dedicated instance. A queue-depth check in the load test would have found it earlier.

Read more: Scaling Up to Accommodate a 40000% Increase in Sales

Where to run the load test

Run the main rounds on an environment with the same size, configuration, and CDN setup as production. A staging server with half the CPU tells you little about Black Friday.

How you test depends on the platform:

• Adobe Commerce on cloud: test on a production-sized environment, watch the results in New Relic, and request the temporary upsize you need for the peak. Adobe’s checklist also covers read replicas, indexers set to Update on Schedule, and asynchronous order processing.
• Self-hosted Magento or headless: you own every layer, so the test has to cover the web servers, database, cache, search engine, message queue, and CDN. Agree any test against production with your host first, and run it at night.
• Shopify and Shopify Plus: Shopify runs and scales the platform, so your test surface is everything you added, such as a headless storefront, custom apps, checkout extensions, and the middleware that connects Shopify to your ERP. Ask Shopify before you point a load generator at the live storefront.

If the test exposes a slow storefront, our guide to speeding up Magento and Shopify performance playbook cover the usual fixes. For drops and limited releases where demand can exceed any capacity you’d buy, a virtual waiting room keeps checkout working for the shoppers already inside.

What to do when the test finds the ceiling

The ceiling is the traffic level where response times climb and errors start. You can move it before Black Friday in two ways: add capacity, so more servers share the work, or make each request cheaper, so the same servers handle more shoppers.

Adding capacity is the quicker lever on most hosting. On Shopify, the platform handles this part for you. On Adobe Commerce on cloud, it is the temporary upsize in the timeline above. On self-hosted Magento, it means more web servers behind the load balancer, and our guide to server autoscaling in Magento 2 explains how to add them automatically. Extra servers cost money for as long as they run, and the database still has to keep up with all of them.

Making each request cheaper raises the ceiling without new hardware. Many Black Friday requests reach Magento uncached, such as filtered category pages, searches and the first visits after a cache flush, and Magento builds each of those pages on the server. Expedio makes that page build at least 2x faster, so the same servers handle 3x the traffic before response times start to rise. The Expedio benchmark shows how we measured it on one merchant’s Hyvä store.

Treat Expedio like any other release. It installs as a module without changing your theme or data, but it still needs a load test, so put it in before the strict freeze on November 13. If that’s too tight, plan it for the next peak.

The incident plan: runbook, roles, and on-call rotation

An eCommerce incident plan for Black Friday is a short document that says who is on call, how an incident is declared, who decides, and what the first action is for each likely failure. It should name people, list phone numbers for every outside provider, define severity levels, and include a tested rollback, so that at 9 p.m. on Black Friday nobody has to work out the process while the checkout is down.

The order of steps matters more than the detail. During an incident, restore sales first, through a rollback, a disabled extension, or a switched payment method. Find the root cause afterward.

Roles to name before the peak

Each role needs a named person and a backup for every shift:

• Incident lead: declares the incident, sets the severity, and keeps the timeline. This person coordinates and doesn’t debug.
• On-call developer: investigates and applies the fix or rollback.
• Infrastructure or hosting contact: scales, restarts, or fails over servers, and talks to the host.
• Business owner: decides on trade-offs, such as pausing a campaign email or switching off a payment method.
• Communications: posts updates to the team every 30 minutes and decides what customers see, such as a site banner.

On-call rotation from Thanksgiving to Cyber Monday

Write the on-call rotation down, with names, shifts, and phone numbers, and keep a copy outside Slack, because the person you need may be offline. For the peak weekend, plan for 24/7 cover with handovers at fixed times, a second person on call for severity 1 incidents, and no one on call for more than 12 hours in a row.

List the outside contacts in the runbook too: hosting, CDN, payment provider, ERP and warehouse integrations, search, and your agency, each with an emergency number and the account ID they’ll ask for. If you’re agreeing response times with an agency for the first time, our guide to support SLA tiers and 24/7 cover explains what to ask for.

Playbooks for the failures you can predict

Most Black Friday website crashes follow a few patterns. Write a first action for each one before the peak:

Each playbook needs a kill switch: a configuration flag or admin setting that turns the risky feature off without a deploy. Test every one of them during rehearsal week.

What to watch on the dashboard

Put the measures that show lost revenue on one screen, compared with the forecast for that hour:

• Orders per minute against the forecast
• Payment success rate by method
• Checkout and cart error rate
• Server response time and error rate
• Queue depth for orders, emails, and stock updates
• Purchase events arriving in GA4 and your ad platforms

The last line catches a quiet failure. If purchase events stop arriving, the ad platforms keep spending on the busiest days of the year with no conversion data. If your tracking runs through a server-side tracking setup, add the server container’s error rate to the same screen.

Practice the plan once before it’s needed. In rehearsal week, simulate one incident, such as a failed payment provider on staging, and time how long it takes from the alert to the workaround.

Test orders on production during peak

Yes, you can place test orders on production during the peak, and you should, as long as they follow agreed rules. A small number of real test orders each morning of the peak and after every approved change is the most direct proof that checkout, payment, stock, and order export still work end to end. Agree who places them, how they’re marked, and how they’re cancelled and refunded.

Mark every test order clearly, for example with a test customer email and an order note, and tell the warehouse and finance teams which orders to ignore. Exclude them from reporting, or your peak-day numbers will be slightly wrong in every dashboard.

FAQ about the Black Friday code freeze

What is a code freeze?

A code freeze is a set period when no changes are deployed to a production system, so it stays in a tested, known state. Before Black Friday, eCommerce teams use a code freeze to protect the store during the peak. A good one also covers configuration, extension updates, tag manager changes, and infrastructure, with an emergency process for security fixes.

When should the code freeze start for Black Friday?

For Black Friday 2026, on November 27, start a feature freeze on November 2 and make the last planned deployment on November 13, two weeks before the peak. Use the time in between for load testing and fixes. If your sales start earlier in November, move each date back by the same number of days.

How long should a Black Friday code freeze last?

Most stores keep the strict freeze for about two to three weeks: from two weeks before Black Friday until the day after Cyber Monday. For 2026, that means November 13 to December 1. Stores with heavy December trade often keep a lighter freeze until their last Christmas delivery date.

Can we deploy a fix during the code freeze?

Yes, through an emergency change process. Security patches (such as the October 2026 PHP2Shell fix) and fixes for bugs that hurt sales can go live during the freeze if they’re tested on staging, approved by a named person, deployed at a quiet hour, and have a rollback ready. Everything else waits until the freeze lifts.

Can the site take 5× traffic?

Only a load test can answer that, and only once you define what 5× means. Base the target on last year’s busiest minute, multiplied by this year’s forecast, then test at that level, at double it, and up to the break point. Five times an average day is often less than a real Black Friday peak.

Should we load test on production?

Run the main load tests on an environment that matches production in size and configuration. Test production itself only with your hosting provider’s agreement, at a low-traffic hour, with payments pointed at a sandbox. On Shopify, check with Shopify before running load against the live storefront.

Can we place test orders on production?

Yes, with rules. Place a few real test orders each morning of the peak and after any approved change, using a small real payment you cancel and refund, or a hidden test product. Mark the orders clearly, tell the warehouse and finance teams, and exclude them from reporting. Don’t switch payment test modes on in a live store.

Who should be on call during Black Friday?

At minimum, an incident lead, an on-call developer, a hosting or infrastructure contact, and a business owner who can pause campaigns or switch payment methods. Cover the full Thanksgiving to Cyber Monday window around the clock, name a backup for each shift, and keep phone numbers for every outside provider in the runbook.

Plan the code freeze this week

A Black Friday code freeze works when it starts from the load-testing plan, covers configuration as well as code, and ends with a team that knows who answers the phone. For 2026, that means locking scope this week, testing from late October, freezing features on November 2, and keeping production stable from November 13 through Cyber Monday. Write the runbook now, while there’s time to rehearse it.

Not sure your store will hold at the peak? Talk to our team about load testing and on-call cover before the freeze starts.

The post Black Friday Code Freeze: 2026 Timeline, Load Testing, and Incident Plan appeared first on scandiweb.

When a buyer asks ChatGPT, Gemini or Perplexity which bank, airline or pharmacy to choose, the answer names a short list of brands, and the order of that list decides who gets chosen. Knowing where your brand stands in those answers is the first step to being recommended more often.

To see where Baltic brands stand, we built the Baltic AI brand ranking. We asked the three assistants 3,419 buyer questions over a month and scored 5,548 companies in 113 industries across Latvia, Estonia and Lithuania, using AnswerRank. Lina Ivanova, our Head of Traffic Acquisition, presented the results at Baltic Brand Forum 2026 in Riga and announced the winners on the main stage.

Banks, an airline, a bookstore and a fuel retailer are among this year’s winners and finalists, and one brand came out on top in three of the four rankings.

The top 10 most AI recommended brands in the Baltics

Circle K leads the Baltic list with a score of 92.6, followed by Swedbank at 88.1 and Revolut at 87.8. The Baltic list only includes brands AI names in all three countries. A company that ChatGPT recommends in Latvia alone appears in the Latvian ranking instead. Two banks, a fuel retailer, a car rental company and an airline make up the top five.

DPD has no Lithuania score in the published table, so its LT cell shows a dash.

The list continues past these ten, and every industry has its own page with results per country. You can see the full Baltic AI Brand Ranking and search it for any company.

Winners and finalists in Latvia, Estonia and Lithuania

Circle K won in Latvia and Lithuania. Rahva Raamat, a bookstore, won in Estonia with 93.5, the highest score among the four winners. The winner of each ranking is the brand ChatGPT, Gemini and Perplexity recommend most, and the finalists hold places 2 to 5. The country lists also include brands AI names in only one or two countries, so the finalists differ from the Baltic top 10.

Latvia

Circle K won Latvia with 91.5. The finalists follow.

• 2nd place: Jānis Roze, Bookstore, 90.2
• 3rd place: Swedbank, Banking, 89.8
• 4th place: Stockmann, Department Store, 89.5
• 5th place: Tet, IPTV, 89.2

Estonia

Rahva Raamat won Estonia with 93.5. The finalists follow.

• 2nd place: Circle K, Fuel Retail, 93.3
• 3rd place: DPD, Parcel Delivery, 90.9
• 4th place: Benu, Pharmacy, 89.7
• 5th place: Selver, Online Grocery Delivery, 89.4

Lithuania

Circle K won Lithuania with 93.2. The finalists follow.

• 2nd place: Revolut, Digital Banking, 91.6
• 3rd place: Pigu, eCommerce Platform, 91.1
• 4th place: Maxima, Grocery / Supermarket, 90.7
• 5th place: Verslo Žinios, Business News, 90.6

Two things stand out in the country results. Circle K won three of the four rankings and finished second in Estonia, 0.2 points behind Rahva Raamat. Bookstores also do well: Rahva Raamat won Estonia, Jānis Roze is second in Latvia and Pegasas leads the Lithuanian bookstore category with 86.5. You can see all winners and finalists, including the company AI names first in each of the 113 industries, on the winners page.

How the Baltic AI Brand Ranking was measured

We ran the study in AnswerRank, our AI search monitoring tool. Over a month, AnswerRank put the same buyer questions to ChatGPT, Gemini and Perplexity for each industry in Latvia, Estonia and Lithuania, 3,419 questions across 113 industries, and recorded every company named in the answers. For each company it tracks how often the answers mention it, how they describe it and where in the answer it appears. A brand only appears in the ranking if AI named it, and the questions behind each industry are listed on that industry’s page of the ranking.

Three measures in one score

Each company gets one score out of 100, built from three measures.

The ranking is independent and built by scandiweb. Baltic Brand Forum does not operate the ranking, and it is separate from the forum’s own Baltic Brand Awards, which are based on Norstat’s Brand Capital research.

Why AI recommendations matter for your brand

When a buyer asks an assistant which bank or pharmacy to use, the answer is a short list, and the order of that list decides who gets seen. Across our industry rankings, the brand named first appears in 67% of answers on average. The brand in fifth place appears in 22%. First place is close to the default answer, while fifth place is an occasional mention.

The ranking page breaks results down by industry and by country, and the same question often gets a different answer in each market. Maxima is the grocery chain AI names first in Latvia and Lithuania, while Prisma leads in Estonia. In parcel delivery, Omniva leads Latvia, DPD leads Estonia and Venipak leads Lithuania. A brand that is well placed in one country needs its own check in the other two.

Visibility in AI answers is the subject of answer engine optimization, or AEO. If the term is new to you, read our post on what answer engine optimization is first. The short version is that assistants build answers from the pages and third-party sources they can read, and a brand can change what those sources say about it.

Announced on stage at Baltic Brand Forum

scandiweb was an official partner of Baltic Brand Forum 2026, held on September 24–25, 2026 at Riga Circus under the theme “Stand Out”. Lina Ivanova, our Head of Traffic Acquisition, spoke on the main stage with the talk “When Buyers Ask AI What to Buy, Is Your Brand in the Answer?” and announced the winners of the AI ranking from that stage.

Brands that heard their name in the hall can find their full industry results on the ranking page.

How to move your brand up in AI answers

AI search optimization builds on SEO. Assistants that search the web read pages that search engines can find, so the technical work you already do for Google still counts. Two more things need attention on top of it: the full-sentence questions buyers ask and the third-party sources AI quotes. Our guide on how to rank in AI search covers each step in detail. The short version follows.

1. Find the questions buyers ask, such as which bank in Lithuania has the lowest fees.
2. Check where AI places you today by searching the ranking for your company and noting your visibility, sentiment, average position and the competitors named ahead of you.
3. Answer those questions on your own site, covering what you sell, where you deliver and what it costs, with one page per market in its own language.
4. Get mentioned in the sources AI reads, including review sites, comparison articles, directories and news coverage.
5. Make your site readable for AI crawlers, with key content in HTML, structured data in place and a robots.txt that does not block GPTBot, OAI-SearchBot, PerplexityBot or Google-Extended.
6. Keep your facts the same everywhere, so your company name, address and product details match across your site, Google Business Profile, social profiles and directories.
7. Work on what AI says about you by answering reviews, fixing the problems customers keep mentioning and correcting outdated facts on third-party pages.
8. Measure the same questions every month, because AI answers change as the assistants update their sources.

For the measurement in step 8, see our post on tracking brand mentions in AI-generated answers.

Where does your brand stand?

Search the Baltic AI Brand Ranking for your company name. The result shows your visibility, sentiment and average position, and the competitors named ahead of you. If your brand is missing from the Baltic list, check the country rankings first, since they include brands named in fewer than three countries. If it is still not there, use the Don’t see your brand? page.

FAQ

What is the Baltic AI Brand Ranking?

It is an independent ranking of 5,548 companies in 113 industries across Latvia, Estonia and Lithuania, ordered by how often ChatGPT, Gemini and Perplexity recommend them. scandiweb built it and gathered the data with AnswerRank, asking 3,419 buyer questions over a month. Each company gets one score out of 100 based on visibility, sentiment and average position.

Which brand does AI recommend most in the Baltics?

Circle K, with a Baltic score of 92.6. Swedbank is second at 88.1 and Revolut third at 87.8. By country, Circle K also won Latvia with 91.5 and Lithuania with 93.2, while Rahva Raamat won Estonia with 93.5. Each of the 113 industries has its own leader per country, listed on the winners page.

How is the AI brand score calculated?

Visibility is the share of answers that mention the company. Sentiment is how favorably the answers describe it. Average position is where the company appears in the answer, with 1 meaning first. The score rolls the three into one number out of 100. Visibility is weighted most, sentiment second, and position separates brands whose scores are close.

Is the ranking connected to the Baltic Brand Awards?

No. The Baltic AI Brand Ranking is independent, built by scandiweb and announced at Baltic Brand Forum, where scandiweb was an official partner. The forum’s Baltic Brand Awards are a separate program based on Norstat’s Brand Capital research. A brand can win one and not appear in the other, so the two should not be read as a single result.

Why is my brand not in the ranking?

There are four common reasons. AI did not name your brand for your industry’s questions. Your brand is listed under another name, as Rimi Eesti Food is in Estonia. Your brand is named in only one or two countries, which keeps it off the Baltic list but still in the country rankings. Or your industry was not among the 113 tested.

How long does it take to move up in AI answers?

There is no fixed timeline. Each assistant refreshes its sources at its own pace, so a change on your site or in a third-party source shows up in ChatGPT, Gemini and Perplexity at different times. That is why the last step in our guide is to measure the same questions every month and compare the results.

What the ranking means for your brand

The Baltic AI brand ranking gives you a measured answer to a question most brand teams have only guessed at: whether ChatGPT, Gemini and Perplexity name you when a buyer in Latvia, Estonia or Lithuania asks what to choose. Circle K, Swedbank and Revolut lead the Baltic list, Rahva Raamat leads Estonia, and 113 industries have their own leaders in each country. The gap between first and fifth place, 67% of answers against 22%, is the number to keep in mind. Congratulations again to the winners and finalists. For everyone else, the eight steps above are where to start, and the ranking page is where to check your position today.

Get a measurement of where AI places your brand, and we will show you which questions it is missing from.

The post We Ranked 5,548 Baltic Brands for AI Search: Meet the Winners appeared first on scandiweb.

At 14:00 UTC on October 21, 2026, PHP released fixes for PHP2Shell, two flaws that can let a stranger with no login run code on a PHP web server. Cloudflare’s CEO counted thousands of exploit attempts in the ten hours before the fixes went out, tens of thousands in the 45 minutes after, and millions after that.

Magento, Adobe Commerce, WooCommerce and Shopware all run on PHP, and this PHP security vulnerability is below the store code, where no store patch reaches. The fix is a PHP update on the server, so your store is only as safe as whoever runs that server: your host, Adobe, your agency or your own team. For most store owners, this week’s question is easy to ask and slow to answer: which PHP version is each of our servers running, and who confirmed it?

What is PHP2Shell?

PHP2Shell is the name for two flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, each rated CVSS v4.0 9.2. A crafted web request can trigger them without a login and let an attacker run their own code on the server. PHP fixed both in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on October 21, 2026. Magento, WooCommerce and WordPress have no patch for it, because the fault is in PHP.

PHP is both the language most store software is written in and the program that runs it on the server. The flaws are in how that program handles memory while it reads an incoming request, before your store’s own code starts. An attacker who gets code running at that point can do what a developer with server access could: add a card skimmer to checkout, copy passwords and API keys out of memory, or take the site offline.

PHP’s advisory calls the first flaw remote code execution through out-of-memory corruption, and the second remote code execution through stale state left behind by an earlier request. It covers every PHP setup that serves web requests (PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed) and rates mod_php highest, with a demonstrated exploit that fires before any application code runs. Sansec traced the vulnerable code back to PHP 5.4.0 from 2012, and Wiz researchers said the findings rank among the most severe vulnerabilities discovered in PHP, a language behind about 69.7% of websites whose server-side language is known, according to W3Techs figures cited by Infosecurity Magazine.

PHP2Shell timeline: what happened in October 2026

The flaws went from private bug report to internet-wide scanning in about ten weeks. Researchers reported them to PHP in August, the first exploit attempt hit a honeypot on October 17, details leaked on October 20, and PHP released the fixes at 14:00 UTC on October 21. CISA listed both CVEs as known exploited on October 26.

Three critical flaws in seven weeks for Magento stores

This was the third critical flaw Magento stores had to deal with in seven weeks, and each one needed a different fix from a different place:

• StyleSmuggler, CVE-2026-75650, CVSS 10.0: a Magento zero-day under attack from September 4, fixed by Adobe’s hotfix APSB26-146 on September 7 (see which versions the StyleSmuggler patch covers)
• BlockStrap, CVE-2026-103849, CVSS 10.0: a template-engine injection fixed in Adobe’s APSB26-153 on October 13, which Sansec named and rates higher than Adobe’s priority 2
• PHP2Shell, October 21: a flaw in PHP itself, closed only by a PHP update

A store that installed the October Magento patch and stopped there is still exposed to the PHP flaw, and a store that updated PHP still needs the October Magento patch.

Is your store affected by PHP2Shell?

Your store is affected if any part of it runs PHP and serves web requests, until that PHP is updated or rebuilt with a vendor backport. That covers Magento, Adobe Commerce, WooCommerce, Shopware, WordPress and Drupal, plus the PHP systems around a store, such as a Pimcore or Akeneo PIM, a blog or a custom tool. Clean store code makes no difference.

Sansec confirmed that Magento, Shopware and WooCommerce stores are affected “even when their own code is clean,” and Calif showed unauthenticated code execution on Magento 2.4.9, WordPress 7.1.2 and Drupal 11.4.3, among others. Who installs the fix depends on how you host:

On Adobe Commerce on cloud infrastructure, Adobe Support told us on October 21 that it would deploy updated PHP images as soon as the patches were available, staging before production, and that no customer action was needed. We found no public Adobe bulletin on PHP2Shell, so a support case is how you confirm it for your own environment.

Which PHP version fixes it on each Magento line

Each Magento line supports a fixed set of PHP branches, listed in our Magento end of life guide. Matched against PHP’s fixed releases:

PHP no longer releases 8.1 or older, so stores on 8.1 depend on a Linux distribution or hosting vendor that applied PHP’s source backport, and they need an upgrade plan. Our step-by-step Magento upgrade guide covers the path.

How to check which PHP version your store runs

On a server you control, run:

php -v

The first line shows the version and build date. Anything built before October 21, 2026 can’t contain the fix. Distribution packages sometimes keep an older version number with the fix backported, so check the package changelog for both CVE IDs. The command line and the web server can also run different builds, so check PHP-FPM or mod_php, not only the terminal. On managed hosting, ask for the version and build date in writing.

What PHP2Shell means for your business

An attacker who gets this flaw to work has the access of a developer on your server, about five weeks before Black Friday on November 27. For a store, that can mean a card skimmer in checkout, stolen customer data or a site that’s down in peak season. Exploit attempts are confirmed at internet scale, and as of October 27, 2026, no successful break-in at a specific store had been publicly confirmed.

The sources disagree on how dangerous the attempts are. Amazon described PHP2Shell as broadly exploited in the wild, while saying it was unclear whether the attempts would have worked against real systems. Sansec found the public exploits don’t work against a default PHP installation and that an attack “needs specific knowledge of the target server and specific conditions on it.” CISA still added both CVEs to its known-exploited catalog.

An unpatched server is exposed, which is different from breached, and a patch only stops new attempts. Sansec notes that leaked memory can contain “passwords, session tokens, API keys and TLS private keys from other requests,” so the checks in the next section are what tell you whether anyone got in between October 17 and your patch date.

Outside parties watch the same dates. PCI DSS requirement 6.3.3 expects critical security patches within one month of release (our PCI DSS SAQ guide covers who is responsible for what), and cyber insurers read the bulletins too. The day after PHP2Shell, the CTO of one retail client forwarded us an alert their insurer had sent about BlockStrap, saying they hadn’t seen an update on it yet. Our team had been working on it for two days.

What to do now if PHP2Shell is not patched yet

Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 on every server that runs it, restart every PHP process, then check for signs of compromise and rotate credentials. PHP’s release notes are blunt about the alternatives: “There are no complete mitigations, updating is the only safe choice.”

1. Update PHP everywhere it serves requests: staging first, then production, then the PIM, the blog and any custom tools. The package changelog should list both CVE IDs.
2. Restart every PHP process, including PHP-FPM or Apache, cron and Magento’s queue consumers. A process that wasn’t restarted still runs the old PHP.
3. On PHP 8.1 or older, get a backported build from your Linux distribution or LTS vendor, or build from the PHP team’s source backports for 7.4, 8.0 and 8.1, then plan the move to a supported branch.
4. Check for compromise before cleaning anything, and keep the logs. Look for unknown admin users, script tags in core_config_data, cms_block and cms_page, unexpected PHP files in pub/media, recently changed PHP files, and PHP processes that started shells, in logs from October 17 onward. A Magento code audit is the thorough version.
5. Rotate payment gateway credentials, integration and API tokens, and database and admin passwords.
6. Test checkout end to end with every live payment method.

If you can’t patch PHP today

CISA’s alert says to take PHP systems offline until they’re patched, while Sansec’s view is that stores don’t need to go offline. If you keep the store up, PHP lists partial measures that “reduce exposure to specific attack paths but do not make an installation safe.” Set them in php.ini, the FPM pool or the server config, because ini_set() and .user.ini apply too late:

memory_limit = -1
post_max_size = 8M
session.upload_progress.enabled = 0
fatal_error_backtraces = 0

Set memory_limit where applications can’t override it, such as php_admin_value in the FPM pool, and add a container or cgroup memory cap, because one request can now take all of the server’s memory. If the site needs uploads, use 32M for post_max_size and keep upload_max_filesize below it. fatal_error_backtraces exists on PHP 8.5 only. Restart every worker afterward.

Sansec’s other stopgap is blocking multipart/form-data requests at the web server, which breaks uploads, so test checkout afterward. Magento maintenance mode doesn’t help. A web application firewall gives interim cover: Cloudflare pushed rules for the known exploit vectors to every plan, including free ones. Remove each stopgap once PHP is updated, and put the memory limit back.

How we handled PHP2Shell across our clients’ stores

By 09:00 UTC on October 21, five hours before PHP published the fix, more than 40 of our client projects each had a critical-priority ticket. On one client’s own AWS setup, PHP 8.5.12 was running in production at 16:38 UTC, under three hours after the release. Every store went through the same steps in between: alert, ticket, temporary protection, patch, test and monitoring.

PHP’s advance notice on October 20 gave us a day to prepare. At 08:23 UTC on October 21, our Executive Board emailed clients that the fix was due at 14:00 UTC and that a successful attack could take a site down, wipe data or leak customer data. The email also said, in these words: “This alert does not mean your store has been compromised. No attacks on our clients have been confirmed so far.”

Each store then got a ticket from one template (what is happening, the hosting, the current PHP version, whether it gets the official fix, the other PHP systems in scope, how to verify) and an eight-hour plan:

• Preparation, 1.5 hours: review every PHP system in scope, back up code and database, write the rollback plan
• Applying the fix, 2 hours: staging, then production, then the other PHP systems
• Testing, 3.5 hours: confirm the flaw can no longer be exploited, run checkout with every live payment method, check that ERP, PIM, shipping, search and marketing integrations still sync, and smoke test the admin, order emails and scheduled jobs
• Aftercare, 1 hour: 24 hours of production monitoring and a summary for the client

Before the fix was out, we applied temporary protections with no downtime: upload-progress tracking off, stricter session settings, and file uploads blocked before they reached PHP. One client’s PIM ran PHP 8.0, which gets no official fix, so we rebuilt PHP with the PHP team’s backport where no fixed package existed, kept a rollback copy on each server, and sent an estimate for a supported version. For Adobe Commerce cloud clients, we opened Adobe Support cases that morning and kept following up. For stores on other hosts, we asked each host for the fixed build and the date it went on. One client’s site went offline behind a redirect and came back once patched. September’s StyleSmuggler response has its own write-up.

What clients told us

Most replies were about being told early. A beauty brand thanked us for being “so quick to react with the PHP vulnerabilities,” and a retailer on Adobe’s cloud wrote: “I just want to sincerely thank you for all your efforts in chasing this update.” Our Executive Board’s note to the team the next day drew the lesson: react fast, and keep clients informed before they have to start asking.

How to prepare for the next critical PHP or Magento vulnerability

Preparing for the next critical vulnerability is work you do before the bulletin arrives: supported PHP on every system, a written answer to who patches what and how fast, a list of every PHP system you run, and a patch routine your team has practiced. Three critical flaws in seven weeks is the pace to plan for.

Start with PHP’s support calendar:

PHP 8.2 stops getting security fixes on December 31, 2026, and it is the newest PHP that Magento 2.4.6 supports. Then work through the rest:

1. Keep every system on a supported PHP branch, including the ones nobody logs into often.
2. Write down who patches what: for each system, the owner (host, Adobe, agency or in-house team), the response time for a critical bulletin, and who covers nights and weekends, which a Magento support retainer should spell out.
3. Keep a list of every PHP system. CISA warns that PHP “is often a component of other software and prevalence may not be directly observable,” and PIMs, blogs and internal tools are the ones that get forgotten.
4. Practice a same-day patch routine: backup, rollback plan, staging first, a scripted checkout test with every payment method, and a check that the exploit no longer works.
5. Put a web application firewall or CDN in front of the store, with skimmer and file-change monitoring behind it, so you would know if someone got in before the patch.
6. Write the messages in advance, for stakeholders and for customers. Our 08:23 UTC alert went out before the fix existed because the template already did.
7. Agree that security fixes override the Black Friday code freeze. An unpatched critical flaw is a bigger risk to peak-season revenue than the patch, and our code freeze guide covers how to plan the exception.
8. Decide how many servers you want to patch yourself. Managed Magento hosting or Adobe Commerce as a Cloud Service moves PHP updates to the provider, and you give up control over timing: on October 21, our client on its own AWS was patched within three hours, while cloud clients waited for Adobe’s rollout.

What CTOs, heads of eCommerce, and heads of marketing should each own

Security incidents tend to go wrong at the handoffs, when the host assumes the agency has it and the agency assumes the host patched. Give each role a short list before the next bulletin, so everyone knows what they own.

For CTOs and technical leads

• A runtime inventory with every PHP version and build on every server, kept current
• An ownership matrix for patching, with a response time for critical bulletins
• A test that proves the exploit no longer works, run after every patch
• An end-of-life roadmap with a budget, since PHP 8.1 is already unsupported and 8.2 follows on December 31
• Logs kept long enough to look back, since the first attempts came four days before disclosure

For heads of eCommerce

• A checkout test list with every live payment method, plus the integrations to check after a patch
• A maintenance page that returns a 503 status, so search engines treat a short outage as temporary
• A code-freeze exception for security fixes, agreed before Black Friday
• Host and vendor contracts that name a response time for critical bulletins

For heads of marketing

• A tag inventory, because third-party scripts and tags are where card skimmers hide, and marketing owns most of them
• A pre-approved holding statement, used only when there is something to tell customers
• Campaigns you can pause within minutes if the store goes into maintenance

For store owners and CEOs

Five questions to ask your team or agency this week:

1. Which PHP version and build date does each of our servers run today?
2. Who installed the fix on each one, and when? Do we have that in writing?
3. Which other PHP systems do we run, and who checked them?
4. What did we check for compromise, and which credentials did we rotate?
5. Who gets the next security bulletin first, and how fast do they act on it?

Take the answers to your insurer and your board before either asks. Then budget upgrades on a calendar instead of as emergencies: our website maintenance cost guide shows what planned support work includes, and a Magento technical audit gives you the baseline.

PHP2Shell FAQ

Is PHP2Shell being exploited?

Exploit attempts are confirmed. Amazon logged the first on October 17, Cloudflare counted millions after disclosure, and CISA added both CVEs to its Known Exploited Vulnerabilities catalog on October 26. Sansec expects mass exploitation to be less likely than it first thought, because the public exploits need specific conditions on the target server. As of October 27, 2026, no break-in at a specific store had been publicly confirmed.

Do I need a Magento patch for PHP2Shell?

No. The flaw is in PHP, so the fix is updating PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restarting every PHP process. You still need Adobe’s October security update, APSB26-153, which fixes BlockStrap and other Magento flaws, but it does nothing for this one.

Does Magento maintenance mode protect against PHP2Shell?

No. Magento handles maintenance mode, and PHP reads the request before Magento runs, which matches the PHP advisory’s warning that the attack can trigger before any application code. Sansec says the same of its own store-level Shield. Taking the server offline or blocking requests at the web server works, while maintenance mode leaves the server just as exposed.

Is Shopify affected by PHP2Shell?

Shopify, BigCommerce and Adobe Commerce as a Cloud Service run and patch their own servers, so the store itself needs nothing from you. Anything you host separately still does: a WordPress blog, a PIM such as Pimcore or Akeneo, custom tools or middleware. Find out which PHP version each one runs, and get the same written confirmation you would ask of a host.

What if my server runs PHP 8.1 or older?

PHP no longer releases updates for 8.1 and older, so there is no official fixed version. Linux distributions and LTS vendors received the patches in advance, and the PHP security team published source backports for 7.4, 8.0 and 8.1. Get a backported build, as we did for one client’s PIM on 8.0, then plan the upgrade. CISA’s advice for systems that can’t be patched is to take them offline.

Does a web application firewall stop PHP2Shell?

A WAF buys time. Cloudflare deployed rules for the known exploit vectors to all its customers, including free plans, and CISA says a WAF may offer interim protection but is not a substitute for patching. It blocks the attack patterns it recognizes, and the flaw stays open behind it until PHP is updated.

Check your PHP version before the next bulletin

PHP2Shell was fixed on October 21, 2026, and the fix only counts on servers where someone installed it, restarted every PHP process and confirmed the build. This week, find out which PHP version and build date each of your systems runs, the store, the PIM, the blog and anything else on PHP, and get the answer in writing from whoever owns each server. Anything below 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or on 8.1 without a backport, goes through the steps above in order. Then use the weeks before Black Friday to fix the handoffs and put PHP 8.2’s December 31 deadline on the plan. StyleSmuggler, BlockStrap and PHP2Shell arrived within seven weeks of each other, so plan for the next one at the same pace.

Send us a list of your systems and who hosts each one, and we'll check the PHP and patch status of all of them, then tell you what we found and what to fix first.

The post PHP2Shell: What the Critical PHP Vulnerability Means for Your Online Store appeared first on scandiweb.

Picking a Magento agency in Canada usually starts with two questions. Does it have an office in your time zone that you can visit, and is Magento its main platform or one more logo on its services page?

We started from about 40 agencies that sell Magento work to Canadian merchants and kept seven. For each one we found the office on its own contact page, looked up its tier in Adobe’s and Hyvä’s directories, and read its Canadian case studies. Where a claim could not be checked, the entry says so.

Top Magento agencies in Canada at a glance

The top Magento agencies in Canada are scandiweb, Valtech, MageMontreal, Kinex Media, TWO DEV, Northern, and Rootways. Each one has an office in Quebec or Ontario that you can find on its own contact page. They differ in partner tier, in how much of their work is Magento, and in whether they publish Canadian case studies with numbers.

Adobe tiers without a note come from Adobe’s directory (searched October 26, 2026). “As stated” means the tier appears only on the agency’s site, and “Not listed” means the search returned nothing. The Hyvä column shows the country each listing is filed under.

How we chose these Magento agencies

We kept an agency when it passed four checks, in this order. An Adobe Commerce partner in Canada with a Platinum tier still fell off if Magento is a sideline or its only Canadian presence is a phone number.

• Magento comes first. Magento or Adobe Commerce leads the agency’s services, and its case studies show Magento builds.
• A Canadian office on the agency’s own contact page. A Canadian phone number on a landing page did not count.
• Named Canadian Magento work or a tier you can check. Canadian Magento clients, a tier in Adobe’s Solution Partner Directory, a tier on Hyvä’s agency finder, or a mix.
• A support plan. Adobe Commerce 2.4.6 left support on August 11, 2026, and every later version has a fixed end date, so someone has to own upgrades after launch.

Most of the 40 fell at the first two checks: Shopify-first studios that keep a Magento page for older clients, general web agencies that list Magento next to WordPress, and offshore firms with a Canadian phone number and no Canadian address. Two well-known names no longer exist as brands: Valtech bought Absolunet in January 2022, and Bounteous absorbed Demac Media in 2018. For agencies outside the country, see our list of global Magento development companies. Our lists for the UK and Australia apply the same checks to other markets.

The 7 best Magento agencies in Canada, profiled

The seven profiles below are in the order we would shortlist them for a mid-market or enterprise Magento store. Each ends with the type of merchant the agency fits best.

1. scandiweb

scandiweb is the world’s most certified Adobe Commerce agency, with 894+ Adobe certifications, Adobe Gold Solution Partner status, and Hyvä Platinum Partner status. It has been an Adobe partner since 2009 and has delivered 2,100+ projects since 2003 for 700+ clients, who rate it at 95 NPS. scandiweb is certified to ISO 9001, ISO 27001, and ISO 27017 and is PCI DSS compliant. Its Hyvä listing is filed under another country on hyva.io, so you will not find it in the Canada section.

In Canada, scandiweb works from a Montreal office. Michael Bliah, VP North America, is based there and is the named contact for Canadian clients, and the Canada team works on Eastern Time. Developers come from the wider certified team, so backend, frontend, and integration work can run at the same time. Our Canada page explains how the team works with Canadian merchants.

Canadian clients named publicly include JYSK Canada and Moose Knuckles, the Canadian outerwear brand. The published Canadian number is PUMA’s: scandiweb’s SEO program grew PUMA’s organic revenue in Canada by 73.98% year over year. JYSK’s Hyvä rebuild is covered in our Hyvä case studies.

Best for: mid-market and enterprise brands that want the deepest certified bench with a Montreal contact, for Hyvä builds, upgrades, and SEO run alongside development.

2. Valtech

Valtech is a global multi-platform consultancy with Canadian offices in Montreal, at 7236 Waverly Street, and Toronto, at 100 University Avenue. In January 2022 it bought Absolunet, the Montreal commerce consultancy with about 300 staff, so Absolunet no longer exists as a brand. Adobe’s directory lists Valtech as a Platinum Solution Partner. It is not on hyva.io, and it also works on Salesforce, commercetools, SAP, and Shopify.

Its strongest Canadian Magento case is Structube, the Montreal furniture retailer with 70+ stores, built as headless Adobe Commerce. Valtech reports a 38% increase in pages viewed per session, a 35% increase in mobile conversion rate, and a 13% increase in desktop conversion rate. For Fountain Tire it built Adobe Commerce with Edge Delivery Services, with the B2B catalog first and B2C after it. We did not find a dedicated support offer on its pages, so ask how support is staffed after launch.

Best for: enterprise Canadian retailers that want headless Adobe Commerce and the wider Adobe stack from one global consultancy.

3. MageMontreal

Despite the name, MageMontreal works from Sainte-Agathe-des-Monts, Quebec, about 100 km north of Montreal. It says it has 19+ years of experience. Adobe’s directory lists it as a Silver Solution Partner working exclusively on Magento, though its own site now also markets Shopify, BigCommerce, and WooCommerce. It is not on hyva.io.

Its Quebec Magento cases come with numbers. For Biron, the Quebec sleep-health and medical equipment company, a Magento 2 rebuild is credited with revenue up 205% from 2024 to 2025. Momo Sports moved to Adobe Commerce Cloud in a Magento 2 rebuild and reports over 300% more sessions. FLB Solution, a Quebec food distributor, had an inherited Magento store rescued with PIM and ERP integration and reports a 35% higher average order value. MageMontreal also sells a dedicated maintenance and improvement service.

Best for: Quebec mid-market and B2B merchants that need Magento with SAP integration, a rescue of an inherited store, or an improvement retainer.

4. Kinex Media

Kinex Media has its head office in Mississauga at 25 Watline Avenue, a Toronto office at 250 University Avenue, and has been in business since 2008. Adobe’s directory lists it as a Silver Solution Partner, and hyva.io lists it as Hyvä Silver, the highest Hyvä tier under Canada. It is a full-service agency, and many of its case studies are WordPress builds, but Magento 2, Adobe Commerce, migration, support, and Hyvä each have their own service page.

Its best Magento case is Ontario Medical Supply, a client since 2013, for which it built a B2B ordering portal on Adobe Commerce 2.4.7 B2B integrated with Pronto ERP. Kinex reports that 100% of online orders transfer to Pronto automatically, that orders reach the ERP about 10 to 20 seconds after checkout, and that the mobile usability score rose from 54 to 93.

Best for: Ontario B2B and B2C brands that want a Hyvä frontend or Adobe Commerce B2B with ERP sync, plus design and marketing from one team.

5. TWO DEV

TWO DEV works from 4000 Saint-Ambroise in Montreal and calls itself an “Alternative eCommerce Agency” built on Adobe Commerce and Akeneo PIM. Every case study on its site is Magento or Adobe Commerce. We found no entry for it in Adobe’s directory, so its Adobe tier is not listed. On hyva.io it is Hyvä Bronze under Canada.

Its Quebec projects are mostly migrations. For Avril Supermarché Santé, the Quebec health-food chain, it moved the store from Magento 1 to Adobe Commerce with a PWA, SAP, and click and collect, and says the full migration took nine months. For SHAN, the Canadian haute-couture brand, it migrated Magento 1 to 2 with Cegid, Mirakl, and a Canada Post integration. For Bicycles Quilicot, the Montreal bike store founded in 1915, it took over maintenance first and then rebuilt the store on Magento 2 with Lightspeed and Akeneo. None publishes metrics, so ask for numbers. Its site promises the team is available 24/7, all year.

Best for: Quebec retailers on Adobe Commerce with Akeneo PIM who want a small senior team and round-the-clock support.

6. Northern

Northern, formerly Northern Commerce, has its head office in London, Ontario, with offices in Toronto and Edmonton. Adobe’s directory lists it as a Gold Solution Partner. It is not on hyva.io. The agency now positions itself around content, data, and operations, so Magento is one practice among several.

Its published Magento 2 case is Andrew Peller, the Canadian winery group, for which Northern reports a 132% increase in mobile revenue and a 28% increase in conversion rate. We could not confirm a support offer on its site, so ask what the support model looks like.

Best for: Canadian brands that want Adobe Commerce alongside content and data work from one Ontario team.

7. Rootways

Rootways works from 2970 Drew Road in Mississauga and has done Magento-led development and support since 2010. It describes itself as an Adobe Bronze Solution Partner, a tier we could not find in Adobe’s directory, so treat it as stated by the agency. It is not on hyva.io.

It sells its own Magento extensions for Canada Post, Purolator, and Day & Ross shipping. Its portfolio includes Canadian Magento stores such as Dimar Canada, a B2B store on Magento 2, Firearms Outlet Canada, and The Pacific Smoke, with no published metrics.

Best for: smaller Canadian Magento stores that need Canadian shipping extensions and affordable support.

Two more names deserve a line. Novatize in Quebec City, an Adobe Silver partner, built a Magento 2 B2B platform for Groupe LD but now leads with Shopify Plus. Bounteous, an Adobe Platinum partner, absorbed Demac Media in 2018, but we found no current Canadian Adobe Commerce case on its site.

Magento agencies in Montreal, Toronto, and the rest of Canada

Six of the seven agencies have an office in Montreal or the Greater Toronto Area. Montreal has scandiweb, Valtech, and TWO DEV, with MageMontreal about 100 km north. The GTA has Valtech, Kinex Media, Rootways, and Northern’s Toronto office. The rest of Canada is served remotely from those two regions, plus Northern’s offices in London, Ontario and Edmonton.

Montreal and Quebec

Four of the seven are in or near Montreal. scandiweb’s Montreal office is the base for its VP North America, Valtech is on Waverly Street, and TWO DEV is on Saint-Ambroise. A workshop with MageMontreal means a drive to Sainte-Agathe-des-Monts. If you need a Magento agency in Montreal with Quebec case studies, Valtech, TWO DEV, and MageMontreal all publish them.

Toronto and the GTA

For Magento developers in Toronto or Magento website development in Mississauga, there are four agencies with offices: Valtech and Kinex Media on University Avenue, Kinex’s head office and Rootways in Mississauga, and Northern’s Toronto office. scandiweb has no Toronto office and serves the GTA from Montreal on the same Eastern Time, as our Magento agency in Toronto page explains.

Elsewhere in Canada

Northern is the only agency on this list with offices outside Quebec and the GTA, in London, Ontario and Edmonton. None of the seven has a Vancouver or Calgary office, so a Magento developer in Calgary or Vancouver on this list means working remotely with an Ontario or Quebec team.

What a Magento agency in Canada should handle

A Canadian Magento agency should handle six things a US or European build does not, and raise them before you do: French for Quebec, sales tax by province, Law 25 consent, AODA accessibility, Canadian payment gateways, and Canadian carriers. Statistics Canada puts retail eCommerce sales at $5.6 billion in August 2026, 7.6% of total retail trade, seasonally adjusted, according to its Retail trade, August 2026 release.

• French in Quebec. Under the Charter of the French Language as amended by Bill 96, commercial websites must be available at least in French, with no other language more prominent, since June 1, 2022. Online terms must be provided in French first since June 1, 2023, and new product-labeling rules for trademarks started June 1, 2025, with a sell-through period for older stock to June 1, 2027, according to the OQLF. In Magento that means a French store view, French checkout emails, and French terms rather than a translated banner.
• Sales tax by province. GST is 5% in Alberta, BC, Manitoba, Quebec, Saskatchewan, and the territories. HST is 13% in Ontario, 15% in New Brunswick, Newfoundland and Labrador, and PEI, and 14% in Nova Scotia since April 1, 2025. On top of GST, BC charges 7% PST, Saskatchewan 6% PST, Manitoba 7% RST, and Quebec 9.975% QST, per the Canada Revenue Agency. Ask to see a test order into each province.
• Privacy. Quebec’s Law 25 phased in from September 22, 2022 to September 22, 2024. Since September 2023, consent must be explicit for each purpose, tracking and profiling tools must be off by default, and penalties reach $10 million or 2% of worldwide turnover, according to the Commission d’accès à l’information. This changes how analytics, pixels, and personalization load on a Quebec storefront.
• Accessibility. In Ontario, businesses with 50+ employees must meet WCAG 2.0 Level AA on public websites under the AODA, and organizations with 20+ employees file their next accessibility compliance report by December 31, 2026, per the Government of Ontario.
• Payments. Interac Online has been discontinued in favor of Interac Debit for online payments and the Konek wallet, and PayBright is now Affirm. Moneris and Worldline (formerly Bambora) are common gateways. Ask which module the agency uses for each and who maintains it.
• Shipping. Canada Post and Purolator both offer developer APIs, and their Magento modules come from third parties rather than the carriers. Ask which module the agency uses and who updates it when the carrier API changes.

How to choose a Magento agency in Canada

Choose a local Magento specialist when your store serves Canada with one main workstream and an ERP that already works. Choose a larger certified Adobe Commerce partner when several workstreams run at once, when you sell outside Canada too, or when one developer leaving would stop your launch.

Choose a local Magento specialist if:

• You run one Canadian store, with English and French store views at most
• The project has one main workstream, such as a Hyvä rebuild or a 2.4.x upgrade
• Your ERP or PIM is already connected and stable
• You want the same people in every meeting and a short drive to the office
• Your budget fits a small team better than an enterprise program

Choose a larger certified Adobe Commerce partner if:

• You need backend, frontend, integrations, and SEO running at the same time
• You sell in the US or Europe as well as Canada and want one instance for all of it
• A developer leaving or on vacation cannot delay your launch
• You want tiers and certifications you can check in Adobe’s and Hyvä’s directories
• You need support cover for incidents outside Eastern Time business hours

If the answer depends on what your ERP and PIM should do after launch, we can map your target architecture first, so every agency quotes against the same picture.

Questions to ask before you sign

A Magento development company in Canada that has done this before will answer these on the first call, with links.

• Which Adobe Solution Partner tier do you hold, and can you send the directory link?
• What is your Hyvä tier, and which country is it listed under on hyva.io?
• Which office will run our account, and which hours does the delivery team overlap with Eastern Time?
• Which French storefronts have you launched for Quebec, and can we see one live?
• How will you set up GST, HST, PST, RST, and QST, and can we see a test order into each province?
• How do you handle Law 25 consent, and what loads before the shopper accepts cookies?
• Which Adobe Commerce version will we run? Under Adobe’s lifecycle policy, 2.4.7 leaves support on May 31, 2027, 2.4.8 on May 31, 2028, and 2.4.9 on May 31, 2029.
• Who owns the code, the repository, and the hosting account when the contract ends?

What does Magento development in Canada cost?

Magento development in Canada is priced in three ways: fixed quotes for builds, migrations, and Hyvä projects, monthly retainers for support, and hourly or daily rates for open-ended work. The drivers that move a Canadian quote most are a French store view, ERP or PIM integration, B2B features, provincial tax setup, and the Adobe Commerce license. Send the same scope to three agencies. The one that itemizes the French store view and the tax setup has probably done it before. Our Magento pricing guide covers license, build, and support costs in detail.

Frequently asked questions about Magento agencies in Canada

What are the best Magento agencies in Canada?

The strongest picks with a Canadian office you can check are scandiweb, Valtech, MageMontreal, Kinex Media, TWO DEV, Northern, and Rootways. scandiweb leads on certifications and Hyvä, Valtech on headless enterprise builds, MageMontreal and TWO DEV on Quebec work, and Kinex Media on Ontario B2B with the only Hyvä Silver tier in Canada.

How much does Magento development in Canada cost?

It depends on the scope. Canadian agencies quote fixed prices for builds, migrations, and Hyvä projects, monthly retainers for support, and hourly or daily rates for ongoing work. Send every agency the same written brief so the quotes compare like for like.

Which Canadian agencies are Hyvä partners?

Hyvä’s directory lists two agencies under Canada: Kinex Media at Silver and TWO DEV at Bronze. Larger Hyvä partners serve Canadian stores from elsewhere. scandiweb, for example, is a Hyvä Platinum Partner with a Montreal office, but its hyva.io listing is filed under another country. Ask any agency which country its listing shows before you count the badge.

Does my Magento store need a French version for Quebec?

Yes, if you sell to consumers in Quebec. Since June 1, 2022, commercial websites must be available at least in French under the Charter of the French Language, and since June 1, 2023, online terms must be provided in French first. In Magento, that means a French store view with French checkout emails and French terms.

Do I need a Magento agency with an office in Canada?

Not always, because most development runs remotely. A Canadian office helps with Eastern Time overlap, in-person workshops, and Quebec language and privacy questions. Ask for a named Canadian contact and the hours the delivery team overlaps with yours.

What is the difference between a Magento agency and an Adobe Commerce agency?

The skills are the same. Adobe Commerce is the licensed edition of Magento and Magento Open Source is the free one, both built on the same codebase, so an agency that works on one works on the other. Our guide to Magento Open Source vs Adobe Commerce explains the trade-offs.

Choosing from the top Magento agencies in Canada

The top Magento agencies in Canada fit different stores. scandiweb fits brands that want the deepest certified bench and Hyvä with a Montreal contact, and Valtech fits enterprise retailers on headless Adobe Commerce. MageMontreal and TWO DEV fit Quebec merchants with SAP or Akeneo, Kinex Media fits Ontario B2B with a Hyvä frontend, Northern fits brands that want content and data work, and Rootways fits smaller stores that need Canadian shipping extensions. Pick three, send them the same brief, and check every tier yourself. If you also sell in the UK, our list of Magento agencies in the UK covers that market the same way.

Talk to our Montreal team about your shortlist, and a Magento lead will tell you which agency fits your store, including when that is another name on this list.

The post Top Magento Agencies in Canada (2026) appeared first on scandiweb.