Shopware hosting en performance die piekdagen aankan
Black Friday valt dit jaar op vrijdag 27 november 2026. Vanaf half november gaat je verkeer omhoog en je advertentiebudget mee. Of je die dag wint, bepaal je in de weken ervoor.
Shopware hosting is iets anders dan een website hosten. Je draait een applicatie met een database, een zoekindex, meerdere cachelagen en achtergrondtaken die allemaal tegelijk onder druk komen te staan.
.png)
Waarom een webshop andere hostingeisen stelt dan een brochuresite
Een brochuresite serveert vrijwel altijd hetzelfde antwoord aan iedereen. Een webshop doet dat juist niet. Het winkelmandje, de klantprijs, de voorraadstatus en de verzendopties verschillen per bezoeker en per moment, dus een deel van elk verzoek moet echt uitgerekend worden.
Dat rekenwerk is precies wat je capaciteit opeet zodra het druk wordt. Op een gemiddelde dag merk je er niets van. Op de dag waarop het geld verdiend wordt, bepaalt het of je checkout het houdt.
Bij Memo werken we daarom bewust met on-premise Shopware op een omgeving die je kunt inzien en bijstellen. Je ziet wat er gebeurt en je kunt ingrijpen, in plaats van te wachten tot een dichtgetimmerde stack vanzelf weer meewerkt.
Wat we tegenkomen als die omgeving is bemeten op een gemiddelde dag:
- Te weinig PHP-workers: verzoeken belanden in de wachtrij.
- Geen zoekindex: filteren belast de database extra.
- Zware productbeelden: de makkelijkste winst blijft liggen.
- Achtergrondtaken zonder ruimte: exports concurreren met je bezoekers.
Wat je Shopware-webshop van zijn hosting vraagt
Zeven onderdelen bepalen samen hoeveel gelijktijdige bezoekers je aankunt. Is er één krap bemeten, dan valt de rest daarna om. Dit is waar we naar kijken voordat we ook maar iets opschalen.
PHP-workers
Elk verzoek dat niet uit cache komt bezet een worker. Dat aantal is je harde bovengrens.
Database
Prijzen, regels, orders en klantdata komen hiervandaan. Trage queries merk je pas als het echt druk is.
Zoekindex
Zonder Elasticsearch of OpenSearch draaien zoeken en filteren op de database, precies wanneer die het al zwaar heeft.
Cachelagen
HTTP-cache, Redis voor sessies en applicatiecache, en eventueel een reverse proxy die anoniem verkeer opvangt.
Media en CDN
Productbeelden zijn vaak het zwaarste deel van je pagina en tegelijk de makkelijkste winst die je kunt pakken.
Monitoring en alerting
Je wilt wachtrijen en responstijden per pagina-type zien, niet alleen of de site nog bereikbaar is.
Back-ups en staging
Een omgeving waarop je een release veilig test, plus een back-up waarvan je de terugzetprocedure kent.
Wat er tijdens een piek breekt, en in welke volgorde
Een piek verloopt vrijwel altijd volgens hetzelfde patroon. Eerst raken de PHP-workers vol, want er zijn meer gelijktijdige bezoekers dan processen. Verzoeken gaan in de wachtrij en de responstijd loopt op.
Daarna wordt de database het knelpunt: meer wachtende verzoeken betekent meer openstaande verbindingen en tragere queries. Vervolgens haakt de zoekfunctie af, omdat filteren en zoeken de duurste handelingen zijn die je draait.
Pas daarna zie je wat iedereen ziet: de checkout die hangt en de klant die afhaakt. Het probleem begon dus drie stappen eerder. Daarom komt monitoring die alleen meet of de site bereikbaar is structureel te laat.
Caching is de goedkoopste performancewinst die er is. Een pagina die volledig uit HTTP-cache komt, raakt PHP en de database helemaal niet. Redis houdt sessies en applicatiedata snel beschikbaar en een reverse proxy vangt het gros van je anonieme verkeer op.
Precies daar zit het risico bij B2B. Je werkt met klantspecifieke prijzen, staffels, klantgroepen en afgeschermde assortimenten. Een cache die niet weet dat een pagina per klantgroep verschilt, serveert de verkeerde prijs aan de verkeerde klant. Dat is geen prestatieprobleem meer maar een vertrouwensprobleem, en in offertetrajecten een dure.
De oplossing is niet minder cachen, maar preciezer cachen. Bepaal welke onderdelen van een pagina voor iedereen gelijk zijn en welke per klantgroep of per ingelogde klant verschillen, en handel die tweede groep apart af. Hoe je prijzen en klantgroepen modelleert lees je op de Shopware B2B-pagina, want dat bepaalt direct hoeveel je kunt cachen.
.png)
Core Web Vitals: wat er gemeten wordt en wat je klant ervan merkt
Google beoordeelt de laadervaring op drie punten: Largest Contentful Paint (hoe snel het grootste zichtbare element staat), Interaction to Next Paint (hoe snel de pagina reageert op een klik of tik) en Cumulative Layout Shift (hoeveel de pagina nog verspringt tijdens het laden). De drempelwaarden voor een goede score publiceert Google op web.dev.
Twee dingen zijn daarbij belangrijk. Google meet velddata van echte bezoekers, niet je testscore op een snelle laptop. En de meest zichtbare winst komt zelden uit serverconfiguratie: te grote productbeelden, te veel scripts van derden en een layout die verspringt omdat afmetingen ontbreken, wegen zwaarder.
Wat je zelf kunt doen is daarmee concreter dan het klinkt. Comprimeer je productbeelden en geef ze vaste afmetingen mee, beperk scripts van derden en laad wat niet direct zichtbaar is later. Dat lost vaak het grootste deel van LCP en CLS op. Serverwerk en frontendwerk horen daarna in hetzelfde traject thuis, want ze bepalen samen dezelfde score.
Zo bereid je 27 november voor
Een piekdag win of verlies je in de weken ervoor. We beginnen met het meten van de nulsituatie: responstijden per pagina-type, velddata van Core Web Vitals en het aantal gelijktijdige bezoekers op een normale dag.
Daarna loadtesten we op een realistisch scenario. Niet alleen de homepage, maar het echte pad: categorie, filter, product, mandje, checkout. Verkoop je B2B, dan test je met ingelogde klanten, want juist dat verkeer komt nauwelijks uit cache. Workers, database en zoekindex stel je vervolgens bij op het punt waar de test daadwerkelijk vastliep, niet op gevoel.
Daaromheen leg je de afspraken vast: alerting op wachtrijen en responstijden met een drempel waarbij iemand gebeld wordt, een rollbackplan waarin staat welke release je terugdraait en wie dat besluit, een deploystop in de dagen rond de piek, en een verkeersluwe fallback met zware functionaliteit die tijdelijk uit mag.
Wanneer je hieraan begint, bepalen we in overleg. Dat hangt af van je releasekalender, van hoe zwaar je piek is en van wat er nog gebouwd wordt. De enige harde regel: het loadtesten moet klaar zijn voordat de deploystop ingaat, anders heb je een testresultaat waar je niets meer mee kunt doen.
Hosting, monitoring en performancewerk zijn terugkerende posten naast de bouwkosten. Hoe die zich tot elkaar verhouden lees je op de kostenpagina.
Dat het ook zonder platformwissel kan, laat Kempers zien. Samen met Hypernode, het hostingplatform voor e-commerceapplicaties waarvan we partner zijn, werd de laadtijd van die webshop drie keer sneller, zonder volledige migratie. Hoe we dat hebben aangepakt staat in de case study die Memo en Hypernode samen publiceerden. Eerst meten waar de tijd blijft, dan gericht ingrijpen.
Veelgestelde vragen
Wat is goede Shopware hosting?
Hosting waarbij PHP-workers, database, zoekindex en cachelagen op elkaar en op jouw verkeer zijn afgestemd, met inzicht in wat er gebeurt. Je moet kunnen zien hoeveel gelijktijdige verzoeken je aankunt en waar de tijd blijft. Een gedeelde omgeving zonder die zichtbaarheid is bij e-commerce vrijwel altijd te krap op het moment dat het telt.
Hoeveel verkeer kan mijn Shopware-webshop aan?
Dat hangt af van het aantal PHP-workers, de responstijd per verzoek en het aandeel verkeer dat uit cache komt. Zonder loadtest is elk getal een gok. Met een test op een realistisch klantpad weet je waar de eerste bottleneck zit en wat opschalen je daadwerkelijk oplevert.
Kan caching mijn B2B-prijzen verkeerd tonen?
Ja, als de cache geen onderscheid maakt tussen klantgroepen. Klantspecifieke prijzen, staffels en afgeschermde assortimenten moeten buiten de gedeelde cache blijven of per klantgroep gescheiden worden. Dat is een inrichtingskeuze die je vooraf maakt, niet iets wat je achteraf repareert.
Moet ik migreren om mijn webshop sneller te maken?
Meestal niet. Bij Kempers is samen met Hypernode performancewinst geboekt zonder volledige migratie. Begin met meten: zit de bottleneck in beelden, scripts of cacheconfiguratie, dan is een platformwissel een dure omweg.
Wat kan ik zelf doen aan Core Web Vitals?
Comprimeer je productbeelden en geef ze vaste afmetingen mee, beperk scripts van derden en laad wat niet direct zichtbaar is later. Dat lost vaak het grootste deel van LCP en CLS op. De rest, zoals serverresponstijd en cachegedrag, hoort bij het hosting- en ontwikkeltraject.