My Adobe Commerce performance checklist

Slow pages cost sales on any platform, and the causes repeat from one shop to the next. All of my own work has been on Magento and Adobe Commerce, so the details below are written for Adobe Commerce. The order of the checks and the reasoning behind it work on most stacks.

Every performance engagement starts the same way. Before I touch code, I run through these twelve checks on a staging copy and against production monitoring. That pass usually explains most of the slowness and tells me where the first week of work should go.

The order matters. Infrastructure problems hide everything above them. If the full-page cache misses, no amount of frontend work will make category pages feel fast. So I start at the bottom of the stack and work up.

Infrastructure

1. Full-page cache hit rate. Varnish or the built-in full-page cache. I look at the hit rate per page type, because a healthy home page can hide a category page that misses on every request. If it is under 80 % on category pages (my own rule of thumb), fix that first. The usual causes are cookies or query parameters that vary the cache key, and blocks that disable caching for the whole page. A third is cache tags that purge far more than they should after a product save.

2. Redis for sessions and cache. Sessions and cache belong in separate Redis instances, so a full cache cannot push out customer sessions. I check memory use, eviction counts and the eviction policy. Evictions on the session instance mean customers lose their carts; evictions on the cache instance mean the store keeps rebuilding the same data.

3. Search engine health. OpenSearch or Elasticsearch heap, shard count and the slow log. An undersized heap shows up as slow layered navigation and search results under load, long before it shows up as errors. I also check that the search index is not being rebuilt for the whole catalog several times a day.

4. PHP-FPM and OPcache. Enough workers for peak traffic, and not so many that the server starts swapping. OPcache must be large enough to hold the whole codebase, including generated code. When it fills up, PHP recompiles files on every request and response times jump without an obvious cause. I check opcache.memory_consumption, opcache.max_accelerated_files and the hit rate.

Backend

5. Indexers. Everything on “Update by Schedule”, cron running every minute, no indexers stuck in “processing” and no changelog tables growing without limit. “Update on Save” makes every admin save slower and can lock tables during busy hours. A stuck indexer also explains many cases of prices or stock that look wrong on the storefront.

6. Slow query log. I enable it on staging with production-sized data, or read it from database monitoring in production. Custom tables without indexes are the usual culprit, followed by collections loaded inside loops and custom attributes joined into every product listing. One missing index on a busy custom table can add seconds to a page.

7. Third-party modules on the hot path. Plugins and observers on product loading, price rendering, cart and checkout run on almost every request. I list them, disable each one in a staging copy and measure the difference. The result is usually a short list of two or three modules that cost most of the backend time. For each one I decide whether to configure, replace or remove it.

8. Layout and block cache. A single block marked cacheable="false" in a layout file makes the whole page uncacheable for the full-page cache. I search the codebase and every installed module for it. Personalized content belongs in private content sections loaded by JavaScript.

Frontend

9. JavaScript payload. On a Luma-based theme I count the RequireJS modules loaded on a product page and look at how much script runs before the page becomes interactive. Bundling and minification help a little; removing modules nobody uses helps more. Hyvä stores avoid most of this problem, because the theme does not use RequireJS or the Luma JavaScript stack.

10. Critical CSS and font loading. One render-blocking stylesheet at most, critical CSS inlined for the first screen, and fonts loaded with font-display: swap so text shows while the fonts arrive. I also count the font files and weights a page requests; a long list is a sign the design grew without anyone watching the cost.

11. Images. Correct sizes for each breakpoint, WebP or AVIF, explicit width and height so the layout does not shift, and lazy loading below the fold. The main product image and the first row of category tiles should load eagerly, because lazy loading the largest image on the page delays Largest Contentful Paint.

12. Third-party tags. Analytics, chat, reviews, A/B testing and marketing pixels. Each tag manager container costs real milliseconds on the main thread. I list every tag, find out who owns it and whether anyone still uses its data. I remove the tags nobody uses and load the rest after consent, and after the first interaction where possible.

What the checklist gives you

At the end of the twelve checks I have a ranked list of problems, each with its cost and its place in the fix order. Most stores have three or four items that matter and a long tail that does not. The ranked list becomes the plan for the fix phase, priced in hours so you can decide what is worth doing.

The checklist does not replace measurement. I record real-user data on the pages that carry revenue before and after every change, so you see the improvement in the numbers.

If you want this run on your store with a written report, see the performance optimization service.