Magento mobil: schnell und bedienbar

Warum Mobil eine andere Disziplin als Desktop ist

Die meisten Magento-Themes sind fuer Desktop gebaut. Mobil bekommt eine responsive Schicht darueber, 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 spuert.

• ▸CPU-Budget: PSI Lab simuliert Mobil mit 4-fachem CPU-Throttle. Ein mittleres Android-Telefon hat buchstaeblich ein Viertel der Rechenleistung eines Desktop-Browsers. JavaScript, das auf Desktop in 200ms parst, benoetigt auf Mobil eine Sekunde oder laenger.
• ▸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 spuerbar.
• ▸Eingabemodus: auf Mobil tippt man, auf Desktop klickt man. Ein 32x20px grosser Button ist mit einer Maus klickbar. Derselbe Button ist auf einem Telefon nicht bedienbar. WCAG 2.5.5 definiert 44x44px als empfohlenes Minimum fuer Touch-Targets.
• ▸Viewport-Verhalten: ein fehlender oder falscher Viewport-Meta-Tag fuehrt 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 fuer mobile Suchanfragen staerker. Ein guter Desktop-Score deckt das mobile Ranking nicht ab.

Das sind keine Randfaelle. In einem Shop mit mehr als 50% mobilem Traffic bestimmt die mobile Erfahrung den groessten Teil der Conversion und des Rankings.

Mein Ansatz fuer ein mobiles Magento-Audit

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

• ▸Lighthouse Mobil ueber 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 koennen 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 pruefe, ob Mobil und Desktop einen strukturellen Unterschied zeigen und bei welcher Metrik (LCP, INP, CLS).
• ▸Visueller Ablauf auf einem echten Geraet: ich teste auf einem physischen mittleren Android-Geraet mit Chrome. Nicht auf einer DevTools-Emulation. Emulation simuliert die Bildschirmgroesse, aber nicht die GPU-Leistung oder Touch-Latenz echter Hardware.
• ▸Tap-Target-Audit mit Lighthouse-Zuegaenglichkeitspruefungen: 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-Schaltflaechen im Warenkorb, Filter-Chips und Hamburger-Menu-Elemente haeufige Verstosser.
• ▸Viewport-Meta-Tag-Pruefung: fehlt der Tag, steht er auf content='width=1024' oder wurde er faelschlicherweise von einer Erweiterung ueberschrieben? Ich pruefe pro Seitentyp.
• ▸JS-Ausfuehrungsbudget-Analyse: welche Skripte laufen auf Mobil, die nur fuer Desktop relevant sind? Hover-Effekt-Widgets, Flyout-Menues und Tooltip-Handler verbrauchen JS-Budget auf Mobil ohne Mehrwert.

Das Audit ergibt eine gerankte Liste mobiler Engpaesse, sortiert nach Auswirkung auf mobiles CrUX, nicht nach Loesungsaufwand.

Was ich typischerweise fuer Mobil auf Magento behebe

Nach dem Audit implementiere ich die Korrekturen mit der groessten Wirkung. Bei Mobil handelt es sich fast immer um eine Kombination der folgenden Massnahmen:

• ▸Mobile Bildvarianten ueber picture + srcset: der Desktop-Hero mit 1400px Breite bringt auf einem 390px breiten Bildschirm nichts. Ich ergaenze picture-Source-Elemente mit kleineren Varianten, damit Mobil ein 600px breites WebP laedt statt der vollstaendigen Desktop-Version.
• ▸font-display: swap fuer alle Web-Fonts: wenn ein Web-Font bei langsamer Verbindung laedt, blockiert er ohne font-display:swap das Text-Rendering. Auf Mobil mit Slow 4G ist das in der Nutzererfahrung spuerbar.
• ▸Nicht-wesentliches JS ueber Media Query verzogern: Skripte, die nur fuer Desktop relevant sind (Flyout-Navigation, Hover-Intent, komplexe Tooltip-Bibliotheken), koennen auf media: (min-width: 1024px) beschraenkt werden. Das gibt dem mobilen Main-Thread Spielraum.
• ▸Sticky Warenkorb-Button mit safe-area-inset: auf Geraeten 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 ueberlappt er mit der Systemoberflaeche.
• ▸Tap-Target-Vergroesserungen: Plus/Minus-Schaltflaechen im Warenkorb, Filter-Tags, Social-Share-Buttons. Ich vergroessere den klickbaren Bereich ueber 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 ueberschrieben wurden, pruefen und wiederherstellen.

Welche Korrekturen gelten, haengt von Ihrem Theme, Ihrem Erweiterungs-Set und Ihrer Magento-Version ab. Ich passe den Ansatz an Ihren Stack an.

Tap-Target-Verstoesse: das unsichtbare Conversion-Problem

In Magento-Shops sehe ich Tap-Target-Probleme am haeufigsten an folgenden Stellen: den Plus/Minus-Schaltflaechen fuer 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 muessen. WCAG 2.5.5 empfiehlt 44x44px fuer bessere Bedienbarkeit. Lighthouse meldet Verstoesse 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, verlaesst die Seite.

Ich behebe Tap-Target-Verstoesse mit minimalem visuellem Einfluss. Das bedeutet Padding hinzufuegen statt Schaltflaechen zu vergroessern, und den Leerraum zwischen benachbarten interaktiven Elementen zu erhoehen, um den empfohlenen 8px-Abstand zu erreichen. Bei Hamburger-Menues pruefe ich, ob eine Bottom-Navigation fuer wiederkehrende Besucher eine bessere Wahl ist als ein Flyout-Menu, das sich von oben links oeffnet.

Was ich beim mobilen Magento nicht mache

Es gibt Ansaetze, die einfach klingen, aber das Kernproblem nicht loesen oder neue Probleme einfuehren.

• ✕AMP-Seiten bauen: AMP ist fuer spezifische Anwendungsfaelle technisch korrekt, aber fuer einen Magento-Shop mit komplexer Produktkonfiguration, Warenkorb-Funktionalitaet 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 hinzuzufuegen ergibt eine installierbare PWA, behebt aber keine LCP-, INP- oder Tap-Target-Probleme. Ich installiere keine PWA-Schicht als Grundlage fuer Performance-Arbeit.
• ✕Hybrid-App-Entwicklung: eine React Native oder Flutter-Shell ueber Ihren Magento-Shop zu bauen ist ein Neubau-Projekt, keine Optimierung. Das liegt ausserhalb des hier beschriebenen Umfangs.
• ✕Mobile-only Codeabschnitte im Magento-Core: separate PHP-Bloecke pro Geraet ueber 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 ueber Tricks zu erreichen, die echten Besuchern auf mittlerer Hardware nicht helfen, ist kein Ziel. Mobiles CrUX ist das Ziel.

Ich erklaere immer, warum ein bestimmter Ansatz nicht empfehlenswert ist, mit der Abwaegung von Kosten, Wirkung und Risiko.

Verwandte Seiten