Where your shop loses timeand how Shopware performancegets better

Measuring

How do you measure the Shopware performance of your shop?

The best way to measure Shopware performance is with the Core Web Vitals, because they show what visitors feel rather than just how fast the server responds. Google names three values: the largest visible element (LCP) should appear within 2.5 seconds, the response to an interaction (INP) should stay under 200 milliseconds and layout shift (CLS) should stay below 0.1.

Two free tools from Google are enough to start with. PageSpeed Insights tests a single page, and the Core Web Vitals report in Search Console shows how whole groups of pages perform. Do not only test the home page, but also a category with many filters, a product page and the cart, because that is where the differences are (the home page is often the fastest page in the whole shop).

Record the current state before every change. If you change three things at once and then see a better number, you will not know which of the three did it, and you can no longer keep or undo the other two with a clear conscience.

Cache

Which Shopware caching delivers the most?

Shopware caching starts with the built-in HTTP cache, which the developer documentation describes as mandatory for every production system. It stores finished pages and serves them without Shopware having to assemble them again on every request. It is switched on with the environment variable SHOPWARE_HTTP_CACHE_ENABLED, and SHOPWARE_HTTP_DEFAULT_TTL controls how long entries live.

If several app servers run side by side, Shopware advises a reverse proxy that sits in front of the shop and delivers the pages itself. The documented option is mainly Varnish, which keeps pages in memory and serves them before a request even reaches the shop. On a single server this is often more effort than it is worth, but for shops with traffic peaks it is frequently the biggest single lever.

Every page cache has a limit you should know about: personalised content cannot simply be cached for everyone. A cache therefore does not make up for slow queries in the code, it only hides them until someone opens a page that is not in the cache.

Redis

What does Shopware need Redis for?

Shopware Redis use is about a fast cache for sessions and cache data, so that these accesses do not land on the hard disk or in the database. Without further configuration, Shopware uses the session store set in PHP, which according to the documentation is the file system on most installations.

For larger setups with clusters or a lot of traffic, the documentation recommends a different store such as Redis to take load off the database. If sessions are held centrally in Redis, the individual app servers no longer carry their own state and are easier to run side by side. Instead of Redis itself, the open source fork Valkey is now also an option, and Shopware names it in its hosting guide as well.

For sessions, do not run Redis as pure memory without persistence, otherwise every cart and login is gone after a restart. The documentation recommends Redis persistence for this. So do not just ask your host whether Redis is available, ask how it is backed up.

Search

When is Shopware Elasticsearch or OpenSearch worth it?

Shopware Elasticsearch or OpenSearch is worth it as soon as search and product listings served from the database become noticeably slower. The search engine then takes over product search in the storefront, category listings and search in the Administration, and the database no longer has to answer these queries itself.

Where exactly the threshold lies is answered differently by different sources. The Shopware documentation talks about projects with several thousand records, while trade articles put the line at 1,000 products in one case and 10,000 in another. So do not rely on a number, measure your slowest category with all filters applied.

Technically the search engine is optional, and Shopware runs without it. But it adds a separate service that needs memory and maintenance, and the data has to be reindexed after changes. For a small shop with a few hundred products, that is often more operational work than it gains in speed.

Background

Why does the admin worker slow down Shopware performance?

The admin worker slows down Shopware performance because it processes background tasks through the browser as long as someone is logged in to the Administration. The developer documentation is clear on this: on a production system, the message queue should be processed from the command line rather than through the browser in the Administration.

There are two reasons. If several people are logged in to the Administration, the admin worker creates high CPU load, and if nobody is logged in, the tasks simply pile up. You switch it off in the configuration with enable_admin_worker: false, and in its place comes a worker that systemd or supervisor keeps running permanently and restarts when needed.

Before you switch, check with your host whether permanently running processes are allowed. Not every hosting package permits them, and in that case switching off the admin worker leaves you with no worker at all.

Images

How do you optimize Shopware for images?

To optimize Shopware for images, use suitable thumbnail sizes and a compact format, because on many pages the product image is exactly the element the LCP value is measured on. By default, Shopware generates thumbnails at 400 × 400, 800 × 800 and 1920 × 1920 pixels for uploaded images. The sizes and quality of these thumbnails can be adjusted in the settings of each media folder.

Shopware accepts WebP as a file format. According to Google, lossy WebP images are 25 to 34 percent smaller than comparable JPEG files at the same quality. Whether a theme then actually delivers the images at the right size is best checked directly in PageSpeed Insights, which lists oversized images one by one.

One mistake comes up again and again: the main image of a page is only loaded once the visitor scrolls. Anything above the visible edge should load immediately, everything below it can wait.

Plugins

Which plugins slow down Shopware performance?

Plugins slow down Shopware performance when they add extra database queries, event listeners or storefront scripts to every request, and you cannot tell that from the outside. The fastest way to the cause is a profiler. Shopware has built-in interfaces for profilers such as the Symfony profiler and Tideways, which show how much time each part of a request takes.

Often it is not the big shop plugin at all, but a custom connection, for example to the ERP system, that loads more data than necessary during checkout. Cases like this are only found by measuring, not by guessing. Extensions that are installed but deactivated should still be cleaned up regularly, because they have to be taken into account with every update too.

If you are having a feature built, performance belongs in the briefing. With Shopware development at Scalableloops, we test our own extensions on Shopware 6.6 and 6.7 before they go live. How such a project runs and how it differs from a Store plugin is covered in our Shopware plugin development guide and in the comparison buy or build.

Hosting

What Shopware hosting does Shopware 6.7 need?

For Shopware hosting, the hosting guide in the developer documentation (as of October 2026, Shopware 6.7) lists PHP 8.2 or newer, a memory limit of at least 512 MB and a database running MariaDB 10.11 or newer or MySQL 8.0. Redis from version 7 and search via OpenSearch or Elasticsearch are listed there as optional.

Optional means the shop will start without them. For a shop that generates revenue, though, the list is more of a minimum than a recommendation, and some trade articles advise more memory than 512 MB in production. So when choosing hosting, ask about the services from the sections above, not just about CPU cores and RAM.

Versions change with every major Shopware release. Before switching, it is worth reading our Shopware update guide, because an update to a new major version often brings new minimum requirements for PHP and the database.

Next week

How to improve Shopware performance step by step

1. 01Measure the baselineTest the home page, a category with filters, a product page and the cart in PageSpeed Insights and note LCP, INP and CLS.
2. 02Check the basicsFind out whether the page cache is active, whether the admin worker is still running and where sessions and cache are stored. Your host or developer can usually answer this in one conversation.
3. 03One change at a timeOnly change one building block at a time and then measure the same pages again. That way you can see what worked.
4. 04Tackle plugins and imagesIf a page stays slow, use a profiler to find the cause and check the size and format of the images. For a second opinion, there is our free consultation.