How to Speed Up a Magento Store in 2026: The Performance Playbook for 2.4.8

Most Magento speed guides open with “clear your cache.” Skip that advice. By the time caching is your bottleneck, you’ve already lost the stack argument. A one-second delay costs Magento stores 7% of conversions, and Tideways’ Q2 2025 benchmark shows the slowest 25% of Magento 2 stores hitting 3-second TTFB on their worst pages. The 2026 wins live in the hosting stack (PHP 8.3+, Valkey 8, Varnish 7.6) and in what you do before the first request ever lands. Magento 2.4.8 (current stable as of March 2026) fixed part of it. The rest is on the store owner.

Quick answer: Run Magento 2.4.8 on PHP 8.3+ with Valkey 8 handling cache, Varnish 7.6 doing full-page, and OpenSearch 2.19 powering catalog search. Switch the storefront to Hyvä if revenue justifies the project. Hyvä sites hit 65% excellent Core Web Vitals versus 41% on Luma. Every step below scores against that baseline.

Last reviewed: April 2026. Version numbers, cache stack, and benchmark data verified against Adobe Commerce release notes and Tideways Q2 2025 report.

Why Magento Speed Is a Revenue Problem

Shoppers don’t grade Magento stores on architecture. They bail. Contentsquare data shows 57% of shoppers abandon a page that takes longer than three seconds to load, and conversion drops 4.42% for every extra second after that. Checkout is worse. More than half of users walk if checkout takes longer than 30 seconds end to end.

Magento starts behind. Stores built on the platform see cart abandonment in the 72-76% range versus the global ecommerce average of 78.77% as of August 2025. That gap sounds small until you remember Magento merchants run much higher average order values than Shopify or WooCommerce shops. A 2% conversion lift on a store pushing USD 4M in GMV (Gross Merchandise Value, total sales processed) is roughly USD 80,000 per year of recovered revenue.

None of this is theoretical. Tideways’ Q2 2025 report logged uncached Magento 2 TTFB at 2 seconds for the slowest 25% of stores and past 3 seconds at the 95th percentile. That’s before your theme, your CDN, your extensions, or your hosting enter the picture. It’s the baseline.

The Real Causes of a Slow Magento 2 Store

Most performance work fails because owners chase symptoms. Skip the generic “clear cache and hope” routine. These are the six patterns that actually account for slow Magento 2 stores in 2026:

• PHP underspecced or misconfigured. Running PHP 8.1 on 2.4.8 works, sort of, but OPcache, JIT, and type-system improvements in PHP 8.3 compound on Magento workloads. If your host is on 8.0 or 8.1, you’re leaving measurable TTFB on the table and inheriting security risk on versions Adobe no longer tests.
• Cache stack incomplete. Varnish without Valkey (or Redis), or Valkey without Varnish, is the most common broken setup. Varnish 7.6 handles full-page caching for anonymous traffic. Valkey 8 handles cache, sessions, and object cache for logged-in traffic. You need both.
• OpenSearch missing or undersized. Magento 2.4.8 requires OpenSearch 2.19. Elasticsearch is deprecated. Some stores still run ancient ES 7.x and wonder why search pages take four seconds.
• Extension bloat. Every third-party extension is a potential plan killer for the dependency injection compiler and for runtime checks. A store with 80+ extensions almost always has one misbehaving observer on the checkout event.
• Luma on commodity hosting. Luma was designed for 2015. It was not designed for Core Web Vitals. Hyvä was.
• Images served as raw JPEG. WebP is 25-34% smaller than JPEG. AVIF halves file size again on hero product shots. Most stores still ship 400KB product images and wonder why LCP (Largest Contentful Paint, how long the biggest visible element takes to render) is 4 seconds.

Where your store sits on that list determines the order of what follows.

Speed Up Magento Step-by-Step

This is a build order. Do the steps top-to-bottom. Skipping early steps and jumping to “optimize JavaScript” is the Magento equivalent of painting a house before fixing the foundation.

1. Upgrade to Magento 2.4.8 (or 2.4.9 When It Lands)

Magento 2.4.8-p4 is the current stable release as of March 10, 2026. Version 2.4.9-beta1 is in testing with GA expected May 2026, dropping MySQL 8.0 and MariaDB 10.6 and requiring PHP 8.4 or 8.5.

A quick note on naming. Adobe Commerce and Magento Open Source share the same core codebase and the same version numbers. Adobe Commerce layers on B2B quoting, commerce staging and preview, advanced reporting, and the managed Adobe Commerce Cloud hosting stack. Performance tips in this guide apply to both. Adobe Commerce customers on the Cloud tier get Fastly, New Relic, and managed Varnish bundled, so steps 3 and 8 below already come pre-configured on that tier.

Why upgrade? 2.4.8 flips all indexers to Update by Schedule mode by default on new installs and upgrades. That alone cuts admin product-save lag and checkout update latency for most stores, because the previous default (“Update on Save”) blocked every save on full reindex. The 2.4.8 release also improved bulk tier-price updates via the REST API, which matters for B2B catalogs.

Running 2.4.5 or earlier? You’re on unsupported code. Start your performance work here, not with caching tweaks on dead branches.

2. Fix the Hosting Stack Before Anything Else

No amount of caching rescues a 1 vCPU / 2 GB shared plan running Magento. The honest minimum for a production 2.4.8 store is 4 GB RAM, with 8-16 GB the practical floor for anything past 500 daily orders. Our Magento VPS hosting roundup breaks down which providers ship the right stack out of the box.

Here’s a specific diagnostic. If your host can’t install OpenSearch 2.19 or doesn’t let you run Varnish 7.6, you’re not on Magento-capable hosting. Migrate before you spend another weekend chasing TTFB on a stack that can’t support the store.

3. Configure Varnish Plus Valkey (or Redis) Properly

Varnish 7.6 is the full-page cache. Configured right, it serves cached pages at sub-200ms TTFB versus 2-5 seconds uncached. The benchmark numbers back it up: cached-from-Varnish requests don’t even appear in Tideways’ slow-TTFB percentiles because they’re that much faster.

Configuration checklist:

• Varnish backend host and port point to your real web server
• Access list (ACL) restricted to admin IPs that should purge cache
• Grace period set to at least 10 minutes (serves stale content while fetching fresh)
• Magento set to use Varnish under Stores > Configuration > Advanced > System > Full Page Cache

Then layer Valkey 8 (or Redis 7.2) for cache, session storage, and object cache. Valkey 8 is the recommended new-install backend for 2.4.8. Redis 7.2 still works for existing stores. Valkey’s edge over Redis on Magento is under memory pressure, where it holds latency better on session reads.

4. Switch the Storefront to Hyvä

Hyvä sites score around 90-100 on Google PageSpeed by default, and 65% of Hyvä stores hit excellent Core Web Vitals versus 41% for Luma stores. The JavaScript payload is a fraction of Luma’s because Hyvä dropped RequireJS and Knockout in favor of Alpine.js and Tailwind.

Here’s the 2026 update most guides haven’t caught: Hyvä went MIT-licensed and free in late 2024. There’s no per-domain theme license anymore. What still costs money is the migration work on a customized Luma store, typically 80-200 hours, plus optional paid add-ons like Hyvä Checkout (EUR 1,000), Hyvä UI (EUR 250), or Hyvä Enterprise (EUR 2,500) if you need them. For any revenue-generating storefront, this is the single biggest Core Web Vitals move available. Still stuck on Luma? Our Magento theme roundup covers faster Luma-compatible options, though none of them close the Hyvä gap.

Important caveat: only 51% of Hyvä shops actually hit good CWV. The theme sets your ceiling. Poor implementation still lowers the floor. Audit third-party modules compiled into the Hyvä theme before you assume you’re done.

5. Enable Production Mode (Properly)

This one’s quick and people still miss it. Magento has three modes: default, developer, and production. Developer and default modes regenerate view files on every request, log aggressively to var/log, and skip the compiled dependency injection configuration. Production mode pre-compiles dependency injection, deploys static view files once, and strips development error output.

The one-line switch:

• php bin/magento deploy:mode:set production

Under the hood that command runs setup:di:compile and setup:static-content:deploy. You can also run those two commands manually during a deploy window without switching modes, which is how most CI pipelines handle it. The payoff is measurable: switching a misconfigured store from developer mode to production commonly drops TTFB 30-50% without any other change, because every request stops paying the DI generation and static file rebuild tax.

If you’re deploying from staging to production, run the compile and deploy steps on staging and rsync the generated files. Avoid regenerating on production during peak hours. Compile spikes CPU for 3-8 minutes depending on theme complexity, and static content deployment can push that to 10-15 minutes on Hyvä sites with multiple locales.

6. Optimize Images With AVIF and WebP

Native lazy loading has shipped in Magento since 2.4.0 using the HTML loading=”lazy” attribute on catalog images. If it was disabled during a theme customization, re-enable it.

Beyond that, push images through modern formats:

• WebP: cuts JPEG size by 25-34% with near-identical visual quality
• AVIF: cuts file size another 40-50% versus WebP, at the cost of more CPU to encode
• For product photography, AVIF is worth the encode time because color fidelity holds

Fastly Image Optimization (on Adobe Commerce Cloud) does format negotiation automatically per browser. Self-hosted stores can use extensions like the JaJuMa Ultimate Image Optimizer or bake AVIF generation into the deploy pipeline. Either way, CDN-level image transformation outperforms per-request PHP conversion for any store doing more than a handful of SKU uploads per week.

7. Prune Extensions That Murder TTFB

Every installed extension ships at least one plugin, observer, or preference. Many ship dozens. The checkout event is the single most-observed event in Magento and the single most common source of 500-800ms TTFB regressions.

Audit workflow:

1. Run bin/magento module:status and list enabled third-party modules
2. Disable non-critical modules one by one on staging
3. Benchmark checkout TTFB after each disable
4. Keep disabled anything that saves 100ms+ without obvious business cost

Look closely at modules in the shipping, promotions, and B2B categories. Those carry the heaviest checkout-event load.

8. Add a CDN With Cache Rules That Actually Cache

Cloudflare, Fastly, or KeyCDN in front of Magento is table-stakes. The mistake is leaving default rules alone. Out of the box, most CDNs bypass cache for anything with a query string, which kills caching for filterable category pages with ?p=2 pagination.

Minimum cache-rule set:

• Static assets (JS, CSS, fonts, images): cache 1 year, serve stale-while-revalidate
• Category pages: cache 1 hour for anonymous, bypass for logged-in
• Product pages: cache 4-12 hours, bypass for logged-in
• Cart, checkout, customer account: bypass entirely

Magento’s Full Page Cache headers tell Varnish what’s cacheable. The CDN should respect those headers. If you’re overriding with blanket rules, you’re working against Magento’s own cache logic.

Also enable HTTP/3 at the CDN layer if it’s an option (Cloudflare and Fastly both support it). HTTP/3 uses QUIC instead of TCP, which recovers from packet loss faster on mobile networks. Real-world mobile LCP improvements of 100-300ms are typical on 4G connections, which is the difference between “loading” and “loaded” for a lot of shoppers.

9. Rebuild Indexers and Maintain the Database

Even with 2.4.8’s Update by Schedule default, indexers drift. Run bin/magento indexer:reindex on a weekly cron minimum, plus targeted reindex after bulk catalog imports.

Database maintenance nobody does:

• Truncate quote and quote_item tables quarterly (abandoned carts accumulate forever)
• Clean sales_bestsellers_aggregated_* if you don’t use the reports
• Archive orders older than 24 months using Adobe Commerce’s built-in archive (Open Source users need a third-party tool)

A 6 GB quote table slows every admin query. Most Magento stores have never truncated it.

10. Defer JavaScript and Merge CSS Carefully

Enable JS minification, merging, and bundling under Stores > Configuration > Advanced > Developer. Bundling reduces request count. Minification cuts payload. Deferring non-critical JS (analytics, chat widgets) prevents them from blocking initial render.

One warning. Advanced bundling on Luma has known regressions for specific third-party modules. Test on staging with synthetic Lighthouse runs before flipping it on production.

How to Diagnose Where Your Store Is Actually Losing Time

Optimization without measurement is guesswork. This is the diagnostic stack we’d run on any Magento store before touching a single setting:

• PageSpeed Insights + CrUX: real-user data from Chrome. Focus on three Core Web Vitals at the 75th percentile: LCP (Largest Contentful Paint, Google’s “good” threshold is under 2.5s), INP (Interaction to Next Paint, target under 200ms), and CLS (Cumulative Layout Shift, target under 0.1).
• Tideways or New Relic APM: transaction-level PHP tracing. Tells you which controllers, observers, and plugins eat time.
• DebugBear or SpeedCurve: synthetic monitoring with historical trends. Catches regressions after deploys.
• Magento’s built-in profiler: enable via .htaccess, inspect the output on slow pages.

Check the 95th percentile, not the median. Your median might be fine. The 5% of slowest pages are usually where cart abandonment hides.

When to Bring in a Magento Performance Specialist

Some performance problems aren’t DIY problems. Bring in a specialist when:

• TTFB is above 800ms with Varnish properly configured and infrastructure right-sized. That points to a deep code issue or plugin chain you won’t find with module:status.
• Checkout events have been customized heavily over 3+ years. Untangling observer chains is a full audit, not an afternoon.
• You’re planning a Hyvä migration from a customized Luma store. Budget 120-200 hours with a certified Hyvä agency for anything past a simple catalog.
• You’ve already done the first six steps in this guide and TTFB is still above 1 second.

A 40-60 hour audit from a Magento performance specialist typically runs USD 8,000-15,000. That sounds like a lot until you calculate what a 1% conversion lift is worth on your annual GMV.

Frequently Asked Questions

Is Hyvä worth it for a small Magento store doing under 500 orders per month?

The theme itself is free now (MIT-licensed since late 2024), so the only cost that remains is migration work, which runs USD 5,000-15,000 all-in for a modest store. Under 500 orders per month at USD 100 AOV, that’s still a multi-year payback window. Fix hosting, Varnish, images, and the extension audit first. Revisit Hyvä once you’re past USD 1M annual GMV, or sooner if you can absorb the migration cost up front.

What’s the minimum hosting spec for a Magento 2.4.8 production store?

4 GB RAM absolute floor, 8 GB if you’re running Varnish, Valkey, and OpenSearch on the same box, 16 GB if you have 50,000+ SKUs or run a B2B catalog. CPU matters less than RAM. Most Magento bottlenecks are memory pressure, not CPU. Our ecommerce VPS roundup lists providers that hit these specs without enterprise pricing.

Does Varnish on Magento help logged-in customers?

Not directly. Varnish serves anonymous traffic, which for most B2C stores is 70-85% of pageviews. Logged-in customers bypass full-page cache because their content is personalized. That’s where Valkey or Redis object cache matters. Your homepage and category pages will fly for new visitors. Product detail and checkout for logged-in users still falls back on PHP plus Valkey.

How much does switching to AVIF or WebP actually reduce LCP?

On a product page where LCP is a hero product image, 300-700ms improvement is typical. If your LCP image drops from 420KB to 140KB, that translates directly into faster render on any connection below 10 Mbps. Caveat: AVIF encoding is CPU-heavy, so generate at upload time (or via CDN) rather than on each request.

What’s the fastest hosting for a Magento 2.4.8 store?

“Fastest” depends on whether you want managed or self-managed. Managed Magento specialists like Nexcess and Hypernode ship a pre-tuned stack (PHP-FPM, Varnish, Redis or Valkey, OpenSearch) and typically deliver sub-300ms TTFB out of the box. On the self-managed side, a Hetzner CX32 or equivalent at 8 GB RAM with Varnish and Valkey correctly configured can match that performance at 40-60% lower monthly cost, at the price of sysadmin work. The Magento VPS roundup linked earlier in this guide has the provider-by-provider breakdown.

Is Magento slower than Shopify out of the box?

On raw page speed metrics, yes. Shopify serves most pageviews from its global edge CDN with aggressive caching, so a brand-new Shopify store typically beats a brand-new Magento store on TTFB. The gap closes dramatically once Magento is on Varnish plus a CDN. On storefront flexibility, customization depth, and B2B features, Magento wins, which is why enterprises tolerate the infrastructure complexity. If you want Shopify-like speed with Magento-level control, that’s the Hyvä plus managed hosting combo.

How do I test my Magento site speed accurately?

Run three tools and compare. PageSpeed Insights gives you Google’s official LCP, INP, and CLS at the 75th percentile from real Chrome users. WebPageTest.org lets you test from specific geographic locations and network speeds (pick a 4G Moto G4 profile for an honest mobile read). GTmetrix or DebugBear track regressions over time. Test both an anonymous category page (where Varnish should kick in) and a logged-in checkout (where it won’t). The gap between the two tells you how much work your non-cached stack is doing.

The Takeaway

The fastest route to a faster Magento store is almost never the glamorous one. Image compression, CDN cache rules, and a Hyvä migration beat a dozen extension-level micro-optimizations every time. Run 2.4.8 (or 2.4.9 once it ships in May 2026) on capable hardware, layer Varnish plus Valkey, and audit extensions ruthlessly. Most stores see 40-60% TTFB improvement from those four moves alone.

If you’re still weighing infrastructure, the NVMe hosting guide is a useful starting point. Disk I/O hits Magento checkout times hard on older SATA drives, and NVMe moves cart and quote table reads into a different latency class. Combine that with the hosting and theme guides linked above, and you have the full stack covered.