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 →Magento performance is a systems problem, not a minification-checkbox problem. The most reliable gains come from measuring real customer journeys, running a supported production stack, serving cacheable pages through the right edge layer, and removing bottlenecks in extensions, integrations, databases, and frontend assets. Work through those changes in that order: it limits risk to checkout and makes each improvement measurable.
1. Measure the journeys that make money
Start with a baseline before changing code or infrastructure. Record results for product, category, search, cart, checkout, login, and account pages on both mobile and desktop. Test warm-cache and cold-cache states, then repeat under realistic peak traffic.
| Measure | What it reveals |
|---|---|
| Time to first byte and origin response time | Whether latency is at the CDN, reverse proxy, network, PHP application, or backend services. |
| Full-page-cache hit and miss rates | Whether visitors receive fast cached HTML or trigger expensive page generation. |
| Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift | Field and lab evidence of loading, responsiveness, and visual stability. |
| PHP, SQL, cache, OpenSearch, and external-API timings | The transaction segment responsible for delay. |
| PHP-FPM saturation, memory pressure, queue backlogs, cron failures, and error rates | Whether capacity or operational failures will worsen during a sale. |
Use Chrome DevTools and Lighthouse during development, PageSpeed Insights for page-level lab and field signals, and New Relic or another APM for traces, database queries, external calls, and PHP execution. Server monitoring should include CPU, RAM, disk I/O, network, PHP-FPM workers, database connections, and cache memory. A high Lighthouse score on a cached homepage does not prove that search, checkout, logged-in pages, or cache misses are fast.
2. Run a supported production configuration
Verify your exact Adobe Commerce or Magento Open Source patch level and its dependency matrix before tuning. Adobe’s current documentation lists the 2.4.9 line with release-specific combinations including PHP 8.5, OpenSearch 3, Valkey 9, Composer 2.10, and nginx 1.30 for applicable on-premises deployments; Cloud and other deployment types can differ. Adobe Commerce 2.4.9 supports PHP 8.4 and 8.5, while PHP 8.2 is not supported in that release. Check the system requirements and 2.4.9 release notes before upgrading extensions or PHP.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match#1 Best Overall
A live store should run production mode, with debugging, Xdebug, verbose logging, and development asset settings removed from the serving path. On a maintenance window or deployment host, verify:
php bin/magento deploy:mode:show
php bin/magento deploy:mode:set production
php bin/magento cache:status
php bin/magento indexer:show-mode
php bin/magento indexer:statusUse your hosting provider’s deployment procedure on a multi-node installation. Changing mode casually can affect generated code, static content, permissions, and caches. Adobe’s production-system guidance and Cloud Docker production examples describe the operational requirements.
3. Configure each cache layer deliberately
Application cache
Magento cache types store configuration, layouts, block HTML, collections, and related application data. Check and enable them with:
php bin/magento cache:status
php bin/magento cache:enable
php bin/magento cache:clean
php bin/magento cache:flushcache:clean removes Magento-generated entries. cache:flush clears the underlying storage and can affect other applications sharing that backend. Catalog, configuration, theme, and extension changes can invalidate substantial content and create a temporary cold-cache slowdown, so warm important URLs deliberately after deployment.
Recommended Free Tools
Full-page cache
Full-page caching is separate from application cache. Adobe strongly recommends Varnish for on-premises production; the documented Adobe Commerce Cloud architecture uses Fastly. Magento’s built-in page-cache mechanism is useful for development and smaller deployments but is not automatically equivalent to a correctly deployed reverse proxy. See Adobe’s caching overview, software recommendations, and frontend caching guide.
Track hit and miss latency separately. If cache-hit pages are slow, inspect edge configuration, payload size, network geography, and blocking assets. If misses are slow, trace PHP, layout generation, extensions, SQL, and integrations.
Redis or Valkey
Redis or Valkey can accelerate application cache and sessions where the release supports the chosen backend. It does not replace HTTP full-page caching. Separate cache, sessions, queues, and unrelated workloads into logical databases or services where appropriate; set memory limits and eviction policies intentionally; monitor evictions, hit rates, connection limits, and network latency. Sessions should not be treated as disposable cache data. Adobe documents release-specific backend choices, including Valkey support, in its cache backend options.
Optional L2 cache
An L2 layer can reduce repeated network traffic from web nodes to remote Redis or Valkey. Adobe documents the modern Symfony-based implementation for particular Adobe Commerce on-premises 2.4.9 scenarios, with Cloud availability documented separately. Confirm edition, deployment, and patch compatibility in the L2 cache documentation before enabling it.
4. Keep public pages public and private data private
Magento distinguishes public cacheable content from session-dependent customer data. Cart, checkout, account information, customer sections, personalized pricing, customer groups, segments, and catalog permissions need private handling. A common mistake is adding session-dependent logic to a cacheable block, making every product page private, or caching a response that contains cookies or authorization data.
Keep the main HTML cacheable whenever possible and load customer-specific fragments through private content or asynchronous requests. Ensure cache identities and invalidation tags are correct, and test CDN cache keys against cookies. Do not disable full-page cache for the whole site because one personalized component is wrong. The page-caching guide and PHP page-cache documentation explain these boundaries.
5. Keep indexers, cron, and queues healthy
Caching reuses responses; indexing prepares catalog, price, inventory, and search data for retrieval. They solve different problems. Check status and execution rather than repeatedly reindexing:
php bin/magento indexer:status
php bin/magento indexer:show-mode
php bin/magento reindex
php bin/magento cron:runThe usual command is php bin/magento indexer:reindex; run it only when required and in a controlled window. Larger stores generally benefit from scheduled indexing when business workflows permit it. Monitor changelog growth, indexer backlog, cron continuity, queue consumers, and slow custom indexers. Move ERP, PIM, inventory, and marketing synchronization to asynchronous queues where the workflow allows. Full reindexes during peak traffic can consume substantial CPU and database capacity. Adobe distinguishes these mechanisms in its cache-management documentation and cron prerequisites.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minute6. Audit extensions and custom modules before buying more hardware
- List every installed module and the business function it serves.
- Use APM traces and SQL timing to find global plugins, observers, layout blocks, API calls, and database joins.
- Disable one suspect module at a time in staging and compare HTML size, cacheability, traces, and query counts.
- Remove unused modules rather than merely hiding their visible feature.
- Check update history, release compatibility, code quality, and vendor support.
Look specifically for N+1 queries, collections loaded repeatedly, synchronous ERP, tax, shipping, or inventory calls during checkout, sitewide third-party scripts, repeated cache invalidation, and customer-segment logic that makes pages private. Keep customizations in modules or child themes; do not edit core files.
7. Reduce frontend work without breaking checkout
- Resize and compress images before delivery; use responsive dimensions and WebP or AVIF where your browser and content workflows support them.
- Reserve image dimensions to prevent layout shift. Lazy-load below-the-fold images, but do not automatically lazy-load the primary product image.
- Limit font families and weights, optimize or self-host fonts, and preload only assets that are genuinely critical.
- Remove unused CSS and JavaScript, defer noncritical scripts, and avoid loading checkout code on every storefront page.
- Audit chat, analytics, heatmap, review, advertising, and other third-party tags.
Test JavaScript merging, bundling, and minification in both enabled and disabled states. They can reduce requests in some deployments, but may increase payload size, complicate debugging, or provide little benefit under HTTP/2 or HTTP/3. Adobe’s 2.4.9 notes include static deployment, minification, SRI, and checkout-script fixes, so test the exact release and theme rather than applying a universal recipe.
8. Treat theme selection as an architecture decision
A lightweight theme can reduce initial CSS and JavaScript, layout handles, and block work, but it is not a guaranteed performance fix. Evaluate the complete trade-off:
| Evaluate | Why it matters |
|---|---|
| Initial payload and layout complexity | Determines browser work on mobile and cache misses. |
| Extension and checkout compatibility | Prevents rewrites, broken payment flows, and upgrade friction. |
| Accessibility and responsive behavior | Protects usability while reducing assets. |
| Upgrade path and vendor support | Controls long-term maintenance cost. |
| Real-user results on product, category, search, cart, and checkout | Shows whether a migration improves revenue journeys rather than only a demo homepage. |
9. Improve database and search capacity after tracing the bottleneck
Enable slow-query logging and inspect traces before adding replicas or changing schema. Add appropriate indexes to custom high-volume tables, avoid repeated EAV reads and collection loads, archive operational tables under a tested retention policy, and size database memory and connections for peak concurrency.
OpenSearch needs its own health checks: heap sizing, shard design, query latency, and autocomplete behavior. Search performance is not the same as category-page performance. Read replicas and split databases can help suitable read-heavy Adobe Commerce workloads, but they are not a default solution for a small Magento Open Source store. Review Adobe’s reference architecture before adopting them. Avoid obsolete Magento 1-era flat-catalog checklists; use the query profile of your current release.
10. Match hosting, CDN, and edge rules to Magento
Infrastructure should provide PHP-FPM headroom, fast local storage, short network distance between web, database, and cache, adequate Varnish memory, load balancing, health checks, TLS termination, and tested stale-cache behavior. Adobe’s hardware guidance and software guidance emphasize memory, bandwidth, cache allocation, Varnish, and dedicated Redis services for scaling scenarios.
Use a CDN to cache static assets with immutable, versioned filenames and reduce geographic latency. Exclude cart, checkout, login, account, and other private routes; respect cookies and authorization headers; use selective purges; and verify cache headers, keys, image URLs, and interaction with Varnish or Fastly. A generic CDN is not automatically Magento-aware full-page caching. Cloudflare’s listed Network & CDN plans on August 18, 2026 were Free, Pro at $20 per month billed annually or $25 monthly, and Business at $200 annually billed monthly or $250 monthly; these are not Magento-specific and exclude optional services. See Cloudflare’s plans.
11. Give checkout its own performance budget
Test guest and logged-in checkout, coupons, promotions, shipping methods, tax calculation, payment authorization, address validation, inventory reservation, split shipments, configurable and bundle products, mobile address entry, payment redirects or frames, failed payments, and retries. Do not blindly defer checkout scripts or cache dynamic responses. Synchronous payment, tax, shipping, inventory, and fraud integrations often dominate checkout latency even when the homepage is fast.
12. Load-test realistic failure modes
- Warm-cache and cold-cache browsing.
- Product and category cache misses, search, and layered navigation.
- Concurrent cart creation and safe test checkout/payment attempts.
- Promotions, catalog-rule activation, and inventory changes.
- Imports, exports, ERP synchronization, reindexing, and queue processing during normal traffic.
- Cache purge, warm-up, deployment, rollback, and flash-sale traffic.
Use realistic catalog size, prices, inventory, cookies, customer groups, and third-party integrations. Repeating one cached URL produces an attractive but misleading result.
13. Protect gains after deployment
Keep APM traces, real-user monitoring, error alerts, cache-hit dashboards, cron and indexer alerts, queue-backlog alerts, and regression budgets in place. Compare field mobile performance with desktop lab results, and review origin latency separately from browser rendering. A deployment is successful only when cache invalidation, private content, search, promotions, checkout, and rollback behave correctly.
Quick Recap
A practical 30-day sequence
- Days 1–3: Capture journey-level baselines, cache-hit ratios, APM traces, server saturation, and error rates.
- Days 4–7: Verify supported versions, production mode, cron, indexers, queue consumers, and cache configuration.
- Week 2: Fix cacheability, remove unused extensions, address the worst SQL or integration bottleneck, and optimize oversized images and third-party tags.
- Week 3: Tune PHP-FPM, database, OpenSearch, Redis/Valkey, CDN rules, and static-asset caching according to measured demand.
- Week 4: Load-test warm and cold paths, checkout, promotions, deployment, rollback, and peak traffic; then set monitoring thresholds and repeat the baseline.
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.
