Every second counts: Google rates a Largest Contentful Paint of 2.5 seconds or less as good (Google/web.dev). At the same time, Shopware 6.7 brings significant performance improvements. In this guide, we show how to systematically optimize your Shopware shop - from server configuration to frontend to caching. The result: faster load times, happier customers and better conditions for conversions.
Why Shop Performance Determines Revenue
The load time of an online shop is not merely a technical detail - it has a direct impact on business success. Slow shops lose visitors, conversions and revenue. The Core Web Vitals thresholds and the experience of large publishers show what matters:
- Google rates a Largest Contentful Paint of 2.5 seconds or less as good (Google/web.dev)
- The BBC reported losing 10% of users for every extra second of page load time (BBC/Creative Bloq)
- An Interaction to Next Paint of 200 milliseconds or less counts as good responsiveness (Google/web.dev)
- A Cumulative Layout Shift of 0.1 or less indicates a stable layout without content jumps (Google/web.dev)
Especially on mobile devices with fluctuating network quality, performance determines the difference between a completed purchase and an abandonment. The Core Web Vitals thresholds apply regardless of device - a mobile network is simply much harder to control than a fibre connection in the office.
If your competition has 4-second load times and you have 1.5 seconds - you have a measurable advantage in bounce rate, conversion and SEO rankings. Performance optimization is one of the most efficient investments in e-commerce.
| Load Time | User Behavior | Conversion Effect |
|---|---|---|
| < 2 seconds | Low bounce rate | Optimal |
| 2-3 seconds | Slight impatience | Slightly reduced |
| 3-5 seconds | Significantly more abandonment | Noticeably reduced |
| 5+ seconds | Massive attrition | Strongly reduced |
Shopware 6.7 - Performance Improvements Overview
With Shopware 6.7, shopware AG has introduced a series of fundamental performance optimizations that noticeably accelerate operations. The most important improvements affect both backend and frontend:
108% more orders/s
According to Shopware, the Storefront processes more than double the orders per second compared to the previous version in the flash sale scenario with active caching (Shopware).
85% less latency
According to Shopware, response times under simultaneous API load have been considerably reduced, directly impacting Time to First Byte (TTFB) (Shopware).
25% smaller payloads
According to Shopware, JavaScript and CSS files are approximately 25% smaller, which shortens load times especially on mobile devices (Shopware).
Additionally, internal processes such as OpenSearch indexing, DAL queries and the event system have been optimized. For shop operators, this means: Simply updating to Shopware 6.7 can bring a noticeable performance boost - provided the server infrastructure is configured accordingly.
Updating to Shopware 6.7 alone is not sufficient to leverage the full performance improvements. Server configuration, caching settings and plugin compatibility must also be adjusted. We support you with migration and optimization.
Optimizing Server Configuration
Server configuration is the foundation of any performance optimization. Without a solid base, frontend optimizations accomplish little. Three areas are particularly relevant for Shopware hosting:
Configuring PHP OPcache Correctly
OPcache stores compiled PHP bytecode in memory, avoiding repeated parsing and compilation on every request. For Shopware 6, OPcache preloading is particularly relevant: it can provide a 2-5% performance improvement (Shopware Documentation).
opcache.enable=1
opcache.memory_consumption=512
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.preload=/var/www/shop/var/cache/opcache-preload.php
opcache.preload_user=www-dataWith validate_timestamps=0, file changes are not automatically detected. After every deployment, the OPcache must be manually cleared (opcache_reset() or PHP-FPM restart). In development environments, validate_timestamps=1 should be set.
MySQL/MariaDB Tuning
Shopware 6 is database-intensive - product listings, filters, shopping carts and orders generate numerous queries. The most important parameters for database performance:
- InnoDB Buffer Pool: As a guideline around 70% of the RAM the database can use exclusively (e.g. 4-8 GB with 8-12 GB RAM)
- Disable Query Cache: Removed in MySQL 8.0 anyway, consciously disable in MariaDB
- Enable Slow Query Log: Identify and optimize queries over 1 second
- Adjust max_connections: Match to the number of PHP-FPM workers
- tmp_table_size and max_heap_table_size: Set to at least 64-128 MB
Redis or Valkey as Session and Cache Store
Redis (or its open-source fork Valkey) is the recommended store for sessions and object cache in Shopware 6. Compared to filesystem-based storage, Redis offers significantly faster access and reduces disk I/O. For professional operations, Redis is virtually indispensable.
framework:
cache:
app: cache.adapter.redis
system: cache.adapter.redis
session:
handler_id: 'redis://127.0.0.1:6379/1'Frontend Optimization for Maximum Speed
The frontend is the area your customers experience directly. This is where your shop is perceived as fast or slow. With Shopware 6.7, JS and CSS payloads are approximately 25% smaller (Shopware), but there are numerous additional optimization opportunities.
Image Optimization: The Biggest Lever
Images account for the largest share of data volume in most online shops. Switching to modern formats like WebP or AVIF can significantly reduce file sizes while maintaining visual quality:
| Format | File size (relative) | Note |
|---|---|---|
| JPEG/PNG | reference | fallback format for older browsers |
| WebP | 25-34% smaller than JPEG (Google) | natively generated in Shopware 6 |
| AVIF | around 50% smaller than JPEG (MDN Web Docs) | additional configuration required |
Shopware 6 supports WebP generation natively through its thumbnail settings. For AVIF support and advanced image optimization, additional configurations are required, which we implement as part of our performance analysis.
Optimizing CSS and JavaScript
- Critical CSS inline: Deliver above-the-fold CSS directly in the HTML
- Remove unused CSS: Eliminate unused CSS through PurgeCSS or manual audit
- JavaScript defer/async: Load non-critical scripts deferred
- Code splitting: Only load code needed on the current page
- Enable minification: Compress CSS and JS (Shopware production mode)
Lazy Loading and Resource Hints
Lazy loading ensures that images and iframes are only loaded when they become visible in the viewport. Combined with resource hints like preload for critical resources and preconnect for external domains, this results in a significant improvement in perceived load time.
<!-- Preload LCP image -->
<link rel="preload" as="image" href="{{ asset('hero.webp') }}" fetchpriority="high">
<!-- Preconnect to external domains -->
<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<link rel="dns-prefetch" href="https://cdn.example.com">Caching Strategies for Shopware 6
Caching is the most effective way to reduce response times of a Shopware shop. Instead of dynamically generating every page on every request, finished pages or partial components are stored. Shopware 6 offers multiple caching layers:
HTTP Cache
Shopware's built-in HTTP cache stores complete pages and serves them without PHP processing. For most shops, the most important cache layer.
Varnish Cache
For shops with high traffic, Varnish as a reverse proxy offers even faster response times than the built-in HTTP cache.
Object Cache (Redis)
Redis caches database queries and computed results. Particularly effective with complex product listings and filtering.
Configuring HTTP Cache
Shopware's built-in HTTP cache is powerful but must be configured correctly. Important considerations:
- Cache invalidation: Shopware automatically invalidates on product changes - ensure this works reliably
- Cache warmup: After a deploy or cache clear, important pages should be pre-cached
- Excluded URLs: Shopping cart, checkout and customer account must be excluded from cache
- Cache TTL: Adjust Shopware's default TTL (typically 3600s) to your update frequency
Varnish as Reverse Proxy
For shops with high traffic volumes, deploying Varnish as a reverse proxy in front of the web server is recommended. Varnish stores cached pages in RAM and can serve them with millisecond-level latency. Integration requires a customized VCL configuration and a well-designed hosting setup.
Improving Core Web Vitals in Shopware Shops
Core Web Vitals are an official Google ranking factor (Google). For Shopware shops, they are particularly relevant since e-commerce pages are typically more resource-intensive than content websites. The three metrics LCP, INP and CLS each require specific optimization approaches. Find more about the fundamental metrics in our Core Web Vitals guide.
Optimizing LCP (Largest Contentful Paint)
LCP measures how quickly the largest visible content is loaded - typically the hero image on category or landing pages. Target: under 2.5 seconds, ideally under 1.5 seconds.
- Identify the LCP element (Chrome DevTools > Performance Tab)
- Hero image as WebP/AVIF with
fetchpriority="high"and<link rel="preload"> - Deliver critical CSS inline to avoid render-blocking
- TTFB under 200ms through optimized hosting and caching
- No render-blocking scripts in
<head>before the LCP
Optimizing INP (Interaction to Next Paint)
INP replaced First Input Delay (FID) in 2024 and measures response time to all user interactions. For Shopware shops, this is particularly critical: product filters, variant selection, cart buttons and the mega menu. Target: under 200ms.
- Keep main thread free: Offload heavy computations to Web Workers
- Optimize event handlers: Debouncing for scroll and resize events
- Reduce third-party scripts: Every external script can worsen INP
- Break up long tasks: Split tasks over 50ms with
requestIdleCallbackorscheduler.yield()
Avoiding CLS (Cumulative Layout Shift)
Layout shifts are particularly annoying in e-commerce: When the "Add to Cart" button jumps while the customer is trying to click it, it leads to frustration. The most common CLS causes in Shopware shops:
- Product images without defined
widthandheightattributes - Late-loading web fonts without
font-display: swapand size-adjust - Dynamically inserted banners, cross-selling blocks or cookie notices
- Lazy loading without placeholder dimensions (use skeleton screens)
- Plugin-based elements that only appear after the initial render
Performance Monitoring and Continuous Optimization
Performance optimization is not a one-time project but an ongoing process. New plugins, content changes, theme updates or seasonal traffic spikes can impact performance at any time. Professional monitoring is therefore essential.
- Google Search Console: Regularly check Core Web Vitals field data
- Lighthouse CI: Automated performance tests in the CI/CD pipeline
- Real User Monitoring (RUM): Measure actual load times from real users
- Synthetic Monitoring: Regular tests of defined pages and workflows
- Alerting: Set up notifications for performance regressions
We recommend running performance checks at least weekly and conducting a full Lighthouse audit after every major update or plugin release. As part of our consulting services, we help you build a sustainable performance monitoring setup.
Performance optimization is an interplay of server, caching, frontend and monitoring. We systematically analyze every aspect of your Shopware shop and implement measures that deliver measurable results - from server configuration to SEO-relevant Core Web Vitals optimization.
This article is based on data from: Shopware (performance figures for Shopware 6.7), Shopware Documentation (OPcache preloading), BBC/Creative Bloq (load time and user loss), Google/web.dev (Core Web Vitals), Google (WebP file sizes), MDN Web Docs (AVIF file sizes). The cited values may vary depending on shop, configuration and measurement time.
Optimal is a load time under 2 seconds. With professional performance optimization and the right server configuration, a very fast shop with Shopware 6 is achievable. As a guideline, use the Largest Contentful Paint: Google rates 2.5 seconds or less as good (Google/web.dev).
Core Web Vitals are an official Google ranking factor (Google). Shops with good LCP, INP and CLS values tend to rank higher with equal relevance. Improving search engine optimization therefore goes hand in hand with performance optimization.
Shopware 6.7 brings significant performance improvements - according to Shopware up to 108% more orders per second in the flash sale scenario with active caching and up to 85% less latency under simultaneous API load (Shopware). However, server configuration, caching and plugins must also be adjusted to fully leverage the improvements.
Depending on the starting situation and scope of the shop, expect 1-4 weeks. The biggest improvements are typically achieved in the first days through caching configuration and image optimization. Fine-tuning Core Web Vitals and frontend development requires more time.
Redis is recommended for virtually every Shopware shop - it significantly accelerates sessions and object cache. Varnish is particularly worthwhile with high traffic volumes. We advise you as part of a performance analysis on which caching strategy is optimal for your shop.
A content delivery network can serve static assets like images, CSS and JavaScript closer to the visitor and thus reduce load times - especially for internationally distributed customers or image-heavy catalogs. Combined with modern protocols like HTTP/3, perceived speed typically improves noticeably. Whether a CDN is worthwhile for your shop is something we clarify as part of our performance analysis.