Magento 2 has a reputation for being slow. In my experience it is rarely Magento alone. It is usually a cache that isn’t doing its job, a database working harder than it should, or infrastructure sized for a quiet Tuesday rather than a sale.
These are the areas I check first when a Magento store on AWS needs to get faster, roughly in the order they tend to pay off.
1. Measure before changing anything
Start with an APM tool such as New Relic and look at real transactions, not just homepage load time. Which controllers are slowest? Is the time spent in PHP, MySQL, Redis or external calls? A category page that makes a synchronous call to a third-party API on every uncached request is a very different problem from a slow query.
Capture a baseline (response times, cache hit rate, database load) so you can prove each change helped.
2. Make the full-page cache work
Varnish (or Fastly on Adobe Commerce Cloud) is the single biggest lever. Most anonymous traffic should never reach PHP. When the hit rate is poor, the usual causes are:
- Blocks marked
cacheable="false"in layout XML, which makes the whole page uncacheable. - Cookies or query parameters (marketing tags especially) creating endless cache variations.
- Extensions that personalise server-rendered HTML instead of using private content sections.
- Aggressive purging, where a stock or price import invalidates far more than it needs to.
A quick way to find the first culprit:
grep -rn 'cacheable="false"' app/code app/design vendor/*/*/view/frontend/layout3. Give Redis its own jobs
Use ElastiCache for Redis for the default cache and sessions, and keep them in separate databases (or separate clusters on busier sites) so cache evictions can never log customers out. Watch memory, evictions and network throughput in CloudWatch; an undersized node shows up as random slowness rather than an obvious failure.
4. Treat the database as a shared, finite resource
- Run indexers in Update by Schedule mode, and make sure cron is actually running and not overlapping.
- Size RDS for peak connections and memory, not average CPU. Enable Performance Insights and look at the top SQL.
- Keep heavy reporting and exports off the primary database where possible.
- Check custom modules for queries inside loops, which is the most common cause of a slow product listing.
5. Scale the application tier properly
Horizontal scaling only works if instances are stateless. Sessions belong in Redis, media in shared storage (EFS or S3 behind a CDN), and every instance needs the same compiled code and static content from the same build. Then an Auto Scaling group behind a load balancer can add capacity before a campaign rather than during it.
Production mode, OPcache with enough memory, and a current PHP version are table stakes, but they are worth confirming. I still find stores running in developer or default mode.
6. Put the edge to work
A CDN for static assets and media takes load and latency off the origin. A WAF in front of the site matters for performance as well as security: bots crawling layered navigation or hammering search can consume more resources than real customers.
The takeaway
Performance work goes well when it is evidence-led and layered: measure, fix the cache, protect the database, then scale. Tuning PHP settings before the full-page cache is healthy is usually wasted effort.
