Black Friday is dit jaar op vrijdag 27 november, Cyber Monday op 30 november. Dat is over drie weken. De dag zelf is zelden het probleem: gaat je shop op 27 november onderuit, dan zit de oorzaak meestal in iets wat er al weken lag. Een indexer die op “Update on Save” draait, een cronjob die al maanden stilletjes faalt, een cache die niet warm is op het moment dat het druk wordt.
Dit is wat je nu nog kunt regelen, en waarom de patch van 10 november in die planning hoort.
Eerst meten: de load test
Voordat je iets gaat optimaliseren, wil je weten waar het misgaat. Een load test op alleen de homepage zegt weinig: die pagina is meestal het best gecached en het minst belastend voor je database. Test een realistisch bezoekersprofiel: categoriepagina, productpagina, zoeken, winkelwagen toevoegen en de checkout doorlopen. Dat laatste raakt onderdelen die niet uit de cache komen en dus je database en PHP-processen belasten.
Magento heeft hiervoor de Performance Testing Toolkit. Met bin/magento setup:performance:generate-fixtures setup/performance-toolkit/profiles/ce/small.xml genereer je testdata op basis van een profiel (small, medium, large of extra large, in setup/performance-toolkit/profiles/ce/), zodat je test tegen een database die qua omvang in de buurt komt van je echte shop. De belasting zelf genereer je met het JMeter-scenario dat in dezelfde toolkit zit (setup/performance-toolkit/benchmark.jmx), of met een eigen tool die dezelfde bezoekerspaden afloopt. Test dit op staging of op een kopie van productie, nooit zonder vooroverleg met je hoster rechtstreeks op productie: een load test is in essentie een zelf georganiseerde piekbelasting.
Wat een load test precies kan laten zien, hangt sterk af van je hostingsetup. Draait Varnish voor je full page cache, gebruik je Redis of Valkey voor sessies en cache, en draait OpenSearch zoals Magento vereist, dan test je of die laag doet wat hij moet doen. Mist er iets in die stack, dan meet je vooral hoe snel de rest het zonder die laag begeeft. Zie wat Magento aan hosting vereist als je niet zeker weet of dat bij jou op orde is.
Cache warm en heel houden
Full page cache via Varnish moet aanstaan, en dat is meestal al zo. Waar het vaker misgaat: de cache is leeg op het moment dat de drukte begint. Warm je cache vóór de piek op door de belangrijkste categorie- en productpagina’s zelf een keer te laden, of automatisch met een crawler. Zonder dat krijgen de eerste bezoekers van de dag allemaal een ongecachte pagina, precies op het moment dat je database het minst kan missen.
Een cache flush tijdens de drukste uren is daarom duur: iedereen die daarna binnenkomt, triggert weer een ongecachte opbouw. Plan content- en prijswijzigingen die een flush nodig maken dus niet op de piekdagen zelf.
Tracking-parameters als utm_*, gclid en fbclid horen niet te leiden tot losse cache-entries per combinatie van parameters. Magento’s eigen Varnish-configuratie filtert de bekende marketingparameters er al uit, maar heb je een eigen VCL of is die aangepast, dan is dit het moment om dat te checken. Elke unieke parametercombinatie die wél een eigen cache-entry oplevert, vermindert je effectieve cache hit rate, net op de dagen dat je die het hardst nodig hebt.
Cron, queues en indexers
Cron is de stille motor achter een Magento-shop, en die staat vaker stil dan je zou willen. Check de tabel cron_schedule op taken met een achterstand of een foutstatus, of vraag je developer dat te doen. Een cron die al weken geen taken meer wegschrijft, valt in rustige tijden niet op; in een piek wel.
Staan je indexers op “Update on Save”, dan wordt bij elke productwijziging direct geïndexeerd, inclusief tijdens de drukste momenten. “Update by Schedule” verwerkt die wijzigingen op de achtergrond via cron, in batches, zonder de actie die de wijziging veroorzaakte te blokkeren. Adobe raadt schedule aan voor shops met veel verkeer. Check de huidige stand met bin/magento indexer:show-mode en zet om met bin/magento indexer:set-mode schedule.
Daarnaast draaien er bij veel shops message queue consumers, via RabbitMQ of de databasequeue, die onder cron of supervisor horen te lopen. Die verwerken vaak asynchrone acties en voorraadmutaties. Welke consumers jouw shop precies gebruikt en of ze draaien, is iets om samen met je developer te checken: een consumer die stilstaat, merk je vaak pas op als voorraad niet meer klopt.
Koppelingen van derden
Je PSP, je voorraad- of ERP-koppeling, je verzendlabels: allemaal systemen buiten je eigen controle, en allemaal met een eigen rate limit. Wat gebeurt er in jouw shop als een van die koppelingen traag reageert, of een paar minuten helemaal uit de lucht is? Valt de checkout dan om, of blijft de rest van de shop werken terwijl alleen dat onderdeel wacht?
Dat zoek je liever nu uit dan op 27 november. Vraag je developer welke timeouts er in de modules van je PSP, ERP-koppeling en vervoerder staan: een aanroep die een halve minuut op antwoord wacht, houdt al die tijd een PHP-proces bezet. Test op staging wat er gebeurt als zo’n externe dienst niet antwoordt, bijvoorbeeld door de koppeling tijdelijk naar een adres te laten wijzen dat niet reageert. En kijk of voorraadmutaties via een queue lopen, zodat een trage ERP-koppeling een bestelling niet tegenhoudt.
Vraag je PSP en je hoster naar hun eigen afspraken voor Black Friday: capaciteit, eventuele rate limits die ook jou raken, en wie je belt als het misgaat. Loop ook je tracking-, chat- en reviewscripts na. Niet elk script dat ooit is toegevoegd, is nog nodig, en elk script dat blijft laden, kost laadtijd op een dag waarop dat extra zwaar weegt.
Code freeze: een afspraak, geen verbod
Een code freeze is geen technische maatregel maar een afspraak binnen het team: vanaf een bepaalde datum gaat er niets meer live zonder dat iemand expliciet akkoord geeft. Kies een datum, bijvoorbeeld een of twee weken voor 27 november. Dat is een keuze die bij jouw risicobereidheid past, geen vaste norm. Spreek ook af wie een uitzondering mag goedkeuren, en leg dat ergens vast zodat niet iedereen zijn eigen interpretatie hanteert.
Wat tijdens de freeze wel doorgaat:
- Monitoring en alerting blijven aan en worden actief bekeken
- Kritieke security patches, zie de volgende sectie
- Een hotfix voor iets dat daadwerkelijk stuk is
- Content- en prijswijzigingen via de admin, al plan je grote wijzigingen niet op de piekdagen zelf (zie de sectie over cache)
Wat niet:
- Nieuwe features
- Extensie-updates die niet urgent zijn
- Grote refactors
- Een PHP- of Magento-upgrade, zie PHP 8.2 end of life voor waarom dat ook los van Black Friday geen moment is om te overhaasten
- Elke deploy op vrijdagmiddag, of op de piekdagen zelf
De patch van 10 november
Dinsdag 10 november is de tweede dinsdag van de maand. Sinds juli 2026 is dat de dag waarop Adobe maandelijks losse, niet-cumulatieve security patches uitbrengt. Voor Magento Open Source zijn die in het meest recente bulletin alleen beschikbaar vanaf versie 2.4.7. Welke patches je al hebt, check je met php vendor/bin/patch-status. Bestaat dat bestand niet, dan mis je in elk geval de patch van juli, want die installeert de tool.
Of er op 10 november een patch komt die jouw versie raakt, weet je pas als Adobe het bulletin publiceert: dat kan, maar is geen zekerheid. Reserveer daarom 10 tot en met 12 november om een eventuele patch op staging te testen en live te zetten, en laat de freeze pas daarna ingaan. Komt een kritieke patch later, tijdens de freeze zelf, dan installeer je die alsnog: daar is de uitzondering voor bedoeld, los van alle andere wijzigingen die wel wachten. Meer over hoe die maandelijkse patches werken staat in de uitleg over de patches van 2026.
Na Cyber Monday
Zodra Cyber Monday voorbij is, hef je de freeze op, met een lijst van wat is blijven liggen. Zet uitgestelde extensie-updates en een eventuele PHP 8.2-upgrade op de planning voor december of januari, niet voor de week erna: geef het team en de shop even rust.
Kijk ook terug op wat de monitoring tijdens de piek liet zien. Welke pagina werd traag, welke koppeling haperde, waar liep een queue op. Dat is de input voor volgend jaar, niet iets om nu nog geforceerd op te lossen.
Hoe wij het doen
Bij shops die bij ons in Magento onderhoud zitten, plannen we de freeze-periode en de patches samen met de klant, en testen we eerst op staging voordat iets naar productie gaat. Los van deze checklist: twijfel je of je code en extensies een piek aankunnen, dan is dat een vraag voor een code review. Neem contact op als je wilt weten hoe jouw shop ervoor staat.
Veelgestelde vragen
Moet ik een code freeze instellen?
Het is niet verplicht, maar het voorkomt dat er vlak voor of tijdens je drukste dagen iets live gaat dat niet goed is getest. Kies een datum die past bij hoeveel risico je wilt lopen, en leg vast wie een uitzondering mag goedkeuren.
Mag een security patch tijdens de freeze?
Ja. Een kritieke security patch is precies waarvoor je de uitzondering in je freeze-afspraak maakt. Je installeert die los van andere wijzigingen, ook als de freeze al is ingegaan.
Wat is het verschil tussen Update on Save en Update by Schedule?
Bij “Update on Save” wordt een indexer bij elke productwijziging meteen bijgewerkt, wat de actie die de wijziging veroorzaakte vertraagt. Bij “Update by Schedule” verwerkt cron die wijzigingen op de achtergrond in batches. Voor shops met veel verkeer, zeker rond een piek, is schedule de aangeraden instelling.
Hoe laat ik een load test iets zeggen over mijn shop?
Test een compleet bezoekerspad, niet alleen de homepage: categorie, productpagina, zoeken, winkelwagen en checkout. Draai de test op staging of een kopie van productie met een realistische hoeveelheid producten, niet zonder afspraak rechtstreeks op productie.