# Magento 2 Speed Optimization Guide: Speed Up Magento in 2026 *Published: 2026-09-29 | Author: Jason Ratzlaff* Updated September 2026. Covers Magento Open Source and Adobe Commerce 2.4.7 to 2.4.9, and Mage-OS. Written by Jason Ratzlaff, author of FastMagento. Most Magento speed guides are the same list: turn on production mode, install Varnish, add Redis, minify your JavaScript, use a CDN. All of that is still right. It is also why so many stores that did every item on that list are still slow for the shoppers who matter most — the ones searching, filtering, logged in, adding to cart and checking out. This guide covers every fix the top-ranking guides cover, updated for 2026 (Valkey, OpenSearch 2.19, PHP 8.4/8.5, free Hyvä, INP instead of FID), and then goes where they do not: the traffic a full-page cache never sees, checkout performance, and real before-and-after numbers. I build [FastMagento](https://github.com/parkktech/FastMagento) and [FastMagento Checkout](https://github.com/parkktech/FastMagentoCheckout), so where my own tools fit, I say so — and I say where they do not. ![A race car getting a pit stop — every Magento request is a race against the clock](https://images.unsplash.com/photo-1748283373393-efe3e2aa8d09?ixid=M3w4ODMzNjJ8MHwxfGFsbHx8fHx8fHx8fDE3OTA2NTc1ODB8&ixlib=rb-4.1.0&w=1520&q=80&fm=jpg&fit=crop&ar=16:9)Photo by [Paul Krüger](https://unsplash.com/@paulkrueger?utm_source=parkk_blog&utm_medium=referral) on [Unsplash](https://unsplash.com/?utm_source=parkk_blog&utm_medium=referral)**3.8×**faster uncached home page*2,911 ms → 775 ms* **−99%**SQL queries on that page*10,090 → 80* **~10×**faster 7-item cart render*~4.0 s → ~0.4 s* **3×**faster full reindex*~2.6 h → ~50 min* FastMagento benchmarks on a 513,000-product catalog; test conditions are detailed below. How to Improve Magento 2 Performance: 12 Fixes Ranked by Impact --------------------------------------------------------------- \#FixImpactEffortImproves1Production mode + all caches onHighLowTTFB2Varnish (or Fastly) full-page cacheVery highMediumCached TTFB3Current stack: PHP 8.3+, OPcache, ValkeyHighMediumAll server time4Indexers on schedule, cron healthyHighLowStability, admin5Audit extensions for N+1 queriesHighMediumUncached TTFB6Serve uncached reads from OpenSearchVery highMediumSearch, cart, checkout7Lighter theme: Hyvä or BreezeVery highHighLCP, INP8Images: WebP/AVIF, sizes, LCP preloadHighLowLCP, CLS9Fast checkout (backend + frontend)Very highMediumConversion10CDN, Brotli, HTTP/2–3MediumLowGlobal latency11Control bots and faceted crawlMediumLowServer load12Real-user monitoring + budgetsOngoingLowKeeps it fastWhy Is Magento 2 So Slow? ------------------------- “Magento is slow” is really two problems, and most failed optimization projects fix the wrong one: - **Server time (TTFB)** — how long Magento takes to produce the HTML. Driven by caching, PHP, the database, extensions and how Magento loads product data. - **Browser time** — how long the page takes to become visible and usable after the HTML arrives. Driven by JavaScript, CSS, images, fonts and third-party scripts. Magento’s field data says server-side loading is the bigger problem. In HTTP Archive and Chrome UX Report data from July 2026, **51.9% of Magento mobile sites pass Core Web Vitals**, against 81.8% for Shopify. Magento’s Interaction to Next Paint pass rate is a healthy 90.8%; its **Largest Contentful Paint pass rate is only 62.9%** ([Store2x study](https://store2x.com/en/studies/core-web-vitals-shop-system-comparison/)). LCP starts with TTFB — the browser cannot paint an image it has not been told about. ![Diagram of where each Magento speed fix acts: frontend, CDN, full-page cache, Magento application on cache miss, services and database](https://www.parkktech.com/wp-content/uploads/2026/09/magento-speed-layers.png)Every fix acts on one layer. Search, filtered listings, logged-in shoppers, cart and checkout all miss the full-page cache and land on the red layer.### How to Measure Magento Speed: TTFB and Core Web Vitals Measure server time directly, with and without the cache: Terminal: measure TTFB``` # Time to first byte for a cached page (run it twice — the second should be a hit) curl -s -o /dev/null -w "ttfb: %{time_starttransfer}s total: %{time_total}s\n" https://www.example.com/ # Force an uncached request: search results are never full-page cached curl -s -o /dev/null -w "ttfb: %{time_starttransfer}s\n" "https://www.example.com/catalogsearch/result/?q=test" ``` Then look at real users, not just lab scores. PageSpeed Insights shows both: the top section is Chrome UX Report field data from real visitors (what Google ranks on); the Lighthouse score below is a single simulated load. Search Console’s Core Web Vitals report groups your URLs by the same field data. MetricGood targetWhere to lookTTFB, cached pageunder 0.3 scurl, WebPageTestTTFB, uncached pageunder 0.8 scurl on search/cartFull-page cache hit rateabove 90%varnishstatLCPunder 2.5 sCrUX / PSI field dataINPunder 200 msCrUX / PSI field dataCLSunder 0.1CrUX / PSI field dataThe Core Web Vitals thresholds are Google’s official “good” boundaries. The TTFB and hit-rate targets are practical goals, not Google thresholds. ### Magento Performance Problems: Symptom to Cause SymptomMost likely causeEvery page slow, even repeat visitsNo Varnish, or cache disabledFast on refresh, slow first timeLow hit rate, cache flushesSearch and filters slowUncached EAV product loadingCart and checkout slowQuote/totals reloads, KnockoutJSAdmin slow under loadShared DB, heavy attributesFast desktop, slow mobileJavaScript weight, imagesSlow after installing a moduleExtension N+1 queriesMagento 2.4.8 and 2.4.9 System Requirements for Speed ----------------------------------------------------- ![A technician inspecting server racks](https://images.unsplash.com/photo-1785682117394-4c8d27afc12a?ixid=M3w4ODMzNjJ8MHwxfGFsbHx8fHx8fHx8fDE3OTA2NTc1ODB8&ixlib=rb-4.1.0&w=1520&q=80&fm=jpg&fit=crop&ar=16:9)Photo by [Valentin Lacoste](https://unsplash.com/@valentinlacoste?utm_source=parkk_blog&utm_medium=referral) on [Unsplash](https://unsplash.com/?utm_source=parkk_blog&utm_medium=referral)Being on a current, supported stack is the cheapest speed you will ever buy — and in 2026 it also means planning a cache migration. ReleasePHPSearchCache/sessionsDatabase2.4.78.2, 8.3OpenSearch 2.xRedis 7.2MySQL 8.0 / MariaDB2.4.88.3, 8.4OpenSearch 2.19Valkey 8 or Redis 7.2MySQL 8.4 / MariaDB 11.42.4.98.4, 8.5OpenSearch 2.xValkey (Redis not for cache)MySQL 8.4 / MariaDB 11.4Sources: [Adobe 2.4.8 release notes](https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/adobe-commerce/2-4-8), [2.4.9 release notes](https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/magento-open-source/2-4-9), [Adobe Redis/Valkey guidance](https://experienceleague.adobe.com/en/docs/commerce-operations/implementation-playbook/best-practices/planning/redis-valkey-service-configuration). Always confirm exact versions against Adobe’s system requirements for your patch level. What 2.4.9 does *not* do is make your store dramatically faster: it adds PHP 8.5, Symfony 7.4 LTS, per-area SRI hashes and lazy media-gallery loading, and Adobe has published no throughput gains. Likewise, independent benchmarks from [Tideways](https://tideways.com/profiler/blog/php-benchmarks-8-5-vs-8-4-8-3-and-7-4) found PHP performance “does not move much” between 8.2 and 8.5. Upgrade for support and security; get speed from the sections below. If you want a leaner distribution, [Mage-OS 3.0](https://mage-os.org/releases/2026-05-18-mage-os-3-0-0-release/) (May 2026) is built on 2.4.9 with a minimal package set. ### Enable Magento Production Mode and All Caches Terminal: production mode``` bin/magento deploy:mode:set production bin/magento cache:enable bin/magento cache:status ``` Production mode serves pre-compiled code and static files instead of generating them on request. Never run a live store in developer or default mode. ### PHP 8.3/8.4 and OPcache Settings for Magento Magento is a large codebase; OPcache must hold all of it. Adobe’s recommended starting point: php.ini: OPcache and realpath cache``` opcache.enable=1 opcache.memory_consumption=512 opcache.max_accelerated_files=60000 opcache.validate_timestamps=0 ; clear OPcache on every deploy opcache.consistency_checks=0 realpath_cache_size=10M realpath_cache_ttl=7200 ``` Source: [Adobe software recommendations](https://experienceleague.adobe.com/en/docs/commerce-operations/performance-best-practices/software). The PHP JIT compiler rarely helps Magento, which is limited by database and I/O work rather than raw computation. Size PHP-FPM so `pm.max_children` × your average worker memory fits in the RAM you give PHP, leaving room for the database and cache on shared servers. Magento Varnish Configuration: Full-Page Cache Done Right --------------------------------------------------------- A full-page cache stores finished HTML and serves it without running PHP. For anonymous shoppers on popular pages, nothing else comes close. - **Varnish** — Adobe’s recommended production cache; free. Set *Stores → Configuration → Advanced → System → Full Page Cache* to Varnish and export the VCL from the same screen, or run `bin/magento config:set system/full_page_cache/caching_application 2`. - **Fastly** — included with Adobe Commerce Cloud, with edge image optimization. - **LiteSpeed LiteMage** — for LiteSpeed servers; LiteSpeed publishes vendor benchmarks claiming up to 3x faster than nginx plus Varnish. - **Built-in file cache** — Adobe describes it as much slower than Varnish; development only. Three things decide whether your cache actually works: 1. **Hit rate.** Check it: `varnishstat -1 -f MAIN.cache_hit -f MAIN.cache_miss`. Below 90% on a stable catalog means something is punching holes. 2. **Uncacheable blocks.** A single block with `cacheable="false"` in a layout file makes the *entire page* uncacheable. Find them with `grep -rn 'cacheable="false"' app/ vendor/ --include=*.xml` and move personalized content to customer-data sections or private content. 3. **Invalidation storms.** ERP/PIM imports that save products one at a time purge thousands of pages. Batch imports, keep indexers on schedule, and warm key pages after large imports. What Varnish Can’t Cache: Search, Filters, Cart and Checkout ------------------------------------------------------------ This is the section missing from every top-ranking Magento speed guide. Even a perfectly tuned Varnish only serves pages that are identical for everyone. Everything else falls through to PHP and MySQL: - **Search results** — every query is a new URL. - **Layered navigation** — thousands of filter and sort combinations, most requested rarely. - **Logged-in and B2B shoppers** — customer-group pricing makes pages personal. - **Cart and checkout** — never cached, and the requests closest to revenue. - **The first view after every deploy, reindex or flush.** - **Bots** — crawlers and AI scrapers walking every filter combination, each one a cache miss. **The cache handles the easy traffic. Your buyers are the hard traffic.**Shoppers who search, filter, log in and check out are the ones with intent to buy, and almost none of their requests are served from the full-page cache. Tuning Varnish further will not reach them; making uncached requests cheap will. ### Block Bots and Faceted-Navigation Crawl Keep crawlers out of infinite filter combinations: disallow parameterized filter and sort URLs in `robots.txt` where they add no search value, make sure filtered pages carry a canonical to the clean category, and rate-limit abusive bots at your CDN or WAF. Compare your Varnish miss count with your access logs; if bots account for a large share of misses, this is the cheapest capacity you will ever reclaim. ### Make Uncached Magento Requests Cheap What remains is real shopper traffic, and on those requests stock Magento loads every product through its EAV (entity-attribute-value) model — one product spread across many tables — often firing hundreds or thousands of SQL queries per page. That is the problem I built **FastMagento** to solve. FastMagento: A Free Magento 2 Speed Optimization Extension ---------------------------------------------------------- [FastMagento](https://github.com/parkktech/FastMagento) is an open-source extension (OSL-3.0/AFL-3.0) that keeps MySQL as the source of truth but serves the storefront’s product reads from OpenSearch — the search engine Magento already requires. It intercepts Magento’s product load at its single choke point, so the rest of Magento and your third-party modules still receive real product objects: - **Product pages** — attributes, prices (tier, special, catalog-rule, per customer group), stock, swatches and reviews come from one OpenSearch document instead of EAV joins. - **Configurables with hundreds of variants** — per-child price and stock are pre-indexed, turning a per-child N+1 into zero price queries. - **Category tree, menus, breadcrumbs and URL routing** — served from one index read, with URL-rewrite lookups batched. - **Search** — autocomplete, an instant results page and live layered navigation, without page reloads. - **Cart and checkout** — Fast Checkout serves line items from the index instead of looping inventory tables for every line. It is designed to fail safe: a product missing from the index is loaded normally once and then indexed, and if OpenSearch is unavailable the whole storefront falls back to standard Magento. It sits *underneath* Varnish, not instead of it. ### FastMagento Benchmark at 513,000 Products Measured on a purpose-built stress catalog — 513,000 simple products, 4,187 configurables, a 50,000-option color attribute — with real third-party extensions (Webkul Marketplace, Stripe and others) running in both columns. Each figure is a cold render, a full-page-cache miss, median of three runs, with the module disabled versus enabled. Full details are in the [FastMagento README](https://github.com/parkktech/FastMagento). Server render time on a full-page-cache miss, 513,000 products Median of three runs, module disabled vs enabled, real third-party extensions active in both. Stock MagentoWith FastMagento Home page2,911 ms**775 ms** Search results631 ms**338 ms** Configurable product, 660 variants1,371 ms**827 ms** Cart totals, 10 items1,485 ms**1,009 ms** Checkout totals1,510 ms**1,110 ms** Simple product555 ms**480 ms** Category page543 ms**622 ms** The category page is the one surface that is not faster yet: its product grid still renders from MySQL. Source: FastMagento README. ![Bar chart: SQL queries per uncached Magento page at 513,000 products, stock versus FastMagento](https://www.parkktech.com/wp-content/uploads/2026/09/fastmagento-500k-sql-queries.png)Queries per page are the scale-invariant number: the home page drops from 10,090 SQL queries to 80, search from 220 to 23.Read these honestly. The query collapse is the headline: those are the product and EAV queries whose cost grows with catalog size and database latency. Wall-clock gains are biggest where loading data is the bottleneck. On a cached page, both setups serve the same HTML in about 231 ms — the cache already handles the easy traffic. On the same catalog, a full reindex dropped from about 2.6 hours to about 50 minutes. Stock Magento 513,000 products, cache miss Home page render2,911 ms Home page SQL queries10,090 Search SQL queries220 Full reindex~2.6 hours 50,000-option attribute pageHangs With FastMagento Same catalog, same extensions Home page render775 ms Home page SQL queries80 Search SQL queries23 Full reindex~50 minutes 50,000-option attribute pageOpens instantly **What FastMagento does not do yet**Category product grids are still rendered from MySQL, which is why the category page above is not faster despite halving its queries. Only the default store view is indexed, and Adobe Commerce category permissions and B2B shared catalogs are not yet applied. If your traffic is mostly category browsing across several store views, weigh that first. Magento OpenSearch vs Elasticsearch, ElasticSuite and Algolia ------------------------------------------------------------- Magento 2.4 requires OpenSearch, and 2.4.8 is optimized for OpenSearch 2.19 with the Elasticsearch modules deprecated — many guides still tell you to “use Elasticsearch”. Beyond the baseline: OptionSolvesCostElasticSuite (Smile)Relevance, merchandisingFree, open sourceAdobe Live Search + Catalog ServiceAI relevance, fast catalog APIAdobe Commerce onlyAlgoliaHosted search, relevanceUsage-basedKlevu (Athos Commerce)AI search, merchandisingPaidFastMagentoServing cost + instant searchFree, open sourceThe distinction that matters: relevance tools decide *which* products to show; the listing page that renders them is still built by Magento, product by product. Adobe’s Catalog Service moves that work off the database, but only inside Adobe’s licensed SaaS stack. FastMagento does it for Magento Open Source, Mage-OS and Adobe Commerce alike. It also learns your catalog’s synonyms with AI, so “front end” and “frontend”, “a-arm” and “control arm”, or “t-shirt” and “tee” return the same results. I compare these tools in depth in [FastMagento vs ElasticSuite, Adobe Live Search, Algolia and Klevu](https://www.parkktech.com/fastmagento-vs-elasticsuite-live-search-algolia-klevu/). ![FastMagento as-you-type autocomplete showing products and categories in Magento search](https://www.parkktech.com/wp-content/uploads/2026/09/fastmagento-autocomplete.gif)Autocomplete: products and categories appear as you type.![FastMagento instant search results page re-rendering without a page reload](https://www.parkktech.com/wp-content/uploads/2026/09/fastmagento-instant-serp.gif)Instant search results: the whole grid re-renders live, with no page reload.![FastMagento live Shop By layered navigation updating results and counts instantly](https://www.parkktech.com/wp-content/uploads/2026/09/fastmagento-shop-by.gif)Live “Shop By” on search: tick a filter and the grid, counts and facets update instantly.**Flat catalog:** leave it off. Adobe no longer recommends the flat catalog on current versions; it adds indexing overhead and can degrade performance. Magento 2 Redis vs Valkey for Cache and Sessions ------------------------------------------------ Keep Magento’s default cache and sessions in memory, in separate databases, never in files. Valkey is the open-source fork of Redis and speaks the same protocol, so Magento’s Redis configuration points at a Valkey server unchanged: Terminal: Valkey or Redis for cache and sessions``` bin/magento setup:config:set --cache-backend=redis \ --cache-backend-redis-server=127.0.0.1 --cache-backend-redis-db=0 bin/magento setup:config:set --session-save=redis \ --session-save-redis-host=127.0.0.1 --session-save-redis-db=2 ``` Plan the move now: Adobe no longer supports Redis for cache from 2.4.9 onward and on the latest patch releases of earlier lines. Follow [Adobe’s Valkey guidance](https://experienceleague.adobe.com/en/docs/commerce-operations/implementation-playbook/best-practices/planning/redis-valkey-service-configuration) for your exact version. Magento Database, Indexer and Cron Optimization ----------------------------------------------- Terminal: indexers and cron``` bin/magento indexer:set-mode schedule bin/magento indexer:status bin/magento cron:run # must run every minute from the system crontab ``` - **Indexers on “Update by Schedule”.** “Update on Save” reindexes inside the admin request and slows every product save. Schedule mode needs healthy cron. - **Message queue consumers** run from cron by default; on busy stores run them under a process supervisor, and consider RabbitMQ. - **MySQL/MariaDB:** on a dedicated database server, give `innodb_buffer_pool_size` most of the RAM (commonly 70–80%), enable the slow query log, and watch for queries without indexes. - **Housekeeping:** set sensible lifetimes for abandoned quotes and customer visitor logs, and keep `cron_schedule` from growing unbounded. Always back up before cleaning tables. - **Huge attributes:** an attribute with tens of thousands of options can hang Magento’s admin attribute page. FastMagento includes a paginated option manager for exactly this. ![FastMagento paginated attribute option manager handling a 50,000-option Magento attribute](https://www.parkktech.com/wp-content/uploads/2026/09/fastmagento-attribute-manager.gif)FastMagento’s paginated option manager opens a 50,000-option attribute that hangs the native admin page.How to Find Slow Magento Extensions ----------------------------------- On most slow stores, the culprit is a third-party extension doing something in a loop. Profile before you guess: - **Built-in profiler:** `bin/magento dev:profiler:enable html` on staging. - **APM tools:** Blackfire, Tideways or New Relic show slow transactions and query counts per request. - **Bisect:** disable modules one at a time on a staging copy and re-measure uncached pages. FastMagento’s Extension Efficiency Monitor automates this: it profiles a real page render and attributes every SQL query to the extension that fired it. On the 500,000-product test store it surfaced, among others, a marketplace extension looping 87 times over the same table on every product page. ![FastMagento Extension Efficiency Monitor attributing SQL queries and N+1 loops to each Magento extension](https://www.parkktech.com/wp-content/uploads/2026/09/fastmagento-extension-efficiency-monitor.jpg)The Extension Efficiency Monitor ranks extensions by the database load they add and points to the exact class and method looping.Hyvä vs Luma vs Breeze: Magento Frontend Performance ---------------------------------------------------- Once the server is fast, the browser becomes the bottleneck. Luma’s RequireJS and KnockoutJS stack commonly ships several hundred kilobytes to over a megabyte of JavaScript on a product page. FrontendApproachCostStatusLumaDefault, RequireJS/KnockoutFreeBaselineHyvä ThemeNew frontend: Alpine.js + TailwindFree since Nov 2025ActiveBreeze EvolutionLuma-compatible, lighter JS layerFreeActivePWA StudioHeadless ReactFreeAdobe shifted focusEdge Delivery ServicesAdobe drop-in storefrontAdobe CommerceActiveThe biggest change of the past year: [the Hyvä theme became free and open source in November 2025](https://www.hyva.io/blog/news/hyva-is-free-open-source.html) (Hyvä Checkout and its commercial products remain paid). Agency analyses of HTTP Archive data report mobile Core Web Vitals pass rates around 65% for Hyvä versus 41% for Luma — secondhand figures, but consistent with what developers see. [Breeze](https://swissuplabs.com/magento-2-breeze-evolution-theme.html) takes a different route: it keeps Luma compatibility, so existing Luma extensions keep working, while replacing the heavy JavaScript layer. For a new build, Hyvä is now the default choice; for an established Luma store with many extensions, Breeze is often the faster path. I cover the trade-offs in [Hyvä, Breeze, Edge Delivery Services and FastMagento](https://www.parkktech.com/hyva-breeze-eds-fastmagento-frontend-backend-magento-speed/). ### Is FastMagento compatible with Hyvä, Breeze and Luma? Yes. FastMagento is mostly backend, so it is theme-agnostic, and its storefront JavaScript (autocomplete and instant search) has no dependencies — no jQuery, RequireJS, Alpine or Knockout — so the same build runs on every theme. It has been verified end to end on one store, switching only the theme: ThemeListingPDP swatchesAdd to cartCheckoutHyvä 1.5.2✓✓✓✓Luma✓✓✓✓Breeze Blank 2.10✓✓✓✓**FastMagento Checkout** runs on Luma and Breeze as-is. On Hyvä it uses Magento’s Luma-based checkout, so you need Hyvä’s `hyva-themes/magento2-luma-checkout` fallback module and must deploy the `Magento/luma` static content alongside your Hyvä theme. The themes speed up painting; FastMagento removes the data cost underneath. You want both. ### Should You Merge or Bundle JavaScript in Magento 2? OptionVerdict in 2026Minify JS and CSSYes, alwaysMerge JS filesLittle gain on HTTP/2Native Magento bundlingAvoid: huge bundlesBaler / MagePackUnmaintainedHyvä or BreezeThe real fixMagento’s own Baler bundler has not been updated since 2020 and MagePack has been quiet since late 2023. Bundling Luma harder is a dead end; replacing its JavaScript layer is not. ### Critical CSS, Fonts and Third-Party Scripts - **Critical CSS:** Magento supports inlining critical CSS (*Advanced → Developer → CSS Settings → Use CSS critical path*); Hyvä and Breeze handle it for you. - **Fonts:** self-host, preload the one or two you use above the fold, and use `font-display: swap`. - **Third-party scripts:** chat widgets, review widgets and tag managers are the most common INP killers. Load them after interaction or idle, and remove the ones nobody uses. ### Magento Image Optimization: WebP, AVIF and Lazy Loading - Serve **WebP or AVIF** — through Fastly Image Optimizer on Adobe Commerce Cloud, an image CDN, or an extension. - Set image sizes in your theme’s `view.xml` so you never send a 2,000-pixel image to a 300-pixel slot. - **Preload the LCP image** (usually the hero or main product image) and never lazy-load it; lazy-load everything below the fold. - Always set `width` and `height` to prevent layout shift (CLS). How to Speed Up Magento Checkout -------------------------------- ![An online checkout screen with payment details and a shopping cart](https://images.unsplash.com/photo-1757301714935-c8127a21abc6?ixid=M3w4ODMzNjJ8MHwxfGFsbHx8fHx8fHx8fDE3OTA2NTc1ODF8&ixlib=rb-4.1.0&w=1520&q=80&fm=jpg&fit=crop&ar=16:9)Photo by [Ze Vieira](https://unsplash.com/@zfvl?utm_source=parkk_blog&utm_medium=referral) on [Unsplash](https://unsplash.com/?utm_source=parkk_blog&utm_medium=referral)Checkout is never cached, recalculates the cart on almost every step, and on Luma is assembled from dozens of KnockoutJS components. It is also the page closest to revenue. There are two separate problems: - **Backend:** every totals collection reloads products, prices, catalog rules and stock — per line item. Each configurable line adds roughly 230 ms natively in my measurements. - **Frontend:** the native checkout waits for a large `window.checkoutConfig` payload before a shopper can type an email. OptionFixesCostOne-step checkout extensionsFewer steps (UX)~$79–$319+Hyvä CheckoutFrontend rewrite€1,000 + €250/yrBoltHosted checkoutPer transactionAdobe checkout drop-inEDS storefront checkoutAdobe CommerceFastMagento Fast CheckoutBackend cart/totalsFree, open sourceFastMagento CheckoutInstant-paint frontendFree, open sourceWhere native Magento’s ~217 queries go when it builds the cart’s line items EAV 119Stock 7127 - **119** EAV attribute loads - **71** MSI stock checks - **27** downloadable-product lookups **Fast Checkout** (built into FastMagento) serves cart lines from the index instead of looping the inventory tables — native Magento loops them around 30 times to add one product to the cart. Checkout render time stays flat as the cart grows: ![Chart: Magento checkout render time by cart size, native checkout versus FastMagento Fast Checkout](https://www.parkktech.com/wp-content/uploads/2026/09/fastmagento-fast-checkout-cart-size.png)Native checkout grows with every configurable line; Fast Checkout stays near 0.4 seconds. Warm render on the reference storefront.Order placement still re-checks salable quantity, so it cannot oversell, and any product missing from the index falls back to native loading. **FastMagento Checkout** fixes the frontend with an “islands” design: the contact and shipping form is static HTML that is typeable immediately; the payment step boots Magento’s own Knockout payment component on its own, so Stripe, PayPal, Braintree and reCAPTCHA work unchanged; and the heavy per-quote configuration loads in the background from its own endpoint, which keeps the page shell cacheable. It adds Google Places address autocomplete, saved addresses served from the browser with no SQL, inline validation and guest-order linking. It makes no schema changes, and if the configuration cannot load it redirects to the stock checkout automatically — add `?fastcheckout=0` to any checkout URL to compare. I have not yet published standalone timing benchmarks for this module. The full comparison is in [FastMagento Checkout vs Hyvä Checkout, One-Step Checkouts and Bolt](https://www.parkktech.com/fastmagento-checkout-vs-hyva-checkout-one-step-checkout-bolt/). Magento CDN Setup: Cloudflare, Fastly and Edge Caching ------------------------------------------------------ - **Static assets and media** belong on a CDN (Fastly, Cloudflare, CloudFront, Bunny) with long cache lifetimes; Magento’s static-content versioning makes that safe. - **Brotli and HTTP/2 or HTTP/3** should be on at the edge. - **HTML at the edge** is powerful but needs Magento-aware rules: bypass on cart, customer and private-content cookies. Without them, a CDN simply passes HTML through to your origin — useful for security and TLS, but not a replacement for Varnish. How to Fix Magento Core Web Vitals (LCP, INP, CLS) -------------------------------------------------- MetricUsual Magento causeFixLCPSlow TTFB on cache missVarnish + FastMagentoLCPOversized hero imageWebP/AVIF, preloadLCPRender-blocking CSS/JSCritical CSS, Hyvä/BreezeINPLuma JS, third-party tagsLighter theme, defer tagsINPCheckout Knockout bootIslands checkoutCLSImages without dimensionsSet width and heightCLSLate banners, fontsReserve space, swap fontsNote that INP replaced First Input Delay (FID) as a Core Web Vital in March 2024; guides still citing FID are out of date. Magento Load Testing and Performance Monitoring ----------------------------------------------- - **Load test** before peak season with k6 or JMeter, using realistic journeys — search, filter, add to cart, checkout — not just the home page. - **Real-user monitoring:** watch CrUX in Search Console and PageSpeed Insights monthly; add an RUM tool for per-template data. - **Performance budgets:** run Lighthouse CI in your deploy pipeline and fail builds that exceed agreed JavaScript weight or LCP. - **Re-measure after every extension install.** Most regressions arrive in a `composer require`. Live Demo: FastMagento on DIYoffroad.com ---------------------------------------- ![A truck driving down a dirt road in the desert](https://images.unsplash.com/photo-1730988388358-05a976ecb3a9?ixid=M3w4ODMzNjJ8MHwxfGFsbHx8fHx8fHx8fDE3OTA2NTc1ODF8&ixlib=rb-4.1.0&w=1520&q=80&fm=jpg&fit=crop&ar=16:9)Photo by [Maxence Amé](https://unsplash.com/@maxence_ame?utm_source=parkk_blog&utm_medium=referral) on [Unsplash](https://unsplash.com/?utm_source=parkk_blog&utm_medium=referral)The FastMagento reference storefront is [DIYoffroad.com](https://www.diyoffroad.com/), an off-road parts store that I own and use as the live testbed for both extensions. It runs Magento 2 with a **Breeze** frontend, **FastMagento** and **FastMagento Checkout**, behind Cloudflare — the “fast frontend plus fast backend” combination this guide recommends. Things to try: - Type into search and watch autocomplete fill as you type. - Search for *a-arm*, then *control arm*, or *front end* then *frontend*, and compare results. - Filter the search results and notice the grid updates without a page reload. - Add a product to the cart and open checkout: the form is typeable before the payment methods finish loading. Because it is a real store on shared infrastructure, timings you see will vary with your location and its traffic; the controlled benchmarks above are the numbers to compare. Magento 2 Speed Optimization Checklist -------------------------------------- 1. Production mode on; all cache types enabled. 2. Varnish or Fastly configured; hit rate above 90%; no stray `cacheable="false"`. 3. Supported stack: 2.4.8+ (or Mage-OS 3), PHP 8.3+, OpenSearch 2.x. 4. OPcache sized to Adobe’s recommendations; PHP-FPM sized to RAM. 5. Cache and sessions in Valkey (or Redis on older versions), separate databases. 6. Indexers on schedule; cron running every minute; queues consumed. 7. Flat catalog off; database buffer pool sized; slow query log reviewed. 8. Extensions profiled; N+1 loops fixed or removed. 9. Uncached reads served from OpenSearch with FastMagento. 10. Bots and filter crawl controlled. 11. Hyvä or Breeze frontend; JS minified; no native bundling. 12. Images WebP/AVIF, sized, LCP image preloaded, dimensions set. 13. Fast Checkout on; FastMagento Checkout or Hyvä Checkout on the frontend. 14. CDN with Brotli and HTTP/2–3. 15. Field data watched monthly; load test before peak; budgets in CI. Does Page Speed Affect Magento Conversion Rates? ------------------------------------------------ Deloitte and Google’s [Milliseconds Make Millions](https://web.dev/case-studies/milliseconds-make-millions) study of 37 brands found that a 0.1-second improvement in mobile site speed was associated with an 8.4% increase in retail conversions and a 9.2% increase in average order value. Portent’s analysis found B2C e-commerce conversion rates of 3.05% for pages loading in one second versus 1.12% at three seconds ([Portent](https://portent.com/blog/analytics/research-site-speed-hurting-everyones-revenue.htm)). Both are correlations, not guarantees — but every study points the same way. Frequently Asked Questions -------------------------- Why is Magento 2 so slow?Usually two things: pages that miss the full-page cache, where Magento loads products through its multi-table EAV model and runs hundreds or thousands of SQL queries, and a heavy default Luma frontend. Fix the server side with Varnish, a current stack and faster data loading, and the browser side with a lighter theme and optimized images. What is a good TTFB for Magento?Aim for under 0.3 seconds on cached pages and under 0.8 seconds on uncached pages such as search, cart and checkout. Google’s own threshold for a good Largest Contentful Paint is 2.5 seconds, and TTFB is the first part of it. What is the single biggest Magento speed improvement?For most stores, a correctly configured full-page cache such as Varnish or Fastly in production mode. After that, the biggest remaining gains are usually uncached traffic — search, filters, cart and checkout — and the frontend theme. Should I merge or bundle JavaScript in Magento 2?Minify, yes. Merging gives little benefit over HTTP/2, and Magento’s native bundling tends to create very large bundles. Baler and MagePack are no longer actively maintained. The effective fix in 2026 is a lighter frontend such as Hyvä or Breeze. Do I need Varnish and Redis?You need Varnish (or Fastly) for full-page caching in production, and an in-memory store for cache and sessions. On Magento 2.4.8 and later that should be Valkey, since Adobe no longer supports Redis for cache from 2.4.9 onward. Is Hyvä free?Yes. The Hyvä theme became free and open source in November 2025. Hyvä Checkout and Hyvä’s other commercial products are still paid. Is FastMagento compatible with Hyvä and Breeze?Yes. FastMagento has been tested end to end on Hyvä 1.5.2, Luma and Breeze Blank 2.10. FastMagento Checkout runs on Luma and Breeze, and on Hyvä it requires Hyvä’s Luma-checkout fallback module plus the Luma static content. Should I enable the flat catalog?No. On current Magento versions Adobe no longer recommends the flat catalog; it adds indexing overhead and can reduce performance. How do I speed up Magento checkout?Address both halves: the backend, where cart totals reload product, price and stock data for every line, and the frontend, where the native checkout waits for a large configuration payload. FastMagento’s Fast Checkout targets the backend; FastMagento Checkout or Hyvä Checkout targets the frontend. I did everything and my store is still slow. What now?Measure an uncached page and profile it. The cause is almost always a third-party extension running queries in a loop, a cache that is being bypassed or purged too often, or bots hammering uncached filter URLs. Want a second pair of eyes on your store? ----------------------------------------- I have led Magento for brands like Yamaha USA, Rubie’s, simplehuman and eos, and I build the tools in this guide. Bring me the store three agencies could not make fast. The first conversation is free, and I will tell you honestly where your time is going. [Start the conversation](https://www.parkktech.com/contact/) --- **Parkk Technology** — Custom Software Development, AI Integration, and Equity Partnerships - Custom Software Development: We build the software your business actually needs — scoped, shipped, supported. - AI Integration for Existing Businesses: Add AI capabilities to what you already have — without rebuilding everything. - Equity Partnership: Considered case by case for validated problems. No fixed package. Contact: https://www.parkktech.com/contact | Author: Jason Ratzlaff, founder of Parkk Technology