Diese Seite wurde von der Cloud Translation API übersetzt.

Device Memory API

Philip Walton

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> Benutzerdefinierte Dimensionen zum Gerätespeicher in Google Analytics erstellen

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> Benutzerdefinierten Bericht zum Gerätespeicher in Google Analytics erstellen

Und der generierte Bericht könnte so aussehen:

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.