Drupal Commerce powers live auctions involving thousands of concurrent users, serves catalogues with millions of products, and presents rich product pages with hundreds of attributes and variations. And it does so with speed and reliability. In fact, it was architected to manage high volume and high complexity.

So why does your Drupal Commerce site feel so slow? Why does it feel like you’re constantly fighting bottlenecks and performance problems?

It’s not the platform. It’s something else.

In this webinar, Ryan Szrama and Tom Ashe cover the most common culprits behind slow Drupal Commerce sites and how you can start fixing them.

Whether you're troubleshooting a slow site yourself or managing a team that is, you'll walk away with a practical checklist to investigate and a process for diagnosing your performance issues.

Replatforming rarely solves performance problems

Many merchants are convinced their only option is to rebuild on a new platform. But most performance problems are portable. They'll follow you to the new platform, where you may have even less ability to diagnose them (try inspecting the database on a SaaS platform).

The same goes for decoupling. A headless front end isn't a silver bullet. We've seen decoupled rebuilds that regressed in both performance and stability, doubled the development effort, and even introduced security gaps. Decoupling can certainly be part of a solution, and we have our share of decoupled implementations, but you need to understand the tradeoffs.

The good news: the problems we find are remarkably consistent from site to site, and most are fixable without a rebuild.

Key points about Drupal Commerce performance:

• Architect for scalability, not just performance. Everything is fast in a demo with five products. Plan for the Taylor Swift ticket-drop moment up front, and you can spend your time on features instead of firefighting. One site we architected this way held steady in load testing at 30,000 orders per hour, and the testing tools gave out before the site did.
• Caching enabled doesn't mean caching is working. Check your browser's developer tools for actual cache hits. We've found sites with Varnish fully provisioned, but Varnish never receives a single request.
• Let the edge do 90–99% of the work. A CDN layer like Cloudflare or Fastly should serve static content from servers near your visitors, reserving your application server for critical business logic.
• Watch for silent cache killers. Personalized cart blocks, views with short cache lifetimes, and modules using the private temp store can quietly break caching for entire pages. Lazy-load the dynamic bits and serve the rest from cache, or move them entirely client-side.
• Consolidate your fields. Hundreds of individually defined fields hurt performance. Bundle related values into a single custom field, like Drupal's address field, so they load and save together.
• Avoid database killers. Index what you search on (but not too much, since every index slows writes), avoid "contains" searches that force full table scans, and normalize the data you actually query.
• Clean up your technical debt. Years of accumulated page builders and clicked-together queries from Views add overhead on every request. Lingering functionality can be executed and slow things down, even if it's not used or displayed.
• Move work to asynchronous queues. Only payment and a few pricing/tax operations truly need to be synchronous. Emails, integrations, and sync jobs belong in queues processed by workers, not blocking page requests.
• Bots and AI crawlers are everyone's problem. LLM training bots are hammering sites across our entire customer base, looping through faceted catalogs and filling caches with junk. Set up edge rules to rein them in before they inflate your hosting bill.