Magento 2 performance optimisation
Magento is powerful but performance-hungry. Without a correctly configured caching stack, tuned hosting, and front-end optimisation, even modest catalogs crawl on mobile. We fix the infrastructure and the front-end together.
A slow Magento store means abandoned carts, weak organic rankings, and paid traffic driven to product pages that load after the ad click has already converted to a bounce.
Magento 2 Open Source and Adobe Commerce optimisation with measurable before and after results.
Magento's flexibility and power come at a significant performance cost if the platform is not properly configured. Unlike simpler platforms, Magento requires a full caching stack — Varnish for full-page cache, Redis for session storage and object caching, and Elasticsearch or OpenSearch for catalog search — to deliver acceptable response times at scale. Without these components in place, every page request hits PHP and the database, producing TTFB times of two to four seconds before any front-end content loads.
Third-party extensions are the other major performance liability. The Magento ecosystem has thousands of extensions, and each one adds PHP observers, plugins, and event listeners that run on every request. An extension that adds a 10ms processing cost in isolation can add 200ms when it runs alongside twenty other extensions, because Magento's dependency injection and event dispatch system chains observers sequentially. Performance-testing extensions individually in staging — not just in production — is the only reliable way to identify which ones are responsible for slow TTFB.
Front-end performance on Magento also requires specific attention. The default theme ships with a substantial JavaScript bundle that includes RequireJS, jQuery, Knockout.js, and numerous Magento UI components — regardless of whether a given page template uses all of them. On mobile, parsing and executing this bundle can take 800ms–1,500ms, making INP scores fail even on stores with fast TTFB. Magento's JavaScript bundling configuration helps, but it requires careful tuning to avoid creating bundles that are too large or too numerous.
Large product catalogs amplify every one of these issues. Category pages with hundreds of products load full-resolution images for each product thumbnail. Without lazy loading and a CDN-based image resizing pipeline, the page weight of a single category can exceed ten megabytes — an LCP disaster on any mobile connection. The combination of server-side latency, JavaScript overhead, and image weight makes Magento one of the most challenging platforms to optimise — and one of the most rewarding when done correctly.
2–4s
TTFB without full-page cache
A Magento 2 store without Varnish or full-page cache configured can produce TTFB times of two to four seconds — before the browser starts parsing HTML, let alone rendering content.
800ms–1.5s
JS parse time on mobile
Magento's default JavaScript bundle, including RequireJS and Knockout.js, can take over a second to parse and execute on mid-range Android devices — directly failing INP thresholds.
20+
extensions on the average store
Most Magento production stores have more than twenty extensions installed. Each adds PHP observers that run on every request, compounding into significant server-side processing time.
Server stack, caching, front-end, and catalog performance — prioritised by revenue impact.
We configure Varnish as a full-page cache layer in front of Magento, tune cache TTLs for product, category, and CMS pages, and implement correct cache invalidation rules so content updates clear only the affected URLs. On stores without Varnish access, we configure Magento's built-in full-page cache as a fallback, reducing TTFB by 60–80% for logged-out visitors.
We set up Redis for object caching to eliminate repeated database queries for product data, configuration, and layout blocks. Session storage is moved to Redis to replace slow file-based sessions, reducing TTFB on authenticated pages. Cache backends are configured with appropriate memory limits and eviction policies to prevent thrashing under load.
Every active extension is profiled using Magento's built-in profiler and Blackfire or similar APM tooling to measure its contribution to PHP execution time. Extensions that add disproportionate observer overhead are identified and either replaced with lighter alternatives, disabled on templates where they are not needed, or refactored to run asynchronously.
We enable and configure Magento's JavaScript bundling to reduce RequireJS network requests, profile which modules are needed on each template type, and create template-specific bundles that balance request count against parse time. Unused Magento UI components are excluded from bundles for templates that do not use them.
Stylesheets from the theme and extensions are merged and minified to reduce request count and file size. Critical CSS for above-fold content on key templates — home, category, product, checkout — is extracted and inlined so the browser can paint the visible page without waiting for a full stylesheet download.
Product images are served through a CDN with on-the-fly WebP conversion and viewport-appropriate resizing. Category grid thumbnails are served at small dimensions; product page images load at full size only when viewed. Lazy loading is implemented for below-fold product images on long category pages.
We run slow query log analysis to identify and optimise the most expensive database queries, add missing indexes on frequently filtered catalog attributes, and clean up accumulated transients and expired sessions that bloat the database. On large catalogs, these changes reduce query time and improve TTFB measurably.
We improve LCP on category and product hero images through CDN delivery and preloading; INP through JavaScript bundle optimisation and extension observer reduction; and CLS from late-loading product images, price badges, and promotional banners that shift content after initial paint.
Magento performance is a systems problem, not a front-end problem. The three server-side components that matter most are Varnish (full-page cache), Redis (object and session cache), and the PHP-FPM configuration. Varnish sits in front of the web server and serves cached HTML responses for logged-out visitors without hitting PHP at all — when configured correctly, TTFB drops from two seconds to under 100ms. Redis eliminates the database round-trips that object caching would otherwise require, and ensures session data is stored in memory rather than written to disk. PHP-FPM worker configuration determines how many simultaneous PHP processes can handle requests — too few and requests queue; too many and the server runs out of memory.
JavaScript performance on Magento requires a different approach to most other platforms. The RequireJS module loader and AMD-based module system that Magento uses was a reasonable choice when Magento 2 launched in 2015, but it produces many individual network requests in development mode and a large monolithic bundle in production mode. The Magento JavaScript bundling feature can help, but it requires profiling which modules are needed on which templates and creating bundles that balance request count against bundle size. Getting this right — particularly with a custom theme and third-party extension JavaScript — typically requires a dedicated JavaScript profiling sprint.
Front-end optimisation on Magento covers images, CSS, and JavaScript. Product images should be served through a CDN with on-the-fly WebP conversion and resizing so category grids load small thumbnails and product pages load full-size images only when needed. CSS should be merged and minified, with critical CSS inlined for key templates. JavaScript should use Magento's bundle mechanism to reduce RequireJS overhead. These are all configurable within Magento's built-in optimisation settings, but each setting needs to be tested against your specific theme and extension combination — a bundle configuration that works on a clean Luma theme may break a custom theme with incompatible module dependencies.
Representative outcomes from optimization projects. Your results depend on stack and traffic.
B2B parts catalog
Before
TTFB 2.8s
After
TTFB 0.6s
Varnish configuration and Redis session storage
Fashion DTC store
Before
Mobile score 28
After
Mobile score 67
Image pipeline and JavaScript bundle optimisation
Wholesale merchant
Before
Category LCP 5.9s
After
Category LCP 2.3s
Lazy loading and product image CDN implementation
We run a deep speed and Core Web Vitals audit on your key templates — home, collection, product, and checkout where relevant. Every issue is ranked by its impact on real user experience and revenue.
We implement prioritised fixes: images, scripts, caching, and theme or app bloat — focused on revenue pages first. Each change is tested in staging and measured against a baseline.
You get ongoing checks so regressions from new apps, themes, or campaigns are caught before they hurt SEO and sales. Alerts fire when scores drop below your target threshold.
Explore our speed optimization services
Straight answers about timelines, risk, and what to expect.
PageSpeed optimisation service to increase your PageSpeed Insights score on mobile and desktop. Fix low scores with a clear, prioritised plan backed by Lighthouse data.
Learn more →Core Web Vitals fix service to improve LCP, INP, and CLS scores. We diagnose failing metrics and implement changes that help SEO and real-user experience.
Learn more →BigCommerce speed optimisation to improve PageSpeed scores, fix Core Web Vitals, and increase conversions. Get a free store audit with a prioritised fix plan.
Learn more →Start with a free speed test. We will identify the top bottlenecks in your stack.