Magento Performance Optimization: The Complete Guide

A merchant forwards you a Lighthouse report. The mobile score reads 18, the largest contentful paint reads 4.8 seconds, and checkout abandonment has crept up two quarters in a row. The catalog is healthy, the campaigns are converting on paid social, but the store itself feels like it is wading through mud. This is the moment most Magento (Adobe Commerce) performance projects actually begin, not with a clean install, but with a store that has accumulated extensions, theme overrides, and third-party scripts until speed quietly became the bottleneck on revenue.

Out of the box, Magento is the slowest of the major eCommerce platforms. According to the PageSpeed Matters eCommerce platform speed ranking, a stock Magento storefront posts a median LCP near 3.8 seconds and passes Core Web Vitals only about 28% of the time. The same data shows the upside: a properly optimized Magento store running Hyvä, Varnish, and a CDN reaches 1.2 to 1.6 second LCP, competitive with an optimized Shopify build. The platform is not slow because it is incapable. It is slow until someone tunes the full stack. This guide walks the levers that matter, from the server up to the frontend.

What slows a Magento store down?

A Magento store slows down when work that should be cached, deferred, or removed is happening on every page load instead. The usual offenders are an unindexed or query-heavy database, full-page cache that is disabled or missing Varnish, too many third-party extensions injecting JavaScript, unoptimized images, and the legacy Luma frontend shipping far more code than a modern storefront needs.

It helps to separate the two halves of the response. Time to first byte, the gap before the server even starts sending HTML, is a backend story driven by hosting, PHP, caching, and the database. Everything after that, the render and interactivity the shopper feels, is a frontend story driven by JavaScript, images, and the theme. A store can have a fast server and a painful frontend, or the reverse. You have to measure both before deciding where to spend.

The other trap is extensions. Every module a merchant installs over the years adds observers, layout XML, and often its own JavaScript bundle. DebugBear notes that reducing the number of active extensions and serving images in optimized formats are among the highest-impact moves available, precisely because extension bloat compounds silently as a catalog matures.

Hosting and the server stack

Performance starts with where Magento runs. The fastest application code cannot rescue an underpowered server, a shared host, or a PHP version Adobe no longer tunes for. Magento is CPU and memory hungry, and time to first byte is decided here before a single line of frontend code executes.

Adobe’s own performance best-practice documentation is direct about the foundation: run the store in production mode, stay on a currently supported PHP release, and provision enough dedicated CPU and RAM for the catalog size. Production mode alone removes the on-the-fly code generation and symlinking that cripples developer-mode stores. For larger catalogs, separating the database, Redis, and the web tier onto their own resources prevents one component from starving another under load.

This is also where managed Magento hosting earns its keep. A tuned stack with Nginx, the right PHP-FPM worker counts, OPcache sizing, and Varnish in front is a different machine from a generic VPS with default settings. scandiweb runs stores on a managed AWS stack built specifically for Magento, and the difference at the TTFB layer is usually the first thing a speed audit surfaces.

Full-page cache with Varnish

Varnish is the single highest-impact caching layer for a Magento storefront. It stores fully rendered page HTML in memory and serves it to anonymous visitors without touching PHP or the database at all, turning a multi-hundred-millisecond render into a near-instant response. Adobe recommends Varnish over Magento’s built-in file cache for any production store.

The mechanics matter. Magento ships with full-page caching, but the default file-based driver still routes requests through PHP. Pointing full-page cache at Varnish moves the work to a reverse proxy that answers from RAM. Adobe’s guidance puts the TTFB saving from Varnish at roughly 0.3 to 0.8 seconds, which on a cold catalog page is often the difference between a passing and a failing Core Web Vitals score.

The honest limitation is that Varnish caches anonymous traffic. Logged-in customers, cart pages, and checkout bypass it by design, which is exactly why the next layer exists.

Redis for sessions and cache

Redis handles the work Varnish cannot. It stores Magento sessions and the application cache in memory rather than on disk or in the database, which keeps logged-in customers, the cart, and checkout fast. Adobe estimates Redis trims roughly 0.2 to 0.5 seconds for authenticated users compared with file or database-backed sessions.

The standard pattern is two Redis instances, one for the default and page cache, one for sessions, kept separate so a session flush never wipes the cache and vice versa. This is the configuration Adobe Commerce Cloud provisions automatically, and it is the configuration any serious self-hosted store should match. Without it, every logged-in request and every checkout step pays a disk or database penalty that Varnish was never going to cover.

Database and indexer tuning

The database is where Magento’s flexibility becomes its tax. The EAV model spreads product data across many tables, and a store with stale indexes or unscheduled reindexing forces expensive joins on page load. Keeping indexers on the “update by schedule” mode, so they rebuild via cron in the background rather than on save, is the baseline fix.

From there, the work is operational: prune the database logs and old quote tables that grow unbounded, tune MySQL or MariaDB buffer sizes to the available memory, and watch the slow query log for the joins that spike under traffic. Much of this is the steady-state work that ongoing Magento support keeps on top of, and it is also where our own before-and-after data, shown later, recorded the largest single improvement, requests dropping by more than half once query load was brought under control.

Image optimization and lazy loading

Images are usually the heaviest asset on a Magento product or category page, which makes them the most direct lever on largest contentful paint. The two moves that matter most are serving modern formats and deferring what is below the fold. Both are well within reach of any store.

Serving images in WebP, as DebugBear and Adobe both recommend, cuts file weight substantially against legacy JPEG and PNG without a visible quality loss. Pair that with native lazy loading so off-screen images do not compete for bandwidth during the initial render, and explicit width and height attributes so the browser reserves space and avoids layout shift. On a media-heavy catalog page, WebP plus lazy loading is frequently the cheapest path to a passing LCP.

JavaScript and CSS bundling with MagePack

On a Luma-based Magento store, JavaScript is often the largest contributor to slow interactivity. The default RequireJS setup loads a long chain of small modules, and bundling them reduces both the number of requests and the total payload the browser has to parse before a page becomes usable.

MagePack is the tool we have used and had success with here. For each page loaded in the browser, it builds the bundles so that any given page only needs to download a shared common bundle plus a page-specific bundle, rather than dozens of individual module requests. The package is well documented, and on a clean installation a team can usually fit both implementation and QA into roughly 20 development hours.

How MagePack bundling works

The common approach is to define bundles by page type. Magento groups pages into categories such as category, product, CMS, cart, and checkout, and each type has a different set of RequireJS module dependencies. When the modules for a type are bundled together, you end up with a handful of bundles that cover the dependencies of any page in the store, instead of a request per module.

An alternative is to bundle by purpose, grouping common features, product features, checkout features, taxes, and form validations. There are no fixed rules. Some bundling strategies work better than others depending on the structure of the store and its customizations. Splitting bundles by page type gives a solid result on a clean Magento installation, while heavily customized stores need more analysis to decide how to distribute assets. Note that bundling is a Luma-era optimization. Stores on Hyvä, covered below, drop RequireJS entirely and largely sidestep the problem.

CDN for global delivery

A content delivery network puts static assets, images, CSS, JavaScript, and fonts, on edge servers close to the shopper, cutting the round-trip distance that adds latency on every request. For any store serving customers across regions, a CDN is required coverage, not an extra.

Adobe Commerce Cloud bundles Fastly, which doubles as both CDN and the Varnish layer, so the two responsibilities are handled by one service at the edge. Self-hosted stores commonly pair Cloudflare or a comparable CDN with their own Varnish instance. Either way, the goal is the same: serve the bytes from the nearest point of presence so distance stops being a tax on load time.

Hyvä as the current frontend path

For years the frontend question was whether to move off Luma to a PWA. The answer the market settled on is Hyvä, a Magento theme that rebuilds the frontend on Tailwind CSS and Alpine.js, drops RequireJS and most of the legacy JavaScript, and ships a fraction of the code Luma does. It is now the default choice for new enterprise Magento frontends rather than a niche bet.

The performance gap is stark. Hyvä’s own benchmarks put Hyvä sites at an average LCP near 1.2 seconds and a Core Web Vitals score around 88, against Luma’s roughly 4.8 second LCP and a score near 31. Adoption tracks the data: as of early 2026 Hyvä powers nearly 6,400 live sites, and it now accounts for the majority of new enterprise Magento deployments.

This is where scandiweb’s first-party experience is clearest. In a Hyvä storefront case study for a global home brand, replacing the Luma bottleneck cut mobile blocking time by up to 91% and turned Core Web Vitals all green. For teams planning the move, our guide on how to work with Hyvä covers the implementation details, from theme fallback to deployment on Adobe Commerce Cloud.

How to improve Magento Core Web Vitals?

To improve Magento Core Web Vitals, attack each metric directly: lower LCP by serving WebP images, preloading the hero asset, and enabling Varnish for fast HTML delivery, reduce INP by trimming and bundling JavaScript or moving to Hyvä, and eliminate CLS by setting explicit image and ad dimensions so nothing shifts as the page loads.

The three metrics map cleanly onto the layers above. LCP, the load metric, responds to caching, image optimization, and a fast server. Interaction to next paint, the responsiveness metric that replaced first input delay, responds to lighter JavaScript, which is exactly what bundling and Hyvä deliver. Cumulative layout shift, the stability metric, responds to reserved space for images, embeds, and shifting banners.

Core Web Vitals are also why platform choice keeps coming up in performance conversations. Merchants weighing whether the effort is worth it often compare paths, and our Magento vs Shopify comparison lays out where each platform lands on speed, cost, and control. An optimized Magento store closes most of the gap, which is the whole point of treating performance as a project rather than a setting.

Our experience with JavaScript bundling

Below is a before-and-after audit sample from a project where our team applied JavaScript bundling on a Luma store. It is first-party data from a real store, not a synthetic benchmark, and it shows both the wins and the honest trade-offs of a frontend-only optimization pass.

The wins are concentrated where bundling does its work. Total blocking time on desktop dropped from 2,290 to 47, and database requests fell by more than half. The regressions, the mobile LCP and the desktop CLS, are a real reminder that a frontend-only pass on a Luma store has a ceiling. The same store on a tuned backend with Varnish, Redis, and a Hyvä frontend would not carry those trade-offs, which is exactly why the modern answer is the full-stack approach rather than bundling alone.

FAQ

How long does Magento performance optimization take?

A focused frontend pass such as JavaScript bundling on a clean store fits in roughly 20 development hours. A full-stack project covering hosting, Varnish, Redis, database tuning, image delivery, and a Hyvä frontend migration runs longer, typically several weeks, depending on catalog size and customization depth.

Is Varnish or Redis more important for Magento speed?

They solve different problems, so a fast store needs both. Varnish caches fully rendered pages for anonymous visitors and delivers the largest single TTFB win. Redis keeps logged-in customers, the cart, and checkout fast by holding sessions and cache in memory, which Varnish cannot cover.

Does moving to Hyvä improve Core Web Vitals?

Yes, significantly. Hyvä drops RequireJS and most of Luma’s legacy JavaScript, which directly improves interaction to next paint and largest contentful paint. Published benchmarks show Hyvä sites averaging around 1.2 second LCP versus Luma’s roughly 4.8 seconds, with Core Web Vitals scores roughly tripling.

Is Magento slower than Shopify?

Out of the box, yes. Stock Magento is the slowest major platform on median load time. Optimized, the gap closes: a Magento store on Hyvä with Varnish and a CDN reaches 1.2 to 1.6 second LCP, competitive with an optimized Shopify build. The difference is the tuning, not the platform ceiling.

Is Magento still worth investing in for performance?

For stores with large catalogs, complex B2B logic, or deep customization, yes. Magento scales where simpler platforms struggle, and an optimized stack performs well. Our analysis of whether Magento is dying covers where the platform still fits and where it does not.

What metrics should I monitor for Magento performance?

Track time to first byte, full page load time, cache hit ratio, server response time, database query time, and CPU and memory utilization. TTFB and cache hit ratio surface backend and caching issues, while the Core Web Vitals trio of LCP, INP, and CLS reflects what shoppers actually experience.

On Magento, speed is revenue. Audit your store speed with our team and find the layer that is costing you conversions.

Share on: