Als je Magento 2-winkel traag aanvoelt, verbeeld je het niet en ben je niet alleen. Magento is een krachtig platform, maar die kracht gaat gepaard met veel bewegende onderdelen. Wanneer een winkel traag is, is het bijna nooit één enkel probleem. Het zijn meestal vijf of zes kleinere problemen die bovenop elkaar zijn gestapeld.
In deze gids loop ik door de 12 oorzaken die ik het vaakst tegenkom bij het auditen van Magento 2-winkels, hoe je elke oorzaak kunt herkennen en wat je eraan kunt doen. Je kunt het gebruiken als een checklist voor je eigen team.
Eerst: meet voordat je iets verandert
Voordat je code of servers aanraakt, krijg een basislijn. Anders weet je nooit welke wijziging daadwerkelijk heeft geholpen.
- Tijd tot Eerste Byte (TTFB) op een gecachte en een ongecachte categoriepagina
- Core Web Vitals (LCP, INP, CLS) van echte gebruikers in Google Search Console of het CrUX-rapport
- Server-side profiling met een tool zoals New Relic, Blackfire of Tideways
- Cache hit rate van je volledige pagina cache (Varnish of de ingebouwde cache)
Schrijf deze nummers op. Elke fix hieronder moet er minstens één van hen verplaatsen.
1. De volledige pagina-cache werkt niet echt
Dit is de nummer één oorzaak. Varnish is geïnstalleerd, maar de meeste pagina’s worden nog steeds door PHP opgebouwd bij elke aanvraag. Veelvoorkomende schuldigen:
- Een blok ergens op de pagina is gemarkeerd
cacheable="false", wat de hele pagina niet-cachebaar maakt. - Klant specifieke gegevens worden op de server weergegeven in plaats van geladen via privé-inhoud (klantsecties)
- Trackingparameters zoals
utm_sourceofgclidcreëren een nieuwe cache-invoer voor elk bezoek
Fix: zoek je layout XML naar cacheable="false", verplaats gepersonaliseerde inhoud naar klantsecties, en verwijder marketingparameters in je Varnish-configuratie zodat ze de cache niet splitsen.
2. De productiemodus is niet ingeschakeld
Het klinkt eenvoudig, maar ik zie nog steeds winkels die draaien in de standaard- of ontwikkelaarsmodus. Statische bestanden worden on-the-fly gegenereerd en fouten zijn uitgebreid.
Oplossing: voer bin/magento deploy:mode:show uit. Als het niet production zegt, schakel het dan over als onderdeel van een juiste implementatie.
3. Te veel derde-partij extensies
Elke extensie voegt waarnemers, plugins en soms extra databasequery’s toe aan elke aanvraag. Twintig extensies die “kleine” dingen doen, kunnen seconden toevoegen.
Fix: lijst elk module met bin/magento module:status, verwijder alles wat je niet gebruikt, en profileer de rest. Let speciaal op extensies die in de productcollectie laden of de checkout haken.
4. Een zware frontend-thema (Luma en zijn kinderen)
De standaard Luma frontend laadt RequireJS, Knockout en jQuery, vaak met honderden JavaScript-bestanden. Op mobiele apparaten heeft dit een negatieve impact op Largest Contentful Paint en Interaction to Next Paint.
Oplossing: op korte termijn, bundel en stel uit wat je kunt. Op lange termijn is de meest effectieve optie overstappen naar een lichtere frontend zoals Hyvä. Ik heb een aparte gids geschreven over de migratie van Luma naar Hyvä met kosten, tijdlijnen en risico’s.
5. Niet-geoptimaliseerde afbeeldingen
Productafbeeldingen die rechtstreeks vanaf een camera of leveranciersfeed zijn geüpload, kunnen elk enkele megabytes groot zijn.
Oplossing: serve moderne formaten (WebP of AVIF), gebruik responsieve srcset groottes, laad afbeeldingen onder de vouw lui en laad nooit de belangrijkste productafbeelding lui, die meestal je LCP-element is.
6. Langzame of verkeerd geconfigureerde database
MySQL of MariaDB die draait met de standaardinstellingen is een veelvoorkomende bottleneck, vooral bij grote catalogi.
Oplossing: pas innodb_buffer_pool_size aan zodat je werkdataset in het geheugen past, schakel het langzame querylog in en kijk naar wat er verschijnt. Houd de database op snelle NVMe-opslag.
7. Indexers die “Update on Save” uitvoeren tijdens drukke uren
Wanneer indexers zijn ingesteld op “Bij Opslaan Bijwerken”, kan elke productopslag in de admin zware herindexering veroorzaken terwijl klanten aan het browsen zijn.
Fix: schakel indexers in op “Bijwerken volgens schema” en zorg ervoor dat cron betrouwbaar draait. Controleer bin/magento indexer:status op indexen die vastzitten in een “verwerken” status.
8. Cron-problemen
Magento is afhankelijk van cron voor indexering, e-mails, cache-schoonmaak en nog veel meer. Een defecte of overlappende cron maakt alles stilletjes trager.
Fix: controleer de cron_schedule tabel op taken die zich ophopen in de status “pending” of “running”, en ruim oude vermeldingen op.
9. Redis niet gebruikt (of slecht gedeeld)
Sessies en cache opgeslagen op het bestandssysteem worden traag onder belasting.
Oplossing: gebruik Redis voor cache en sessies, idealiter aparte instanties, zodat een cache-flush uw klanten nooit uitlogt.
10. Zoekmachine onder druk
OpenSearch (of Elasticsearch in oudere versies) drijft cataloguszoekopdrachten aan en, in veel configuraties, gelaagde navigatie. Te weinig geheugen maakt categoriepagina’s traag.
Oplossing: geef de zoekmachine toegewezen geheugen, houd het gebruik van de heap in de gaten en houd het op hetzelfde netwerk als uw webservers.
11. Grote catalogusimporten gedurende de dag
Grote product- of prijsimporten vergrendelen tabellen en maken caches ongeldig. Als ze om 11:00 uur op een maandag draaien, voelen je klanten het.
Oplossing: voer imports ’s nachts uit, importeer in batches en vermijd volledige cache-flushes na elke import. Maak alleen de tags schoon die zijn gewijzigd.
12. Ondermaatse of verouderde hosting
Soms is de server echt het probleem: oude PHP-versies, te weinig PHP-FPM-werknemers, of gedeelde hosting die nooit bedoeld was voor Magento.
Oplossing: draai een ondersteunde PHP-versie, pas de grootte van PHP-FPM-werkers aan op basis van je verkeer, en zet een CDN voor statische assets. Alleen hardware lost zelden een trage winkel op, maar slechte hardware kan een goede winkel vertragen.
Een praktische volgorde van werkzaamheden
Als je niet zeker weet waar je moet beginnen, geeft deze volgorde de grootste winst met de minste risico:
- Los het hitpercentage van de volledige pagina-cache op.
- Bevestig productiemodus, Redis en cron
- Verwijder ongebruikte extensies
- Optimaliseer afbeeldingen en het LCP-element
- Stem de database en zoek
- Plan een frontend-upgrade (bijvoorbeeld naar Hyvä)
Veelgestelde vragen
Hoe snel zou een Magento 2-winkel moeten zijn?
Streef naar een gecachte TTFB ver onder de halve seconde en Core Web Vitals in het “goede” bereik voor de meeste echte gebruikers: LCP op of onder de 2,5 seconden, INP op of onder de 200 ms en CLS op of onder de 0,1.
Zal meer serverkracht een trage Magento-winkel oplossen?
Gewoonlijk slechts gedeeltelijk. Als de volledige pagina-cache de meeste verzoeken mist, draait een grotere server gewoon trage code iets sneller. Los eerst caching en code op.
Is Magento 2 nog steeds een goede keuze in 2026?
Voor winkels met complexe catalogi, B2B-behoeften of meerdere winkels, ja. Het vereist regelmatige technische zorg, daarom moet prestatiewerk gepland worden, niet reactief.
Een tweede paar ogen nodig?
Ik help winkeleigenaren en e-commerce teams precies deze problemen te vinden en op te lossen, van Varnish-configuratie tot volledige Hyvä-migraties. Als je winkel traag is en je een duidelijk, geprioriteerd plan wilt, kijk dan naar mijn Magento 2 en Hyvä service of vraag een prestatie-audit aan.