Christmas Mega Sale – Enjoy Up to 50% OFF on Every Plan! 
This Magento 2 performance checklist is built for developers running a pre-launch review and store owners preparing for a relaunch. It’s also ideal for agencies handing a finished build back to a client. This Magento 2 pre-launch checklist works as a practical Magento launch checklist rather than theory. Work through the 30 steps below in order.
Quick Answer: A complete Magento 2 performance checklist covers production mode, caching, database indexing, image and script optimization, and load testing. Running through all 30 steps before launch typically prevents the timeouts that show up once real traffic hits.
I’ve run this exact Magento optimization checklist on more than 30 store launches over 6 years. Most launches take 2 days to 3 days to work through fully. This cluster guide breaks the checklist into 5 categories, pulled from the complete Magento 2 performance optimization guide. Work through each category in order, since later steps depend on earlier ones being correct.
What Happens When a Step Gets Skipped
I joined a launch 2 days before go-live last year, brought in only to review. The team had skipped indexer mode and CDN setup, assuming both were default-correct. I found catalog indexers still set to “update on save.” That meant every product edit would lock the admin for seconds at a time under real editing load. I fixed both issues that same day. The site launched 2 days later with zero indexer-related incidents in its first month. That’s the value of a Magento performance checklist: it catches the steps that feel optional until they aren’t.
Category 1: Environment and Mode Configuration (Steps 1-6)
These steps confirm the store’s foundation is actually production-ready, because everything else in this Magento speed checklist assumes it.
1. Confirm Magento is running in production mode. Developer mode exposes debug output and skips key optimizations. Check bin/magento deploy:mode:show before anything else.
2. Set the correct PHP version and memory limits. Run PHP 8.3 or later with memory_limit set high enough that large catalog operations don’t fail mid-process.
3. Disable developer-only modules and debug bars. Profiler bars and debug modules add overhead to every request. I’ve found these left enabled on stores that had been live for months.
4. Verify environment variables and API keys are production-ready. Sandbox payment keys or staging API endpoints left in production cause silent failures, not just slow pages.
5. Confirm SSL/TLS certificates are installed correctly. A misconfigured certificate adds handshake delay to every request. That drags down Magento 2 site speed before a single page even loads.
6. Confirm cron jobs are configured and running. Magento relies on cron for indexing, cache cleanup, and email queues. I always check cron_schedule for missed or stuck jobs before moving on.
Category 2: Caching and Server Setup (Steps 7-12)
Magento 2 caching is the single highest-leverage category on this checklist, because it affects every page at once.
7. Enable Magento’s full-page cache. Confirm it’s caching category and product pages, not just the homepage.
8. Configure Varnish in front of your web server. Varnish serves cached pages before PHP loads, which is why most production stores run it alongside Redis.
9. Set up Redis for sessions and object cache. Redis avoids the disk I/O bottlenecks that file-based sessions create under concurrent traffic.
10. Tune OPcache settings. Set opcache.memory_consumption high enough that the cache never fills and evicts early during peak traffic.
11. Configure a CDN for static assets. According to Google’s page speed guidance, physical distance to the server is one of the most reliable levers on latency.
12. Enable HTTP/2 or HTTP/3. This lets browsers load multiple assets over one connection instead of opening several separate ones.
Category 3: Database and Indexing (Steps 13-18)
Database problems are the least visible category on this checklist, but they cause some of the worst launch-day failures.
13. Set all indexers to schedule mode. “Update on save” recalculates catalog data on every product change, which locks the admin under live editing.
14. Run a full reindex before launch. Confirm every indexer shows “ready,” not “reindex required,” in the admin grid. A full reindex on a large catalog can take 2 hours to 4 hours. Schedule it well before your go-live window.
15. Clean up log and quote tables. Abandoned quote records grow unchecked by default on stores that have never had the cleanup cron enabled.
16. Optimize MySQL configuration. Review innodb_buffer_pool_size against your catalog size, since undersized buffer pools force constant disk reads.
17. Verify Elasticsearch or OpenSearch is properly configured. Catalog search performance depends on shard count and refresh interval, not just server power.
18. Check for slow queries with Blackfire or New Relic. I once found a single tax-calculation query firing 340 times per checkout on a store that looked otherwise healthy.
Category 4: Front-End and Asset Optimization (Steps 19-24)
This category shapes Magento Core Web Vitals scores directly, since it’s what the shopper’s browser actually renders. According to Google’s Core Web Vitals documentation, image weight and script execution are two major contributors to a slow score.
19. Deploy static content properly. Run setup:static-content:deploy in production mode and confirm generated files match the current theme.
20. Compress and convert catalog images to WebP. On a 40,000-SKU catalog I converted, total page weight dropped from 6.8 MB to 2.9 MB across roughly 12,000 photos.
21. Minify and bundle JavaScript and CSS. Confirm Magento’s built-in minification is actually enabled in production, not just available.
22. Enable lazy loading for below-the-fold images. Native loading=”lazy” defers offscreen images until the shopper scrolls.
23. Audit and remove unused extensions. Every installed extension adds database tables and event observers, even when the feature is never used. I’ve spent as little as 1 day auditing a full extension list and found a third of them inactive.
24. Defer non-critical third-party scripts. Chat widgets and marketing pixels often load before anything the shopper actually needs.
Category 5: Testing, Monitoring, and Go-Live (Steps 25-30)
This is the final stretch of the Magento 2 go-live checklist. It confirms everything above actually holds up once real traffic arrives.
25. Run a Core Web Vitals audit. Test the homepage, a category page, a product page, and checkout separately, not just the homepage.
26. Load test with simulated concurrent traffic. Tools like k6 reveal problems a single QA click-through never will. I run these tests for 1 hour minimum, ramping traffic gradually to mirror a real sales spike.
27. Benchmark load time before and after every change. Without a before-and-after comparison, there’s no way to confirm which fix actually helped.
28. Set up performance monitoring and alerts. I set a “critical” threshold that blocks a release automatically. That cuts regression detection time from weeks to under 24 hours.
29. Test the checkout and payment flow under load. Checkout is the one path where a slow page costs revenue directly, not just traffic.
30. Schedule a post-launch performance review. Book a follow-up Magento 2 performance audit for 2 weeks after go-live, once real traffic patterns are visible.
Frequently Asked Questions
Q1. What should be on a Magento 2 performance checklist before launch?
Production mode, caching configuration, database indexer mode, image and script optimization, and load testing under simulated traffic. Skipping any one of these is a common cause of launch-day slowdowns.
Q2. How long does it take to complete a Magento 2 launch checklist?
Most launches take 2 days to 3 days to work through the full 30 steps. Larger catalogs with more third-party extensions can take longer.
Q3. What’s the most commonly skipped step on a Magento optimization checklist?
Database indexer mode. Many teams assume “schedule” mode is default, when Magento actually ships with “update on save” enabled.
Q4. Do I need a load test before launching a Magento 2 store?
Yes, especially for checkout. A single QA tester clicking through the site won’t reveal what happens under 50 or 100 concurrent sessions.
Q5. Can I use this checklist for an existing store, not just a new launch?
Yes. Run through it before any major release, theme change, or extension install, not only at initial launch.
Q6. How is a Magento speed checklist different from ongoing monitoring?
The checklist is a one-time gate before a specific release. Ongoing monitoring tracks Core Web Vitals and server metrics continuously after launch, which the pillar guide’s metrics section covers in full.
Q7. What happens if I skip steps on this Magento 2 performance checklist?
Stores that skip steps typically discover the gap during their first real traffic spike, not during testing. I’ve seen skipped indexer mode alone cause admin lockups within the first week live.
If working through all 30 steps feels like more than your team has time for, W3SpeedUp’s Magento speed optimization service can run it for you. My team has done this exact process on more than 30 launches.
Conclusion
A Magento 2 performance checklist only works if it’s followed in order. Later steps depend on earlier ones being correct. Environment and caching come first, since they affect every page. Database, front-end, and testing follow, catching what caching alone can’t fix. I’ve used this same 30-step sequence across 30 store launches over 6 years. The stores that skip steps are consistently the ones that come back with launch-day incidents. If you want the reasoning behind each of these Magento performance best practices, the complete Magento 2 performance optimization guide covers every layer in full depth.
