Die Bandbreite der Möglichkeiten von Geräten, die eine Verbindung mit dem Internet herstellen können, ist heute größer als je zuvor. Dieselbe Webanwendung, die auch für High-End- kann auch auf einem Smartphone, einer Smartwatch oder einem Tablet mit geringer Leistung und es kann unglaublich schwierig sein, überzeugende Erlebnisse zu schaffen, problemlos auf jedem Gerät.
Die Device Memory API ist eine neue Webversion
Plattformfunktion, die Webentwicklern den Umgang mit modernen Geräten erleichtert
zu verbessern. Dem Objekt navigator
wird ein schreibgeschütztes Attribut hinzugefügt.
navigator.deviceMemory
: gibt an, wie viel RAM das Gerät hat
Gigabyte abgerundet auf die nächste Potenz von zwei. Das API bietet außerdem ein
Client Hints Header,
Device-Memory
, die denselben Wert meldet.
Die Device Memory API bietet Entwicklern vor allem zwei Möglichkeiten:
- Treffen von Laufzeitentscheidungen dazu, welche Ressourcen basierend auf dem zurückgegebenen Wert des Gerätespeichers (z.B. eine Lite-Version einer App für Nutzer von Geräten mit wenig Arbeitsspeicher).
- Melden Sie diesen Wert an einen Analysedienst, um besser zu verstehen, wie Gerätespeicher mit Nutzerverhalten, Conversions oder anderen Messwerten korreliert die für Ihr Unternehmen wichtig sind.
Inhalte basierend auf dem Gerätespeicher dynamisch anpassen
Wenn Sie Ihren eigenen Webserver betreiben und in der Lage sind, die Logik für
stellt Ressourcen bereit, können Sie bedingt auf Anfragen antworten, die den Parameter
Device-Memory
Client Hints Header.
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 Anwendung erstellen.
und auf Anfragen vom Client basierend auf dem
im Header Device-Memory
festgelegt. Diese Versionen müssen keine
anderen Codes, da er schwieriger zu verwalten ist. In den meisten Fällen
"Lite" werden in der Version nur Funktionen ausgeschlossen, die teuer und unkritisch sein könnten.
die User Experience verbessern.
Client Hints-Header verwenden
Fügen Sie entweder das <meta>
-Tag für Client-Hints hinzu, um den Device-Memory
-Header zu aktivieren
in die <head>
Ihres Dokuments ein:
<meta http-equiv="Accept-CH" content="Device-Memory">
Oder fügen Sie „Gerätespeicher“ hinzu. in den Accept-CH
-Antwortheadern Ihres Servers:
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 Header Device-Memory
mit allen Unterressourcen zu senden
-Anfragen für die aktuelle Seite.
Wenn Sie also eine der oben genannten Optionen für Ihr
Wenn ein Nutzer die Website auf einem Gerät mit 0,5 GB RAM aufruft, werden alle Bild-, CSS- und
JavaScript-Anfragen von dieser Seite enthalten den Header Device-Memory
mit
Wert auf „0.5“ setzen, und Ihr Server kann auf solche Anfragen beliebig antworten
anpassbar.
Die folgende Express-Route bedient beispielsweise
"Lite" Version eines Skripts, wenn der Device-Memory
-Header festgelegt ist und sein Wert
weniger als 1, oder es wird eine vollständige falls der Browser den Parameter
Device-Memory
-Header oder der Wert ist 1 oder größer:
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 CDN) können Sie auf Anfragen basierend auf einem HTTP-Header bedingt antworten. In diesen Fällen können die JavaScript API verwenden, um bedingte Anfragen in Ihrem JavaScript-Code zu senden.
Die folgende Logik ähnelt der oben beschriebenen Expressroute, allerdings dynamisch. bestimmt die Skript-URL in der clientseitigen Logik:
// 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();
Dabei werden verschiedene Versionen derselben Komponente basierend auf Gerätefunktionen ist eine gute Strategie. Manchmal ist es sogar noch besser, überhaupt keine Komponente.
In vielen Fällen sind Komponenten reine Verbesserungen. Sie verleihen dem Design aber für die Hauptfunktion der App sind sie nicht erforderlich. In ist es sinnvoll, diese Komponenten gar nicht erst zu laden. Wenn eine Komponente, die die Nutzererfahrung verbessern soll, die App langsam macht oder reagiert nicht, erreicht es sein Ziel nicht.
Bei jeder Entscheidung, die Sie treffen, die sich auf die User Experience auswirkt, deren Auswirkungen zu messen. Es ist auch wichtig, dass Sie ein klares Bild davon haben, die aktuelle Leistung der App erzielt.
Zusammenhänge zwischen dem Gerätespeicher und dem Nutzerverhalten für den aktuellen Version Ihrer App gibt Aufschluss darüber, welche Maßnahmen Sie ergreifen müssen. Ihnen eine Grundlage liefern, an der Sie den Erfolg zukünftiger Änderungen messen können.
Gerätespeicher mit Analysen verfolgen
Die Device Memory API ist neu und wird von den meisten Analyseanbietern nicht verfolgt ist standardmäßig aktiviert. Glücklicherweise bieten die meisten Analyseanbieter die Möglichkeit, benutzerdefinierte (Google Analytics verfügt beispielsweise über die Funktion Benutzerdefinierte Dimensionen), Hiermit können Sie den Gerätespeicher für die Geräte.
Benutzerdefinierte Dimension für den Gerätespeicher wird verwendet
Die Verwendung benutzerdefinierter Dimensionen in Google Analytics erfolgt in zwei Schritten.
- Richten Sie die benutzerdefinierte Dimension in Google Analytics ein.
- Aktualisieren Sie Ihren Tracking-Code auf
set
. Wert des Gerätespeichers für die benutzerdefinierte Dimension, die Sie gerade erstellt haben.
Geben Sie der benutzerdefinierten Dimension den Namen „Gerätespeicher“. und wählen Sie den Bereich „Sitzung“ da sich der Wert während der Browsersitzung eines Nutzers nicht ändert:
<ph type="x-smartling-placeholder">![Benutzerdefinierte Dimensionen zum Gerätespeicher in Google Analytics erstellen](https://developer.chrome.com/static/blog/device-memory/image/creating-device-memory-c-109ba2212b2a9.png?authuser=6&hl=de)
Aktualisieren Sie als Nächstes Ihren Tracking-Code. Hier ist ein Beispiel, wie das aussehen könnte. Bei Browsern, die die Device Memory API nicht unterstützen, lautet „(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');
Berichte zum Gerätespeicher erstellen
Wenn die Größe des Gerätespeichers
set
im
Tracker-Objekt enthält, enthalten alle Daten, die Sie an Google Analytics senden, diesen Wert.
So können Sie die gewünschten Messwerte nach Gerät aufschlüsseln (z.B. Seitenladezeit oder Zielerreichungsrate).
um zu sehen, ob es Korrelationen gibt.
Da es sich bei dem Gerätespeicher um eine benutzerdefinierte und nicht um eine integrierte Dimension handelt, ist er in Standardberichten nicht enthalten. Um auf diese Daten zuzugreifen, müssen Sie Erstellen Sie einen benutzerdefinierten Bericht. Beispielsweise kann die Konfiguration für einen benutzerdefinierten Bericht, der Ladezeiten nach Gerätespeicher etwa so aussehen:
<ph type="x-smartling-placeholder">![Benutzerdefinierten Bericht zum Gerätespeicher in Google Analytics erstellen](https://developer.chrome.com/static/blog/device-memory/image/creating-device-memory-c-c446b651392e8.png?authuser=6&hl=de)
Und der generierte Bericht könnte so aussehen:
<ph type="x-smartling-placeholder">![Bericht zum Gerätespeicher](https://developer.chrome.com/static/blog/device-memory/image/device-memory-report-6607be7fb3de.png?authuser=6&hl=de)
Wenn Sie Daten zum Gerätespeicher erfassen und eine Referenz für die Ihre Anwendung in allen Bereichen des Speicherspektrums testen, verschiedene Ressourcen für verschiedene Nutzer bereitstellen (mithilfe der den im obigen Abschnitt beschriebenen Verfahren). Anschließend können Sie sich um zu sehen, ob sie sich verbessert haben.
Zusammenfassung
In diesem Beitrag wird beschrieben, wie du deine App mit der Device Memory API anpassen kannst die Fähigkeiten der Nutzenden Geräte und zeigt, wie Sie messen können, wie diese Nutzenden Ihre App erleben.
In diesem Beitrag geht es zwar um die Device Memory API, auf jede API angewendet werden können, die Gerätefunktionen oder Netzwerkbedingungen
Da die Gerätelandschaft immer größer wird, ist es wichtiger denn je, berücksichtigen Webentwickler bei Entscheidungen, die auf die User Experience auswirken.