Magento mobiel snel en bruikbaar

Waarom mobiel een ander discipline is dan desktop

De meeste Magento-themes zijn gebouwd voor desktop. Mobiel krijgt dan een responsieve laag overheen, maar de onderliggende JavaScript-bundle, de image-aanpak en de tap-interacties blijven desktop-first denken. Dat heeft concrete gevolgen die je niet ziet met een muisklik, maar wel voelt op een telefoon.

• ▸CPU-budget: PSI lab simuleert mobiel met 4x CPU-throttle. Een mid-range Android telefoon heeft letterlijk een kwart van de verwerkingskracht die een desktop-browser heeft. JavaScript die op desktop in 200ms parseert, duurt op mobiel een seconde of langer.
• ▸Netwerk-context: Slow 4G in PSI lab is 1,6 Mbps download, 750 kbps upload, 150ms RTT. Dat klinkt snel, maar een Magento-pagina met 400 kB aan JS plus afbeeldingen zonder mobile-specifieke varianten maakt elk kilobyte voelbaar.
• ▸Input mode: op mobiel tik je, op desktop klik je. Een knop van 32x20px is klikbaar met een muis. Diezelfde knop is op een telefoon onbruikbaar. WCAG 2.5.5 definieert 44x44px als aanbevolen minimum voor touch targets.
• ▸Viewport-gedrag: een ontbrekende of verkeerde viewport-meta-tag zorgt dat mobiele browsers een desktop-breedte simuleren en inzoomen. Dat geeft een desktop-layout op mobiel, compleet met horizontale scroll.
• ▸CrUX splitsing: Google split de Core Web Vitals in mobiel en desktop. De mobiele CrUX-data weegt zwaarder in rankings voor mobile searches. Een goede desktop-score dekt de mobiele ranking niet af.

Dit zijn geen randgevallen. Op een webshop met verkeer van meer dan 50% mobiel bepaalt de mobiele ervaring het grootste deel van de conversie en de ranking.

Mijn aanpak voor een mobiele Magento-audit

Ik begin niet met DevTools op desktop. Een mobiele audit vereist mobiele meetpunten.

• ▸Lighthouse mobiel via PSI API: ik run meerdere metingen op dezelfde dag, op homepage, categoriepagina en productpagina. Lab-variantie op mobiel is groot. Twee metingen op dezelfde URL op hetzelfde moment kunnen 10 tot 20 punten schelen door CPU-scheduling op de Google-server.
• ▸CrUX mobile dashboard: Google Search Console toont Core Web Vitals per paginatype, gesplitst op mobiel en desktop. Dit is de bron-van-waarheid. Ik kijk of mobiel en desktop een structureel verschil laten zien, en op welk metric (LCP, INP, CLS).
• ▸Visuele flow op een echt device: ik test op een fysiek mid-range Android met Chrome. Niet op een DevTools-emulatie. Emulatie simuleert het schermformaat maar niet de GPU-prestaties of de touch-latency van echte hardware.
• ▸Tap-target audit met Lighthouse accessibility checks: ik noteer alle elementen die kleiner zijn dan 24x24px (WCAG 2.5.8 minimum) of 44x44px (WCAG 2.5.5 aanbevolen). Op Magento-shops zijn plus/min knoppen in de cart, filter-chips en hamburgermenu-items veelvoorkomende overtreders.
• ▸Viewport meta-tag check: ontbreekt de tag, staat hij op content='width=1024' of is hij foutief door een derde extensie overschreven? Ik check het per paginatype.
• ▸JS execution budget analyse: welke scripts draaien op mobiel die alleen voor desktop relevant zijn? Widgets voor hover-effects, flyout-menu's en tooltip-handlers verbruiken JS-budget op mobiel zonder waarde toe te voegen.

Uit de audit komt een gerangschikte lijst van mobiel-specifieke knelpunten. Gesorteerd op impact op CrUX-mobiel, niet op hoe makkelijk ze te fixen zijn.

Wat ik typisch fix op Magento voor mobiel

Na de audit implementeer ik de fixes met de hoogste impact. Op mobiel gaat het bijna altijd om een combinatie van het volgende:

• ▸Mobile-specifieke image-varianten via picture + srcset: de desktop-hero op 1400px breed heeft op een 390px breed scherm geen nut. Ik voeg picture-source-elementen toe met kleinere varianten, zodat mobiel een 600px breed WebP laadt in plaats van de volledige desktop-versie.
• ▸font-display: swap op alle webfonts: als een webfont laadt op een trage verbinding, blokkeert het zonder font-display:swap de tekst-render. Op mobiel met Slow 4G is dit hoorbaar in de gebruikerservaring.
• ▸Defer non-essential JS via media query: scripts die alleen voor desktop relevant zijn (flyout-nav, hover-intent, complexe tooltip-bibliotheken) kunnen worden uitgesteld of alleen geladen op media: (min-width: 1024px). Dat geeft de mobile main thread ruimte.
• ▸Sticky cart-button met safe-area-inset: op apparaten met een notch of een home-indicator (iPhone met Face ID, Android met navigatiebalk) moet een sticky call-to-action padding-bottom: env(safe-area-inset-bottom) krijgen, anders overlapt hij met de systeeminterface.
• ▸Tap-target vergrotingen: plus/min knoppen in de cart, filter-tags, sociale deelknoppen. Ik vergroot de klikbare zone via padding of min-height/min-width zonder het visuele ontwerp te breken.
• ▸Hide-on-mobile patterns opruimen: elementen met display:none op mobiel die toch worden ingeladen, parsed en gestyled. Ze zijn onzichtbaar maar kosten wel main thread budget. Ik vervang lazy-hidden patterns door conditioneel laden waar de performance-winst dat rechtvaardigt.
• ▸Viewport meta-tag correctie: controleren en herstellen van verkeerde width of initial-scale waarden die door extensies zijn overschreven.

Welke fixes van toepassing zijn, hangt af van jouw theme, extensie-set en Magento-versie. Ik pas de aanpak aan op jouw stack.

Tap-target violations: het onzichtbare conversieprobleem

Op Magento-shops zie ik tap-target problemen het vaakst op de volgende plekken: de plus/min knoppen bij de producthoeveelheid in de mini-cart, filter-checkboxen in de layered navigation, de hamburger-menu-knop die te klein is of te dicht bij de rand van het scherm zit, en product-swatches die dicht op elkaar gepakt zijn.

WCAG 2.5.8 (nieuw in WCAG 2.2) stelt dat interactieve elementen een minimum touch-target van 24x24 CSS-pixels moeten hebben. WCAG 2.5.5 raadt 44x44px aan voor betere bruikbaarheid. Lighthouse rapporteert overtredingen als 'Tap targets are not sized appropriately'. Dit is geen stijlkwestie maar een conversieprobleem: een gebruiker die driemaal mis-tikt op een vergrootglas-knop of een min-knop, verlaat de pagina.

Ik herstel tap-target violations met minimale visuele impact. Dat betekent padding toevoegen in plaats van knoppen groter maken, en witruimte tussen aangrenzende interactieve elementen vergroten zodat ze de aanbevolen afstand van 8px halen. Voor hamburger-menus bekijk ik of een bottom-navigation voor terugkerende bezoekers een betere keuze is dan een flyout-menu dat vanuit de linkerbovenhoek opent.

Wat ik niet doe op mobile Magento

Er zijn benaderingen die makkelijk klinken maar de kern van het probleem niet aanpakken, of nieuwe problemen introduceren.

• ✕AMP-pages bouwen: AMP is technisch correct voor specifieke use cases, maar voor een Magento webshop met uitgebreide productconfiguratie, cart-functionaliteit en extensies is AMP een parallel platform dat dubbele onderhoudskosten geeft zonder garantie op betere CrUX-scores.
• ✕Native PWA-installs forceren: een service worker en web app manifest toevoegen levert een installeerbare PWA op, maar lost LCP, INP en tap-target problemen niet op. Ik installateer geen PWA-laag als basis voor performance-werk.
• ✕Hybrid app development: een React Native of Flutter shell over je Magento shop bouwen is een nieuwbouwtraject, geen optimalisatie. Het valt buiten de scope van wat ik hier beschrijf.
• ✕Mobile-only code-branches in Magento core: aparte PHP-blocks per device via user-agent detection zijn fragiel en moeilijk onderhoudbaar. CSS met media queries is de aanpak en conditioneel JS met matchMedia checks.
• ✕Lab-score als enige doel: een mobile PSI-score van 90 halen via tricks die echte bezoekers op mid-range hardware niet helpen, is geen doel. CrUX-mobiel is het doel.

Ik leg altijd uit waarom een bepaalde aanpak af te raden is, met de afweging van kosten, impact en risico.

Verwante pagina's