Mit dem Save-Data-Clienthinweis-Anfrageheader, der in Chrome-, Opera- und Yandex-Browsern verfügbar ist, können Entwickler schlankere und schnellere Anwendungen für Nutzer bereitstellen, die den Datensparmodus in ihrem Browser aktivieren.
Warum leichte Seiten wichtig sind

Schnellere und schlankere Webseiten bieten eine bessere Nutzererfahrung, ermöglichen ein besseres Verständnis und eine bessere Speicherung von Inhalten und führen zu mehr Conversions und Umsatz. Google-Studien haben ergeben, dass „…optimierte Seiten viermal schneller als die ursprünglichen Seiten geladen werden und 80 % weniger Datenvolumen verbrauchen. Und da sie deutlich schneller laden, konnten wir auf diesen Seiten auch eine Steigerung des Traffics um 50% feststellen.“
Und obwohl die Anzahl der 2G-Verbindungen endlich rückläufig ist, war 2G 2015 immer noch die dominierende Netzwerktechnologie. Die Verbreitung und Verfügbarkeit von 3G- und 4G-Netzwerken nimmt rasant zu, aber die damit verbundenen Kosten und Netzwerkbeschränkungen sind für Hunderte Millionen von Nutzern immer noch ein wichtiger Faktor.
Das sind gute Gründe für die Seitenoptimierung.
Es gibt alternative Methoden zur Verbesserung der Websitegeschwindigkeit, die nicht direkt von Entwicklern durchgeführt werden müssen, z. B. Proxybrowser und Transcodierungsdienste. Obwohl solche Dienste sehr beliebt sind, haben sie erhebliche Nachteile: einfache (und manchmal inakzeptable) Bild- und Textkomprimierung, Unfähigkeit, sichere (HTTPS-)Seiten zu verarbeiten, Optimierung nur von Seiten, die über ein Suchergebnis aufgerufen werden, und mehr. Die Beliebtheit dieser Dienste ist ein Indikator dafür, dass Webentwickler die hohe Nutzernachfrage nach schnellen und schlanken Anwendungen und Seiten nicht richtig bedienen. Das Erreichen dieses Ziels ist jedoch ein komplexer und manchmal schwieriger Weg.
Der Save-Data-Anfrageheader
Eine recht einfache Methode besteht darin, den Browser mit dem Anfrageheader Save-Data zu unterstützen. Durch die Identifizierung dieses Headers kann eine Webseite die Nutzererfahrung für Nutzer mit Kosten- und Leistungsbeschränkungen anpassen und optimieren.
In den unten aufgeführten unterstützten Browsern kann der Nutzer einen *Datensparmodus aktivieren, der dem Browser die Berechtigung erteilt, eine Reihe von Optimierungen anzuwenden, um die zum Rendern der Seite erforderliche Datenmenge zu reduzieren. Wenn diese Funktion verfügbar ist oder beworben wird, kann der Browser Bilder mit niedrigerer Auflösung anfordern, das Laden einiger Ressourcen verzögern oder Anfragen über einen Dienst weiterleiten, der andere inhaltsbezogene Optimierungen wie die Komprimierung von Bild- und Textressourcen anwendet.
Unterstützte Browser
- Chrome 49 und höher gibt
Save-Dataan, wenn der Nutzer die Option „Datensparmodus“ auf Mobilgeräten oder die Erweiterung „Datensparmodus“ in Desktopbrowsern aktiviert. - Opera 35+ gibt
Save-Dataan, wenn der Nutzer auf dem Computer den Modus Opera Turbo oder in Android-Browsern die Option Datensparmodus aktiviert. - Yandex 16.2+ bewirbt
Save-Data, wenn der Turbomodus auf Computern oder Mobilgeräten aktiviert ist.
Einstellung Save-Data erkennen
Um zu ermitteln, wann die „Light“-Version für Ihre Nutzer bereitgestellt werden soll, kann Ihre Anwendung den Client-Hinweis-Anfrageheader Save-Data prüfen. Dieser Anfrageheader gibt die Präferenz des Clients für eine reduzierte Datennutzung aufgrund hoher Übertragungskosten, langsamer Verbindungsgeschwindigkeiten oder anderer Gründe an.
Wenn der Nutzer den Datensparmodus in seinem Browser aktiviert, fügt der Browser den Anfrageheader Save-Data an alle ausgehenden Anfragen (sowohl HTTP als auch HTTPS) an.
Derzeit wird im Header nur ein *on-Token (Save-Data: on) angegeben. Dies kann in Zukunft jedoch erweitert werden, um andere Nutzereinstellungen anzugeben.
Außerdem lässt sich in JavaScript erkennen, ob Save-Data aktiviert ist:
if ('connection' in navigator) {
if (navigator.connection.saveData === true) {
// Implement data saving operations here.
}
}
Es ist wichtig, das Vorhandensein des connection-Objekts im navigator-Objekt zu prüfen, da es die Network Information API darstellt, die nur in Chrome, Chrome für Android und Samsung Internet-Browsern implementiert ist. Dort müssen Sie nur prüfen, ob navigator.connection.saveData gleich true ist, und können alle datensparenden Vorgänge in dieser Bedingung implementieren.
Wenn Ihre Anwendung einen Service Worker verwendet, kann sie die Anfrageheader prüfen und relevante Logik anwenden, um das Nutzererlebnis zu optimieren.
Alternativ kann der Server nach den beworbenen Einstellungen im Anfrageheader Save-Data suchen und eine alternative Antwort zurückgeben, z. B. ein anderes Markup oder kleinere Bilder und Videos.
Implementierungstipps und Best Practices
- Wenn Sie
Save-Dataverwenden, stellen Sie einige UI-Elemente bereit, die dies unterstützen und Nutzern ermöglichen, einfach zwischen den verschiedenen Modi zu wechseln. Beispiel:- Nutzer darüber informieren, dass
Save-Dataunterstützt wird, und sie dazu auffordern, die Funktion zu verwenden. - Nutzer sollten den Modus mithilfe geeigneter Aufforderungen und intuitiver Ein-/Aus-Schaltflächen oder Kästchen auswählen können.
- Wenn der Datensparmodus ausgewählt ist, weisen Sie darauf hin und bieten Sie eine einfache und offensichtliche Möglichkeit, ihn zu deaktivieren und bei Bedarf zur vollständigen Nutzung zurückzukehren.
- Nutzer darüber informieren, dass
- Leichte Anwendungen sind nicht weniger leistungsfähig. Wichtige Funktionen oder Daten werden nicht ausgelassen, sondern die Kosten und die Nutzerfreundlichkeit werden stärker berücksichtigt. Beispiel:
- Eine Fotogalerie-App kann Vorschauen mit niedrigerer Auflösung bereitstellen oder einen weniger codeintensiven Karussellmechanismus verwenden.
- Eine Suchanwendung kann jeweils weniger Ergebnisse zurückgeben, die Anzahl der mediaintensiven Ergebnisse begrenzen oder die Anzahl der zum Rendern der Seite erforderlichen Abhängigkeiten reduzieren.
- Auf einer nachrichtenausgerichteten Website werden möglicherweise weniger Artikel angezeigt, weniger beliebte Kategorien ausgelassen oder kleinere Medienvorschauen bereitgestellt.
- Stellen Sie Serverlogik bereit, um den
Save-Data-Anfrageheader zu prüfen, und erwägen Sie, eine alternative, schlankere Seitenantwort bereitzustellen, wenn er aktiviert ist. Reduzieren Sie beispielsweise die Anzahl der erforderlichen Ressourcen und Abhängigkeiten und wenden Sie eine aggressivere Ressourcenkomprimierung an.- Wenn Sie eine alternative Antwort basierend auf dem
Save-Data-Header bereitstellen, denken Sie daran, ihn der Vary-Liste (Vary: Save-Data) hinzuzufügen, um Upstream-Caches mitzuteilen, dass sie diese Version nur dann im Cache speichern und bereitstellen sollen, wenn derSave-Data-Anfrageheader vorhanden ist. Weitere Informationen finden Sie in den Best Practices für die Interaktion mit Caches.
- Wenn Sie eine alternative Antwort basierend auf dem
- Wenn Sie einen Service Worker verwenden, kann Ihre Anwendung erkennen, wann die Option zum Speichern von Daten aktiviert ist. Dazu muss sie prüfen, ob der Anfrageheader
Save-Datavorhanden ist oder ob der Wert der Eigenschaftnavigator.connection.saveDatafestgelegt ist. Wenn diese Option aktiviert ist, sollten Sie prüfen, ob Sie die Anfrage so umformulieren können, dass weniger Byte abgerufen werden, oder ob Sie eine bereits abgerufene Antwort verwenden können. - Erwägen Sie,
Save-Datamit anderen Signalen zu ergänzen, z. B. Informationen zum Verbindungstyp und zur Technologie des Nutzers (siehe NetInfo API). So können Sie beispielsweise die optimierte Version für alle Nutzer mit einer 2G-Verbindung bereitstellen, auch wennSave-Datanicht aktiviert ist. Umgekehrt bedeutet eine „schnelle“ 4G-Verbindung nicht, dass der Nutzer kein Interesse daran hat, Daten zu sparen, z. B. beim Roaming. Außerdem können Sie die Präsenz vonSave-Datamit dem Client-HinweisDevice-Memoryoptimieren, um die Anpassung an Nutzer auf Geräten mit begrenztem Arbeitsspeicher zu verbessern. Der Arbeitsspeicher des Nutzergeräts wird auch im Client-Hinweisnavigator.deviceMemorybeworben.
Rezepte
Die Möglichkeiten von Save-Data sind nur durch Ihre Fantasie begrenzt. Damit Sie sich ein Bild davon machen können, was möglich ist, sehen wir uns einige Anwendungsfälle an. Vielleicht fallen Ihnen beim Lesen noch weitere Anwendungsfälle ein. Probieren Sie einfach aus, was möglich ist.
Nach Save-Data im serverseitigen Code suchen
Der Status Save-Data kann zwar in JavaScript über die Eigenschaft navigator.connection.saveData erkannt werden, aber die serverseitige Erkennung ist manchmal vorzuziehen. In einigen Fällen kann die Ausführung von JavaScript fehlschlagen. Außerdem ist die serverseitige Erkennung die einzige Möglichkeit, Markup zu ändern, bevor es an den Client gesendet wird. Das ist bei einigen der nützlichsten Anwendungsfälle von Save-Data erforderlich.
Die spezifische Syntax zum Erkennen des Save-Data-Headers im serverseitigen Code hängt von der verwendeten Sprache ab. Das Grundprinzip sollte jedoch für jedes Anwendungs-Backend gleich sein. In PHP werden Anfrageheader beispielsweise im $_SERVER-Superglobal-Array an Indexen gespeichert, die mit HTTP_ beginnen. Das bedeutet, dass Sie den Save-Data-Header erkennen können, indem Sie das Vorhandensein und den Wert der $_SERVER["HTTP_SAVE_DATA"]-Variable so prüfen:
// false by default.
$saveData = false;
// Check if the `Save-Data` header exists and is set to a value of "on".
if (isset($_SERVER["HTTP_SAVE_DATA"]) && strtolower($_SERVER["HTTP_SAVE_DATA"]) === "on") {
// `Save-Data` detected!
$saveData = true;
}
Wenn Sie diese Prüfung vor dem Senden von Markup an den Client platzieren, enthält die Variable $saveData den Status Save-Data und ist überall auf der Seite verfügbar. Nachdem wir uns diesen Mechanismus angesehen haben, wollen wir uns einige Beispiele dafür ansehen, wie wir ihn verwenden können, um die Menge der Daten zu begrenzen, die wir an den Nutzer senden.
Bilder mit niedriger Auflösung für Bildschirme mit hoher Auflösung bereitstellen
Ein häufiger Anwendungsfall für Bilder im Web ist die Bereitstellung von Bildersets mit zwei Bildern: Ein Bild für „normale“ Bildschirme (1x) und ein anderes Bild, das doppelt so groß ist (2x), für Bildschirme mit hoher Auflösung (z.B. Retina-Display). Diese Klasse von hochauflösenden Bildschirmen ist nicht unbedingt auf High-End-Geräte beschränkt und wird immer häufiger. Wenn eine schlankere Anwendung bevorzugt wird, ist es möglicherweise ratsam, Bilder mit niedrigerer Auflösung (1x) an diese Bildschirme zu senden, anstatt größere (2x) Varianten. Wenn der Save-Data-Header vorhanden ist, ändern wir dazu einfach das Markup, das wir an den Client senden:
if ($saveData === true) {
// Send a low-resolution version of the image for clients specifying `Save-Data`.
?><img src="butterfly-1x.jpg" alt="A butterfly perched on a flower."><?php
}
else {
// Send the usual assets for everyone else.
?><img src="butterfly-1x.jpg" srcset="butterfly-2x.jpg 2x, butterfly-1x.jpg 1x" alt="A butterfly perched on a flower."><?php
}
Dieses Beispiel zeigt, wie wenig Aufwand es erfordert, auf die Bitte einer Person einzugehen, ihr weniger Daten zu senden. Wenn Sie die Markierung nicht im Backend ändern möchten, können Sie dasselbe Ergebnis auch mit einem URL-Rewrite-Modul wie mod_rewrite von Apache erzielen. Hier finden Sie Beispiele, wie Sie dies mit relativ wenig Konfiguration erreichen können.
Sie können dieses Konzept auch auf CSS-background-image-Eigenschaften ausweiten, indem Sie dem <html>-Element einfach eine Klasse hinzufügen:
<html class="<?php if ($saveData === true): ?>save-data<?php endif; ?>">
Hier können Sie die Klasse save-data für das Element <html> in Ihrem CSS-Code festlegen, um die Art der Bildbereitstellung zu ändern. Sie können wie im obigen HTML-Beispiel Hintergrundbilder mit niedriger Auflösung an Bildschirme mit hoher Auflösung senden oder bestimmte Ressourcen ganz weglassen.
Nicht benötigte Bilder weglassen
Einige Bildinhalte im Web sind einfach nicht wichtig. Solche Bilder können zwar eine schöne Ergänzung für Inhalte sein, sind aber für Nutzer, die ihr Datenvolumen optimal nutzen möchten, möglicherweise nicht wünschenswert. Im vielleicht einfachsten Anwendungsfall von Save-Data können wir den PHP-Erkennungscode von oben verwenden und nicht benötigtes Bild-Markup ganz weglassen:
<p>This paragraph is essential content. The image below may be humorous, but it's not critical to the content.</p>
<?php
if ($saveData === false) {
// Only send this image if `Save-Data` hasn't been detected.
?><img src="meme.jpg" alt="One does not simply consume data."><?php
}
Diese Technik kann durchaus eine deutliche Wirkung haben, wie Sie in der Abbildung unten sehen:
Das Weglassen von Bildern ist natürlich nicht die einzige Möglichkeit. Sie können auch auf Save-Data reagieren, um das Senden anderer nicht kritischer Ressourcen wie bestimmter Schriftarten zu vermeiden.
Nicht benötigte Webschriftarten weglassen
Webfonts machen in der Regel nicht annähernd so viel von der Gesamt-Nutzlast einer Seite aus wie Bilder, sind aber dennoch sehr beliebt. Sie verbrauchen auch keine unbedeutende Menge an Daten. Außerdem ist die Art und Weise, wie Browser Schriftarten abrufen und rendern, komplizierter als Sie vielleicht denken. Konzepte wie FOIT, FOUT und Browserheuristiken machen das Rendern zu einem differenzierten Vorgang.
Es ist also sinnvoll, nicht unbedingt erforderliche Webfonts für Nutzer, die eine schlankere Nutzererfahrung wünschen, wegzulassen. Save-Data macht das Ganze relativ einfach.
Angenommen, Sie haben auf Ihrer Website die Schriftart Fira Sans von Google Fonts eingebunden. Fira Sans ist eine ausgezeichnete Schriftart für den Fließtext, aber vielleicht nicht so wichtig für Nutzer, die Daten sparen möchten. Wenn wir dem <html>-Element die Klasse save-data hinzufügen, wenn der Save-Data-Header vorhanden ist, können wir Stile schreiben, die zuerst den nicht essenziellen Schriftfont aufrufen, ihn dann aber deaktivieren, wenn der Save-Data-Header vorhanden ist:
/* Opt into web fonts by default. */
p,
li {
font-family: 'Fira Sans', 'Arial', sans-serif;
}
/* Opt out of web fonts if the `save-Data` class is present. */
.save-data p,
.save-data li {
font-family: 'Arial', sans-serif;
}
Bei dieser Methode können Sie das <link>-Snippet von Google Fonts beibehalten, da der Browser CSS-Ressourcen (einschließlich Webfonts) spekulativ lädt, indem er zuerst Stile auf das DOM anwendet und dann prüft, ob HTML-Elemente Ressourcen im Stylesheet aufrufen. Wenn jemand mit Save-Data vorbeikommt, wird Fira Sans nie geladen, da sie vom formatierten DOM nie aufgerufen wird. Stattdessen wird Arial verwendet. Sie ist nicht so schön wie Fira Sans, aber für Nutzer, die ihren Datentarif nicht überziehen möchten, ist sie möglicherweise die bessere Wahl.
Zusammenfassung
Der Header Save-Data ist nicht sehr differenziert. Er ist entweder aktiviert oder deaktiviert. Die Anwendung muss unabhängig vom Grund für die Einstellung für eine angemessene Nutzererfahrung sorgen.
Einige Nutzer erlauben den Datensparmodus möglicherweise nicht, wenn sie befürchten, dass App-Inhalte oder ‑Funktionen verloren gehen, selbst wenn die Verbindung schlecht ist. Umgekehrt aktivieren einige Nutzer die Funktion möglicherweise grundsätzlich, um Seiten so klein und einfach wie möglich zu halten, auch wenn die Verbindung gut ist. Am besten gehen Sie in Ihrer App davon aus, dass der Nutzer die vollständige und uneingeschränkte Nutzung wünscht, bis Sie durch eine explizite Nutzeraktion einen klaren Hinweis erhalten, dass dies nicht der Fall ist.
Als Websiteinhaber und Webentwickler sollten wir die Verantwortung für die Verwaltung unserer Inhalte übernehmen, um die Nutzerfreundlichkeit für Nutzer mit begrenztem Datenvolumen und Budget zu verbessern.
Weitere Informationen zu Save-Data und hervorragende praktische Beispiele finden Sie unter Help Your Users Save Data.