Entfernung:
ein versteckter Faktor beim mobilen Lernen

Eine kurze Lektion bedeutet nicht automatisch, dass alles schnell geht. Ein Beispiel: Ein Kunde informiert sich in einer Fintech-App über Transaktionsgebühren. Der Text ist schnell gelesen. Doch beim Öffnen des Kapitels, beim Laden der Grafik und bis zur Rückmeldung zum Quiz entstehen jeweils neue Wartezeiten.

Bei kurzen Lerneinheiten fallen wiederholte Wartezeiten auf

Googles Empfehlungen zur nutzerorientierten Performance unterscheiden zwischen hilfreichen Inhalten und der Möglichkeit, eine Anwendung zu bedienen. Sie erklären außerdem, wie Geräte und Netzwerke das Nutzungserlebnis beeinflussen. (web.dev) Für Microlearning heißt das: Die Länge einer Lektion sagt wenig über den Aufwand aus, wenn es nur nach immer neuen Ladevorgängen weitergeht.

Jeder Schritt beim Lernen braucht eine eigene Zeitmessung

Eine sinnvolle Leistungsprüfung für ein mobiles LMS orientiert sich an den Schritten der Lernenden, statt die gesamte Lernplattform wie eine einzelne Seite zu behandeln.

• Vom Öffnen eines Moduls bis zur nutzbaren Navigation.
• Vom Tippen auf ein Kapitel bis zu dem Zeitpunkt, an dem der benötigte Text sichtbar und die Bedienelemente nutzbar sind.
• Vom Tippen auf ein Kapitel bis zur sichtbaren Anzeige des erforderlichen Bildes.
• Vom Absenden einer Antwort bis zur sichtbaren Rückmeldung und Bestätigung des Lernfortschritts.

Die W3C-Schnittstelle Resource Timing liefert Zeitmesswerte für einzelne Ressourcen in Webanwendungen. (w3.org) Diese Messwerte sollten mit Ereignissen in den jeweiligen Ansichten verknüpft werden. Text- und API-Anfragen, Bilder sowie Dienste von Drittanbietern müssen getrennt erfasst werden. So wird aus einer langsam ladenden Grafik nicht die pauschale Diagnose, die ganze Anwendung sei langsam.

Wie sich Entfernung auf Anfragen auswirkt

Zur Wartezeit bei einer Anfrage gehören sowohl die Netzwerklatenz für Hin- und Rückweg als auch die Vorbereitungszeit auf dem Server. (developer.chrome.com) Deshalb lässt sich die Latenz einer weltweit genutzten Lernplattform nicht allein anhand der Verarbeitungszeit im Backend beurteilen. Wird ein Bild erst angefordert, nachdem die Kapiteldaten angekommen sind, addieren sich diese Wartezeiten für die Lernenden.

Dieser Beitrag beruht auf der Analyse einer Lernplattform. Kapitelanfragen und das Laden von Bildern wurden dabei als mögliche Ursachen für Verzögerungen bei einer weit entfernten Zielgruppe identifiziert. Anpassungen an der Auslieferung setzten an beiden Stellen an. Unabhängig überprüfte Vorher-nachher-Messungen lagen jedoch nicht vor. Schnellere Ladezeiten blieben damit eine Erwartung, kein nachgewiesenes Ergebnis.

Bilder brauchen beim Microlearning ein eigenes Ladezeitbudget

Googles Empfehlungen zum Laden von Inhalten nennen drei getrennte Ansatzpunkte für kürzere Übertragungszeiten: Dateigröße, Entfernung zum ausliefernden Server und Caching. (web.dev) Welche Maßnahme für die Auslieferung von LMS-Inhalten sinnvoll ist, sollten die Messdaten zeigen: Zu große Grafiken erfordern kleinere Dateien, wiederholte Downloads sprechen für Anpassungen am Caching, und lange Wartezeiten in einzelnen Regionen rechtfertigen Tests mit kürzeren Auslieferungswegen. Das sind unterschiedliche Maßnahmen, keine austauschbaren Infrastruktur-Upgrades.

MDN unterscheidet in seinen Caching-Empfehlungen zwischen gemeinsam genutzten Ressourcen und personalisierten Antworten und warnt davor, private Inhalte für andere zugänglich zu machen. (developer.mozilla.org) Die Auslieferungsregeln einer Lernplattform sollten diese Grenze ausdrücklich festhalten. Versionierte Lektionsdateien müssen dabei getrennt von Lernfortschritten und Quizergebnissen behandelt werden.

Die Testumgebung muss zur Zielgruppe passen

Messungen im realen Einsatz erfassen tatsächliche Geräte, Netzwerke und geografische Standorte; kontrollierte Labortests erfüllen einen anderen Zweck. (web.dev) Eine sinnvolle Testmatrix kombiniert repräsentative Smartphones und Verbindungen in den Zielregionen mit reproduzierbaren Tests, bei denen die Leistung gezielt gedrosselt wird. Sie umfasst Erstbesuche, erneute Aufrufe mit bereits gefülltem Cache sowie Kapitel- und Quizabläufe im angemeldeten Zustand – nicht nur die Startseite der Lernplattform.

Verbesserungen brauchen Abnahmetests in den jeweiligen Ansichten

Die vorgeschlagene Messübersicht erfasst drei Zeitspannen mit p75 und p95: bis das erste Kapitel nutzbar ist, bis das erforderliche Bild sichtbar ist und bis die Quizrückmeldung nachweislich angezeigt wird. Ist ein Bild für das Verständnis nötig, gilt das Kapitel erst als nutzbar, wenn auch das Bild sichtbar ist. Die Ergebnisse sollten nach Region, Geräteklasse und Cache-Zustand aufgeschlüsselt sein und jeweils die Anzahl der Messungen ausweisen. Vor der Veröffentlichung legt das Team fest, welche Schwellenwerte akzeptabel sind und wie stark sich die Leistung höchstens verschlechtern darf. Anschließend vergleicht es vergleichbare Abläufe vor und nach jeder Änderung.

Für App-Learning endet die Verantwortung für die gemeinsam genutzte Lernplattform nicht beim CMS für die Lektionen. Sie umfasst repräsentative Tests, die Optimierung von Dateien und ihrer Auslieferung sowie die Prüfung, ob Änderungen in den Kapitel-, Quiz- und Bildansichten ankommen. Aufwendigere Interaktionen sollten warten, bis diese Grundlage verlässlich funktioniert.

Wie schnell eine Lern-App ist, zeigt sich beim Lernen, nicht im Hosting-Dashboard. Die Arbeit ist erst abgeschlossen, wenn Lernende mit weniger Wartezeit durch die Lektion kommen – nicht, wenn eine einzelne Serverkennzahl auf Grün springt.