Websites zu entwickeln, die überall schnell sind, kann eine schwierige Angelegenheit sein. Die Fülle an Gerätefunktionen – und die Qualität der Netzwerke, mit denen sie eine Verbindung herstellen – lässt diese Aufgabe als unüberwindbare Aufgabe erscheinen. Obwohl wir Browserfunktionen nutzen können, um die Ladeleistung zu verbessern, woher wissen wir, was das Gerät des Nutzers kann und wie die Qualität der Netzwerkverbindung ist? Die Lösung sind Client-Hinweise!
Client-Hinweise sind eine Reihe von Opt-in-HTTP-Anfrageheadern, die Aufschluss über diese Aspekte des Geräts des Nutzers und des Netzwerks geben, mit dem er verbunden ist. Durch die Nutzung dieser Informationen auf Serverseite können wir ändern, wie Inhalte je nach Geräte- und/oder Netzwerkbedingungen bereitgestellt werden. So können wir inklusivere User Experiences schaffen.
Hier geht es um das Aushandeln von Inhalten
Clienthinweise sind eine weitere Methode der Aushandlung von Inhalten. Dabei werden Inhaltsantworten basierend auf den Anfrageheadern des Browsers geändert.
Ein Beispiel für die Inhaltsverhandlung ist der Anfrageheader Accept. Sie beschreibt, welche Inhaltstypen der Browser versteht, mit denen der Server die Antwort aushandeln kann. Bei Bildanfragen sieht der Accept-Header von Chrome so aus:
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Alle Browser unterstützen Bildformate wie JPEG, PNG und GIF. Annehmen teilt in diesem Fall aber mit, dass der Browser auch WebP und APNG unterstützt. Anhand dieser Informationen können wir die besten Image-Typen 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 bieten auch Clienthinweise eine weitere Möglichkeit zum Verhandeln von Inhalten, allerdings im Kontext von Gerätefunktionen und Netzwerkbedingungen. Mit Clienthinweisen können wir serverseitige Leistungsentscheidungen auf der Grundlage der individuellen Erfahrung eines Nutzers treffen, z. B. zu entscheiden, ob nicht kritische Ressourcen Nutzern mit schlechten Netzwerkbedingungen bereitgestellt werden sollen. In diesem Leitfaden beschreiben wir alle verfügbaren Tipps und wie du sie nutzen kannst, um die Inhaltsübermittlung für Nutzer angenehmer zu gestalten.
Aktivieren
Im Gegensatz zum Header Accept erscheinen Clienthinweise nicht einfach von Zauberhand (mit einer Ausnahme von Save-Data, die wir später besprechen werden). Damit Sie mindestens Anfrageheader erhalten können, müssen Sie festlegen, welche Clienthinweise Sie erhalten möchten. Dazu senden Sie 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 angeforderter Hinweise, anhand derer die Website die Ergebnisse für nachfolgende Ressourcenanfragen ermittelt. Wenn der Client diesen Header liest, wird ihm mitgeteilt, dass die Website die Client-Hinweise Viewport-Width und Downlink benötigt. Sie brauchen sich keine Gedanken über die spezifischen Hinweise selbst zu machen.
Darauf kommen wir gleich zu sprechen.
Sie können diese Opt-in-Header in jeder beliebigen Backend-Sprache festlegen. Beispielsweise kann die header-Funktion von PHP verwendet werden.
Sie können diese Opt-in-Header sogar mit dem Attribut http-equiv in einem <meta>-Tag festlegen:
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
Alle Kundenhinweise!
Clienthinweise beschreiben eines von zwei Dingen: das Gerät, das Ihre Nutzer verwenden, und das Netzwerk, über das sie auf Ihre Website zugreifen. Lassen Sie uns kurz auf alle verfügbaren Hinweise eingehen.
Gerätehinweise
Einige Clienthinweise beschreiben Eigenschaften des Geräts des Nutzers, in der Regel Bildschirmeigenschaften. Einige davon können Ihnen bei der Auswahl der optimalen Medienressource für den Bildschirm eines bestimmten Nutzers helfen, aber nicht alle sind unbedingt medienorientiert.
Bevor wir auf diese Liste eingehen, sollten Sie sich mit einigen wichtigen Begriffen vertraut machen, die zur Beschreibung von Bildschirmen und Medienauflösung verwendet werden:
Intrinsische Größe: die tatsächlichen Abmessungen einer Medienressource. Wenn Sie beispielsweise ein Bild in Photoshop öffnen, beschreiben die im Dialogfeld „Bildgröße“ angezeigten Abmessungen seine systeminterne Größe.
Dichtekorrigierte intrinsische Größe:Die Abmessungen einer Medienressource, nachdem die Pixeldichte korrigiert wurde. Dabei wird die systeminterne Größe durch das Pixel-Verhältnis des Geräts geteilt. Nehmen wir zum Beispiel dieses Markup:
<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 ursprüngliche Größe des 1x-Bildes ist in diesem Fall 320 × 240 und die eigentliche Größe des 2x-Bilds 640 × 480. Wenn dieses Markup von einem Client geparst wird, der auf einem Gerät mit einem Bildschirmgeräte-Pixelverhältnis von 2 (z.B. einem Retina-Bildschirm) installiert ist, wird das 2x-Image angefordert. Die dichtekorrigierte intrinsische Größe des 2x-Bildes beträgt 320 × 240, da 640 × 480 geteilt durch 2 320 × 240 ergibt.
Extrinsische Größe: die Größe einer Medienressource, nachdem CSS und andere Layoutfaktoren (z. B. width- und height-Attribute) darauf angewendet wurden. Angenommen, Sie haben ein <img>-Element, das ein Bild mit einer dichtekorrigierten Größe von 320 × 240 lädt, aber es enthält auch die CSS-Eigenschaften width und height mit den Werten 256px bzw. 192px. In diesem Beispiel beträgt die externe Größe dieses <img>-Elements 256 × 192.
width: 256px; und height: 192px; ein Bild mit der ursprünglichen Größe der Größe 320 × 240 in ein Bild mit einer externen Größe von 256 × 192 umgewandelt.Sehen wir uns nun 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 zusammen mit anderen bildschirmspezifischen Hinweisen verwendet werden, um ein Bild durch verschiedene Bearbeitungen (z.B. zuschneiden) zu optimieren, die für bestimmte Bildschirmgrößen optimal sind (z.B. Bildrichtung), oder um Ressourcen auszulassen, die für die aktuelle Bildschirmbreite nicht erforderlich sind.
DVR
DPR, kurz für Geräte-Pixel-Verhältnis, gibt das Verhältnis von physischen Pixeln zu CSS-Pixeln des Bildschirms des Nutzers an:
DPR: 2
Dieser Hinweis ist hilfreich bei der Auswahl von Bildquellen, die der Pixeldichte eines Bildschirms entsprechen (wie bei x-Deskriptoren im Attribut srcset).
Breite
Der Hinweis Width wird bei Anfragen für Bildressourcen angezeigt, die von <img>- oder <source>-Tags mithilfe des Attributs sizes ausgelöst wurden.
sizes teilt dem Browser mit, wie hoch die externe Größe der Ressource sein wird. Width verwendet diese externe Größe, um ein Bild mit einer systeminternen Größe anzufordern, die für das aktuelle Layout optimal ist.
Angenommen, ein Nutzer fordert eine Seite mit einem 320-CSS-Pixel-Breitbildschirm und einer DPR von 2 an. Das Gerät lädt ein Dokument mit einem <img>-Element, das den sizes-Attributwert 85vw (d.h. 85% des Darstellungsbereichs für alle Bildschirmgrößen. Wenn der Width-Hinweis aktiviert wurde, sendet der Client diesen Width-Hinweis mit der Anfrage für die src der <img> an den Server:
Width: 544
In diesem Fall weist der Client den Server an, dass eine optimale intrinsische Breite für das angeforderte Bild 85% der Breite des Darstellungsbereichs (272 Pixel) multipliziert mit dem DPR des Bildschirms (2) wäre, der 544 Pixeln entspricht.
Dieser Hinweis ist besonders hilfreich, da er nicht nur die dichtekorrigierte Breite des Bildschirms berücksichtigt, sondern diese wichtige Information auch mit der externen Größe des Bildes im Layout abstimmt. So haben Server die Möglichkeit, Bildantworten auszuhandeln, die sowohl für den Bildschirm als auch für das Layout optimal sind.
Content-DPR
Obwohl Sie bereits wissen, dass Bildschirme ein Pixelverhältnis des Geräts haben, haben Ressourcen auch eigene Pixelverhältnisse. Bei den einfachsten Anwendungsfällen für die Ressourcenauswahl können die Pixelverhältnisse zwischen Geräten und Ressourcen gleich sein. In Fällen, in denen sowohl der DPR- als auch der Width-Header vorkommen, kann die externe Größe einer Ressource Szenarien erzeugen, in denen sich die beiden unterscheiden. Hier kommt der Hinweis Content-DPR ins Spiel.
Im Gegensatz zu anderen Clienthinweisen ist Content-DPR kein Anfrageheader, der von Servern verwendet werden soll. Stattdessen muss ein Antwortheader gesendet werden, wenn DPR- und Width-Hinweise zur Auswahl 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 Bild an das Pixelverhältnis des Bildschirms und an das Layout des Bildschirms angepasst werden soll. Andernfalls werden Bilder
möglicherweise nicht richtig skaliert.
Gerätespeicher
Aus technischer Sicht ist Device-Memory ein Teil der Device Memory API und zeigt die ungefähre Speichermenge des aktuellen Geräts in GiB an:
Device-Memory: 2
Ein möglicher Anwendungsfall für diesen Hinweis wäre, die Menge von JavaScript zu reduzieren, die an Browser auf Geräten mit begrenztem Arbeitsspeicher gesendet wird, da JavaScript der ressourcenintensivste Inhaltstyp ist, den Browser normalerweise laden. Sie können auch Bilder mit geringerem DPR senden, da für die Decodierung weniger Speicher benötigt wird.
Netzwerkhinweise
Die Network Information API bietet eine weitere Kategorie von Clienthinweisen, die die Leistung der Netzwerkverbindung des Nutzers beschreiben. Meiner Meinung nach sind dies die nützlichsten Hinweise. Mit ihnen können wir die Nutzung auf Nutzer zuschneiden, indem wir die Art und Weise, wie wir Ressourcen für Kunden mit langsamen Verbindungen bereitstellen, ändern.
RTT
Der Hinweis RTT gibt die ungefähre Umlaufzeit in Millisekunden auf der Anwendungsebene an. Der RTT-Hinweis enthält im Gegensatz zur Transportschicht RTT die Serververarbeitungszeit.
RTT: 125
Dieser Hinweis ist aufgrund der Rolle, die die Latenz bei der Ladeleistung spielt, nützlich.
Mit dem RTT-Hinweis können wir Entscheidungen basierend auf der Reaktionsschnelligkeit des Netzwerks treffen, was dazu beitragen kann, die Bereitstellung einer gesamten Erfahrung zu beschleunigen (z.B. durch Auslassen einiger Anfragen).
Downlink
Während die Latenz für die Ladeleistung wichtig ist, hat sie auch Einfluss. Der Hinweis Downlink in Megabit pro Sekunde (Mbit/s) gibt die ungefähre Downstream-Geschwindigkeit der Nutzerverbindung an:
Downlink: 2.5
Zusammen mit RTT kann Downlink nützlich sein, um zu ändern, wie Inhalte Nutzern basierend auf der Qualität einer Netzwerkverbindung bereitgestellt werden.
ECT
Der Hinweis ECT steht für Effective Connection Type. Der entsprechende Wert gehört zu einer Liste von Verbindungstypen, die jeweils eine Verbindung in angegebenen Bereichen von RTT- und Downlink-Werten beschreiben.
Dieser Header erklärt nicht den tatsächlichen Verbindungstyp – zum Beispiel wird nicht angegeben, ob Ihr Gateway ein Mobilfunkmast oder ein WLAN-Zugangspunkt ist. Stattdessen werden die Latenz und Bandbreite der aktuellen Verbindung analysiert und ermittelt, welchem Netzwerkprofil sie am ähnlichsten ist. Wenn Sie beispielsweise über WLAN eine Verbindung zu einem langsamen Netzwerk herstellen, kann ECT mit dem Wert 2g ausgefüllt werden. Dies ist der nächste Näherungswert der effektiven 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.
Daten speichern
Save-Data ist weniger ein Hinweis zur Beschreibung von Netzwerkbedingungen, sondern eine Nutzerpräferenz, die besagt, dass Seiten weniger Daten senden sollen.
Ich bevorzuge es, Save-Data als Netzwerkhinweis zu klassifizieren, da viele Dinge, die Sie damit tun würden, anderen Netzwerkhinweisen ähneln. Es ist außerdem wahrscheinlich, dass Nutzer ihn in Umgebungen mit hoher Latenz/niedriger Bandbreite aktivieren. Dieser Hinweis, sofern vorhanden, sieht immer so aus:
Save-Data: on
Wir von Google haben gerade über die Möglichkeiten gesprochen, die Save-Data bietet.
Die Auswirkungen auf die Leistung können tiefgreifend sein. Das ist ein Signal dafür, dass Nutzer
im wahrsten Sinne des Wortes darum bitten, ihnen weniger Geld zu senden. Wenn Sie dieses Signal hören und darauf reagieren, werden die Nutzer es zu schätzen wissen.
Konzepte verbinden
Was Sie mit Clienthinweisen tun, hängt von Ihnen ab. Da sie so viele Informationen bieten, haben Sie viele Möglichkeiten. Um ein paar Ideen in die Tat umzusetzen, sehen wir uns an, wie Kundenhinweise für Sconnie Timber, ein fiktives Holzunternehmen im ländlichen Upper Midwest, genutzt werden können. Wie in entfernten Gebieten häufig der Fall, können Netzwerkverbindungen instabil sein. Hier kann eine Technologie wie Client Hints wirklich einen Unterschied machen.
Responsive Bilder
Bis auf die einfachsten Anwendungsfälle für responsive Bilder kann es kompliziert werden. Was ist, wenn Sie mehrere Behandlungen und Varianten derselben Bilder für unterschiedliche Bildschirmgrößen und unterschiedliche Formate haben? Dieses Markup wird sehr sehr schnell kompliziert.
Es kann schnell zu Fehlern kommen und wichtige Konzepte (z. B. sizes) werden leicht vergessen oder falsch verstanden.
<picture> und srcset sind zweifellos geniale Tools, deren Entwicklung und Wartung für komplexe Anwendungsfälle kann jedoch zeitaufwändig sein. Wir können das Generieren von Markups automatisieren. Das ist aber auch schwierig, weil die Funktionen von <picture> und srcset so komplex sind, dass die Automatisierung unter Beibehaltung der Flexibilität erfolgen muss.
Client-Hinweise können dies vereinfachen. Das Aushandeln von Bildantworten mit Kundenhinweisen könnte so aussehen:
- Falls dies auf Ihren Workflow zutrifft, wählen Sie zuerst eine Bildbearbeitung (z. B. künstlerische Bilder) aus. Klicken Sie dazu auf den Hinweis
Viewport-Width. - Wählen Sie eine Bildauflösung aus. Setzen Sie dazu ein Häkchen bei den Hinweisen
WidthundDPRund wählen Sie eine Quelle aus, die zur Layoutgröße und Bildschirmdichte des Bildes passt (ähnlich wie bei den Deskriptorenxundwinsrcset). - Wähle das optimale Dateiformat aus, das vom Browser unterstützt wird. Mit
Acceptist das in den meisten Browsern möglich.
Bezüglich des fiktiven Kunden eines Holzunternehmens besorgte ich eine naive responsive Bildauswahlroutine in PHP mit Client-Hinweisen. Anstatt dieses Markup an alle Nutzer zu senden, bedeutete dies:
<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>
Aufgrund der individuellen Browserunterstützung konnten wir die Anzeige auf folgende 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 URL /image ein PHP-Skript gefolgt von Parametern, die von mod_rewrite umgeschrieben wurden. Es verwendet einen Bilddateinamen und zusätzliche Parameter, damit ein Backend-Skript das beste Bild unter den gegebenen Bedingungen auswählen kann.
Ich denke, „Wird dadurch nicht nur <picture> und srcset im Backend neu implementiert?“ ist Ihre erste Frage.
Ja, mit einer wichtigen Unterscheidung: Wenn eine Anwendung Clienthinweise verwendet, um Medienantworten zu erstellen, ist der Großteil (wenn nicht alle) der Arbeit viel einfacher zu automatisieren. Dazu kann ein Dienst (z. B. ein CDN) gehören, der dies für Sie erledigen kann. Im Gegensatz zu HTML-Lösungen muss für jeden Anwendungsfall neues Markup geschrieben werden. Natürlich können Sie die Markup-Generierung automatisieren. Wenn sich Ihr Design oder Ihre Anforderungen jedoch ändern, ist es sehr wahrscheinlich, dass Sie Ihre Automatisierungsstrategie in Zukunft überdenken sollten.
Client-Hinweise ermöglichen es, mit einem verlustfreien Bild mit hoher Auflösung zu beginnen, dessen Größe dann dynamisch angepasst werden kann, um für jede Kombination aus Bildschirm und Layout optimal zu sein. Im Gegensatz zu srcset, für das Sie eine feste Liste möglicher Imagekandidaten für den Browser auflisten müssen, kann dieser Ansatz flexibler sein. Während srcset Sie zwingt, Browser eine grobe Gruppe von Varianten anzubieten, z. B. 256w, 512w, 768w und 1024w, kann eine auf Client-Hinweisen basierende Lösung alle Breiten ohne großen Markup-Haufen bedienen.
Natürlich müssen Sie die Logik für die Bildauswahl nicht selbst schreiben. Cloudinary nutzt Clienthinweise, um Bildantworten zu erstellen, wenn Sie den Parameter w_auto verwenden. Dabei wurde festgestellt, dass durchschnittliche Nutzer 42% weniger Byte heruntergeladen haben, wenn sie Browser verwenden, die Clienthinweise unterstützen.
Aber Vorsicht! Durch die Änderungen in der Desktopversion von Chrome 67 werden ursprungsübergreifende Clienthinweise nicht mehr unterstützt. Glücklicherweise wirken sich diese Einschränkungen nicht auf mobile Versionen von Chrome aus und werden für alle Plattformen aufgehoben, wenn die Arbeit an der Funktionsrichtlinie abgeschlossen ist.
Unterstützung für Nutzer in langsamen Netzwerken
Bei der adaptiven Leistung können wir die Bereitstellung von Ressourcen basierend auf den Informationen anpassen, die uns Clienthinweise zur Verfügung stellen, insbesondere Informationen zum aktuellen Status der Netzwerkverbindung des Nutzers.
In Bezug auf die Website von Sconnie Timber ergreifen wir Maßnahmen, um die Last bei langsamen Netzwerken zu reduzieren. Dabei werden die Header Save-Data, ECT, RTT und Downlink in unserem Backend-Code geprüft. Danach generieren wir einen Qualitätsfaktor für das Netzwerk, anhand dessen wir feststellen können, ob wir eingreifen sollten, um die Nutzererfahrung zu verbessern. Diese Netzwerkpunktzahl liegt zwischen 0 und 1, wobei 0 die geringste mögliche Netzwerkqualität und 1 die beste Netzwerkqualität ist.
Zu Beginn wird geprüft, ob Save-Data vorhanden ist. Wenn dies der Fall ist, wird die Punktzahl auf 0 gesetzt, da wir davon ausgehen, dass der Nutzer alles tun soll, was erforderlich ist, um die Nutzung einfacher und schneller zu machen.
Wenn Save-Data nicht vorhanden ist, fahren wir fort und wägen die Werte der Hinweise für ECT, RTT und Downlink ab, um eine Punktzahl zu berechnen, die die Qualität der Netzwerkverbindung beschreibt. Der Quellcode für die Generierung der Netzwerkpunktzahl ist auf GitHub verfügbar. Fazit: Wenn wir die netzwerkbezogenen Hinweise auf irgendeine Art und Weise nutzen, können wir die User Experience für diejenigen verbessern, die langsame Netzwerke nutzen.
Wenn sich Websites an die vom Client bereitgestellten Informationen anpassen, müssen wir nicht nach einem „Alles oder nichts“-Ansatz verfolgen. Wir können intelligent entscheiden, welche Ressourcen gesendet werden. Wir können unsere responsive Bildauswahllogik so ändern, dass Bilder in geringerer Qualität für ein bestimmtes Display gesendet werden. So lässt sich bei schlechter Netzwerkqualität die Ladeleistung beschleunigen.
In diesem Beispiel sehen wir, wie sich Clienthinweise auf die Leistungsverbesserung von Websites in langsameren Netzwerken auswirken. Unten siehst du einen WebPagetest-Ablauf einer Website in einem langsamen Netzwerk, die sich nicht an Clienthinweise anpasst:
Und jetzt eine Vermittlungsabfolge für dieselbe Website mit derselben langsamen Verbindung. In diesem Fall verwendet die Website Clienthinweise, um nicht kritische Seitenressourcen zu entfernen:
Clienthinweise haben die Seitenladezeit von über 45 Sekunden auf weniger als ein Zehntel dieser Zeit reduziert. Die Vorteile von Clienthinweisen können in diesem Szenario nicht genug betont werden und können ein echter Segen für Nutzer sein, die über langsame Netzwerke nach wichtigen Informationen suchen.
Außerdem ist es möglich, Clienthinweise zu verwenden, ohne dass die Nutzung für Browser beeinträchtigt wird, die sie nicht unterstützen. Wenn Sie beispielsweise die Ressourcenlieferung anhand des Werts des Hinweises ECT anpassen und gleichzeitig die volle Erfahrung für nicht unterstützte Browser bieten möchten, können Sie einen Standardwert wie den folgenden verwenden:
// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";
Hier steht "4g" für die Netzwerkverbindung mit der höchsten Qualität, die im Header ECT beschrieben wird. Wenn wir $ect bis "4g" initialisieren, sind Browser, die keine Client-Hinweise unterstützen, nicht betroffen. FTW aktivieren
Achte auf die Caches!
Wenn Sie eine Antwort auf Basis eines HTTP-Headers ändern, müssen Sie beachten, wie Caches zukünftige Abrufe für diese Ressource verarbeiten. Der Vary-Header ist hier unverzichtbar, da er Cache-Einträge dem Wert der ihm bereitgestellten Anfrageheader zuordnet. Einfach ausgedrückt: Wenn Sie eine Antwort basierend auf einem bestimmten HTTP-Anfrageheader ändern, sollten Sie diesen Header fast immer so in Vary einfügen:
Vary: DPR, Width
Allerdings gibt es einen großen Nachteil: Im Cache speicherbare Antworten sollten nie für einen sich häufig ändernden Header (wie Cookie) mit Vary aktualisiert werden, da diese Ressourcen praktisch nicht mehr im Cache gespeichert werden können. Daher sollten Sie Vary-Angaben in Client-Hinweisheadern wie RTT oder Downlink vermeiden, da sich diese Verbindungsfaktoren recht häufig ändern können. Wenn Sie die Antworten auf diese Header ändern möchten, sollten Sie nur den ECT-Header angeben, um Cache-Fehler zu minimieren.
Dies gilt natürlich nur, wenn Sie eine Antwort überhaupt im Cache speichern.
Beispielsweise werden HTML-Assets nicht im Cache gespeichert, wenn deren Inhalte dynamisch sind, weil dies die Nutzererfahrung bei wiederholten Besuchen beeinträchtigen kann. In solchen Fällen können Sie diese Antworten nach Bedarf ändern, ohne sich Gedanken über Vary zu machen.
Clienthinweise in Service Workern
Die Verhandlung von Inhalten läuft nicht mehr nur auf Servern ab. Da Service Worker als Proxys zwischen Clients und Servern fungieren, können Sie steuern, wie Ressourcen über JavaScript bereitgestellt werden. Dazu gehören auch Clienthinweise. Im Service Worker-Ereignis fetch können Sie die Methode request.headers.get des event-Objekts verwenden, um die Anfrageheader einer Ressource so zu 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!
})(),
);
});
Jeder von Ihnen aktivierte Client-Hinweis-Header kann auf diese Weise gelesen werden. Allerdings ist das nicht die einzige
Möglichkeit, einige dieser Informationen zu erhalten. Netzwerkspezifische Hinweise können in den folgenden entsprechenden JavaScript-Eigenschaften im navigator-Objekt gelesen werden:
| Kundenhinweis | JS-Äquivalent |
|---|---|
| „ECT“ | `navigator.connection.effectiveType` |
| RTT | „navigator.connection.rtt“ |
| „Daten speichern“ | `navigator.connection.saveData` |
| „Downlink“ | `navigator.connection.downlink` |
| „Gerätespeicher“ | „navigator.deviceMemory“ |
Da diese APIs nicht überall verfügbar sind, sollten Sie den in-Operator prüfen:
if ('connection' in navigator) {
// Work with netinfo API properties in JavaScript!
}
Von hier aus können Sie eine ähnliche Logik wie auf dem Server verwenden, mit der Ausnahme, dass Sie keinen Server benötigen, um Inhalte mit Clienthinweisen auszuhandeln. Allein Service Worker können die Abläufe beschleunigen und zuverlässiger gestalten, da sie Inhalte auch dann bereitstellen müssen, wenn der Nutzer offline ist.
Zusammenfassung
Mit Client-Hinweisen haben wir die Möglichkeit, die Abläufe für Nutzer auf vollständig progressive Weise zu beschleunigen. Wir können Medien basierend auf den Gerätefunktionen des Nutzers auf eine Weise bereitstellen, die das Bereitstellen responsiver Bilder einfacher macht, als <picture> und srcset zu verwenden, insbesondere bei komplexen Anwendungsfällen. Dadurch können wir nicht nur den Zeit- und Arbeitsaufwand für die Entwicklung reduzieren, sondern auch Ressourcen – insbesondere Bilder – so optimieren, dass die Bildschirme der Nutzer besser angesprochen werden als
Und was noch wichtiger ist: Wir können schlechte Netzwerkverbindungen erkennen und die Lücke für Nutzer schließen, indem wir ändern, was wir senden – und wie wir es senden. Dadurch kann der Zugriff auf Websites für Nutzer in instabilen Netzwerken erheblich erleichtert werden. Kombiniert mit Service Workern können wir unglaublich schnelle Websites erstellen, die offline verfügbar sind.
Clienthinweise sind nur in Chrome – und in Chromium-basierten Browsern – verfügbar. Sie können aber so verwendet werden, dass Browser, die sie nicht unterstützen, nicht belastet werden. Erwägen Sie die Verwendung von Clienthinweisen, um wirklich inklusive und anpassungsfähige Umgebungen zu schaffen, bei denen die Gerätefunktionen jedes Nutzers und die Netzwerke, zu denen er eine Verbindung herstellt, berücksichtigt wird. Hoffentlich erkennen auch andere Browseranbieter den Nutzen dieser Tools und beabsichtigen, sie zu implementieren.
Ressourcen
- Automatische responsive Bilder mit Clienthinweisen
- Änderungen in Chrome 67
- Hinweis für (Kunden) (Google Präsentationen)
- Bereitstellung schneller und leichter Anwendungen mit
Save-Data
Wir danken Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss und Estelle Weyl für ihr wertvolles Feedback und die Änderungen zu diesem Artikel.