Magento mobil: schnell und bedienbar

Warum Mobil eine andere Disziplin als Desktop ist

Die meisten Magento-Themes sind für Desktop gebaut. Mobil bekommt eine responsive Schicht darüber, aber das zugrunde liegende JavaScript-Bundle, der Bild-Ansatz und die Touch-Interaktionen bleiben Desktop-First. Das hat konkrete Folgen, die man nicht mit einem Mausklick sieht, aber auf einem Telefon spürt.

• CPU-Budget: PSI Lab simuliert Mobil mit 4-fachem CPU-Throttle. Ein mittleres Android-Telefon hat buchstäblich ein Viertel der Rechenleistung eines Desktop-Browsers. JavaScript, das auf Desktop in 200ms parst, benötigt auf Mobil eine Sekunde oder länger.
• Netzwerk-Kontext: Slow 4G in PSI Lab bedeutet 1,6 Mbps Download, 750 kbps Upload, 150ms RTT. Das klingt schnell, aber eine Magento-Seite mit 400 kB JS plus Bildern ohne mobile Varianten macht jedes Kilobyte spürbar.
• Eingabemodus: auf Mobil tippt man, auf Desktop klickt man. Ein 32x20px größer Button ist mit einer Maus klickbar. Derselbe Button ist auf einem Telefon nicht bedienbar. WCAG 2.5.5 definiert 44x44px als empfohlenes Minimum für Touch-Targets.
• Viewport-Verhalten: ein fehlender oder falscher Viewport-Meta-Tag führt dazu, dass mobile Browser eine Desktop-Breite simulieren und herauszoomen. Das ergibt ein Desktop-Layout auf Mobil, mit horizontalem Scrollen.
• CrUX-Aufteilung: Google teilt Core Web Vitals in Mobil und Desktop auf. Die mobilen CrUX-Daten wiegen bei Rankings für mobile Suchanfragen stärker. Ein guter Desktop-Score deckt das mobile Ranking nicht ab.

Das sind keine Randfälle. In einem Shop mit mehr als 50% mobilem Traffic bestimmt die mobile Erfahrung den größten Teil der Conversion und des Rankings.

Mein Ansatz für ein mobiles Magento-Audit

Ich beginne nicht mit DevTools auf Desktop. Ein mobiles Audit erfordert mobile Messpunkte.

• Lighthouse Mobil über PSI API: ich fuhre mehrere Messungen am selben Tag durch, auf Homepage, Kategorie- und Produktseite. Lab-Varianz auf Mobil ist gross. Zwei Messungen derselben URL zur gleichen Zeit können durch CPU-Scheduling auf dem Google-Server 10 bis 20 Punkte auseinanderliegen.
• CrUX Mobile Dashboard: Google Search Console zeigt Core Web Vitals pro Seitentyp, aufgeteilt nach Mobil und Desktop. Das ist die Quelle der Wahrheit. Ich prüfe, ob Mobil und Desktop einen strukturellen Unterschied zeigen und bei welcher Metrik (LCP, INP, CLS).
• Visueller Ablauf auf einem echten Gerät: ich teste auf einem physischen mittleren Android-Gerät mit Chrome. Nicht auf einer DevTools-Emulation. Emulation simuliert die Bildschirmgröße, aber nicht die GPU-Leistung oder Touch-Latenz echter Hardware.
• Tap-Target-Audit mit Lighthouse-Zugänglichkeitsprüfungen: ich notiere alle Elemente kleiner als 24x24px (WCAG 2.5.8 Minimum) oder 44x44px (WCAG 2.5.5 empfohlen). In Magento-Shops sind Plus/Minus-Schaltflächen im Warenkorb, Filter-Chips und Hamburger-Menu-Elemente häufige Verstosser.
• Viewport-Meta-Tag-Prüfung: fehlt der Tag, steht er auf content='width=1024' oder wurde er fälschlicherweise von einer Erweiterung überschrieben? Ich prüfe pro Seitentyp.
• JS-Ausführungsbudget-Analyse: welche Skripte laufen auf Mobil, die nur für Desktop relevant sind? Hover-Effekt-Widgets, Flyout-Menüs und Tooltip-Handler verbrauchen JS-Budget auf Mobil ohne Mehrwert.

Das Audit ergibt eine gerankte Liste mobiler Engpässe, sortiert nach Auswirkung auf mobiles CrUX, nicht nach Lösungsaufwand.

Was ich typischerweise für Mobil auf Magento behebe

Nach dem Audit implementiere ich die Korrekturen mit der größten Wirkung. Bei Mobil handelt es sich fast immer um eine Kombination der folgenden Maßnahmen:

• Mobile Bildvarianten über picture + srcset: der Desktop-Hero mit 1400px Breite bringt auf einem 390px breiten Bildschirm nichts. Ich ergänze picture-Source-Elemente mit kleineren Varianten, damit Mobil ein 600px breites WebP lädt statt der vollständigen Desktop-Version.
• font-display: swap für alle Web-Fonts: wenn ein Web-Font bei langsamer Verbindung lädt, blockiert er ohne font-display:swap das Text-Rendering. Auf Mobil mit Slow 4G ist das in der Nutzererfahrung spürbar.
• Nicht-wesentliches JS über Media Query verzogern: Skripte, die nur für Desktop relevant sind (Flyout-Navigation, Hover-Intent, komplexe Tooltip-Bibliotheken), können auf media: (min-width: 1024px) beschränkt werden. Das gibt dem mobilen Main-Thread Spielraum.
• Sticky Warenkorb-Button mit safe-area-inset: auf Geräten mit Notch oder Home-Indikator (iPhone mit Face ID, Android mit Navigationsleiste) braucht ein Sticky-Call-to-Action padding-bottom: env(safe-area-inset-bottom), sonst überlappt er mit der Systemoberfläche.
• Tap-Target-Vergrößerungen: Plus/Minus-Schaltflächen im Warenkorb, Filter-Tags, Social-Share-Buttons. Ich vergrößere den klickbaren Bereich über Padding oder min-height/min-width ohne das visuelle Design zu brechen.
• Hide-on-Mobile-Muster bereinigen: Elemente mit display:none auf Mobil, die trotzdem geladen, geparst und gestylt werden. Sie sind unsichtbar, verbrauchen aber Main-Thread-Budget. Ich ersetze lazy-hidden-Muster durch bedingtes Laden, wo der Performance-Gewinn das rechtfertigt.
• Viewport-Meta-Tag-Korrektur: falsche width oder initial-scale Werte, die von Erweiterungen überschrieben wurden, prüfen und wiederherstellen.

Welche Korrekturen gelten, hängt von deinem Theme, deinem Erweiterungs-Set und deiner Magento-Version ab. Ich passe den Ansatz an deinen Stack an.

Tap-Target-Verstöße: das unsichtbare Conversion-Problem

In Magento-Shops sehe ich Tap-Target-Probleme am häufigsten an folgenden Stellen: den Plus/Minus-Schaltflächen für die Produktmenge im Mini-Warenkorb, den Filter-Checkboxen in der Layered Navigation, dem Hamburger-Menu-Button, der zu klein ist oder zu nah am Bildschirmrand sitzt, und Produkt-Swatches, die eng beieinander liegen.

WCAG 2.5.8 (neu in WCAG 2.2) legt fest, dass interaktive Elemente ein Touch-Target-Minimum von 24x24 CSS-Pixeln haben müssen. WCAG 2.5.5 empfiehlt 44x44px für bessere Bedienbarkeit. Lighthouse meldet Verstöße als 'Tap targets are not sized appropriately'. Das ist kein Stilproblem, sondern ein Conversion-Problem: ein Nutzer, der dreimal danebentippt bei einem Lupen-Button oder einem Minus-Button, verlässt die Seite.

Ich behebe Tap-Target-Verstöße mit minimalem visuellem Einfluss. Das bedeutet Padding hinzufügen statt Schaltflächen zu vergrößern, und den Leerraum zwischen benachbarten interaktiven Elementen zu erhöhen, um den empfohlenen 8px-Abstand zu erreichen. Bei Hamburger-Menüs prüfe ich, ob eine Bottom-Navigation für wiederkehrende Besucher eine bessere Wahl ist als ein Flyout-Menu, das sich von oben links öffnet.

Was ich beim mobilen Magento nicht mache

Es gibt Ansätze, die einfach klingen, aber das Kernproblem nicht lösen oder neue Probleme einführen.

• AMP-Seiten bauen: AMP ist für spezifische Anwendungsfälle technisch korrekt, aber für einen Magento-Shop mit komplexer Produktkonfiguration, Warenkorb-Funktionalität und Erweiterungen ist AMP eine parallele Plattform mit doppelten Wartungskosten ohne Garantie auf bessere CrUX-Werte.
• Native PWA-Installationen erzwingen: ein Service Worker und Web App Manifest hinzuzufügen ergibt eine installierbare PWA, behebt aber keine LCP-, INP- oder Tap-Target-Probleme. Ich installiere keine PWA-Schicht als Grundlage für Performance-Arbeit.
• Hybrid-App-Entwicklung: eine React Native oder Flutter-Shell über deinen Magento-Shop zu bauen ist ein Neubau-Projekt, keine Optimierung. Das liegt außerhalb des hier beschriebenen Umfangs.
• Mobile-only Codeabschnitte im Magento-Core: separate PHP-Blöcke pro Gerät über User-Agent-Erkennung sind fragil und schwer wartbar. CSS mit Media Queries und bedingtes JS mit matchMedia-Prüfungen ist der richtige Ansatz.
• Lab-Score als einziges Ziel: einen mobilen PSI-Score von 90 über Tricks zu erreichen, die echten Besuchern auf mittlerer Hardware nicht helfen, ist kein Ziel. Mobiles CrUX ist das Ziel.

Ich erkläre immer, warum ein bestimmter Ansatz nicht empfehlenswert ist, mit der Abwägung von Kosten, Wirkung und Risiko.

Verwandte Seiten