Mit Client-Hinweisen an Nutzer anpassen

Jeremy Wagner

Es kann schwierig sein, Websites zu entwickeln, die überall schnell geladen werden. Die Vielzahl an Gerätefunktionen und die Qualität der Netzwerke, mit denen sie verbunden sind, können die Aufgabe unüberwindbar erscheinen lassen. Wir können zwar Browserfunktionen nutzen, um die Ladeleistung zu verbessern, aber wie können wir herausfinden, was das Gerät des Nutzers leisten kann oder wie gut seine Netzwerkverbindung ist? Die Lösung sind Client-Hints.

Client Hints sind eine Reihe von HTTP-Anfrageheadern, die uns Einblick in diese Aspekte des Geräts des Nutzers und des Netzwerks geben, mit dem er verbunden ist. Durch den Zugriff auf diese Informationen auf der Serverseite können wir ändern, wie wir Inhalte basierend auf Geräte- und/oder Netzwerkbedingungen bereitstellen. So können wir inklusivere Nutzererlebnisse schaffen.

Inhaltsaushandlung

Client-Hinweise sind eine weitere Methode der Inhaltsvereinbarung. Dabei werden Inhaltsantworten basierend auf Browser-Anfrageheadern geändert.

Ein Beispiel für die Inhaltsaushandlung ist der Anfrageheader Accept. Sie beschreibt, welche Inhaltstypen der Browser versteht. Der Server kann diese Informationen verwenden, um die Antwort zu verhandeln. Bei Bildanfragen ist der Inhalt des Accept-Headers von Chrome:

Accept: image/webp,image/apng,image/*,*/*;q=0.8

Alle Browser unterstützen Bildformate wie JPEG, PNG und GIF. In diesem Fall wird mit „Accept“ jedoch angegeben, dass der Browser auch WebP und APNG unterstützt. Anhand dieser Informationen können wir die besten Bildtypen für jeden Browser aushandeln:

<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;

// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">

Wie Accept sind Client-Hinweise eine weitere Möglichkeit, Inhalte auszuhandeln, jedoch im Kontext von Gerätefunktionen und Netzwerkbedingungen. Mit Client-Hinweisen können wir serverseitige Leistungsentscheidungen auf Grundlage der individuellen Nutzererfahrung treffen. So können wir beispielsweise entscheiden, ob nicht kritische Ressourcen für Nutzer mit schlechten Netzwerkbedingungen bereitgestellt werden sollen. In diesem Leitfaden werden alle verfügbaren Hinweise und einige Möglichkeiten beschrieben, wie Sie sie verwenden können, um die Bereitstellung von Inhalten für Nutzer zu optimieren.

Aktivieren

Im Gegensatz zum Accept-Header werden Client-Hinweise nicht einfach so gesendet (mit Ausnahme von Save-Data, das wir später besprechen). Um die Anzahl der Anfrageheader so gering wie möglich zu halten, müssen Sie festlegen, welche Client-Hinweise Sie erhalten möchten. Senden Sie dazu einen Accept-CH-Header, wenn ein Nutzer eine Ressource anfordert:

Accept-CH: Viewport-Width, Downlink

Der Wert für Accept-CH ist eine durch Kommas getrennte Liste der angeforderten Hinweise, die die Website verwendet, um die Ergebnisse für nachfolgende Ressourcenanfragen zu ermitteln. Wenn der Client diesen Header liest, wird ihm mitgeteilt, dass diese Website die Client-Hinweise Viewport-Width und Downlink benötigt. Die spezifischen Hinweise selbst sind nicht wichtig. Dazu kommen wir gleich.

Sie können diese Opt-in-Header in jeder Back-End-Sprache festlegen. Dazu könnte beispielsweise die header-Funktion von PHP verwendet werden. Sie können diese Opt-in-Header auch mit dem Attribut http-equiv in einem <meta>-Tag festlegen:

<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />

Alle Client-Hints.

Client-Hinweise beschreiben entweder das Gerät, das Ihre Nutzer verwenden, oder das Netzwerk, über das sie auf Ihre Website zugreifen. Sehen wir uns kurz alle verfügbaren Hinweise an.

Gerätehinweise

Einige Client-Hinweise beschreiben Merkmale des Geräts des Nutzers, in der Regel Bildschirmmerkmale. Einige können Ihnen helfen, die optimale Media-Ressource für den Bildschirm eines bestimmten Nutzers auszuwählen, aber nicht alle sind unbedingt mediabezogen.

Bevor wir uns diese Liste ansehen, sollten wir uns mit einigen wichtigen Begriffen vertraut machen, die zur Beschreibung von Bildschirmen und Media-Auflösung verwendet werden:

Integrierte Größe:Die tatsächlichen Abmessungen einer Media-Ressource. Wenn Sie beispielsweise ein Bild in Photoshop öffnen, werden im Dialogfeld „Bildgröße“ die Abmessungen der natürlichen Größe angezeigt.

Dichteberichtigte intrinsische Größe:Die Abmessungen einer Media-Ressource nach der Korrektur für die Pixeldichte. Sie ergibt sich aus der natürlichen Größe des Bildes geteilt durch das Gerätepixelverhältnis. Sehen wir uns zum Beispiel dieses Markup an:

<img
  src="whats-up-1x.png"
  srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
  alt="I'm that image you wanted."
/>

Angenommen, die intrinsische Größe des 1x-Bildes ist in diesem Fall 320 × 240 und die des 2x-Bildes 640 × 480. Wenn dieses Markup von einem Client geparst wird, der auf einem Gerät mit einem Geräte-Pixelverhältnis von 2 (z.B. einem Retina-Display) installiert ist, wird das Bild 2x angefordert. Die dichteberichtigte intrinsische Größe des Bildes 2x ist 320 × 240, da 640 × 480 geteilt durch 2 gleich 320 × 240 ist.

Äußere Größe:Die Größe einer Media-Ressource, nachdem CSS und andere Layoutfaktoren (z. B. die Attribute width und height) darauf angewendet wurden. Angenommen, Sie haben ein <img>-Element, das ein Bild mit einer dichteberichtigten intrinsischen Größe von 320 × 240 lädt. Außerdem sind die CSS-Eigenschaften width und height mit den Werten 256px bzw. 192px darauf angewendet. In diesem Beispiel wird die äußere Größe des <img>-Elements zu 256 × 192.

Nachdem wir einige Begriffe geklärt haben, sehen wir uns die Liste der gerätespezifischen Client-Hinweise an, die Ihnen zur Verfügung stehen.

Breite des Darstellungsbereichs

Viewport-Width ist die Breite des Darstellungsbereichs des Nutzers in CSS-Pixeln:

Viewport-Width: 320

Dieser Hinweis kann mit anderen bildschirmbezogenen Hinweisen verwendet werden, um unterschiedliche Darstellungen (z.B. Zuschnitte) eines Bildes zu liefern, die für bestimmte Bildschirmgrößen (z.B. Art Direction) optimiert sind, oder um Ressourcen auszulassen, die für die aktuelle Bildschirmbreite nicht erforderlich sind.

DPR

DPR (kurz für „Device Pixel Ratio“) gibt das Verhältnis von physischen Pixeln zu CSS-Pixeln des Bildschirms des Nutzers an:

DPR: 2

Dieser Hinweis ist nützlich, wenn Sie Bildquellen auswählen, die der Pixeldichte eines Bildschirms entsprechen (wie x-Deskriptoren im srcset-Attribut).

Breite

Der Hinweis Width wird bei Anfragen für Bildressourcen angezeigt, die von <img>- oder <source>-Tags mit dem sizes-Attribut ausgelöst werden. sizes teilt dem Browser die extrinsische Größe der Ressource mit. Width verwendet diese extrinsische Größe, um ein Bild mit einer intrinsischen Größe anzufordern, die für das aktuelle Layout optimal ist.

Angenommen, ein Nutzer ruft eine Seite mit einem 320 CSS-Pixel breiten Bildschirm und einem DPR von 2 auf. Das Gerät lädt ein Dokument mit einem <img>-Element, das den sizes-Attributwert 85vw enthält (d.h. 85% der Darstellungsbereichsbreite für alle Bildschirmgrößen). Wenn das Width-Hinweis aktiviert wurde, sendet der Client diesen Width-Hinweis mit der Anfrage für die src des <img> an den Server:

Width: 544

In diesem Fall teilt der Client dem Server mit, dass eine optimale intrinsische Breite für das angeforderte Bild 85% der Viewportbreite (272 Pixel) multipliziert mit dem DPR des Bildschirms (2) wäre, was 544 Pixel entspricht.

Dieser Hinweis ist besonders hilfreich, da er nicht nur die dichteberichtigte Breite des Bildschirms berücksichtigt, sondern diese wichtige Information auch mit der extrinsischen Größe des Bildes im Layout in Einklang bringt. So können Server Bildantworten aushandeln, die sowohl für den Bildschirm als auch für das Layout optimal sind.

Content-DPR

Bildschirme haben ein Geräte-Pixelverhältnis. Das gilt auch für Ressourcen. In den einfachsten Anwendungsfällen für die Ressourcenauswahl können die Pixelverhältnisse zwischen Geräten und Ressourcen gleich sein. Aber! Wenn sowohl die Header DPR als auch Width verwendet werden, kann die extrinsische Größe einer Ressource zu Szenarien führen, in denen sich die beiden unterscheiden. Hier kommt der Hinweis Content-DPR ins Spiel.

Im Gegensatz zu anderen Client-Hinweisen ist Content-DPR kein Anfrage-Header, der von Servern verwendet werden kann, sondern ein Antwort-Header, den Server senden müssen, wenn DPR- und Width-Hinweise zum Auswählen einer Ressource verwendet werden. Der Wert von Content-DPR sollte das Ergebnis dieser Gleichung sein:

Content-DPR = [Ausgewählte Bildressourcengröße] / ([Width] / [DPR])

Wenn ein Content-DPR-Anfrageheader gesendet wird, weiß der Browser, wie das angegebene Bild für das Gerätepixelverhältnis und das Layout des Bildschirms skaliert werden muss. Andernfalls werden Bilder möglicherweise nicht richtig skaliert.

Gerätespeicher

Device-Memory ist technisch gesehen Teil der Device Memory API und gibt die ungefähre Menge an Arbeitsspeicher an, die das aktuelle Gerät in GiB hat:

Device-Memory: 2

Ein möglicher Anwendungsfall für diesen Hinweis wäre, die Menge an JavaScript zu reduzieren, die an Browser auf Geräten mit begrenztem Arbeitsspeicher gesendet wird, da JavaScript der ressourcenintensivste Inhaltstyp ist, den Browser normalerweise laden. Alternativ können Sie Bilder mit niedrigerer DPR senden, da für die Dekodierung weniger Arbeitsspeicher benötigt wird.

Netzwerk-Hinweise

Die Network Information API bietet eine weitere Kategorie von Client-Hinweisen, die die Leistung der Netzwerkverbindung des Nutzers beschreiben. Meiner Meinung nach sind diese Hinweise am nützlichsten. Damit können wir die Nutzerfreundlichkeit anpassen, indem wir die Art und Weise ändern, wie wir Ressourcen über langsame Verbindungen an Clients senden.

RTT

Der Hinweis RTT gibt die ungefähre Umlaufzeit in Millisekunden auf der Anwendungsebene an. Der RTT-Hinweis umfasst im Gegensatz zur RTT der Transportschicht die Serverbearbeitungszeit.

RTT: 125

Dieser Hinweis ist nützlich, da die Latenz eine wichtige Rolle für die Ladeleistung spielt. Mit dem RTT-Hinweis können wir Entscheidungen auf Grundlage der Reaktionsfähigkeit des Netzwerks treffen, was dazu beitragen kann, die Bereitstellung einer gesamten Anwendung zu beschleunigen (z.B. durch das Auslassen einiger Anfragen).

Downlink

Die Latenz ist zwar wichtig für die Ladeleistung, aber auch die Bandbreite spielt eine Rolle. Der Downlink-Hinweis in Megabit pro Sekunde (Mbit/s) gibt die ungefähre Downstream-Geschwindigkeit der Verbindung des Nutzers an:

Downlink: 2.5

In Verbindung mit RTT kann Downlink nützlich sein, um die Art und Weise zu ändern, wie Inhalte basierend auf der Qualität einer Netzwerkverbindung an Nutzer gesendet werden.

ECT

Der Hinweis ECT steht für Effektiver Verbindungstyp. Der Wert ist einer aus einer aufgezählten Liste von Verbindungstypen, die jeweils eine Verbindung innerhalb bestimmter Bereiche von RTT- und Downlink-Werten beschreiben.

Dieser Header gibt nicht an, welcher tatsächliche Verbindungstyp verwendet wird. Es wird beispielsweise nicht angegeben, ob Ihr Gateway ein Mobilfunkmast oder ein WLAN-Zugangspunkt ist. Stattdessen werden die Latenz und Bandbreite der aktuellen Verbindung analysiert und es wird ermittelt, welchem Netzwerkprofil sie am ehesten entspricht. Wenn Sie sich beispielsweise über WLAN mit einem langsamen Netzwerk verbinden, kann ECT mit dem Wert 2g gefüllt werden. Das ist die beste Annäherung an die effektive Verbindung:

ECT: 2g

Gültige Werte für ECT sind 4g, 3g, 2g und slow-2g. Dieser Hinweis kann als Ausgangspunkt für die Bewertung der Verbindungsqualität verwendet und anschließend mit den Hinweisen RTT und Downlink verfeinert werden.

Save-Data

Save-Data ist weniger ein Hinweis auf die Netzwerkbedingungen als eine Nutzereinstellung, die besagt, dass Seiten weniger Daten senden sollen.

Ich würde Save-Data lieber als Netzwerk-Hinweis einstufen, da viele der Dinge, die Sie damit tun würden, anderen Netzwerk-Hinweisen ähneln. Nutzer aktivieren die Funktion möglicherweise auch in Umgebungen mit hoher Latenz und geringer Bandbreite. Wenn dieser Hinweis angezeigt wird, sieht er immer so aus:

Save-Data: on

Wir bei Google haben darüber gesprochen, was Sie mit Save-Data tun können. Die Auswirkungen auf die Leistung können erheblich sein. Es ist ein Signal, dass Nutzer Sie buchstäblich darum bitten, ihnen weniger zu senden. Wenn Sie auf dieses Signal reagieren, werden die Nutzer es Ihnen danken.

Alles miteinander verbinden

Was Sie mit Client-Hinweisen tun, hängt von Ihnen ab. Da sie so viele Informationen enthalten, haben Sie viele Möglichkeiten. Um einige Ideen zu entwickeln, sehen wir uns an, was Client-Hinweise für Sconnie Timber, ein fiktives Holzunternehmen im ländlichen Upper Midwest, tun können. Wie so oft in abgelegenen Gebieten können Netzwerkverbindungen instabil sein. Hier kann eine Technologie wie Client-Hinweise Nutzern wirklich helfen.

Responsive Bilder

Alle außer den einfachsten Anwendungsfällen für responsive Bilder können kompliziert werden. Was ist, wenn Sie mehrere Testgruppen und Varianten derselben Bilder für verschiedene Bildschirmgrößen und verschiedene Formate haben? Dieses Markup wird sehr schnell sehr kompliziert. Es ist leicht, Fehler zu machen und wichtige Konzepte (z. B. sizes) zu vergessen oder falsch zu verstehen.

<picture> und srcset sind zweifellos großartige Tools, aber die Entwicklung und Wartung für komplexe Anwendungsfälle kann zeitaufwendig sein. Wir können die Markuperstellung automatisieren, aber das ist auch schwierig, da die Funktionen <picture> und srcset so komplex sind, dass ihre Automatisierung so erfolgen muss, dass die Flexibilität erhalten bleibt, die sie bieten.

Client-Hinweise können diesen Prozess vereinfachen. Die Aushandlung von Bildantworten mit Client-Hinweisen könnte so aussehen:

1. Wählen Sie, falls für Ihren Workflow zutreffend, zuerst eine Bildbearbeitung aus (z.B. künstlerisch gestaltete Bilder), indem Sie auf den Hinweis Viewport-Width klicken.
2. Wählen Sie eine Bildauflösung aus, indem Sie sich die Hinweise Width und DPR ansehen und eine Quelle auswählen, die der Layoutgröße und der Bildschirmdichte des Bildes entspricht (ähnlich wie die Deskriptoren x und w in srcset funktionieren).
3. Wählen Sie das optimale Dateiformat aus, das vom Browser unterstützt wird. Accept hilft uns dabei in den meisten Browsern.

Für meinen fiktiven Kunden aus der Holzbranche habe ich eine einfache Routine zur Auswahl responsiver Bilder in PHP entwickelt, die Client-Hinweise verwendet. Das bedeutet, dass dieses Markup nicht an alle Nutzer gesendet wird, sondern nur an:

<picture>
  <source
    srcset="
      company-photo-256w.webp   256w,
      company-photo-512w.webp   512w,
      company-photo-768w.webp   768w,
      company-photo-1024w.webp 1024w,
      company-photo-1280w.webp 1280w
    "
    type="image/webp"
  />
  <img
    srcset="
      company-photo-256w.jpg   256w,
      company-photo-512w.jpg   512w,
      company-photo-768w.jpg   768w,
      company-photo-1024w.jpg 1024w,
      company-photo-1280w.jpg 1280w
    "
    src="company-photo-256w.jpg"
    sizes="(min-width: 560px) 251px, 88.43vw"
    alt="The Sconnie Timber Staff!"
  />
</picture>

Ich konnte die Liste basierend auf der Unterstützung durch die einzelnen Browser auf Folgendes reduzieren:

<img
  src="/image/sizes:true/company-photo.jpg"
  sizes="(min-width: 560px) 251px, 88.43vw"
  alt="SAY CHEESY PICKLES."
/>

In diesem Beispiel ist die /image-URL ein PHP-Skript, gefolgt von Parametern, die von mod_rewrite umgeschrieben wurden. Es verwendet einen Bilddateinamen und zusätzliche Parameter, damit ein Back-End-Skript unter den gegebenen Bedingungen das beste Bild auswählen kann.

Ihre erste Frage ist wahrscheinlich: „Aber wird damit nicht einfach <picture> und srcset im Backend neu implementiert?“

In gewisser Weise ja, aber mit einem wichtigen Unterschied: Wenn eine Anwendung Client-Hinweise verwendet, um Media-Antworten zu erstellen, lässt sich der Großteil (wenn nicht sogar die gesamte) Arbeit viel einfacher automatisieren. Das kann auch einen Dienst (z. B. ein CDN) umfassen, der dies in Ihrem Namen erledigen kann. Bei HTML-Lösungen muss für jeden Anwendungsfall neues Markup geschrieben werden. Ja, Sie können die Markuperstellung automatisieren. Wenn sich Ihr Design oder Ihre Anforderungen ändern, müssen Sie Ihre Automatisierungsstrategie in Zukunft wahrscheinlich noch einmal überarbeiten.

Mit Client-Hinweisen können Sie mit einem verlustfreien Bild in hoher Auflösung beginnen, das dann dynamisch an jede Kombination aus Bildschirm und Layout angepasst werden kann. Im Gegensatz zu srcset, bei dem Sie eine feste Liste möglicher Bildkandidaten angeben müssen, aus denen der Browser auswählen kann, ist dieser Ansatz flexibler. Bei srcset müssen Sie Browsern eine grobe Auswahl an Varianten anbieten, z. B. 256w, 512w, 768w und 1024w. Mit einer Client-Hints-basierten Lösung können Sie alle Breiten ohne eine riesige Menge an Markup bereitstellen.

Natürlich müssen Sie die Logik für die Bildauswahl nicht selbst schreiben. Cloudinary verwendet Client-Hinweise, um Bildantworten zu erstellen, wenn Sie den Parameter w_auto verwenden. Es wurde beobachtet, dass Nutzer im Median 42% weniger Byte heruntergeladen haben, wenn sie Browser verwendet haben, die Client-Hinweise unterstützen.

Aber Vorsicht! Durch Änderungen in der Desktopversion von Chrome 67 wurde die Unterstützung für clientseitige Hinweise für ursprungsübergreifende Anfragen entfernt. Glücklicherweise wirken sich diese Einschränkungen nicht auf die mobilen Versionen von Chrome aus. Sie werden für alle Plattformen aufgehoben, sobald die Arbeiten an der Funktionsrichtlinie abgeschlossen sind.

Nutzern in langsamen Netzwerken helfen

Adaptive Leistung bedeutet, dass wir die Bereitstellung von Ressourcen anpassen können, basierend auf den Informationen, die uns Client-Hinweise zur Verfügung stellen, insbesondere Informationen zum aktuellen Zustand der Netzwerkverbindung des Nutzers.

Bei der Website von Sconnie Timber ergreifen wir Maßnahmen, um die Belastung bei langsamen Netzwerken zu verringern. Dazu werden die Header Save-Data, ECT, RTT und Downlink in unserem Backend-Code untersucht. Anschließend wird ein Netzwerkqualitätsscore generiert, anhand dessen wir entscheiden können, ob wir eingreifen sollten, um die Nutzerfreundlichkeit zu verbessern. Dieser Netzwerk-Score liegt zwischen 0 und 1, wobei 0 die schlechteste und 1 die beste Netzwerkqualität darstellt.

Zuerst prüfen wir, ob Save-Data vorhanden ist. Wenn das der Fall ist, wird der Wert auf 0 gesetzt, da wir davon ausgehen, dass der Nutzer möchte, dass wir alles tun, um die Nutzung zu beschleunigen und zu vereinfachen.

Wenn Save-Data fehlt, gewichten wir die Werte der Hinweise ECT, RTT und Downlink, um einen Wert zu berechnen, der die Qualität der Netzwerkverbindung beschreibt. Der Quellcode für die Generierung von Netzwerkbewertungen ist auf GitHub verfügbar. Wenn wir die netzwerkbezogenen Hinweise in irgendeiner Weise verwenden, können wir die Nutzererfahrung für Nutzer mit langsamen Netzwerken verbessern.

Wenn Websites sich an die Informationen anpassen, die Client-Hinweise liefern, müssen wir nicht nach dem „Alles oder Nichts“-Prinzip vorgehen. Wir können intelligent entscheiden, welche Ressourcen gesendet werden sollen. Wir können unsere Logik zur Auswahl responsiver Bilder so anpassen, dass Bilder in geringerer Qualität für ein bestimmtes Display gesendet werden, um die Ladeleistung bei schlechter Netzwerkqualität zu verbessern.

In diesem Beispiel sehen wir, wie sich Client-Hinweise auf die Leistung von Websites in langsameren Netzwerken auswirken. Unten sehen Sie ein WebPagetest-Wasserfalldiagramm einer Website in einem langsamen Netzwerk, die nicht auf Client-Hinweise reagiert:

Und hier sehen Sie nun ein Wasserfalldiagramm für dieselbe Website mit derselben langsamen Verbindung. Dieses Mal werden jedoch Client-Hinweise verwendet, um nicht kritische Seitenressourcen zu entfernen:

Durch Client-Hinweise konnte die Seitenladezeit von über 45 Sekunden auf weniger als ein Zehntel dieser Zeit reduziert werden. Die Vorteile von Client-Hinweisen in diesem Szenario können nicht genug betont werden. Sie können für Nutzer, die über langsame Netzwerke auf wichtige Informationen zugreifen, eine große Hilfe sein.

Außerdem können Client-Hints verwendet werden, ohne die Nutzerfreundlichkeit für Browser zu beeinträchtigen, die sie nicht unterstützen. Wenn wir beispielsweise die Bereitstellung von Ressourcen mithilfe des Werts des Hinweises ECT anpassen möchten, aber trotzdem die vollständige Nutzererfahrung für nicht unterstützende Browser bereitstellen möchten, können wir so einen Fallback auf einen Standardwert festlegen:

// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";

Dabei steht "4g" für die Netzwerkverbindung mit der höchsten Qualität, die im ECT-Header beschrieben wird. Wenn wir $ect auf "4g" initialisieren, sind Browser, die keine Client-Hinweise unterstützen, nicht betroffen. Aktivieren ist der Hit!

Achte auf die Caches!

Wenn Sie eine Antwort basierend auf einem HTTP-Header ändern, müssen Sie wissen, wie Caches zukünftige Abrufe für diese Ressource verarbeiten. Der Header Vary ist hier unerlässlich, da Cacheeinträge auf den Wert der Anfrageheader abgestimmt werden, die ihm übergeben werden. Wenn Sie eine Antwort auf Grundlage eines bestimmten HTTP-Anfrageheaders ändern, sollten Sie diesen Header fast immer in Vary einfügen, z. B. so:

Vary: DPR, Width

Es gibt jedoch eine wichtige Einschränkung: Sie sollten niemals Vary-Antworten in einem häufig wechselnden Header (z. B. Cookie) im Cache speichern, da diese Ressourcen dann effektiv nicht mehr im Cache gespeichert werden können. Daher sollten Sie sich nicht auf Client-Hinweis-Headern wie RTT oder Downlink verlassen, da diese Verbindungsfaktoren sich häufig ändern können.Vary Wenn Sie Antworten auf diese Header ändern möchten, sollten Sie nur den ECT-Header als Schlüssel verwenden, um Cache-Fehler zu minimieren.

Das gilt natürlich nur, wenn Sie eine Antwort überhaupt im Cache speichern. HTML-Assets werden beispielsweise nicht im Cache gespeichert, wenn ihr Inhalt dynamisch ist, da dies die Nutzerfreundlichkeit bei wiederholten Besuchen beeinträchtigen kann. In solchen Fällen können Sie diese Antworten nach Bedarf ändern und müssen sich nicht um Vary kümmern.

Client-Hints in Service Workern

Die Inhaltsaushandlung ist nicht mehr nur für Server relevant. Da Service Worker als Proxys zwischen Clients und den Servern fungieren, können Sie über JavaScript steuern, wie Ressourcen bereitgestellt werden. Dazu gehören auch Client-Hinweise. Im fetch-Ereignis des Service Workers können Sie mit der Methode request.headers.get des event-Objekts die Anfrage-Header einer Ressource so lesen:

self.addEventListener('fetch', (event) => {
  let dpr = event.request.headers.get('DPR');
  let viewportWidth = event.request.headers.get('Viewport-Width');
  let width = event.request.headers.get('Width');

  event.respondWith(
    (async function () {
      // Do what you will with these hints!
    })(),
  );
});

Alle Client-Hinweis-Header, die Sie aktivieren, können auf diese Weise gelesen werden. Das ist aber nicht die einzige Möglichkeit, diese Informationen zu erhalten. Netzwerkspezifische Hinweise können in diesen entsprechenden JavaScript-Attributen im navigator-Objekt gelesen werden:

Da diese APIs nicht überall verfügbar sind, müssen Sie die Funktion mit dem in-Operator prüfen:

if ('connection' in navigator) {
  // Work with netinfo API properties in JavaScript!
}

Hier können Sie eine ähnliche Logik wie auf dem Server verwenden. Sie benötigen jedoch keinen Server, um Inhalte mit Client-Hinweisen auszuhandeln. Service Worker allein können die Nutzerfreundlichkeit verbessern und die Zuverlässigkeit erhöhen, da sie Inhalte auch dann bereitstellen können, wenn der Nutzer offline ist.

Zusammenfassung

Mit Client-Hinweisen können wir die Nutzerfreundlichkeit auf progressive Weise verbessern. Wir können Media basierend auf den Gerätefunktionen des Nutzers bereitstellen. Dadurch wird die Bereitstellung responsiver Bilder einfacher als bei der Verwendung von <picture> und srcset, insbesondere bei komplexen Anwendungsfällen. So können wir nicht nur Zeit und Aufwand bei der Entwicklung reduzieren, sondern auch Ressourcen, insbesondere Bilder, so optimieren, dass sie besser auf die Bildschirme der Nutzer abgestimmt sind als mit und srcset.

Noch wichtiger ist, dass wir schlechte Netzwerkverbindungen erkennen und die Lücke für Nutzer schließen können, indem wir ändern, was und wie wir senden. Das kann viel dazu beitragen, dass Nutzer mit instabilen Netzwerken leichter auf Websites zugreifen können. In Kombination mit Service Workern können wir unglaublich schnelle Websites erstellen, die auch offline verfügbar sind.

Client-Hinweise sind zwar nur in Chrome und Chromium-basierten Browsern verfügbar, sie lassen sich aber so verwenden, dass Browser, die sie nicht unterstützen, nicht beeinträchtigt werden. Mit Client-Hinweisen können Sie wirklich inklusive und anpassungsfähige Oberflächen erstellen, die die Gerätefunktionen der einzelnen Nutzer und die Netzwerke, mit denen sie verbunden sind, berücksichtigen. Wir hoffen, dass andere Browseranbieter den Wert dieser APIs erkennen und sie implementieren werden.

Ressourcen

• Automatische responsive Bilder mit Client-Hinweisen
• Client-Hints und responsive Bilder – Änderungen in Chrome 67
• Take a (Client) Hint! (Präsentationen)
• Schnelle und schlanke Anwendungen mit Save-Data bereitstellen

Vielen Dank an Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss und Estelle Weyl für ihr wertvolles Feedback und ihre Änderungen an diesem Artikel.