Geräte, die mit dem Internet verbunden werden können, bieten heute noch mehr Funktionen. Die gleiche Webanwendung, die auf einem High-End-Desktop-Computer bereitgestellt wird, kann auch auf einem Smartphone, einer Uhr oder einem Tablet mit geringer Leistung bereitgestellt werden. Es kann unglaublich schwierig sein, überzeugende Erlebnisse zu schaffen, die auf jedem Gerät nahtlos funktionieren.
Die Device Memory API ist eine neue Webplattformfunktion, die Webentwicklern beim Umgang mit der modernen Gerätelandschaft helfen soll. Dem navigator-Objekt wird eine schreibgeschützte Eigenschaft navigator.deviceMemory hinzugefügt, die den RAM-Speicher des Geräts in Gigabyte zurückgibt, abgerundet auf die nächste Potenz von zwei. Die API verfügt außerdem über den Header „Client Hints“ (Device-Memory), der denselben Wert meldet.
Mit der Device Memory API haben Entwickler vor allem zwei Möglichkeiten:
- Treffen Sie Laufzeitentscheidungen darüber, welche Ressourcen basierend auf dem zurückgegebenen Wert des Gerätespeichers bereitgestellt werden sollen. Stellen Sie z. B. Nutzern auf Geräten mit wenig Arbeitsspeicher eine Lite-Version einer App bereit.
- Melden Sie diesen Wert an einen Analysedienst, damit Sie besser nachvollziehen können, wie der Gerätespeicher mit dem Nutzerverhalten, Conversions oder anderen für Ihr Unternehmen wichtigen Messwerten korreliert.
Inhalte dynamisch basierend auf dem Gerätespeicher anpassen
Wenn Sie einen eigenen Webserver ausführen und die Logik ändern können, die Ressourcen bereitstellt, können Sie auf Anfragen, die den Header für Client-Hinweise Device-Memory enthalten, unter bestimmten Bedingungen antworten.
GET /main.js HTTP/1.1
Host: www.example.com
Device-Memory: 0.5
Accept: */*
Mit dieser Technik können Sie eine oder mehrere Versionen Ihrer Anwendungsskripts erstellen und auf Anfragen vom Client basierend auf dem Wert, der im Device-Memory-Header festgelegt ist, bedingt antworten. Diese Versionen müssen keinen komplett unterschiedlichen Code enthalten, da dies schwieriger ist. Meistens werden bei der Lite-Version nur Funktionen ausgeschlossen, die möglicherweise teuer sind und für die Nutzerfreundlichkeit nicht entscheidend sind.
Header für Clienthinweise verwenden
Wenn Sie den Device-Memory-Header aktivieren möchten, fügen Sie entweder dem <head> Ihres Dokuments das <meta>-Tag für Clienthinweise hinzu:
<meta http-equiv="Accept-CH" content="Device-Memory">
Oder fügen Sie „Device-Memory“ in die Accept-CH-Antwortheader Ihres Servers ein:
HTTP/1.1 200 OK
Date: Thu Dec 07 2017 11:44:31 GMT
Content-Type: text/html
Accept-CH: Device-Memory, Downlink, Viewport-Width
Dadurch wird der Browser angewiesen, den Device-Memory-Header mit allen Unterressourcenanfragen für die aktuelle Seite zu senden.
Wenn Sie eine der oben genannten Optionen für Ihre Website implementiert haben und ein Nutzer sie auf einem Gerät mit 0,5 GB RAM aufruft, enthalten alle Bild-, CSS- und JavaScript-Anfragen von dieser Seite den Header Device-Memory mit dem Wert „0.5“. Ihr Server kann auf solche Anfragen dann so reagieren, wie Sie es für angemessen halten.
Die folgende Express-Route stellt beispielsweise eine Lite-Version eines Skripts bereit, wenn der Header Device-Memory festgelegt ist und sein Wert kleiner als 1 ist. Wenn der Browser den Header Device-Memory nicht unterstützt oder der Wert mindestens 1 ist, wird die Vollversion verwendet:
app.get('/static/js/:scriptId', (req, res) => {
// Low-memory devices should load the "lite" version of the component.
// The logic below will set `scriptVersion` to "lite" if (and only if)
// `Device-Memory` isn't undefined and returns a number less than 1.
const scriptVersion = req.get('Device-Memory') < 1 ? 'lite' : 'full';
// Respond with the file based on `scriptVersion` above.
res.sendFile(`./path/to/${req.params.scriptId}.${scriptVersion}.js`);
});
JavaScript API verwenden
In einigen Fällen (z. B. bei einem statischen Dateiserver oder einem CDN) sind Sie nicht in der Lage, auf Anfragen basierend auf einem HTTP-Header bedingt zu antworten. In diesen Fällen können Sie die JavaScript API verwenden, um bedingte Anfragen im JavaScript-Code zu senden.
Die folgende Logik ähnelt der obigen Express-Route, mit dem Unterschied, dass die Skript-URL in der clientseitigen Logik dynamisch bestimmt wird:
// Low-memory devices should load the "lite" version of the component.
// The logic below will set `componentVersion` to "lite" if (and only if)
// deviceMemory isn't undefined and returns a number less than 1.
const componentVersion = navigator.deviceMemory < 1 ? 'lite' : 'full';
const component = await import(`path/to/component.${componentVersion}.js`);
component.init();
Die Bereitstellung verschiedener Versionen derselben Komponente basierend auf den Gerätefunktionen ist zwar eine gute Strategie, manchmal ist es aber noch besser, eine Komponente überhaupt nicht bereitzustellen.
In vielen Fällen sind Komponenten reine Verbesserungen. Sie sorgen für einige nüchterne Ergänzungen, sind aber für die Hauptfunktionen der App nicht erforderlich. In diesen Fällen kann es sinnvoll sein, diese Komponenten von vornherein nicht zu laden. Wenn eine Komponente zur Verbesserung der Nutzererfahrung die App langsam reagiert oder nicht mehr reagiert, wird ihr Ziel nicht erreicht.
Es ist entscheidend, dass Sie jede Entscheidung, die sich auf die Nutzererfahrung auswirkt, deren Auswirkungen messen. Außerdem sollten Sie sich ein klares Bild von der aktuellen Leistung Ihrer App machen.
Wenn Sie verstehen, wie der Gerätespeicher mit dem Nutzerverhalten in der aktuellen Version Ihrer App korreliert, können Sie besser einschätzen, welche Maßnahmen ergriffen werden müssen, und Sie erhalten eine Referenz, an der Sie den Erfolg zukünftiger Änderungen messen können.
Gerätespeicher mit Analysen nachverfolgen
Die Device Memory API ist neu und die meisten Analyseanbieter verfolgen sie nicht standardmäßig. Glücklicherweise bieten Ihnen die meisten Analyseanbieter eine Möglichkeit, benutzerdefinierte Daten zu verfolgen. Google Analytics bietet beispielsweise eine Funktion namens Benutzerdefinierte Dimensionen, mit der Sie den Gerätespeicher der Geräte Ihrer Nutzer verfolgen können.
Sie verwenden eine benutzerdefinierte Dimension für den Gerätespeicher.
Benutzerdefinierte Dimensionen in Google Analytics können in zwei Schritten verwendet werden.
- Richten Sie die benutzerdefinierte Dimension in Google Analytics ein.
- Ändern Sie den Tracking-Code so, dass
setder Wert für den Gerätespeicher für die soeben erstellte benutzerdefinierte Dimension ist.
Benennen Sie die benutzerdefinierte Dimension „Gerätespeicher“ und wählen Sie als Umfang „Sitzung“ aus, da sich der Wert während der Browsersitzung eines Nutzers nicht ändert:
Aktualisieren Sie als Nächstes Ihren Tracking-Code. Hier ist ein Beispiel, wie dies aussehen könnte. Bei Browsern, die die Device Memory API nicht unterstützen, lautet der Dimensionswert „(nicht festgelegt)“.
// Create the tracker from your tracking ID.
// Replace "UA-XXXXX-Y" with your Google Analytics tracking ID.
ga('create', 'UA-XXXXX-Y', 'auto');
// Set the device memory value as a custom dimension on the tracker.
// This will ensure it gets sent with all future data to Google Analytics.
// Note: replace "XX" with the index of the custom dimension you created
// in the Google Analytics admin.
ga('set', 'dimensionXX', navigator.deviceMemory || '(not set)');
// Do any other other custom setup you want...
// Send the initial pageview.
ga('send', 'pageview');
Berichterstellung zu Daten zum Gerätespeicher
Sobald die Dimension „Gerätespeicher“ für das Tracker-Objekt set lautet, enthalten alle Daten, die Sie an Google Analytics senden, diesen Wert.
Auf diese Weise können Sie beliebige Messwerte (z.B. Seitenladezeiten, Abschlussquoten für Zielvorhaben usw.) nach Gerätespeicher aufschlüsseln, um Korrelationen zu erkennen.
Da es sich bei dem Gerätespeicher nicht um eine integrierte, sondern um eine benutzerdefinierte Dimension handelt, ist sie in keinem Standardbericht enthalten. Um auf diese Daten zugreifen zu können, müssen Sie einen benutzerdefinierten Bericht erstellen. Die Konfiguration für einen benutzerdefinierten Bericht, der die Ladezeiten nach Gerätespeicher vergleicht, könnte beispielsweise so aussehen:
Der generierte Bericht könnte wie folgt aussehen:
Sobald Sie Gerätespeicherdaten erfassen und eine Referenz dafür haben, wie Nutzer Ihre Anwendung in allen Bereichen des Arbeitsspeicherspektrums verwenden, können Sie experimentieren und verschiedenen Nutzern mithilfe der im obigen Abschnitt beschriebenen Techniken verschiedene Ressourcen bereitstellen. Danach können Sie die Ergebnisse ansehen und sehen, ob sie sich verbessert haben.
Zusammenfassung
In diesem Beitrag wird beschrieben, wie Sie mit der Device Memory API Ihre Anwendung an die Funktionen der Geräte Ihrer Nutzer anpassen und messen können, wie diese Nutzer Ihre App erleben.
Der Schwerpunkt dieses Beitrags liegt auf der Device Memory API. Die meisten der hier beschriebenen Techniken können jedoch auf jede API angewendet werden, die Gerätefunktionen oder Netzwerkbedingungen meldet.
Da die Gerätelandschaft immer umfangreicher wird, ist es wichtiger denn je, dass Webentwickler bei Entscheidungen, die sich auf ihre Erfahrung auswirken, das gesamte Spektrum der Nutzer berücksichtigen.