Shopware 6 performance 2026: server and shop setup

Many Shopware 6 shops load more slowly than they need to. Usually it is not the platform’s fault, but a mismatch between server, configuration and shop setup. This guide shows the measures we use to make shops on Shopware 6.5, 6.6 and 6.7 faster: from AVIF images, Redis and OpenSearch to php.ini, PHP-FPM and the database.

In e-commerce, loading times cost visitors, conversions and rankings. The recommendations come from projects with more than 250,000 products, 10 languages and complex variant structures.

Applies to: Shopware 6.5, 6.6 and 6.7, self-hosted (on-premise). The recommendations are aimed at shop operators and agencies with access to the server configuration.

1. Convert images to AVIF

Product images account for the largest share of a shop’s page weight. Compared with JPEG and PNG, AVIF compresses by 50 to 70 per cent at the same or better image quality. For Shopware 6, that means faster loading times, better Core Web Vitals and less bandwidth, especially on mobile devices.

With our Media Booster plugin, all existing and newly uploaded images can be converted to AVIF automatically. This runs in the background, and your team does not have to change its usual workflow.

Quick win: switching to AVIF alone can reduce your shop’s total loading time by 30 to 50 per cent, because images usually make up the largest part of the page weight.

2. Remove unnecessary plugins

Every active plugin in Shopware 6 is loaded on every page request, even if it does nothing on the current page. Many shops accumulate plugins over the years that were tested once and never deactivated. That costs time on every single request.

How to proceed:

Make a list of all active plugins and check for each one whether it is actually in use.
Deactivate and uninstall everything that is not needed, even if it is “just a small plugin”.
Pay particular attention to plugins that load their own JavaScript or CSS files. They slow down the frontend directly.
After the clean-up, use the FroshTools plugin (by Friends of Shopware) to find further open performance issues.

Caution: always create a full backup (database and files) before removing plugins. Some plugins create their own database tables, which should be cleaned up during uninstallation.

3. Enable lazy loading

Lazy loading only loads images and other resources when they appear in the visible area of the browser. Instead of loading all 50 product images of a category page at once on the first visit, only the visible ones load immediately and the rest follow as you scroll.

In Shopware 6, native lazy loading via the HTML attribute loading="lazy" is already provided for in most themes. Still, check whether it is really active for product images in listings, on category pages and in Shopping Experiences. It is often missing in custom themes and older theme versions.

4. Set up OpenSearch or Elasticsearch

Shopware’s standard database search quickly reaches its limits with larger product ranges, in the frontend (product search, filters, listing) as well as in the admin. The remedy is OpenSearch or Elasticsearch as a dedicated search engine.

What this actually brings:

Frontend: product listings, filters and shop search load much faster. In shops with thousands of products and many properties, you notice the difference immediately.
Admin: product, customer and order search responds without long waits. Anyone who has worked in the admin of a shop with more than 50,000 products knows how slow the standard search is.

OpenSearch is the recommended successor to Elasticsearch and is officially supported by Shopware. Setting it up requires a separate service on the server, but the benefit is noticeable from around 1,000 products.

5. Redis as cache and session backend

Redis is an in-memory data store: the data is held in RAM rather than on disk. For Shopware 6, this means that cache queries and session data are processed many times faster than with the standard file system.

We recommend Redis for:

HTTP cache: cached pages are delivered very quickly.
Application cache: internal Shopware caches (configuration, routes, categories) are held in RAM.
Sessions: carts and login sessions run via Redis instead of files.

Hardware recommendation: plan at least 8 GB RAM for Redis. For larger shops with many parallel sessions and a large product range, more is better. Redis is only as fast as the available memory allows.

6. Optimise the PHP configuration (php.ini)

Most hosting providers’ default PHP configuration is designed to just about work, not for performance. For Shopware 6, it pays to adjust php.ini specifically. We use the following values in our projects and recommend them for shops on dedicated hardware with at least 8 CPU cores and 32 GB RAM (correspondingly more for larger projects).

Memory and upload

Shopware needs sufficient memory for imports, plugin installations and media management. These values prevent large operations from aborting:

memory_limit = 2048M
post_max_size = 512M
upload_max_filesize = 256M
max_input_vars = 6000
max_file_uploads = 100
file_uploads = On

Setting memory_limit to 2 GB gives Shopware enough room for extensive product imports and admin operations. max_input_vars at 6000 is important because Shopware submits many fields at once in complex forms (e.g. variant configuration).

Execution times

max_execution_time = 120
max_input_time = 120

120 seconds is enough for most Shopware operations. If you regularly run large data imports via the admin, you can set the value higher. In normal frontend operation, this limit is never reached.

Error handling (production)

display_errors = Off
display_startup_errors = Off
log_errors = On
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

Error messages belong in the log, not on the screen. On a production system, end customers should never see errors: it is a security risk and looks unprofessional. Deprecated and strict warnings are suppressed because in Shopware they often come from third-party plugins and do not require immediate action.

Security

expose_php = Off
allow_url_fopen = On
allow_url_include = Off

expose_php = Off prevents the PHP version from appearing in the HTTP header. allow_url_fopen must be enabled for Shopware (Composer, Plugin Store), while allow_url_include should always stay off for security reasons.

Session handling via Redis

session.save_handler = redis
session.save_path = "unix://{REDIS_SOCKET}?database=0&auth={REDIS_PASSWORD}"
session.gc_maxlifetime = 14400
session.auto_start = Off
session.use_strict_mode = On
session.cookie_httponly = On
session.cookie_secure = On
session.cookie_samesite = "Lax"

This configures Redis as the session backend. Replace {REDIS_SOCKET} and {REDIS_PASSWORD} with your actual values. The cookie settings (httponly, secure, samesite) follow current security best practices. Setting gc_maxlifetime to 14400 seconds (4 hours) ensures that carts are not lost too quickly.

Realpath cache

realpath_cache_size = 4096K
realpath_cache_ttl = 3600

This often overlooked value is particularly important for Shopware. Shopware 6 is based on Symfony and loads hundreds of PHP files on every request. The realpath cache stores the resolved file paths in memory so that the file system does not have to be queried again each time. A cache size of 4 MB and a TTL of 1 hour suit most shops.

OPcache: the biggest lever

opcache.enable = 1
opcache.enable_cli = 1
opcache.memory_consumption = 512
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 65000
opcache.max_wasted_percentage = 10

; Disable timestamps in production
; (after deploy: php-fpm reload required!)
opcache.validate_timestamps = 0
opcache.revalidate_freq = 0

opcache.fast_shutdown = 1
opcache.enable_file_override = 1
opcache.huge_code_pages = 1

; JIT (PHP 8.x, significant performance boost)
opcache.jit = 1255
opcache.jit_buffer_size = 256M

OPcache compiles PHP files once and keeps the result in memory. Without OPcache, PHP has to parse and compile all files again on every request, and with Shopware that means thousands of files per page view.

The most important settings:

memory_consumption = 512: 512 MB for the OPcache. Shopware 6 with plugins often needs 200 to 400 MB, so plan generously.
max_accelerated_files = 65000: maximum number of cached files. Shopware 6 alone ships thousands of PHP files, plus plugins and vendor libraries.
validate_timestamps = 0: the most important setting in production. PHP no longer checks on every request whether a file has changed, which saves a lot of I/O. Important: after every deployment, PHP-FPM must be reloaded (systemctl reload php-fpm) so that the new files take effect.
JIT (opcache.jit = 1255): the just-in-time compiler in PHP 8.x translates frequently executed code directly into machine code. In Shopware, this brings noticeably more speed, especially for compute-intensive tasks such as price calculations and template rendering.

7. PHP-FPM process management

PHP-FPM (FastCGI Process Manager) manages the PHP processes that handle requests to your shop. The default configuration is intended for small websites, not for a Shopware shop under load. With the right configuration, enough workers are available to process parallel requests without waiting.

Our starting configuration:

pm = dynamic
pm.max_children = 128
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 40
pm.max_requests = 500

What the values mean:

pm = dynamic: PHP-FPM starts and stops workers depending on load. This is the best compromise between performance and resource consumption.
max_children = 128: maximum number of simultaneous PHP processes. With 32 GB RAM and an average of around 80 to 120 MB per worker, this is enough for most shops.
start_servers = 20: number of workers available immediately when PHP-FPM starts.
min/max_spare_servers: always keeps 10 to 40 idle workers ready so that requests do not wait for a new process.
max_requests = 500: a worker is restarted after 500 requests. This prevents memory leaks from long-running processes.

Important: these values are a starting point, not dogma. After the switch, check your server’s CPU and RAM usage and adjust the values if necessary. We use this setup for small and large shops alike, but the right balance always depends on your hardware and your traffic.

8. Web server: Nginx instead of Apache

For Shopware 6, we generally recommend Nginx as the web server. Nginx handles static files (images, CSS, JavaScript) more efficiently than Apache and copes better with many simultaneous connections. Together with PHP-FPM, Nginx is the faster choice.

If your shop still runs on Apache and you are considering a switch: you can also book Nginx-based hosting with us, preconfigured for Shopware 6.

9. Database tuning

Every product page, every order and every search in the admin triggers database queries. If the database responds slowly, even the best PHP configuration won’t help.

Our recommendations:

Plan at least 2 GB RAM for the database, preferably 4 GB or more. The InnoDB buffer pool should be large enough for the entire database to fit into memory.
Prefer MariaDB: Shopware 6 runs on MariaDB and on MySQL 8. In most cases, MariaDB is the more straightforward choice.
Check the configuration with MySQL 8: if you use MySQL 8 instead of MariaDB, you need to make sure the configuration is correct. The authentication mode and collation settings in particular cause problems if they are not explicitly adjusted for Shopware.

10. Profiling, if things still stutter

You have implemented all the measures and your shop still stutters? Then a profiling tool will help. With Tideways, you can analyse at code level which functions, database queries or plugin calls take up the most time.

Tideways shows exactly where the milliseconds are lost: a badly written plugin, a missing database index or an inefficient template block. In complex shops with many plugins and integrations, profiling is often the only way to find the actual bottlenecks.

Practical examples: shops with this setup, hosted by us

We run these shops with the performance setup described:

eurafco.com: international B2B shop with 10 languages, several subshops and complex variant structures, with fast loading times on all sales channels.
fahrwerkonline.de: more than 250,000 products in the range. Thanks to OpenSearch and Redis, search stays fast even with this volume of data.
finnia-gartenwelt.de: a tidy shop with an optimised checkout and fast loading times.
vinlorenc.de: wine shop with its own design and fast delivery.
schecker.de: pet supplies shop with a large product range and high traffic.

Summary: the performance checklist

All measures at a glance, sorted by effort and impact.

Quick wins (can be implemented immediately)

Convert images to AVIF (Media Booster plugin)
Deactivate and uninstall unnecessary plugins
Make sure lazy loading is active for all images
Install FroshTools and run the performance check

Server optimisation (medium effort)

Set up Redis for cache and sessions (at least 8 GB RAM)
Optimise php.ini (OPcache, JIT, realpath cache)
Configure and monitor PHP-FPM workers
Switch to Nginx (if still on Apache)

Infrastructure (greater effort, biggest effect)

Set up OpenSearch or Elasticsearch
Optimise database RAM and configuration
Profile with Tideways if bottlenecks remain

A fast shop through a well-matched setup

A fast Shopware shop rarely comes from a single measure. It takes suitable hosting, a clean configuration and a tidy shop. You set up most of the optimisations described here once, and after that they work permanently.

Your customers will notice the difference, so will your team in the admin, and ultimately so will your Google rankings.

Get in touch if you would like us to analyse your current setup and implement the optimisations, from the server configuration to the shop. Find out more on our page about Shopware performance optimisation or contact us directly via our contact page.

Shopware 6 performance guide 2026: how to make your shop fast