Optimér Shopware-performance 2026: indlæsningstid, Core Web Vitals, caching

Hvorfor Shopware 6 bliver langsom, og hvilke indstillinger fra Shopware-dokumentationen der hjælper i hvilken rækkefølge: HTTP-cache, Redis, queue-workers, OpenSearch, billeder, PHP. Med målværdier og priser for webshops i Danmark.

Det korte svar

De største gevinster ligger i backend, ikke i temaet. En aktiv HTTP-cache, Redis i stedet for filsystemet, en slået fra admin-worker med rigtige queue-workers og fra nogle tusinde produkter OpenSearch giver i de fleste Shopware 6-shops mere end nogen frontend-optimering.

Mål med feltdata, ikke kun med Lighthouse. Google vurderer Core Web Vitals ved 75. percentil af rigtige brugere: LCP højst 2,5 sekunder, INP højst 200 millisekunder, CLS højst 0,1.

Regn med 11.000 til 30.000 kr. til audit og basistiltag. Redis, OpenSearch, billed-CDN og oprydning i temaet koster afhængigt af shoppen 37.000 til 112.000 kr. ekstra, et cluster med Varnish mere. Det er erfaringstal fra vores projekter, ikke listepriser.

Før vi grundlagde solution25, byggede vi selv en webshop op til mere end 500 ordrer om dagen og lærte, hvad hvert sekunds indlæsningstid koster i omsætning. Siden 2017 har vi drevet og optimeret Shopware-shops for forhandlere, fra startershoppen på én server til clusteret med Varnish og OpenSearch, og vi hjælper også forhandlere i Danmark.

En langsom shop mister besøgende og ordrer, og Google vurderer indlæsningstiden via Core Web Vitals. Indlægget henvender sig til shopejere, e-handelsansvarlige og udviklere i Danmark, hvis Shopware 6-shop indlæses langsomt eller skal kunne bære mere belastning før en kampagne.

Når du har læst indlægget, kan du optimere Shopware-performance målrettet: selv indkredse årsagen til langsomme sider, prioritere tiltagene efter effekt og indsats og afgøre, hvad hostingudbyder, bureau eller eget team skal gennemføre. Alle oplysninger gælder Shopware 6.7 og Shopware-dokumentationen, alle priser er status oktober 2026, ekskl. moms. Vores erfaringstal er omregnet til danske kroner, priser fra tredjeparter står i euro ifølge udbyderen.

Mål Shopware-performance: Core Web Vitals, PageSpeed Insights og TTFB

Før du ændrer en indstilling, har du brug for en udgangsmåling. Ellers ved ingen bagefter, om optimeringen har virket.

De tre Core Web Vitals og deres målværdier

Google vurderer sider ud fra tre nøgletal, som web.dev definerer. Afgørende er i hvert tilfælde 75. percentil af sidevisningerne, opdelt på mobil og desktop.

Nøgletal	God	Dårlig	Hvad det måler i shoppen	Typisk årsag i Shopware
LCP (Largest Contentful Paint)	op til 2,5 s	over 4,0 s	Hvornår det største synlige element er renderet, oftest hero- eller produktbilledet	Serversvar uden cache, for store billeder, billedslider uden prioritering
INP (Interaction to Next Paint)	op til 200 ms	over 500 ms	Hvor hurtigt siden reagerer på klik, for eksempel i offcanvas-kurven eller i filtre	For meget JavaScript fra plugins, consent-værktøjer og tracking i hovedtråden
CLS (Cumulative Layout Shift)	op til 0,1	over 0,25	Hvor meget indholdet hopper under indlæsning	Billeder uden reserveret plads, fonte der indlæses senere, indskudte bannere

Målværdierne stammer fra artiklerne om LCP, INP og CLS på web.dev. INP afløste i 2024 det tidligere nøgletal First Input Delay. Hvis du stadig analyserer FID-værdier, måler du et nøgletal, som Google ikke længere bruger.

Hold feltdata og laboratoriedata adskilt

PageSpeed Insights viser to forskellige ting. Øverst står feltdata fra Chrome User Experience Report, altså rigtige brugere fra de seneste 28 dage ved 75. percentil. Derunder følger en Lighthouse-laboratorietest, der simulerer en mellemklasse-smartphone på mobilnettet.

For placeringen tæller feltdataene. En Lighthouse-score på 95 på forsiden siger intet om kategorisiden, hvor de fleste besøgende lander.

TTFB: nøgletallet for serveren

Tiden til første byte (TTFB) adskiller server- fra frontendproblemer. PageSpeed Insights vurderer op til 800 millisekunder som godt. En Shopware-shop, hvis side kommer fra HTTP-cachen, svarer efter vores erfaring på under 100 millisekunder, en kategoriside uden cache og med mange filtre bruger ofte 500 til 1.500 millisekunder.

Mål den samme URL to gange i træk. Er det andet kald ikke tydeligt hurtigere, er HTTP-cachen ikke aktiv eller bliver hele tiden tømt. Det er i vores audits den hyppigste enkeltårsag til en langsom Shopware-shop.

Hvad en langsom shop koster

Google dokumenterer flere casestudier på web.dev. Vodafone øgede omsætningen med 8 %, efter at LCP blev forbedret med 31 %, og BBC mistede 10 % af sine brugere for hvert ekstra sekunds indlæsningstid. Tallene kan ikke overføres direkte til enhver shop, men retningen kan.

Optimér Shopware-performance: de seks hyppigste årsager og rækkefølgen af tiltag

Shopware 6 er ikke langsom fra starten. Shopware måler selv for 6.7 i benchmark-scenariet uden caching en svartid på 231 millisekunder, som 95 % af alle forespørgsler ligger under (p95). En shop bliver langsom på grund af drift og konfiguration, næsten altid af en af disse seks grunde.

• HTTP-cache slået fra eller uden effekt: SHOPWARE_HTTP_CACHE_ENABLED står på 0, eller et plugin, en import eller et natligt cronjob tømmer cachen så ofte, at næsten hver side renderes på ny.
• Admin-worker i stedet for queue-workers: Som standard behandler den indloggede administrators browser message queuen. Indeksering, mails og cache-invalidering konkurrerer så med kunderne om PHP-processer.
• Filsystem i stedet for Redis: Object-cache og sessioner ligger i var/cache og i PHP’s standardhandler. Det skalerer ikke og bliver langsomt ved mange cache-tags.
• For mange eller dårlige plugins: Hvert plugin kan koble sig på events, indlæse JavaScript og udløse databaseforespørgsler. 20 plugins fra tre års shopdrift er normalen.
• Billeder og tredjepartsscripts: Herobilleder på 3 MB, chat-widgets, consent-managere, tracking-pixels og anmeldelsesbadges indlæses før selve indholdet.
• Database og søgning ved store kataloger: Fra nogle tusinde produkter med mange egenskaber bliver listing, filtre og søgning via MySQL mærkbart langsomme.

Begreberne kort forklaret

• HTTP-cache: Et lager til færdigrenderede sider, hvorfra Shopware besvarer gentagne kald uden ny beregning.
• Reverse proxy (Varnish, Fastly): En server foran shoppen, der leverer cachede sider, før forespørgslen når Shopware.
• Redis: Et hurtigt datalager i arbejdshukommelsen til cache, sessioner og indkøbskurve.
• Message queue og worker: Køen til baggrundsopgaver som indeksering og mails og de processer, der behandler den.
• OpenSearch og Elasticsearch: Søgeservere, der besvarer søgning, filtre og listings i store kataloger hurtigere end MySQL.
• OPcache: Et mellemlager til kompileret PHP-kode, som PHP ellers indlæser på ny ved hvert kald.
• CDN og lazy loading: Et CDN leverer billeder og filer via distribuerede servere tæt på den besøgende, lazy loading indlæser først billeder, når de kommer ind i det synlige område.

Prioriteringsliste: hvad der virker først

Følgende rækkefølge har vist sig at fungere i vores projekter. Indsatsen er erfaringstal fra bureauprojekter, med timepriser som beskrevet i indlægget om Shopware-omkostninger.

Tiltag	Virker især på	Indsats	For hvem
1. Aktivér HTTP-cache og tjek invalideringen	TTFB, LCP	1 til 2 dage	Alle shops
2. Slå admin-worker fra, opsæt queue-workers og cronjob	TTFB, stabilitet	0,5 til 1 dag	Alle shops
3. Redis til cache, sessioner og Delayed Invalidation	TTFB, cache-hitrate	1 til 2 dage	Fra mellemstor trafik
4. PHP-version, OPcache og MySQL-indstillinger	TTFB på sider uden cache	0,5 til 1 dag	Alle shops
5. Billeder: thumbnails, lazy loading, WebP, CDN	LCP, datamængde	1 til 3 dage	Alle shops
6. Plugin-audit og færre tredjepartsscripts	INP, LCP	2 til 5 dage	Shops med mere end 10 plugins
7. OpenSearch eller Elasticsearch	Listing, filtre, søgning	3 til 5 dage plus hosting	Fra nogle tusinde produkter
8. Varnish eller Fastly som reverse proxy	Belastningstoppe, TTFB	2 til 5 dage plus hosting	Kampagner, høj trafik, cluster

Vores vurdering: Vi anbefaler at gennemføre tiltag 1 til 4, før du investerer i større servere eller Varnish. De koster tilsammen tre til seks dage og løser de årsager, vi oftest finder i audits; mere hardware gør en shop uden fungerende cache dyrere, men knap hurtigere.

Sådan gør du: performance-optimering i seks trin

1. Mål udgangsværdien: Du eller dit bureau tjekker forside, kategori, produktside og kurv på mobil i PageSpeed Insights og noterer feltdata og TTFB, plus det dobbelte kald fra afsnittet om TTFB.
2. Forbered staging: Test hver ændring først i et staging-miljø med produktionsdata, så en fejl ikke koster omsætning.
3. Gennemfør serverbasis: Hostingudbyder eller bureau gennemfører tiltag 1 til 4, derefter måler du TTFB igen.
4. Ryd op i frontend: Tag fat på billeder, plugins og tredjepartsscripts (tiltag 5 og 6), og sammenlign LCP og INP i laboratorietesten med udgangsværdien.
5. Udbyg efter behov: Store kataloger får OpenSearch, shops med kampagnebelastning en reverse proxy (tiltag 7 og 8), hver gang med belastningstest før go-live.
6. Evaluér efter 28 dage: Først da afspejler feltdataene ændringen fuldt ud; sammenlign dem med udgangsværdien fra trin 1.

HTTP-cache og reverse proxy: den største gevinst for indlæsningstiden

Den indbyggede HTTP-cache

Shopware 6 leveres med en full-page-cache, som aktiveres via SHOPWARE_HTTP_CACHE_ENABLED=1 i .env. Cache-dokumentationen kalder den et must i produktion. Om den kører, kan du se i administrationen under Indstillinger, System, Caches og indekser.

To tilstande udelukker som standard en side fra cachen: indloggede kunder og fyldte kurve (shopware.cache.invalidation.http_cache med værdierne logged-in og cart-filled). Hvis du ikke viser personaliseret indhold, kan du ifølge dokumentationen om performance-tweaks tømme listen i config/packages/prod/shopware.yaml og opnå markant højere hitrater.

Siden Shopware 6.7 indlæses header og footer via ESI (Edge Side Includes) som separate byggesten og caches adskilt fra resten af siden, ifølge release notes til 6.7.0.0. En ændring i menuen behøver dermed ikke længere at kassere alle cachede produktsider.

Delayed Invalidation: hvorfor importer ikke længere behøver at tømme cachen

Siden 6.7 er den forsinkede cache-invalidering aktiv som standard (shopware.cache.invalidation.delay_enabled: true). I stedet for straks at slette cache-poster ved hver produktændring samler Shopware de berørte tags og behandler dem hvert femte minut via den planlagte opgave shopware.invalidate_cache. Intervallet står i kolonnen run_interval i tabellen scheduled_task.

Som lager bruger Shopware som standard MySQL. Dokumentationen anbefaler Redis (shopware.cache.invalidation.delay_options.storage: redis), fordi MySQL-adapteren kan forårsage deadlocks ved mange samtidige skriveadgange, for eksempel ved ERP-importer med tusindvis af lagerændringer.

Varnish eller Fastly som reverse proxy

Den indbyggede cache kører i PHP, så hvert hit koster en PHP-proces. En reverse proxy foran shoppen besvarer cachede sider uden at røre Shopware. Ifølge dokumentationen understøtter Shopware Varnish fra version 6.0 med modulet xkey til målrettet sletning via cache-tags, som er obligatorisk siden 6.7, samt Fastly siden Shopware 6.4.11.0.

Konfigurationen ligger siden 6.6 under shopware.http_cache.reverse_proxy med enabled: true, use_varnish_xkey: true og listen over Varnish-hosts. Aktivér soft purges, så kunderne får den gamle side under opdateringen, og tilføj proxyen i SYMFONY_TRUSTED_PROXIES. Står svarheaderen Age konstant på 0, cacher proxyen ikke.

Hvad det giver, viser Shopware i sine benchmarks til 6.7: I scenariet flash sale med Varnish steg antallet af ordrer pr. sekund med 108 % i forhold til 6.6, og p99-latensen faldt fra 1.000 til 425 millisekunder. Hvordan Varnish ser ud i administreret drift, beskriver vi i indlægget om Shopware PaaS på Platform.sh.

Vigtigt for deployment-scripts: cache:clear tømmer siden 6.7 ikke længere HTTP-cachen. Til det findes cache:clear:http (siden 6.6.10) og cache:clear:all (siden 6.6.8).

Figur: Fra cachen ligger serversvaret langt under grænseværdien, kategorisider uden cache ligger ofte over; tjek derfor HTTP-cachen først. Grænseværdi: Google PageSpeed Insights; cache- og kategoriværdier: erfaringstal solution25, status oktober 2026

Redis til object-cache, sessioner, kurv og låse

Som standard skriver Shopware object-cachen til var/cache og sessioner til PHP’s standardhandler. Til en enkelt server er det ifølge cache-dokumentationen tilstrækkeligt. Ved flere servere, mange cache-tags eller høje ordretal er Redis det bedre valg.

Tre Redis-instanser i stedet for én

Redis-dokumentationen anbefaler at adskille dataene efter levetid, fordi en Redis-instans kun kender én eviction-strategi. En instans med allkeys-lru, som samtidig gemmer kurve, smider under belastning netop disse kurve væk.

Datatype	Eksempler	Persistens	Eviction policy
Flygtig	HTTP-cache, object-cache, Delayed Invalidation	ingen, tab ved genstart er ukritisk	volatile-lru
Varig, aldrende	Sessioner	RDB-snapshots og/eller AOF	allkeys-lru
Varig, kritisk	Kurve, nummerserier, lock store, increment storage	RDB-snapshots og/eller AOF	volatile-lru

De vigtigste indstillinger med kilde

• Object-cache: framework.cache.app og framework.cache.system sat til cache.adapter.redis_tag_aware (fra 6.5.8.3), forbindelsen via default_redis_provider. Kilde: cache-dokumentationen.
• Sessioner: session.save_handler = redis i php.ini eller framework.session.handler_id: “redis://host:port/0” i Shopware (session-dokumentation).
• Kurv: Standard er MySQL-tabellen cart. Ved stor ordremængde anbefaler dokumentationen om cart storage Redis, og eksisterende kurve flyttes med bin/console cart:migrate sql.
• Nummerserier og increment storage: Som standard i MySQL. Med flere queue-workers låser tabellen increment ofte, og increment-dokumentationen anbefaler Redis eller typen array.
• Lock store: I cluster-opsætninger bryder filbaserede låse systemet, derfor framework.lock: ‘redis://host:6379/0’ (lock store-dokumentation).

Redis-fælden: cache-tags uden udløbsdato

Symfonys tag-aware-adapter opretter tag-indekser uden TTL. Disse nøgler hober sig op over måneder, indtil Redis trods volatile-lru ikke længere kan fjerne noget og stopper med out-of-memory. Tjek andelen af persistente nøgler med redis-cli INFO keyspace, og ryd forældreløse tags op om natten, for eksempel med frosh:redis-tag:cleanup fra FroshTools.

Message queue, admin-worker og indexer

Shopware klarer indeksering, thumbnails, mails, sitemap og cache-invalidering asynkront via Symfony Message Queue. Som standard behandler admin-workeren denne kø: Så længe en administrator er logget ind, spørger browseren hvert 20. sekund og sætter behandlingen i gang. Message queue-dokumentationen advarer om, at det ved flere admin-brugere skaber høj CPU-belastning og påvirker PHP-FPM.

• Deaktivér admin-worker: shopware.admin_worker.enable_admin_worker: false i shopware.yaml.
• Start CLI-workers: bin/console messenger:consume async low_priority --time-limit=60 --memory-limit=128M, overvåget af systemd eller supervisor. En separat worker til transporten failed er obligatorisk, ellers bliver fejlede beskeder liggende.
• Planlagte opgaver via cron: */5 * * * * php bin/console scheduled-task:run --no-wait (fra 6.5.5.0) sætter forfaldne opgaver i køen. Opsætningen viser vores indlæg om cronjobs og planlagte opgaver i Shopware.
• Skift transport: Doctrine-transporten i MySQL er ifølge dokumentationen beregnet til udvikling. Fra cirka tre parallelle workers anbefaler Shopware en broker som RabbitMQ.

To indexere kan slås fra, hvis du ikke har brug for dem: product stream-indexeren (shopware.product_stream.indexing: false, fra 6.6.10.0) og den planlagte sitemap-generering (shopware.sitemap.scheduled_task.enabled: false, fra 6.7.1.0, i stedet om natten via cron sitemap:generate). Uden product stream-indexer opdateres dynamiske produktgrupper først, når HTTP-cachen udløber.

Elasticsearch eller OpenSearch til store kataloger

Listing, filtre og søgning kører i Shopware 6 som standard via MySQL. Shopware-dokumentationen anbefaler en søgemaskine fra flere tusinde poster. I vores projekter bliver forskellen tydelig fra cirka 5.000 produkter med mange egenskaber og varianter, og ved 50.000 produkter er OpenSearch uden alternativ.

Tilslutningen sker via få variabler: OPENSEARCH_URL til hosts, SHOPWARE_ES_ENABLED=1 til søgningen, SHOPWARE_ES_INDEXING_ENABLED=1 til indekseringen og SHOPWARE_ES_INDEX_PREFIX til indeksnavnet. Indekseringen med bin/console es:index kører via message queuen og kræver altså workerne fra forrige afsnit.

Sæt SHOPWARE_ES_THROW_EXCEPTION=1. Uden denne indstilling falder Shopware ved en fejl i søgemaskinen stiltiende tilbage til MySQL, og du opdager først udfaldet på indlæsningstiden. Med 6.7.2.0 har Shopware desuden omarbejdet sortering og forespørgsler til OpenSearch og nævner i release notes op til 85 % kortere forespørgselstider.

Shopware betragter en enkelt node som testmiljø og nævner tre master-egnede noder som minimum for høj tilgængelighed. I mellemstore shops driver vi alligevel ofte en enkelt OpenSearch-instans med 2 til 4 GB RAM, så med overvågning. Installation og typiske fejl beskriver vi i indlægget om Elasticsearch og OpenSearch til Shopware 6.

Billeder, thumbnails, WebP og CDN

Billeder er på næsten alle shopsider LCP-elementet. Shopware genererer ifølge mediedokumentationen som standard tre thumbnail-størrelser ved upload (400, 800 og 1920 pixels), som kan konfigureres pr. mediemappe inklusive kvalitetsniveau. Efter en ændring genererer bin/console media:generate-thumbnails filerne på ny.

Brug storefront-skabelonen rigtigt

Storefrontens thumbnail-skabelon opbygger automatisk srcset og sizes, så browseren indlæser den passende størrelse pr. viewport, siden 6.7.12 også for XXL-breakpointet. Som standard indlæser den billeder med loading=”eager”, produktfliserne i listingen sætter loading=”lazy”. I egne CMS-elementer skal du selv sætte lazy loading, og kun under det synlige område.

For herobilledet gælder det modsatte: Siden 6.7.2.0 findes der i CMS-konfigurationen af billedslider og billedgalleri en indstilling for fetchpriority, så browseren indlæser det første billede med prioritet. Shopware begrunder det i release notes udtrykkeligt med LCP.

Skabelonen udskriver ikke width- og height-attributter. Reservér pladsen til billeder i temaet via CSS (aspect-ratio), ellers hopper layoutet under indlæsning, og CLS lider.

WebP og AVIF

Shopware accepterer WebP ved upload, men konverterer ikke selv JPG og PNG til moderne formater. Tre veje fører til målet: uploade produktbilleder som WebP fra starten, bruge en udvidelse fra Shopware Store til konvertering eller outsource billedbehandlingen.

Den tredje vej er siden 6.6.4.0 indbygget i kernen: Med shopware.media.remote_thumbnails.enable: true genererer Shopware ikke længere thumbnail-filer, men opbygger URL’er efter et mønster som {mediaUrl}/{mediaPath}?width={width}, som et billed-CDN eller en tjeneste som imgproxy løser. Tjenesten leverer WebP eller AVIF afhængigt af browseren. Kilde: dokumentation om remote thumbnails.

CDN til statiske filer

Et CDN tilsluttes via URL’en til det offentlige filsystem (shopware.filesystem.public.url), og derefter køres bin/console asset:install og theme:compile. Til assets fra CDN’et anbefaler Shopware en Cache-Control-header som public, max-age=86400. Kilde: filesystem-dokumentation.

Tema, JavaScript og plugins: få styr på INP og CLS

Med 6.7 har Shopware ifølge egne oplysninger gjort storefront-JavaScriptet 25 % og CSS’en 24 % mindre. Det, der stadig bremser derefter, kommer næsten altid fra plugins, tematilpasninger og tredjepartsscripts.

JavaScript og tredjepartsscripts

• Kortlæg tredjepartsscripts: Consent-manager, tag manager, chat, anmeldelsesbadges, retargeting-pixels og A/B-testværktøjer. I vores audits finder vi jævnligt 15 til 30 eksterne scripts, hvoraf halvdelen ikke længere bliver analyseret af nogen.
• Indlæs efter samtykke: Alt, der kræver samtykke, må først indlæses efter klikket. Det er databeskyttelse og performance på én gang, og i Danmark kræver cookiebekendtgørelsen netop samtykke, før ikke-nødvendige cookies sættes.
• Tjek plugin-JavaScript: Hvert storefront-plugin leverer sit eget JavaScript, som indlæses på hver side. Afinstallér det, der ikke bruges, i stedet for blot at deaktivere det.
• Byg ikke på produktionsserveren: Tema og administration bør bygges i CI og deployes som artefakt. Shopware-dokumentationen beskriver build uden database med theme:dump og statiske loaders.
• Speculation rules: Siden 6.6.10.0 kan storefronten (Indstillinger, System, Storefront) forhåndsrendere efterfølgende sider, så snart en bruger rører et link. Det virker som øjeblikkelig indlæsning, men skaber serverbelastning og kan forvrænge analytics-tal.

Færre data pr. listing

Siden 6.7.12 indlæser Shopware efter ønske kun reducerede produktdata i listingen, med et HTML-frit uddrag af beskrivelsen på højst 512 tegn. Indstillingen core.listing.partialDataLoading (Indstillinger, Produkter) er aktiv ved nyinstallationer, men ikke i eksisterende shops. Aktivér den kun, hvis tema og udvidelser ikke behøver flere produktfelter i listingen. Kilde: Release Notes 6.7.12.0.

Siden 6.7.2.0 indlæser sidenavigationen aktive kategoriniveauer dynamisk. Navigationsdybden i salgskanalen styrer dermed især header-navigationen og kan sænkes for at få mere fart.

Plugin-audit i fire trin

• Optælling: Liste over alle plugins med formål, producent, seneste opdatering og lejepris. Det, ingen kan placere, er en kandidat til fjernelse.
• Mål: Profiling med Blackfire eller Tideways på forside, kategori og checkout viser, hvilke subscribers og forespørgsler et plugin tilføjer.
• Staging-test uden plugin: Deaktivér mistænkelige plugins enkeltvis i staging-miljøet, og mål TTFB og INP igen.
• Erstat eller udvikl: Tre plugins til opgaver, som en ren egenudvikling løser på 50 linjer, er dyrere end udviklingen. Hvad det koster, står under Shopware-pluginudvikling.

Hosting, PHP, OPcache og MySQL

PHP-version og OPcache

Shopware 6.7 understøtter ifølge update-guiden PHP 8.2, 8.3 og 8.4, siden 6.7.6.0 (januar 2026) ifølge Shopware også PHP 8.5. Brug den nyeste version, som dine plugins kan klare.

Dokumentationen om performance-tweaks nævner konkrete PHP-indstillinger til produktion: zend.assertions=-1, opcache.enable_file_override=1, opcache.interned_strings_buffer=20, opcache.validate_timestamps=0, zend.detect_unicode=0, realpath_cache_ttl=3600 og opcache.max_accelerated_files på mindst 20000. Med validate_timestamps=0 skal du genindlæse PHP-FPM efter hvert deployment, ellers kører gammel kode videre. OPcache-preloading giver ifølge dokumentationen yderligere 2 til 5 %, men slår Extension Manager fra.

Dertil kommer små ting med effekt: dump .env til en PHP-fil med bin/console dotenv:dump prod, deaktivér ubrugte Symfony secrets, og sæt Monolog i produktion til level: error, også for handleren business_event_handler_buffer. Med PHP-udvidelsen zstd komprimerer cache og kurv siden 6.6.4.0 hurtigere end med gzip (shopware.cache.cache_compression_method: zstd).

MySQL og MariaDB

Shopware 6.7 kræver MySQL fra 8.0.17 (ikke 8.0.20 og 8.0.21) eller MariaDB fra 10.11 (ikke 10.11.5 og 11.0.3). To serverværdier nævner dokumentationen om performance-tweaks udtrykkeligt: group_concat_max_len på mindst 320000 og en sql_mode uden ONLY_FULL_GROUP_BY. Ellers sætter Shopware selv begge værdier ved hver forbindelse.

Dimensionér innodb_buffer_pool_size, så shoppens arbejdsdata kan være der, efter vores erfaring 2 til 4 GB til kataloger op til 20.000 produkter. Til meget store shops understøtter Shopware læsereplikaer via DATABASE_REPLICA_0_URL, som flytter listing-forespørgsler væk fra den skrivende databaseserver.

Dimensionér hosting

Følgende størrelser er erfaringstal fra vores projekter for specialiseret Shopware-hosting i Tyskland, ikke et krav fra Shopware. Serverne står i EU og drives GDPR-kompatibelt, hvilket også passer til webshops i Danmark. Priserne er hostingudbydernes priser i euro, ekskl. moms. Størrelserne svarer til niveauerne i vores guide Shopware-hosting, hvor du også finder udbydere og priser.

• Op til 1.000 produkter, op til 50 ordrer om dagen: 2 til 4 vCPU, 8 GB RAM, PHP-FPM, Redis og MySQL på samme server, 50 til 100 € om måneden.
• 1.000 til 20.000 produkter, op til 300 ordrer om dagen: 4 til 8 vCPU, 16 til 32 GB RAM, Redis og OpenSearch som separate tjenester, ved kampagnebelastning Varnish foran, 150 til 500 € om måneden.
• Derover eller B2B med ERP-takt: Flere applikationsservere bag en load balancer, separat database, Redis med persistens, OpenSearch-cluster, fra 1.000 € om måneden. Her kan det betale sig at sammenligne med Shopware PaaS.

Hvilke tiltag passer til din shop? Optimér Shopware 6-performance efter shopstørrelse

Ikke alle shops har brug for Varnish og OpenSearch. Tre profiler dækker de fleste forhandlere, der kommer til os med en langsom shop, også fra Danmark.

• Lille shop, op til 5.000 produkter, én server: Tjek HTTP-cachen, slå admin-worker fra, opsæt worker og cron, PHP og OPcache efter dokumentationen, billeder i WebP og lazy loading, ryd op i plugins. Indsats efter erfaring 11.000 til 30.000 kr., og ofte rækker det til gode Core Web Vitals.
• Mellemstor virksomhed, 5.000 til 50.000 produkter, ERP-integration: Derudover Redis til cache, sessioner og Delayed Invalidation, OpenSearch, billed-CDN med remote thumbnails, overvågning. Engangsbeløb 37.000 til 112.000 kr., løbende 100 til 400 € mere om måneden til tjenester ifølge udbyderne.
• Stort katalog, kampagner, B2B: Derudover Varnish eller Fastly, Redis i tre instanser med persistens, kurv og nummerserier i Redis, RabbitMQ, belastningstest med k6 før hver kampagne. Engangsbeløb 112.000 til 299.000 kr., løbende fra 500 € om måneden til tjenester ifølge udbyderne.

Alle beløb er erfaringstal fra bureauprojekter, ekskl. moms. En shop med 40 plugins og et individuelt tema koster mere at rydde op i end en shop med standardtema.

Fra vores projekter: brandshop og stort katalog

I Shopware-shoppen for kosmetikbrandet Banana Beauty bremsede lange indlæsningstider og en begrænset mobiloptimering konverteringer og engagement. Efter caching, billedkomprimering, lazy loading og et CDN faldt indlæsningstiderne ifølge casestudiet med 40 % på alle enheder.

Hos Miniature Market, en forhandler af brætspil og miniaturer med tusindvis af varer, ramte den tidligere Magento-shop performanceflaskehalse ved efterspørgselstoppe omkring nyheder. I Shopware 6 har vi optimeret søgning og filtre med Elasticsearch, forbedret kategoricachingen, leveret assets via et CDN og simuleret store lanceringer med belastnings- og stresstest. Ifølge casestudiet leverer shoppen siden hurtigere søgeresultater, mere flydende filtre og bedre indlæsningstider, og antallet af forladte kurve er faldet.

Forudsætninger, begrænsninger og typiske fejl

• Forudsætning serveradgang: De fleste tiltag kræver adgang til .env, konfigurationsfiler og cronjobs. I SaaS-varianten driver Shopware infrastrukturen, og dér er det primært billeder, apps og tema, du selv kan påvirke.
• Cachens begrænsninger: Indloggede kunder og fyldte kurve omgår som standard HTTP-cachen. Shops med mange indloggede kunder, for eksempel i B2B, har derfor også brug for hurtige sider uden cache.
• Typiske fejl: Natligt cache:clear, admin-worker i produktion, én Redis-instans til alle data og målinger kun med Lighthouse på forsiden finder vi oftest i audits.

Mål effekten: nøgletal, værktøjer og rytme

En optimering holder cirka til næste plugin, derfor hører en løbende opfølgning med.

• Feltdata, månedligt: Core Web Vitals-rapporten i Search Console og PageSpeed Insights for de vigtigste sidetyper, med målværdierne fra tabellen ovenfor ved 75. percentil på mobil.
• Server, løbende: TTFB og fejlrate via oppetidsovervågning, pejlemærke TTFB under 800 ms og fra cachen under 100 ms. Headeren Age viser cache-hits, en voksende tabel messenger_messages manglende workers.
• Applikation, efter hvert deployment: Application Performance Monitoring (APM) som Blackfire, Tideways eller New Relic med alarm ved stigende svartid.
• Belastningstest, før kampagner: Før Black Friday, julehandlen eller tv-kampagner en k6-test med den forventede spidsbelastning på kategori, produkt og checkout.
• Juster kursen: Forlader et nøgletal i månedssammenligningen området “god”, eller stiger TTFB efter et deployment, så tjek først den seneste ændring: nyt plugin, temaopdatering eller cacheindstilling.

Ofte stillede spørgsmål om optimering af Shopware-performance

Hvorfor er min Shopware 6-shop langsom?

I de fleste audits er HTTP-cachen slået fra eller bliver hele tiden tømt, admin-workeren behandler køen i browseren, og for mange plugins og tredjepartsscripts indlæses på hver side. Et dobbelt kald af den samme kategoriside viser på få sekunder, om cachen mangler.

Hvilken indlæsningstid bør en Shopware-shop have?

LCP op til 2,5 sekunder, INP op til 200 millisekunder og CLS op til 0,1, hver gang ved 75. percentil af de mobile brugere. Serversvaret (TTFB) regnes som godt op til 800 millisekunder, og fra cachen bør en Shopware-shop svare på under 100 millisekunder.

Har jeg brug for Varnish til Shopware 6?

Ikke nødvendigvis, den indbyggede HTTP-cache rækker for mange shops langt op i en sekscifret årsomsætning i euro. Varnish eller Fastly kan betale sig ved belastningstoppe fra kampagner eller ved flere applikationsservere; siden Shopware 6.7 er modulet xkey obligatorisk til det.

Er Shopware 6.7 hurtigere end 6.6?

Ifølge Shopwares benchmarks ja: Med Varnish steg antallet af ordrer pr. sekund med 108 %, og storefront-JavaScriptet blev 25 % mindre. Version 6.6 får ifølge endoflife.date sikkerhedsopdateringer frem til 28. februar 2028, men ingen af disse forbedringer.

Kan performance-optimering stadig betale sig for Shopware 5?

Nej. Shopware 5 har været udfaset siden 31. juli 2024 og får ikke længere regulære sikkerhedsopdateringer; budgettet er bedre givet ud på migreringen til Shopware 6.

Hjælper et performance-plugin fra Shopware Store?

Sjældent på årsagerne. Udvidelser til billedkonvertering, cache-warmup eller lazy loading forbedrer enkelte punkter, men erstatter hverken en serverindstilling eller en queue-worker.

Hvor ofte bør man tømme Shopware-cachen?

Så sjældent som muligt. Med Delayed Invalidation opdaterer Shopware selv ændrede sider hvert femte minut, mens et natligt cache:clear smider full-page-cachen væk og gør shoppen langsom for alle om morgenen. En fuldstændig tømning hører til deployments, ikke i cron.

Hvor din shop står i dag

Vil du vide, hvilke af de nævnte tiltag der mangler i din shop, og hvad de ville give? Vores gratis shopanalyse måler indlæsningstid og Core Web Vitals med laboratorie- og feltdata, crawler din shop og leverer inden for to hverdage en prioriteret fejlliste. Den kræver ikke adgang til din server.

Til en performance-audit med profiling, belastningstest og implementeringsplan kan du skrive til os. Vi hjælper forhandlere i Danmark og fortæller dig på forhånd, om indsatsen kan betale sig for din shop.

Læs mere om vores arbejdsmetode, certificeringer og lokationer på siden Shopware-bureauet solution25.

Læs videre

• Shopware-hosting: Hvilken hosting Shopware 6.7 kræver, og hvad self-hosting, PaaS og SaaS koster.
• Shopware SEO: Hvilke indstillinger ud over indlæsningstiden der afgør synligheden på Google.
• Konverteringsoptimering: Hvilke greb ud over indlæsningstiden der giver flest ordrer.
• Shopware 6-plugins: Hvordan du vælger udvidelser og fjerner overflødige med en plugin-audit.
• Shopware-opdatering og versioner: Hvordan du sikkert opdaterer til en aktuel 6.7-version.

Kilder

• Shopware Developer: Performance Tweaks, hentet i oktober 2026
• Shopware Developer: Caches, hentet i oktober 2026
• Shopware Developer: Reverse HTTP Cache, hentet i oktober 2026
• Shopware Developer: Redis, hentet i oktober 2026
• Shopware Developer: Message Queue, hentet i oktober 2026
• Shopware Developer: Opsætning af Elasticsearch og OpenSearch, hentet i oktober 2026
• Shopware: Performance i Shopware 6.7 (benchmarks), hentet i oktober 2026
• web.dev: Web Vitals, hentet i oktober 2026
• Google for Developers: Om PageSpeed Insights, hentet i oktober 2026
• web.dev: Why does speed matter?, hentet i oktober 2026
• endoflife.date: Shopware, hentet i oktober 2026

Om forfatteren

Besar Bilalli er medstifter og co-CEO af solution25, Shopware-bureauet fra Bremen. Før bureauet blev grundlagt i 2017, byggede han sammen med Besnik Bilalli en egen webshop op uden startkapital og nåede mere end 500 ordrer om dagen. Siden da har han hjulpet forhandlere med Shopware-projekter, fra valg af system til den løbende drift. Spørgsmål til artiklen besvarer han gerne personligt: Kontakt os.

Ansvarlig for indhold og opdatering: Besar Bilalli. Status: oktober 2026. Næste faglige gennemgang: januar 2027.