The definitive guide to Shopware performance on Shopware PaaS

A recent performance study analyzing hundreds of real Shopware projects found a 10× difference in page load times between similar storefronts. Product search pages ranged from under 200ms to well over 2 seconds; same platform, same page types, vastly different results.

This massive gap is not about luck or the platform itself. Running a high-performing Shopware store requires intentional infrastructure decisions, careful configuration, and defined development practices. A single misconfigured plugin, an unbatched ERP sync, or debug logging left enabled in production can transform a fast storefront into an unusable one.

This guide shares practical lessons from months of load testing across seven infrastructure tiers. We tested scenarios handling 3,000 to 73,000 orders per day to identify what configurations deliver the best Shopware performance.

Who this guide is for

If you're a developer, software architect, DevOps engineer, or product manager working with Shopware, this guide is written for you. We'll walk through the common performance challenges we've encountered across dozens of projects, what the testing data actually reveals, and how to optimize your Shopware deployment for real-world scalability.

The performance problem

Two Shopware sites that appear identical can behave very differently under load. Here's what we experience repeatedly across Shopware projects:

• Plugins are often the weak link. Third-party and custom extensions are often poorly optimized, difficult to debug, and challenging to support under load.
• Cache invalidation causes problems. ERP imports or admin changes can trigger mass cache purges, creating backend spikes and latency bursts.
• Headless architectures expose caching limitations. The Store API relies heavily on POST requests, which don't play well with HTTP caching tools like Fastly or Varnish.
• DevOps workflows are inconsistent. Teams waste time reinventing deployment, monitoring, and staging processes instead of focusing on product development.

These issues aren't due to bad intentions—they stem from complexity. Shopware is modular and capable, but without discipline and the right tools, performance suffers.

What makes Shopware PaaS different

Built on Upsun, Shopware PaaS provides enterprise-grade infrastructure with SLAs for scalability, high availability, and performance. It includes standardized developer workflows with Git-based environments, CI/CD, and rollback capabilities built in. You also get tools for diagnosis and performance tuning, including native support for Blackfire, as well as best-practice templates and architectural guidance.

How Shopware really performs

A recent Shopware 6 performance benchmark by Tideways analyzed hundreds of real projects and found a 10× difference in Time-to-First-Byte (TTFB) across similar page types. Product search pages ranged from under 200ms to well over 2 seconds, depending on the project.

This disparity reflects what we see in practice: the software isn't inherently slow, but it's highly sensitive to how it's used.

Real example: Debug logging nearly broke a store

In late 2024, we received a support ticket about a Shopware storefront suffering severe slowness. Some pages took over 10 seconds to load, with extreme cases exceeding 3 minutes.

Using Blackfire's profiling capabilities, we quickly identified the root cause: the PayPal plugin was running with DEBUG-level logging enabled. Under heavy traffic, this overwhelmed the disk with write operations, causing I/O contention as processes queued to write their own logs. Once debug mode was disabled, response times recovered almost immediately.

This case illustrates a recurring theme: a small misconfiguration in a third-party extension can destabilize the entire stack.

Common performance pitfalls

• ERP integrations that trigger cache invalidations: Inventory and product updates, especially when unbatched, cause sweeping cache invalidations, resulting in backend load spikes and frontend latency.
• Excessive personalization: Serving unique content, such as customer-specific pricing or postal code-based adjustments, reduces cache efficiency and increases infrastructure load.
• Lack of performance budget: Teams deploy features or plugins without defining acceptable performance thresholds, leading to slow degradation over time.

Cache first, then everything else

No matter how efficient your custom code is, nothing beats a fast cache. Whether at the edge (Fastly), on the application side (Symfony HTTP cache), or in the database/query layer (Redis, Doctrine metadata), caching is the primary strategy for sustainable performance.

Studies correlate every second of added load time with a drop in conversion rate. For Shopware stores competing in crowded retail markets, performance isn't just technical, it's commercial.

Understanding infrastructure options

Shopware PaaS offers several infrastructure tiers:

Grid plans (XL, 2XL, 4XL)

Shared-resource model where your project runs in isolated containers on VMs shared with other customers. Best suited for entry-level and small-to-medium projects, offering cost-effective pricing; however, performance predictability is limited under extreme load conditions.

Dedicated grid hosts (DGH-16, DGH-32, DGH-64, DGH-128)

Container-based model, but on dedicated VMs. All resources are exclusive to your project, enabling burst capacity and consistent performance. All containers are co-located on the same host, eliminating inter-service network latency. DGH plans also provide significantly higher memory limits than standard Grid plans.

Best for mid-sized to high-traffic storefronts needing predictable CPU access.

Dedicated plans (D-12, D-24, D-48, D-96, D-192)

Three fully dedicated VMs configured for high availability with MySQL in multimaster cluster configuration, Redis with multi-master setup, and redundant application containers. Fully dedicated compute, network, and storage with zero-downtime vertical scaling.

Best for production environments with high concurrency and uptime demands.

Dedicated split clusters

Separates concerns explicitly: three core nodes handle backend services (DB, cache, queues) while three or more web nodes serve application traffic. Core nodes scale vertically; web nodes scale both vertically and horizontally for seamless dynamic auto-scaling.

Best for enterprise-grade setups with high frontend concurrency or traffic spikes.

Best practices for high performance

Infrastructure and runtime configuration

Don't leave memory allocation and CPU resources at defaults. Set memory usage expectations explicitly in .upsun/config.yaml, enabling the platform to optimize PHP-FPM concurrency settings accordingly.

Maintain CPU usage below 70% under load to preserve headroom during peak traffic events. Infrastructure tiers should be selected based on both average load and burst capacity, considering business seasonality.

Caching strategy

HTTP caching, application-side caching (Symfony HTTP cache), and object caching (Redis) must work in concert. Where possible, content should be made cacheable by design—using GET rather than POST methods where appropriate, ensuring consistent cache headers, and avoiding patterns that lead to cache fragmentation.

Prewarm the Fastly cache of critical pages after deployments or content imports to ensure traffic isn't served cold.

Validate that the cache is functioning by inspecting HTTP response headers, particularly the X-Cache header. A HIT value indicates the response was served from cache; MISS suggests a cache bypass or expiration.

Manage cache invalidation responsibly. Unbatched product updates or poorly scheduled ERP synchronizations can result in widespread cache purges. Techniques such as soft purges and deferred purging intervals can help mitigate their impact.

Advanced cache features

ESI (Edge Side Includes) (Shopware ≥ 6.6.10.0) lets developers split page rendering into independently cacheable fragments. This is ideal when only parts of a page need frequent updates.

Soft purge (Shopware ≥ 6.4.15.0) marks entries as stale but still serves them until refreshed. The first request triggers background regeneration, allowing users to receive functional content without backend spikes.

Extension and Plugin Management

Performance regressions are most frequently traced to third-party or custom plugins. These may introduce costly hooks, register redundant services, or execute blocking logic during template rendering or checkout flows.

Performance-aware development must include plugin impact assessment—both at installation and during updates. Even unused plugins may consume resources. Routinely audit the full plugin stack and remove obsolete packages.

Admin Configuration and Application Logic

Misconfiguration at the admin level can significantly impact performance. For example, configuring category pages to display too many products leads to inefficient query execution. Dynamic rule conditions and promotions must be designed with query complexity in mind.

Where possible, avoid relying on raw SQL-based search behavior. Shopware PaaS supports integration with scalable search engines, such as OpenSearch, which offload search logic from the database.

External API calls should never block storefront responses. APIs are inherently brittle—slowness or outages can cascade across your entire system. External communications should be handled asynchronously whenever possible.

Logging levels must be adjusted appropriately for production environments. Enabling verbose or debug-level logs in live storefronts can overwhelm disk I/O and cause delays in application responses.

Performance as a discipline

Successful Shopware implementations have a defined performance budget: measurable targets for TTFB thresholds, acceptable CPU usage under peak load, memory constraints, and failure rate ceilings. These metrics should guide development and be validated continuously.

Performance expectations must also be reflected in the development lifecycle: Git-based CI/CD workflows, environment consistency (dev, staging, production), and continuous observability.

Load testing methodology

We used Grafana K6 as the load testing framework, building on Shopware-specific K6 scenarios that include four key traffic patterns:

• browse_only: Simulates casual users or bots (homepage visits, search, category browsing, product views)
• browse_and_buy: Emulates a full customer journey (browsing, account creation, cart operations, checkout)
• logged_in_fast_buy: Models repeat customers (quick login and direct checkout)
• api_import: Represents system integrations (product imports, stock updates, price changes)

We tuned tests to mirror production behavior by using a fixed dataset and codebase across all tests, maintaining a consistent cache state with Crawlee to prewarm Fastly's HTTP cache, and resetting the database before each run.

We adjusted virtual users (VUs) and pauses between actions to simulate natural usage rather than raw concurrency. Without these pauses, smaller plans are saturated almost instantly, producing stress test results rather than load test results.

Target metrics

We calibrated each test to align with:

• Conversion rate of ~3% (visitors to buyers)
• API requests share between 5%–10% of total traffic
• Response time target: p95 TTFB under 600ms
• CPU usage ceiling: kept near but below 70%
• Error rate: under 0.05% failed requests

Tests ran for 5 minutes per configuration, repeated across six plan types.

Performance results

Here's what the testing revealed:

Key Observations

• Performance scales predictably with resources. Even modest plans, like XL, were capable of processing over 3,000 orders/day under optimal conditions.
• p95 response time held steady. p95 TTFB remained under or near the 600ms target across all plans. However, to maintain this objective, we had to cap API import VUs at a maximum of 5. Going over five increased TTFB and limited RPS, even on the biggest plans.
• API load is expensive. API requests, especially those that create or update products, invalidate multiple cache layers and stress both the database and Fastly edge. Even at just 5–10% of total traffic, they account for a disproportionate share of resource usage.
• Low failure rates across all tiers. All plans maintained failure rates below 0.05%, demonstrating Shopware PaaS's resilience under consistent load.

Using Blackfire to identify bottlenecks

Shopware PaaS includes Blackfire by default, giving you powerful tools to profile, observe, and continuously optimize your storefronts.

Why profiling matters

Profiling helps answer questions like:

• Why does this category page cause the CPU to spike?
• What's behind this sudden I/O contention?
• Is my ERP update logic inefficient?
• Why does this plugin kill performance in staging but not locally?

How to profile a Shopware page

You can initiate a profile from the Blackfire browser extension, the Blackfire CLI in staging or development, or your CI pipeline for automated test-based profiling.

Each profile provides a flame graph of the full request lifecycle, including execution time per function or service, I/O and memory usage hotspots, and time spent in templates, Doctrine queries, Redis calls, and plugins.

Shopware-specific insights

Blackfire offers Shopware-specific instrumentation that exposes performance metrics aligned with the platform's architecture, including precise timings for ProductListingRoute, template rendering performance, and plugin listener overhead.

Common bottlenecks

• Plugins with inefficient hooks: Profiling reveals plugins that hook into every request and perform expensive logic, such as redundant database lookups or external API calls.
• Overloaded product listings: Pages that render too many products or lack pagination trigger massive SQL queries and costly rendering.
• Unbatched ERP updates: Frequent product updates without batching or delay saturate I/O, invalidate caches, and block PHP workers.
• Verbose logging in production: As seen in the PayPal debug case, this can overwhelm disk I/O and cause delays in responses.

Real-world example: analytics extension

Three years ago, a Shopware PaaS pilot customer experienced significant performance degradation, which occasionally resulted in downtime lasting several minutes and occurred multiple times a month. Using Blackfire enabled the immediate detection of a Statistics module executing exceptionally large queries, which effectively locked the MySQL database for durations of up to 16 minutes.

Blackfire facilitated rapid identification of the root cause within minutes, converting prolonged speculative analyses into swift diagnoses.

Lessons from the field

Configuration must be intentional

Default or ill-considered configuration choices are one of the most common sources of performance degradation. Category pages set to display too many products, logging levels left at debug in production, or pagination settings left in the default state all contribute to poor performance.

Projects that perform well exhibit intentionality in their setup: pagination, logging verbosity, cache invalidation behavior, and plugin configurations are explicitly tuned.

Plugin usage requires vigilance

Third-party and custom plugins frequently account for the majority of runtime overhead in poorly performing storefronts. A plugin may introduce hooks that trigger on every request, perform redundant database operations, or interfere with cacheability.

High-performing projects treat plugins as runtime components to be evaluated and, where necessary, replaced or disabled; not just installed.

Caching is central but often undervalued.

Caching success depends on deliberate implementation: using GET methods over POST, proper cache headers, and URL structures that avoid unnecessary variation.

In many cases, performance issues stem not from an absence of caching, but from cache invalidation processes triggered by unbatched ERP updates or administrative changes. Projects that maintain performance under load manage invalidation carefully and employ soft purge strategies.

Performance testing must be realistic

Effective testing requires representative traffic blends, realistic conversion rates, appropriate delays between actions, and accurate replication of backend behaviors. This includes your CDN; while including Fastly in load tests may seem controversial, it's essential since Fastly is a key component of the runtime environment.

Testing that omits API imports, bot traffic, or concurrent checkout processes may fail to reveal scalability bottlenecks until they manifest in production.

Operational discipline drives resilience

Successful Shopware projects are characterized by operational discipline, including CI/CD pipelines, staging environments that mirror production, monitoring and alerting, and well-tested rollback procedures.

This extends to campaign preparation; peak traffic events are treated as technical milestones. High-performing teams rehearse traffic scenarios in advance, prewarm caches, monitor system metrics throughout, and ensure rollback readiness.

Pre-launch readiness checklist

Before going live or launching a major campaign, confirm:

• [ ] Product and category listings are paginated and optimized for efficient SQL queries.
• [ ] Plugin and extension performance has been profiled; unnecessary plugins are disabled.
• [ ] Logging levels are correctly set for production (no debug logs unless needed temporarily)
• [ ] ERP and external synchronizations are batched and scheduled outside peak hours.
• [ ] API-driven cache invalidations are delayed, batched, or throttled (Shopware ≥ 6.7)
• [ ] Cache prewarming is in place for key landing pages and navigation flows.
• [ ] HTTP cache is working: X-Cache headers return HIT for expected routes.
• [ ] The volume of cache invalidations per day remains within expected bounds.
• [ ] Infrastructure capacity has been sized for a realistic peak load (CPU usage stays below ~70%)
• [ ] Load tests have been run using realistic traffic mixes and session behaviors.
• [ ] CI/CD pipelines are tested and produce deterministic builds.
• [ ] Monitoring and alerting are enabled for application, system, and business-critical metrics.
• [ ] Deployment logs are reviewed for uncaught exceptions or failed hooks.
• [ ] 3rd-party integrations are monitored for availability and latency.
• [ ] Security headers and HTTPS enforcement are tested.
• [ ] SEO-critical pages are crawlable and performant under PageSpeed Insights.

Conclusion

The results of our testing and field experience demonstrate that Shopware can perform exceptionally well, but only when supported by deliberate infrastructure decisions, thoughtful architectural patterns, and disciplined operational practices.

The most consistent lesson: Shopware performance is a shared, continuous responsibility. It's shaped not only by infrastructure size or application code, but by how thoughtfully a project is configured, extended, observed, and operated.

Real-world deployments prove this. A misconfigured payment plugin logging at the debug level in one project generated excessive disk I/O, severely slowing the site. Another experienced regular freezes due to an analytics module issuing long-running SQL queries that locked the database. One customer generated over 500 million cache invalidations per day through unbatched ERP updates, resulting in the cache remaining perpetually cold.

In contrast, projects that achieved stable, fast response times shared certain habits: they employed tools like Blackfire to locate bottlenecks, used deferred or soft purging to manage cache invalidation intelligently, and maintained close alignment between ERP updates and cache regeneration strategies. They didn't wait for performance to degrade; they designed for it.

What you can do next

• Review your caching strategy
• Audit your plugin stack
• Validate configuration
• Replicate traffic
• Standardize deployment
• Use environment variables for configuration
• Protect your infrastructure (ask about Fastly Next-Generation WAF)
• Centralize your logs and audit them

Performance excellence isn't reserved for large teams or enterprise budgets; it's the result of consistently applying engineering discipline.

Recommended tools and resources

• Blackfire documentation: https://docs.blackfire.io
• Shopware PaaS Blackfire integration: https://developer.shopware.com/docs/products/paas/blackfire.html
• Grafana K6 (Open Source): https://k6.io
• Shopware K6 scenario repository: https://github.com/shopware/k6-shopware
• Crawlee (for cache prewarming): https://crawlee.dev
• PHP-FPM runtime tuning (Upsun): https://fixed.docs.upsun.com/languages/php/fpm.html