Magento performance, gebouwd voor je echte bezoekers

Waarom Magento traag is by default

Magento 2 is gebouwd voor flexibiliteit en uitbreiding, niet voor snelheid. Een standaard Magento-installatie met een paar populaire extensies levert al een JavaScript-bundle op die de browser seconden nodig heeft om te parsen voordat er iets zichtbaar wordt.

• ▸Zware theme-JavaScript: frameworks zoals Infortis Ultimo of RWD laden complete UI-bibliotheken, ook op pagina's die ze niet gebruiken.
• ▸RequireJS module-loading: Magento's front-end bundelsysteem is gebouwd voor compatibiliteit, niet voor snelheid. Elke module laadt zijn eigen dependencies in een waterval van requests.
• ▸Plumrocket en cookie-consent plugins: dit soort modules injecteert scripts die render-blocking zijn zolang er geen user-consent is.
• ▸Plugin sprawl: elke extensie voegt CSS en JavaScript toe aan elke pagina, zonder te checken of het daar nodig is.
• ▸Geen hero LCP-prioritering: de producthero of banner-afbeelding wordt standaard behandeld als een gewone afbeelding, zonder eager load of fetchpriority.
• ▸Shared hosting TTFB: op Hypernode-plannen die niet goed zijn geconfigureerd, of op shared omgevingen zonder Full Page Cache, loopt de Time to First Byte al op tot boven de 800ms.

PSI lab simuleert dit onder worst-case omstandigheden: 4x CPU-throttle, Slow 4G netwerk. Dat verklaart waarom lab-scores zo laag uitpakken voor Magento-shops. Het is geen teken dat de shop onbruikbaar is. Het is wel een signaal dat er ruimte is voor verbetering die echte bezoekers direct voelen.

PSI lab versus CrUX: wat echte bezoekers ervaren

PageSpeed Insights toont twee soorten data naast elkaar, en de meeste shop-eigenaren lezen alleen de lab-score. Dat is het getal dat varieert en tegenvalt. De field-data eronder, gevoed door het Chrome User Experience Report (CrUX), is wat je klanten daadwerkelijk ervaren.

Lab meet op een gesimuleerde device: 4x CPU-throttle, Slow 4G, Lighthouse-engine op een Google-server. Field-data meet op de hardware en verbindingen van echte bezoekers over de afgelopen 28 dagen. Voor Magento-shops die hoofdzakelijk desktop-verkeer hebben, of bezoekers met 4G+ verbindingen, is het verschil tussen lab en field aanzienlijk.

Bij CarCare24 was de lab-LCP op mobiel 14 tot 16 seconden. De CrUX-LCP over 28 dagen: 2,14 seconden. Dat is niet omdat de shop het zo goed doet dat lab het niet bijhoudt. Het is omdat lab een worst-case scenario simuleert. Ik optimaliseer voor wat je klanten ervaren, niet voor wat Lighthouse rapporteert. CrUX is de bron-van-waarheid voor Core Web Vitals ranking in Google.

Mijn audit-aanpak voor Magento 2

Een Magento performance-audit begint niet met gokken. Ik meet eerst, dan analyseer ik, dan prioriteer ik. Het verschil met een generieke webperf-audit: ik ken de Magento-internals die anderen overslaan.

• ▸PSI API op homepage, categoriepagina, productpagina en checkoutpagina: elk paginatype heeft zijn eigen knelpuntenprofiel.
• ▸Network waterfall in Chrome DevTools: welke request is de LCP-kandidaat, wat laadt ervoor, welk script blokkeert de render.
• ▸CrUX-dashboard en Google Search Console CWV-rapport: wat zien echte bezoekers de afgelopen 28 dagen, per paginatype.
• ▸Magento mode check: staat de shop in developer mode op productie? Dan draait RequireJS unbundled en is elke JS-file een aparte request.
• ▸Full Page Cache status: is Varnish of Magento FPC actief en correct geconfigureerd? TTFB van 800ms+ is bijna altijd een cache-miss.
• ▸MagePack of requirejs-bundling analyse: is JS al gebundeld en geminified, en zo ja, hoe is de bundle-strategie ingericht?
• ▸Third-party impact: hoeveel main thread time claimen Plumrocket, GTM, chat-widgets en consent-banners samen?

Uit deze analyse komt een gerangschikte lijst van knelpunten. Niet gesorteerd op hoe makkelijk ze te fixen zijn, maar op hoeveel impact de fix heeft op CrUX. Dat is het verschil tussen score-chasing en daadwerkelijk verbeteren.

Wat ik typisch fix op Magento

Na de audit implementeer ik de fixes met de hoogste CrUX-impact. Op Magento-shops gaat het bijna altijd om een combinatie van de volgende ingrepen:

• ▸Hero-image: loading=eager en fetchpriority=high op de LCP-kandidaat. Dit is de snelste win op bijna elke Magento-shop. De banner of productafbeelding above the fold wordt standaard lazy-loaded. Dat is precies verkeerd.
• ▸WebP-conversie: Magento 2.4.x heeft ingebouwde WebP-support via de mediagallery. Activeren en testen per browser-support is een kwestie van configuratie.
• ▸Deferred third-party scripts: Plumrocket-consent, GTM, livechat-widgets en social embeds verplaatsen naar na het first contentful paint. Ze mogen de render niet blokkeren.
• ▸Custom CSP-module: een Content Security Policy die te breed of te permissief is, blokkeert op sommige Magento-installaties scripts die nodig zijn. Ik schrijf een module die de CSP correct afdwingt zonder functionaliteit te breken.
• ▸MagePack bundling tuning: MagePack groepeert RequireJS-modules per pagina-type. Verkeerde configuratie geeft juist grotere bundles. Ik analyseer het bundle-profiel en pas de configuratie aan.
• ▸Full Page Cache warming: een cold cache geeft hoge TTFB op de eerste bezoeker. Met een cache-warmer script wordt elke pagina vooraf gegenereerd.

Welke van deze fixes van toepassing zijn, hangt af van jouw installatie, theme en extensie-set. Op een Hypernode-omgeving met Cloudflare Free zijn andere knoppen beschikbaar dan op een generieke VPS. Ik pas de aanpak aan op wat jouw stack toelaat.

Wat ik niet doe

Er zijn manieren om een Lighthouse-score omhoog te duwen zonder dat bezoekers daar iets van merken. Ik gebruik ze niet, en ik leg altijd uit waarom een bepaalde tactiek af te raden is.

• ✕Score-chasing zonder CrUX-context: een score van 90 in lab die niet terug te zien is in CrUX-field-data is weinig waard. Ik optimaliseer voor field-data, niet voor lab-schermafdrukken.
• ✕Ongeautoriseerde preload-hints: fetchpriority=high op resources die niet op het kritieke pad zitten, geeft de browser verkeerde prioriteitssignalen en kan performance verslechteren.
• ✕Theme-rewrites zonder kostenanalyse: een full Hyvä-migratie lost veel op, maar kost ook substantieel. Als de huidige stack met gerichte fixes al CrUX-doelen haalt, is een theme-rewrite geen proportionele keuze.
• ✕Afbeeldingen verbergen om CLS te verlagen: de visuele stabiliteitscore omhoog krijgen door elementen te verstoppen lost de oorzaak niet op.
• ✕Lichtere pagina's serveren aan bots: Google detecteert cloaking en bestraft het. De pagina die Lighthouse ziet, moet identiek zijn aan wat bezoekers zien.

Ik geef altijd inzicht in de afweging: wat kost een fix, wat levert het op in CrUX, en wat is de risicobeoordeling voor de rest van de shop.

Verwante pagina's