Why Shopware 6 Feels Slow on Shared Hosting

Shopware 6 is a Symfony-based application with a heavy bootstrap. Every uncached request has to build the dependency injection container, resolve the sales channel context, run the DAL (Data Abstraction Layer) against MySQL/MariaDB, and render Twig templates through the Storefront bundle. On a dedicated box this overhead is masked by fast CPUs and generous memory. On managed shared hosting, the same work competes with other accounts, so any inefficiency in the caching layers becomes visible as multi-second Time To First Byte (TTFB).

The practical reality is that Shopware is designed to serve the overwhelming majority of storefront traffic from its HTTP cache, never touching the full PHP stack. When pages feel slow, it is almost always because one of three layers is missing or misconfigured: the application container/template cache is cold and being rebuilt per request, the HTTP cache is disabled or constantly invalidated, or the PHP runtime (OPcache + memory limits) is too small to keep compiled code resident. None of these require root to fix. They live inside the Shopware admin, the .env file in your document root, the PHP Selector in cPanel/DirectAdmin, and your .htaccess.

Before changing anything, measure. In the Shopware administration, open Settings → System → Caches & indexes and confirm the caches are warm. Then check your account's PHP version and extensions in cPanel's Select PHP Version (MultiPHP / PHP Selector) or DirectAdmin's PHP Version Selector. Shopware 6.5+ expects PHP 8.1–8.3; running an older interpreter or missing opcache, redis, or apcu extensions forces slow fallbacks. Finally, tail the application log at var/log/ (for example var/log/prod-2026-10-01.log) through File Manager to see whether cache rebuilds or deprecation warnings are firing on normal page views.

OPcache and PHP Runtime Tuning via PHP Selector and .user.ini

OPcache keeps compiled PHP bytecode in memory so Symfony's thousands of class files are not recompiled on every request. A default OPcache sized for a brochure site chokes on Shopware's file count, evicting entries constantly. You cannot edit php.ini directly on shared hosting, but CloudLinux PHP Selector exposes the same directives per account.

In cPanel open Select PHP Version → Options (or in DirectAdmin PHP Version Selector → Options / PHP Settings) and raise the following values where the panel allows it:

opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 50000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 60

The max_accelerated_files value matters most: Shopware plus its vendor tree easily exceeds 20,000 PHP files, and a low ceiling means OPcache silently stops caching once it fills. For values the panel does not expose, drop a .user.ini file in your document root (the folder containing public/, usually ~/public_html or a subfolder). LiteSpeed and PHP read it per directory:

memory_limit = 512M
max_execution_time = 120
max_input_vars = 10000
realpath_cache_size = 4096K
realpath_cache_ttl = 600
opcache.memory_consumption = 256
opcache.max_accelerated_files = 50000

The realpath_cache tuning is frequently overlooked. Symfony resolves many symlinked and nested paths; a small realpath cache forces repeated stat() calls on disk, which is expensive on shared storage. The memory_limit of 512M covers plugin installs, theme compilation, and the admin, without which you will see white screens during theme:compile style operations. After saving, changes to .user.ini take effect after the user_ini.cache_ttl window (typically 300 seconds) or an LSPHP process recycle. Verify the live values by creating a temporary public/phpinfo.php with <?php phpinfo();, loading it once, then deleting it immediately so it is never left exposed.

While you are in PHP Selector, confirm the opcache, redis, apcu, intl, gd, and zip extensions are ticked. Shopware's console warmers and the DAL depend on intl; a missing redis extension means your Redis configuration below will silently be ignored and Shopware will fall back to filesystem caching.

Redis, HTTP Cache, and LiteSpeed Full-Page Caching

Shopware's single biggest win on shared hosting is serving full pages from cache. There are two cooperating layers: Shopware's own reverse-proxy-aware HTTP cache, and a backing store (filesystem, APCu, or Redis) for the application cache, sessions, and cart data. If your hosting plan provides a per-account Redis instance (check cPanel for a Redis icon or ask support for your socket/port), point Shopware at it to avoid thousands of small file writes to shared disk.

Edit the .env (or .env.local) file in your Shopware root through File Manager. Enable the HTTP cache and wire Redis for cache, sessions, and cart:

APP_ENV=prod
APP_DEBUG=0
SHOPWARE_HTTP_CACHE_ENABLED=1
SHOPWARE_HTTP_DEFAULT_TTL=7200

REDIS_URL=redis://127.0.0.1:6379/0
SESSION_HANDLER=redis

For the application cache pools and cart storage, Shopware 6.5+ reads a YAML override. Create or edit config/packages/prod/cache.yaml:

framework:
    cache:
        app: cache.adapter.redis
        default_redis_provider: 'redis://127.0.0.1:6379/1'

shopware:
    cart:
        redis_url: 'redis://127.0.0.1:6379/2'
    number_range:
        redis_url: 'redis://127.0.0.1:6379/3'

Using separate Redis databases (/1, /2, /3) keeps cart and number-range data from being flushed when you clear the application cache. If your plan has no Redis, leave the defaults; Shopware will use the filesystem under var/cache, which still benefits enormously from the OPcache and realpath tuning above. After editing, clear and warm the cache from Settings → System → Caches & indexes → Clear caches so the new adapters take effect.

On LiteSpeed-powered accounts, the server honors cache-control headers Shopware emits, giving you edge full-page caching without a separate plugin. Confirm your storefront .htaccess (in public/) has not stripped these headers and that no rule forces Cache-Control: no-cache. A minimal, safe block looks like this:

<IfModule LiteSpeed>
CacheLookup on
</IfModule>

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
</IfModule>

Do not attempt to add server-wide LiteSpeed cache roots or vhost directives; those live in server config you cannot touch. The CacheLookup on directive is the only account-level switch that lets LSWS serve Shopware's cacheable responses from its own store, and it respects the TTL Shopware sets via SHOPWARE_HTTP_DEFAULT_TTL.

Application-Level Optimizations and Keeping Caches Warm

Caching infrastructure only helps if Shopware isn't invalidating it constantly or doing avoidable work per request. Start in the admin under Settings → System → Caches & indexes and make sure the indexers (product, category, SEO URL, sitemap) are built. A storefront that triggers live indexing on each visit will never cache well. Rebuild them with the console if you have terminal access through cPanel, or trigger a full reindex from that admin screen.

Themes are the other common culprit. An uncompiled or repeatedly recompiled theme forces Shopware to assemble CSS/JS on demand. After any theme or plugin change, run Settings → Theme → … → Update theme (or theme:compile) once so compiled assets live under public/theme and are served statically. Enable asset versioning so browsers cache aggressively while still picking up new deployments.

Reduce the number of products loaded per listing and the associations the DAL eager-loads. In Settings → Shop → Listings, keep products-per-page reasonable (24–48) and disable unused dynamic product group refreshes, which run expensive queries. Audit installed plugins from Extensions → My extensions: deactivate any that subscribe to storefront events or inject uncached content, since a single plugin forcing no-store headers can defeat the entire HTTP cache for every page.

Finally, confirm your database health, because slow queries surface as slow PHP. Through phpMyAdmin, check that large tables such as product, sales_channel, and enqueue are not bloated with stale message-queue rows; truncate the enqueue table during maintenance if it has grown into the hundreds of thousands. The same filesystem and index hygiene principles apply across PHP CMS platforms — the companion walkthrough on MODX Revolution performance and caching covers OPcache and Redis diagnostics that translate directly to Shopware. With OPcache sized correctly, Redis or filesystem caching warm, LiteSpeed serving cacheable responses, and indexers and themes compiled, a Shopware 6 storefront on managed shared hosting routinely returns cached pages in well under 200ms TTFB without any root-level changes.