Waarom is mijn Magento-webshop traag?

Hoe meet je waar de tijd zit?

Voordat je iets verandert, meet je. Anders weet je achteraf niet wat het opleverde.

Er zijn twee delen:

• De server. Hoe lang duurt het voordat de eerste byte van de pagina binnenkomt? Dat is werk van Magento, PHP, de database en de cache.
• De browser. Hoe lang duurt het daarna voordat de pagina bruikbaar is? Dat is werk van het thema: scripts, stijlen, lettertypen en afbeeldingen.

Meet op een paar vaste typen pagina’s: de homepage, een categorie, een product, de winkelwagen en de checkout. Die gedragen zich elk anders.

Welke cijfers kijk je naar?

Op de server is dat de wachttijd tot de eerste byte, per type pagina en met en zonder cache.

In de browser zijn het de Core Web Vitals van Google: hoe snel het grootste element in beeld staat (LCP), hoe snel de pagina reageert op een klik (INP) en of de opmaak verspringt tijdens het laden (CLS). Die meet je in een testomgeving, en waar Google genoeg bezoekers heeft gezien, ook bij echte bezoekers. Het tweede telt het zwaarst: een testmeting op een snelle laptop zegt weinig over een klant op een oude telefoon.

Doet de paginacache wel mee?

Dit is de oorzaak die we het vaakst vinden, en meestal de snelste winst.

Magento kan pagina’s kant-en-klaar uit een cache serveren. Adobe raadt daar voor productie sterk Varnish voor aan; de ingebouwde cache is veel trager. Maar de cache werkt alleen als de pagina cachebaar is. Als één blok op een pagina als niet-cachebaar is gemarkeerd, geldt dat voor de hele pagina. Eén module die dat doet op de productpagina, en elke bezoeker van elke productpagina gaat langs PHP en de database.

Staat zo’n markering in de algemene layout, dan cachet de shop geen enkele pagina meer. Dat komt vaker voor dan je zou denken.

Lopen cron en de indexers bij?

Magento houdt indexen bij voor prijzen, voorraad, categorieën en zoeken. Die kunnen bij elke wijziging in de admin opnieuw rekenen, of op een schema via cron.

Rekenen ze bij elke wijziging, dan wordt de beheeromgeving traag zodra er veel verandert, bijvoorbeeld bij een import van een leverancier. Staan ze op schema maar draait cron niet goed, dan lopen prijzen en voorraad in de winkel achter. Allebei zie je terug als we meten of cron bijblijft.

Doen de modules te veel?

Een module is code die op bepaalde momenten meedraait. Een goede module doet weinig. Een slechte doet bij elke pagina een externe aanroep of een zware query.

We meten per module wat hij kost. Daarna bespreken we wat eruit kan, wat anders moet en wat beter opnieuw gebouwd wordt. Hoe we zelf modules bouwen, staat op een eigen pagina.

Is het de frontend?

Het standaardthema van Magento laadt veel JavaScript. Dat merk je vooral op telefoons. Wat helpt:

• Scripts bundelen en uitstellen wat niet meteen nodig is
• Scripts van derden kritisch bekijken: chat, tracking, reviews
• Afbeeldingen in WebP of AVIF, in de maat die het scherm vraagt, en alleen laden wat in beeld komt

Soms is een lichter thema zoals Hyvä de grootste stap. Dat betekent wel dat het thema en een deel van de modules opnieuw gebouwd worden. Eerst halen we wat zonder nieuw thema te halen is.

Is de hosting op Magento ingericht?

Magento vraagt meer dan een gewone website. Te weinig PHP-processen, geen OPcache, een database die niet is afgesteld of een zoekmachine die op een andere plek draait dan de shop: het tikt allemaal aan. Een database vol oude winkelwagens, logs en verlopen sessies ook.

Hosten wij de shop, dan lossen we dat op de server op. Host je elders, dan beschrijven we wat je hoster moet aanpassen.

Hoe pakken wij het aan?

Meten, oplossen, opnieuw meten. Je krijgt de metingen voor en na zelf, met onze conclusie erbij, en geen beloofde cijfers vooraf. Meer op Magento sneller maken en Magento hosting.