Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteSome links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
Magento performance improves most when you fix the slowest part of the request path—not when you switch on every optimization setting. Start by measuring real storefront journeys, then prioritize production configuration, full-page caching, code and integration bottlenecks, and frontend payload. Treat checkout, personalized content, and cache misses as separate cases: a fast cached homepage is not proof that the store is ready for customers or peak traffic.
Measure the storefront before changing it
Build a baseline that separates what shoppers experience from what the server is doing. A single Lighthouse score—especially for a warm-cache homepage—cannot reveal slow search, account pages, cache misses, or checkout integrations.
| Measure | What to capture |
|---|---|
| Server response | Time to first byte and origin response time, split by full-page-cache hit and miss. |
| Real-user experience | Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS), segmented by mobile and desktop. |
| Page journeys | Product, category, search and layered navigation, cart, checkout, login, and account pages. |
| Application and dependencies | PHP execution and database query time; cache and OpenSearch latency; and time spent in external APIs such as tax, shipping, payment, or ERP services. |
| Capacity and operations | Error rates, PHP-FPM worker saturation and queueing, database connections, CPU, memory, disk I/O, network, cache evictions, queue backlogs, and cron or indexer failures. |
| Operating conditions | Warm- and cold-cache behavior, cache purge and warm-up, ordinary traffic, and expected sale or campaign peaks. |
Use Chrome DevTools and Lighthouse for development diagnostics, PageSpeed Insights for page-level lab and field-oriented checks, and an APM such as New Relic for transaction traces, SQL, PHP, and external-call timing. Pair them with server and service metrics. Compare the same page and journey under comparable conditions; record the cache state and traffic level so a change can be judged fairly.
Recommended Free Tools
Use a supported production configuration
For a live store, production mode is the baseline. Development mode, debug features, Xdebug, verbose logging, or assets that have not been deployed for production can add overhead or make measurements unrepresentative. Verify the environment before tuning individual components:
#1 Best Overall
php bin/magento deploy:mode:show
php bin/magento cache:status
php bin/magento indexer:show-mode
php bin/magento indexer:statusAdobe’s documentation lists the 2.4.9 release line and its release-specific software requirements. For example, the documented on-premises combinations include PHP 8.4 or 8.5, OpenSearch 3, Valkey 9, Composer 2.10, and nginx 1.30; supported combinations differ by deployment type and patch. PHP 8.2 is no longer supported in 2.4.9. Check the [system requirements](https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/system-requirements?lang=en) and [2.4.9 release notes](https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/adobe-commerce/2-4-9?lang=en) against your actual edition, hosting model, patch, and extensions before upgrading.
Adobe’s [production-system guidance](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/deployment/production-system) describes production operation; its [Cloud Docker production-mode guide](https://developer.adobe.com/commerce/cloud-tools/docker/deploy/production-mode) shows a Cloud Docker deployment example. A mode switch is not a casual live-site toggle: generated code, static assets, permissions, caches, and multiple web nodes all need a deployment plan. Use your hosting environment’s supported release procedure. The mode-setting command, when appropriate to that procedure, is:
php bin/magento deploy:mode:set productionDiagnose the slow path, then choose the fix
Use traces and cache headers to locate the bottleneck before changing infrastructure. The same symptom can have very different causes: an uncached product page may be PHP- or SQL-bound, while a slow checkout may be waiting on a payment or shipping service.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Cache-hit pages are slow: inspect CDN and reverse-proxy behavior, network and origin delivery, response size, and browser asset waterfalls. If only mobile is poor, investigate JavaScript execution, image weight, fonts, and third-party tags.
- Cache-miss pages are slow: trace PHP execution, layout and block generation, database queries, and extension hooks. Compare misses with hits rather than averaging the two.
- Search or layered navigation is slow: inspect OpenSearch health, query latency, and the relevant catalog workload; search latency is distinct from ordinary category rendering.
- Checkout is slow: trace tax, shipping, payment, inventory reservation, address validation, and other synchronous calls in the actual checkout flow.
- Performance collapses under load: check PHP-FPM queues and worker capacity, database connections, cache memory and network, queue consumers, and origin saturation during misses or reindexing.
- Logged-in users are slower: inspect customer sections, personalization, private content, and account-specific extension work.
Configure each caching layer for its job
Magento’s application cache, full-page cache, and browser/CDN asset cache solve different problems. Do not treat Redis or Valkey as a substitute for full-page caching, and do not assume a CDN configured for static assets is correctly caching HTML.
Application cache
Magento cache types hold application-generated data, including configuration, layout, and block HTML. Check status and enable the required types through the CLI:
php bin/magento cache:status
php bin/magento cache:enableAfter changes, distinguish cache:clean, which removes Magento-generated cache entries, from cache:flush, which clears the underlying storage and can affect other applications or data sharing that backend:
php bin/magento cache:clean
php bin/magento cache:flushCache invalidation after catalog, configuration, theme, or extension changes can temporarily increase origin work while entries are rebuilt. Avoid broad flushes as a routine performance remedy; understand the storage scope and expected warm-up impact first.
Free tools Windows power users keep installed
One-click scans. No signup required.
Full-page cache: Varnish or Fastly, depending on deployment
Full-page caching serves eligible rendered pages without regenerating them through the application on every request. Adobe strongly recommends Varnish for on-premises production deployments. Adobe Commerce Cloud uses Fastly for full-page caching in the documented Cloud architecture. The built-in page-cache mechanism can be useful in development or smaller deployments, but it is not automatically equivalent to a properly configured reverse proxy. See Adobe’s [caching overview](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cache/caching-overview), [software recommendations](https://experienceleague.adobe.com/en/docs/commerce-operations/performance-best-practices/software), and [frontend page-caching guide](https://developer.adobe.com/commerce/frontend-core/guide/caching).
Monitor hit and miss rates, response headers, purge behavior, and warm-up. A high hit rate is useful only if the right pages are eligible and customers receive correct content. If one personalized widget is forcing whole pages to be dynamic, fix the widget’s delivery model rather than disabling full-page caching across the store.
Redis or Valkey for application data and sessions
Redis or Valkey can serve application cache and session workloads where the Commerce release and deployment support them. They are separate from HTTP full-page caching. Adobe’s [cache backend documentation](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cache/cache-options) describes supported options; compatibility is release-specific, and the 2.4.9 line documents Valkey support in relevant combinations.
Size and operate the service for its actual workloads: monitor memory, hit rates, evictions, connection limits, and network latency. Consider separate services or logical databases for workloads with different persistence and eviction needs; sessions should not be treated like disposable application cache. Avoid putting cache, sessions, queues, and unrelated applications into one undifferentiated instance without capacity and failure-isolation planning.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Consider L2 cache only where supported
A local second-level cache can reduce repeated network traffic between web nodes and remote Redis or Valkey. Availability depends on Commerce edition, deployment type, and release: Adobe documents the modern Symfony-based implementation for Adobe Commerce on-premises 2.4.9 customers, with Cloud availability documented separately. Confirm your eligibility and test invalidation and consistency before enabling it; it is not a universal Magento setting. See [Adobe’s L2 cache configuration](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cache/level-two-cache).
Keep public pages cacheable and private data private
Product and category pages can often remain publicly cacheable even when they contain customer-specific elements. Keep customer, cart, and session-dependent content in private or separately loaded components—such as customer sections or AJAX requests—instead of making the entire page dynamic.
- Do not place session-dependent logic in a cacheable block or publish customer-specific API responses to a shared cache.
- Keep cart, checkout, account, and other private responses out of public caches; verify CDN rules respect cookies and authorization headers.
- Check cache identities and invalidation tags when catalog, price, stock, or configuration changes must invalidate an entry.
- Test customer groups, segments, catalog permissions, and personalized pricing with the actual cache key and invalidation behavior.
Adobe explains [Commerce page caching](https://developer.adobe.com/commerce/frontend-core/guide/caching) and [PHP page-cache development](https://developer.adobe.com/commerce/php/development/cache/page/). Test both correctness and cacheability after customizations: a page that is fast but shows the wrong customer’s content is a serious failure.
Keep cron, indexers, and queues healthy
Caching avoids regenerating repeated responses; indexing prepares derived catalog, price, inventory, and search data for retrieval. They are not interchangeable, and a full reindex is not a general speed fix. Adobe’s [cache-management guidance](https://experienceleague.adobe.com/en/docs/commerce-admin/systems/tools/cache-management) distinguishes their purposes.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Check indexer state and mode, and confirm cron runs continuously rather than only during deployment:
php bin/magento indexer:status
php bin/magento indexer:show-mode
php bin/magento cron:runWhere the business workflow permits, scheduled indexing can avoid forcing large indexing operations into storefront requests. For larger catalogs, monitor backlog and changelog growth, investigate slow custom indexers and observers, and avoid repeated full reindexes during busy periods. Reindexing consumes CPU and database capacity and can make a struggling storefront slower. Move suitable ERP, PIM, inventory, and marketing synchronization to queues or asynchronous processing, while preserving the business rules and freshness guarantees customers need. Adobe’s [cron prerequisites](https://experienceleague.adobe.com/en/docs/commerce-operations/upgrade-guide/prepare/prerequisites) provide additional operational checks.
Find extension and custom-code costs with traces
Extensions can add work to every request through plugins, observers, layout blocks, SQL joins, external calls, or global frontend scripts. Use APM traces and query profiles to identify the cost rather than removing modules by guesswork.
- Inventory installed modules and record why each is needed.
- Flag modules that run on broad request paths, add database joins, inject sitewide assets, or call external APIs.
- In staging, disable one suspected module at a time and compare transaction traces, SQL time, response size, and cacheability.
- Remove genuinely unused modules and review vendor maintenance, version compatibility, and support for the installed Commerce release.
- Keep customizations in modules or child themes rather than modifying core files, so upgrades and rollback remain manageable.
Look especially for N+1 queries during product and category rendering, repeated collection loads, observers that trigger excessive invalidation, and synchronous tax, shipping, inventory, or ERP calls during checkout. Replacing an extension or moving work asynchronously can help, but first verify that the change preserves pricing, inventory, and order behavior.
Reduce frontend weight without breaking journeys
Use the browser waterfall and field data to identify which resources delay rendering or interaction. Optimize what customers download and execute, rather than relying on a blanket minification setting.
- Resize and compress images for their rendered dimensions; use responsive sources so mobile devices do not download desktop-sized assets. WebP or AVIF may reduce weight where the image pipeline and browser support fit your needs.
- Reserve image dimensions to limit layout shifts. Lazy-load below-the-fold imagery, but do not indiscriminately lazy-load the primary product image. Preload only genuinely critical assets.
- Limit font families and weights; optimize or self-host fonts where appropriate and avoid loading unused variants.
- Remove unused CSS and JavaScript, defer noncritical scripts, and avoid loading checkout-only code on every storefront page.
- Audit chat, review, heatmap, advertising, and analytics tags. Third-party scripts can consume main-thread time or add network dependencies even when Magento itself is fast.
- Test JavaScript merge, bundling, and minification in the exact theme and release. They may reduce requests, but can increase payload or complicate debugging, and request consolidation is not automatically a win with HTTP/2 or HTTP/3.
Adobe’s [2.4.9 release notes](https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/adobe-commerce/2-4-9?lang=en) include release-specific fixes involving static-content deployment, JavaScript minification, SRI hash storage, and checkout script compatibility. That is a reason to test frontend changes against the exact release and theme, not a promise that a particular setting will improve every store.
Choose a theme for the whole store, not a single score
A lighter theme can reduce CSS, JavaScript, layout, and block overhead, but it is an architectural change rather than a guaranteed speed switch. Evaluate initial payload, layout handles and blocks, extension compatibility, checkout behavior, accessibility, responsive design, vendor support, and upgrade path across product, category, search, cart, and checkout journeys.
For a stable store whose bottleneck is database queries or backend integrations, a theme migration may add cost without solving the main problem. Include extension rewrites, checkout compatibility, testing, and maintenance in the decision.
Tune database and search against measured workloads
Enable and inspect slow-query data, trace expensive transactions, and check whether custom tables and high-volume workflows have appropriate indexes. Reduce unnecessary EAV reads and repeated collection loading; review operational-table growth under a tested retention policy. Database memory, connection sizing, and storage I/O should reflect measured workload rather than a generic tuning recipe.
For search, monitor OpenSearch health, heap, shard design, and query latency. Diagnose autocomplete and search-result performance separately from category-page rendering. Read replicas or split-database architectures can help appropriate read-heavy workloads, but require an eligible deployment and application behavior that can use them; they are not a default fix for a small Magento Open Source store. Adobe describes such options in its [reference architecture](https://experienceleague.adobe.com/en/docs/commerce-operations/performance-best-practices/reference-architecture).
Avoid applying legacy “flat catalog” checklists without verifying the current release documentation and query profile. Start with the actual slow query or search request.
Scale hosting and CDN behavior to the bottleneck
Infrastructure changes help when measurements show a capacity or delivery constraint. Check PHP-FPM worker counts and request queues, CPU headroom during misses and reindexing, fast local storage, database/cache network distance, CDN and origin geography, and Varnish memory for the important cache set. For multiple web nodes, include load-balancer health checks, cache consistency, TLS termination, deployment behavior, and stale-cache or grace behavior in the design.
Adobe’s [hardware recommendations](https://experienceleague.adobe.com/en/docs/commerce-operations/performance-best-practices/hardware) emphasize memory, network bandwidth, and adequate cache allocation; its [software recommendations](https://experienceleague.adobe.com/en/docs/commerce-operations/performance-best-practices/software) discuss Varnish and dedicated Redis services for scaling scenarios. Size from observed concurrency and resource pressure, and test backup restoration and rollback rather than assuming a larger server alone will fix slow code.
A CDN can improve static-asset delivery and reduce origin load, especially for geographically dispersed shoppers. Cache versioned static assets aggressively, but treat HTML as Magento-aware application content: exclude cart, checkout, login, account, and other private routes; respect cookies and authorization; inspect cache keys and headers; and purge selectively. Test image optimization for quality and URL changes, and verify that an additional CDN does not conflict with Varnish or Fastly rules. A CDN does not eliminate the need for correctly configured full-page caching.
Give checkout its own performance and correctness tests
Checkout often depends on dynamic business logic and synchronous services, so do not optimize it by delaying scripts indiscriminately or caching private responses. Trace and exercise guest and logged-in checkout, coupons and promotions, shipping methods, tax, payment authorization, address validation, inventory reservation, split shipments, and configurable or bundle products. Include mobile address entry and keyboard behavior, embedded payment frames or redirects, and failed-payment retries.
Changes to checkout scripts, extension integrations, or asynchronous processing need end-to-end tests in a safe environment. Measure the customer-visible flow as well as individual server transactions.
Load-test realistic traffic and protect gains
Use a representative catalog, customer groups, prices, inventory, cookies, and integrations. A test that requests one already-cached URL repeatedly says little about a sale where shoppers search, create carts, apply promotions, and check out.
- Exercise warm-cache browsing and cold-cache browsing, including product and category misses.
- Test search, layered navigation, concurrent cart creation, and checkout/payment attempts in a safe test environment.
- Include promotion and catalog-rule activation, imports, exports, ERP synchronization, and reindexing alongside ordinary traffic.
- Measure cache purge and warm-up, deployment and rollback, and campaign or flash-sale load.
After deployment, compare field metrics and transaction traces with the baseline. Alert on error rates, cache-hit changes, PHP-FPM saturation, slow queries, OpenSearch latency, cache evictions, and cron, indexer, or queue backlogs. Add regression checks for critical journeys to deployment review; tune alerts to distinguish a temporary warm-up from a sustained origin problem.
Quick Recap
A practical 30-day optimization sequence
- Days 1–3: establish evidence. Capture field and lab metrics, traces, cache-hit/miss behavior, service health, and checkout timings for key journeys.
- Days 4–7: fix safe operational basics. Confirm production mode, supported software, cron and indexer health, current cache configuration, and unnecessary third-party scripts.
- Week 2: correct cache and code bottlenecks. Validate Varnish or Fastly behavior for the deployment, inspect Redis/Valkey workload health, and trace expensive modules, queries, and external calls.
- Week 3: reduce frontend and data costs. Optimize image delivery, fonts, CSS/JavaScript, and the measured database or OpenSearch bottleneck; stage and test each change.
- Week 4: validate under load and operationalize. Test realistic journeys, misses, cache warm-up, promotions, checkout, deployment, and rollback. Keep only changes that improve the targeted user journey without correctness or stability regressions.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
