Die Entwicklung von Websites, die überall schnell sind, kann eine Herausforderung sein. Die Flut der Gerätefunktionen und der Qualität der verbundenen Netzwerke kann dies wie eine unüberwindbare Aufgabe erscheinen. Wir können zwar Browserfunktionen zur Verbesserung der Ladeleistung nutzen, woher wissen wir, was das Gerät des Nutzers kann oder die Qualität seines Netzwerks Verbindung? Die Lösung: Kunde Hinweise!
Clienthinweise sind eine Reihe von optionalen HTTP-Anfrageheadern, die uns Einblick in des Nutzers und des Netzwerks, mit dem er verbunden ist. Von Da wir diese Informationen serverseitig nutzen, können wir ändern, wie wir unsere Produkte basierend auf den Geräte- und/oder Netzwerkbedingungen. Dies kann uns helfen, inklusiverer User Experiences.
Inhalte verhandeln
Kundenhinweise sind eine weitere Methode zur Verhandlung von Inhalten. Daher sollten Sie Inhaltsantworten basierend auf Browser-Anfrageheadern.
Ein Beispiel für die Verhandlung von Inhalten ist die
Accept
Anfrageheader. Darin wird beschrieben, welche Inhaltstypen der Browser versteht.
kann der Server die Antwort aushandeln. Bei Bildanfragen gilt:
des Accept-Headers von Chrome ist:
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Alle Browser unterstützen Bildformate wie JPEG, PNG und GIF, aber Accept informiert In diesem Fall unterstützt der Browser auch WebP und APNG Mit diesen Informationen können wir aushandeln, um die besten Image-Typen für jeden Browser auszuhandeln:
<?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 bei Accept sind auch Clienthinweise eine weitere Möglichkeit, über Inhalte zu verhandeln,
Kontext von Gerätefunktionen und Netzwerkbedingungen. Mit Clienthinweisen
kann serverseitige Leistungsentscheidungen auf Basis der individuellen
z. B. die Entscheidung, ob nicht kritische Ressourcen
schlechten Netzwerkbedingungen. In diesem Leitfaden werden alle
Hinweise und Möglichkeiten, die Inhaltsübermittlung zu optimieren
den Nutzenden gerecht wird.
Aktivieren
Im Gegensatz zum Header Accept werden Clienthinweise nicht einfach nur wie von Zauberhand angezeigt (mit dem
Ausnahme von Save-Data, auf das wir später genauer eingehen werden. Um möglichst viele
mindestens Anfrageheadern, müssen Sie die Clienthinweise, die Sie
die Sie empfangen möchten, indem Sie einen Accept-CH-Header senden, wenn ein Nutzer eine
Ressource:
Accept-CH: Viewport-Width, Downlink
Der Wert für Accept-CH ist eine durch Kommas getrennte Liste von Hinweisen, die die Website
zur Bestimmung der Ergebnisse für nachfolgende Ressourcenanfragen verwendet. Wenn der Parameter
Client liest diesen Header und es wird ihm mitgeteilt: „Diese Website möchte, dass die Viewport-Width
und Downlink Kundenhinweise.“ Über die spezifischen Hinweise selbst musst du dir keine Gedanken machen.
Darauf kommen wir gleich.
Sie können diese Opt-in-Header in einer beliebigen Backend-Sprache festlegen. Zum Beispiel ist PHP's
header-Funktion verwendet werden.
Sie können diese Opt-in-Header sogar mit dem http-equiv
für ein <meta>-Tag:
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
Alle Kundenhinweise!
Kundenhinweise beschreiben eines von zwei Dingen: das Gerät, das Ihre Nutzer verwenden, und über das sie auf Ihre Website zugreifen. Sehen wir uns kurz an, Hinweise verfügbar sind.
Gerätehinweise
Einige Kundenhinweise beschreiben die Eigenschaften des Nutzergeräts, in der Regel der Bildschirm. Eigenschaften. Einige davon können Ihnen bei der Auswahl der optimalen Medienressource für Bildschirm eines Nutzers angezeigt, aber nicht alle sind unbedingt medienorientiert.
Bevor wir uns dieser Liste widmen, sollten wir uns ein paar wichtige Begriffe um die Bildschirm- und Medienauflösung zu beschreiben:
Intrinsische Größe:Die tatsächlichen Abmessungen einer Medienressource. Wenn beispielsweise Öffnen Sie ein Bild in Photoshop. Die Abmessungen, die im Dialogfeld für die Bildgröße angezeigt werden, beschreiben ihre intrinsische Größe.
Dichte korrigierte intrinsische Größe:Die Dimensionen einer Medienressource nach dass die Pixeldichte korrigiert wurde. Es ist die systeminterne Größe des Bildes. geteilt durch ein Gerätepixel Seitenverhältnis. 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."
/>
Nehmen wir an, die intrinsische Größe des 1x-Bildes ist in diesem Fall 320 × 240 und das
Die tatsächliche Größe des 2x-Bildes beträgt 640 x 480. Wenn dieses Markup von einem Client geparst wird,
die auf einem Gerät mit einem Bildschirm-Pixel-Verhältnis von 2 installiert sind (z.B. eine Retina
wird, wird das Bild 2x angefordert. Die dichtekorrigierte intrinsische Größe von
Das 2x-Bild hat eine Größe von 320 x 240, da 640 x 480 geteilt durch 2 eine Größe von 320 x 240 hat.
Extrinsische Größe:Die Größe einer Medienressource nach CSS und einem anderen Layout.
auf sie angewendet wurden, z. B. die Attribute width und height. Lassen Sie uns
Angenommen, Sie haben ein <img>-Element, das ein Bild mit einer korrigierten Dichte lädt.
intrinsische Größe von 320 x 240, verfügt aber auch über die CSS-Eigenschaften width und height
mit den Werten 256px bzw. 192px. In diesem Beispiel
wird die extrinsische Größe dieses <img>-Elements zu 256 x 192.
width: 256px;
und height: 192px; wandelt ein Bild mit unveränderlicher Größe von 320 x 240 um.
zu einer extrinsischen Größe von 256 × 192.Sehen wir uns nun die Liste der gerätespezifischen Clienthinweise, 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 (z.B. zugeschnittene) Behandlungen eines Bildes, die für bestimmte Bildschirmgrößen optimal sind (d.h. Kunst Richtung) oder Ressourcen auslassen, die für die aktuelle Bildschirmbreite nicht erforderlich sind.
DPR
DPR, kurz für „Geräte-Pixel-Verhältnis“, gibt das Verhältnis von physischen Pixeln zu CSS an
Pixel auf dem Bildschirm der Nutzenden:
DPR: 2
Dieser Hinweis ist bei der Auswahl von Bildquellen nützlich, die den
Pixeldichte (wie x-Deskriptoren im srcset-
Attribut)
Breite
Der Hinweis Width wird bei Anfragen für Bildressourcen angezeigt, die von <img> ausgelöst wurden, oder
<source>-Tags mit sizes
angeben.
sizes teilt dem Browser die externe Größe der Ressource mit.
Width verwendet diese externe Größe, um ein Bild mit einer unveränderlichen Größe anzufordern,
für das aktuelle Layout optimal ist.
Angenommen, ein Nutzer fordert eine Seite mit einem Breitbildformat von 320 CSS-Pixeln an.
mit einem effektiven Jahreszins von 2. Das Gerät lädt ein Dokument mit einem <img>-Element, das
den sizes-Attributwert 85vw (d.h. 85% der Breite des Darstellungsbereichs für alle
Bildschirmgrößen). Wenn der Width-Hinweis aktiviert wurde, sendet der Client
dieser Width-Hinweis an den Server mit der Anfrage für src der <img>:
Width: 544
In diesem Fall weist der Client dem Server an, Die Breite für das angeforderte Bild würde 85% der Breite des Darstellungsbereichs entsprechen (272 Pixel). multipliziert mit dem DPR (2) des Bildschirms, was 544 Pixeln entspricht.
Dieser Hinweis ist besonders wirkungsvoll, da nicht nur die an die Dichte des Displays angepasste Breite des Bildschirms. mit der externen Größe des Bildes innerhalb des Layouts. Dadurch erhalten Sie Server die Möglichkeit, Image-Antworten auszuhandeln, die für beide Bildschirm und das Layout.
Inhalts-DPR
Wie Sie bereits wissen, haben Bildschirme ein Geräte-Pixel-Verhältnis, Ressourcen
haben ihre eigenen Pixelverhältnisse. In den einfachsten Anwendungsfällen
der Ressourcenauswahl
kann das Verhältnis zwischen Geräten
und Ressourcen gleich sein. In Fällen, in denen sowohl
ob die Header DPR und Width gerade abgespielt werden, kann die externe Größe einer Ressource
erzeugen Szenarien, in denen sich die beiden unterscheiden. Hier wird der Hinweis Content-DPR angezeigt
ins Spiel.
Im Gegensatz zu anderen Clienthinweisen ist Content-DPR kein request-Header, der von
Server für den Antwortheader müssen senden, wenn DPR und
Width-Hinweise werden zur Auswahl einer Ressource verwendet. Der Wert von Content-DPR sollte
das Ergebnis dieser Gleichung sein:
Content-DPR = [Ausgewählte Größe der Bildressource] ÷ ([Width] ÷ [DPR])
Wenn ein Content-DPR-Anfrageheader gesendet wird, weiß der Browser, wie die Skalierung erfolgt
das gegebene Bild für das Geräte-Pixel-Verhältnis des Bildschirms und das Layout. Ohne sie
Bilder möglicherweise nicht richtig skaliert werden.
Gerätespeicher
Technisch ein Teil des Gerätespeichers
API zeigt Device-Memory die
ungefähre Anzahl von
Erinnerung
des aktuellen Geräts in GiB:
Device-Memory: 2
Ein möglicher Anwendungsfall für diesen Hinweis wäre die Reduzierung der JavaScript-Menge an Browser auf Geräten mit begrenztem Speicher gesendet, da JavaScript ressourcenintensiven Inhaltstypen, laden. Sie können auch Bilder mit geringerer DVR-Rate senden, da diese weniger Arbeitsspeicher für die Decodierung benötigen.
Netzwerkhinweise
Die Network Information API bietet eine weitere Kategorie von Clienthinweisen, die die Leistung des Nutzernetzwerks beschreiben Meiner Meinung nach sind dies die nützlichsten Hinweise. Mit ihnen haben wir in der Lage, unsere Angebote an unsere Nutzer anzupassen. Ressourcen für Clients mit langsamen Verbindungen.
RTT
Der Hinweis RTT gibt die ungefähre Umlaufzeit in Millisekunden an,
Anwendungsschicht. Der RTT-Hinweis enthält im Gegensatz zur Transportschicht-RTT Folgendes:
die Verarbeitungszeit des Servers.
RTT: 125
Dieser Hinweis ist aufgrund der Rolle, die die Latenz bei der Ladeleistung spielt, nützlich.
Mit dem Hinweis RTT können wir Entscheidungen
auf der Reaktionsfähigkeit des Netzwerks treffen,
Dies kann dazu beitragen, die Bereitstellung eines gesamten Erlebnisses zu beschleunigen (z.B. durch
einige Anfragen auslassen).
Downlink
Auch wenn die Latenz
für die Ladeleistung wichtig ist,
. Der Downlink-Hinweis in Megabit pro Sekunde (Mbit/s) zeigt, welche
ungefähre Downstream-Geschwindigkeit der Nutzerverbindung:
Downlink: 2.5
In Verbindung mit RTT kann Downlink nützlich sein, um die Art und Weise, wie Inhalte
basierend auf der Qualität der Netzwerkverbindung
an Nutzer ausgeliefert werden.
ECT
Der Hinweis ECT steht für Effective Connection Type. Sein Wert ist einer
Aufzählung von Verbindungstypen, die jeweils eine Verbindung beschreiben
innerhalb der angegebenen Bereiche von RTT und Downlink
Werte.
Dieser Header erklärt nicht, was der tatsächlich Verbindungstyp ist – für
Es wird beispielsweise nicht angegeben, ob Ihr Gateway ein Mobilfunkmast oder ein WLAN-Zugang ist.
Punkt. Es analysiert vielmehr die Latenz und Bandbreite der aktuellen Verbindung
welches Netzwerkprofil ihm am ähnlichsten ist. Wenn Sie beispielsweise
über WLAN mit einem langsamen Netzwerk verbinden, ist für ECT der Wert 2g,
Dies entspricht der effektiven Verbindung am besten:
ECT: 2g
Gültige Werte für ECT sind 4g, 3g, 2g und slow-2g. Dieser Hinweis kann
die als Ausgangspunkt für die Bewertung der Verbindungsqualität dient.
mit den Hinweisen RTT und Downlink verfeinert.
Daten speichern
Save-Data beschreibt die Netzwerkbedingungen nicht so sehr, da er ein Nutzer ist.
Einstellung, dass Seiten weniger Daten senden sollen.
Ich klassifiziere Save-Data lieber als Netzwerkhinweis,
ähneln anderen Netzwerkhinweisen. Nutzende können auch
in Umgebungen mit hoher Latenz und geringer Bandbreite. Dieser Hinweis:
vorhanden ist, sieht immer so aus:
Save-Data: on
Hier bei Google haben wir darüber gesprochen,
Save-Data
Das kann tiefgreifende Auswirkungen auf die Leistung haben. Es ist ein Signal, bei dem Nutzende
bitten Sie im wahrsten Sinne des Wortes, ihnen weniger zu schicken. Wenn Sie darauf achten und darauf reagieren,
werden die Nutzer es zu schätzen wissen.
Konzepte verbinden
Was Sie mit Clienthinweisen vornehmen, ist von Ihnen abhängig. Weil sie so viel haben Sie viele Möglichkeiten. Lassen Sie uns herausfinden, Kundenhinweise für Sconnie Holz, ein fiktives Holz Unternehmen im ländlichen Upper Midwest. Wie bei Remote- Regionen, Netzwerkverbindungen instabil sein. Hier kommt eine Technologie wie Clienthinweise für die Nutzenden wirklich einen Unterschied machen.
Responsive Bilder
Mit Ausnahme der einfachsten Anwendungsfälle für responsive Bilder kann es kompliziert werden. Was ist, wenn Sie
haben mehrere Darstellungen und Varianten desselben Bildes für unterschiedliche Bildschirme
Größen und verschiedenen Formaten? Dieses Markup wird sehr sehr kompliziert
Es ist leicht, Fehler zu machen, und leicht vergessen oder missverstanden sind,
(z. B. sizes).
<picture> und srcset sind sicherlich tolle Tools, aber sie können
die Entwicklung und Wartung
für komplexe Anwendungsfälle sehr zeitaufwändig. Wir können die Daten automatisieren,
die Erstellung von Markups zu. Dies ist jedoch auch schwierig,
<picture> und srcset sind so komplex, dass ihre Automatisierung erforderlich ist
dass ihre Flexibilität gewahrt bleibt.
Kundenhinweise können dies vereinfachen. Bildantworten mit dem Kunden aushandeln können Hinweise in etwa so aussehen:
- Sofern dies für Ihren Workflow relevant ist, wählen Sie zuerst eine Bildbearbeitung aus (z.B.
künstlerische Bilder), indem Sie den Hinweis
Viewport-Widthprüfen. - Wählen Sie eine Bildauflösung aus, indem Sie den Hinweis
WidthundDPRprüfen. die Auswahl einer Quelle, die zur Layoutgröße und Bildschirmdichte des Bildes passt (ähnliche zur Funktionsweise vonx- undw-Deskriptoren insrcset). - Wählen Sie das optimale Dateiformat aus, das der Browser unterstützt (etwa
Accept). in den meisten Browsern.
Mein fiktiver Kunde aus dem Holzkonzern beschäftigte sich mit einer naiven Routine für die responsive Bildauswahl in PHP, die Clienthinweise verwendet. Das bedeutete anstatt dieses Markup an alle Nutzer zu senden:
<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 Unterstützung einzelner Browser konnte ich die Anzahl auf folgende Optionen 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.
überarbeitet von
mod_rewrite. Es
verwendet einen Bilddateinamen und zusätzliche Parameter zur Unterstützung eines Back-End-Skripts
das beste Bild unter den gegebenen Bedingungen auszuwählen.
Ich stelle mir Folgendes vor: „Aber wird damit nicht nur die Neuimplementierung von <picture> und srcset
Back-End?“ ist Ihre erste Frage.
In gewisser Weise ja, aber mit einem wichtigen Unterschied: Wenn eine Anwendung Hinweise für die Erstellung von Medienantworten geben, ist der Großteil der Arbeit Dazu gehört unter anderem ein Dienst wie ein CDN, der dies . Bei HTML-Lösungen muss das neue Markup hingegen für jeden Anwendungsfall bieten. Natürlich können Sie die Markup-Generierung automatisieren. Wenn Ihr Design oder Anforderungen ändern, müssen Sie das jedoch mit hoher Wahrscheinlichkeit Ihre Automatisierungsstrategie zu überarbeiten.
Mithilfe von Clienthinweisen kann mit einer verlustfreien, hochauflösenden
Bild, das dynamisch angepasst werden kann, sodass es für beliebige Kombinationen optimal ist
Bildschirm und Layout. Im Gegensatz zu srcset, bei dem Sie eine feste
der möglichen Bildkandidaten für den Browser aufgelistet,
flexibler sein können. Während Sie mit srcset gezwungen sind, Browsern eine grobere Einstellung anzubieten
der Varianten, z. B. 256w, 512w, 768w und 1024w, sind Client-Hinweise.
gestützte Lösung können alle Breiten ohne einen riesigen Haufen Markup bedienen.
Natürlich müssen Sie nicht selbst eine Logik für die Bildauswahl schreiben. Cloudinary
nutzt Clienthinweise, um Bildantworten zu erstellen, wenn du die w_auto verwendest
Parameter
und festgestellt, dass durchschnittlich 42% weniger Bytes heruntergeladen wurden,
unterstützenden Client-Hinweisen.
Aber Vorsicht! Aufgrund von Änderungen in der Desktopversion von Chrome 67 wird der Support eingestellt für Cross-Origin Client Hinweise. Glücklicherweise wirken sich diese Einschränkungen nicht auf mobile Versionen von Chrome aus und werden sie vollständig für alle Plattformen entfernt, wenn Sie an Feature- Richtlinie vollständig ist.
Unterstützung für Nutzer in langsamen Netzwerken
Adaptive Leistung bedeutet, dass wir die Bereitstellung von Ressourcen anpassen können. basierend auf den Informationen, die uns Clienthinweise zur Verfügung stellen; insbesondere Informationen zum aktuellen Status der Netzwerkverbindung des Nutzers
Wenn es um die Website von Sconnie Timber geht, unternehmen wir Schritte, um die Last zu verringern,
langsame Netzwerke, mit Save-Data-, ECT-, RTT- und Downlink-Headern
Back-End-Code untersucht haben. Danach generieren wir eine Netzwerkqualität,
eine Punktzahl, mit der wir feststellen können, ob wir einschreiten sollten,
Nutzererfahrung. Diese Netzwerkpunktzahl liegt zwischen 0 und 1, wobei 0 am schlechtesten ist
Netzwerk möglich und 1 ist die beste Einstellung.
Zuerst prüfen wir, ob Save-Data vorhanden ist. Ist dies der Fall, wird die Punktzahl
0, da wir davon ausgehen, dass der Nutzer will, dass wir alles tun, um das
einfacher und schneller.
Fehlt Save-Data jedoch, fahren wir fort und gewichten die Werte von ECT,
RTT und Downlink geben Hinweise zur Berechnung einer Punktzahl, die das Netzwerk beschreibt
die Verbindungsqualität. Quelle für die Generierung der Netzwerkpunktzahl
Code
ist auf GitHub verfügbar. Das Fazit ist: Wenn wir die netzwerkbezogenen Hinweise
etwas Mode machen, können wir die Nutzererfahrung für diejenigen verbessern, die langsam sind.
Netzwerken.
Wenn Websites sich an die in Clienthinweisen bereitgestellten Informationen anpassen, müssen wir die „Alles oder nichts“-Ansatz. Wir können intelligent entscheiden, welche Ressourcen senden. Wir können unsere Logik zur Auswahl von Bildern für responsive Bilder ändern, um für einen bestimmten Bildschirm, um die Ladeleistung bei der Netzwerkqualität zu beschleunigen ist schlecht.
In diesem Beispiel sehen wir, wie sich Clienthinweise auf die Leistung von Websites in langsameren Netzwerken verbessern. Unten sehen Sie einen WebPagetest. Wasserfall einer Website in einem langsamen Netzwerk, das sich nicht an Clienthinweise anpasst:
Und jetzt ein Wasserfall für dieselbe Website mit derselben langsamen Verbindung, mit dem Unterschied, verwendet die Website Clienthinweise, um nicht kritische Seitenressourcen zu entfernen:
Mithilfe von Client-Hinweisen wurde die Seitenladezeit von über 45 Sekunden auf weniger als eine Zehntel dieser Zeit. Die Vorteile von Clienthinweisen können in diesem Fall nicht betont genug betont, und kann ein Segen für Nutzende sein, die Daten über langsame Netzwerke übertragen.
Darüber hinaus ist es möglich, Clienthinweise zu verwenden,
für Browser, die diese Funktionen nicht unterstützen. Wenn wir z. B. die Ressource anpassen möchten,
Auslieferung mit dem Wert des ECT-Hinweises, während weiterhin der vollständige Hinweis zurückgegeben wird
nicht unterstützenden Browsern angezeigt wird, können wir einen Fallback auf einen Standardwert
etwa so:
// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";
Hier ist "4g" die Netzwerkverbindung mit der höchsten Qualität im Header „ECT“
beschrieben. Wenn $ect mit "4g" initialisiert wird, werden Browser, die den Client nicht unterstützen,
Hinweise sind davon nicht betroffen. Jetzt aktivieren!
Achte auf die Caches!
Wenn Sie eine Antwort auf Basis eines HTTP-Headers ändern, müssen Sie Folgendes beachten:
wie Caches
künftige Abrufe dieser Ressource verarbeiten. Die Vary
Überschrift ist
sind hier unverzichtbar, da sie Cache-Einträge mit dem Wert der Anfrageheader
übergeben wird. Wenn Sie eine Antwort basierend auf einem bestimmten
-Anforderungsheader sollten Sie fast immer diese Kopfzeile in Vary einfügen.
etwa so:
Vary: DPR, Width
Es gibt jedoch einen großen Vorbehalt: Sie sollten niemals Vary-speicherbare
auf eine sich häufig ändernde Kopfzeile (wie Cookie), weil diese
Ressourcen faktisch nicht im Cache speicherbar. Mit diesem Wissen sollten Sie
Vary in Clienthinweis-Headern wie RTT oder Downlink, da diese
die sich recht häufig ändern können. Wenn Sie
Antworten auf diese Header erhalten, sollten Sie nur den ECT-Header eingeben, wodurch
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 ihr Inhalt dynamisch ist.
die bei wiederholten Besuchen die Nutzererfahrung beeinträchtigen können. In solchen Fällen fühlen Sie sich
Sie können diese Antworten nach Bedarf ändern.
sich Gedanken über Vary machen.
Clienthinweise in Service Workern
Die Aushandlung von Inhalten ist nicht mehr nur für Server gedacht. Da Service Worker
als Proxys zwischen Clients und Servern haben, können Sie steuern, wie Ressourcen
werden über JavaScript bereitgestellt. Dazu gehören auch Clienthinweise. Im Service Worker
fetch-Ereignis, können Sie das Objekt event
request.headers.get
, um die Anfrageheader einer Ressource 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 Clienthinweis-Header, den Sie aktivieren, kann so gelesen werden. Das ist zwar
nicht die einzige Möglichkeit,
einige dieser Informationen zu erhalten. Netzwerkspezifische Hinweise
können in den folgenden JavaScript-Eigenschaften im navigator-Objekt gelesen werden:
| Kundenhinweis | JS-Entsprechung |
|---|---|
| "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, wo Sie Feature-Prüfungen mit dem
in
Operator:
if ('connection' in navigator) {
// Work with netinfo API properties in JavaScript!
}
Von hier aus können Sie eine Logik verwenden, die derjenigen auf dem Server ähnelt, außer dass Sie brauchen keinen Server, um Inhalte mit Clienthinweisen auszuhandeln. Dienst Beschäftigten alleine in der Lage sind, Abläufe schneller und widerstandsfähiger zu gestalten, zusätzlich zur Möglichkeit, Inhalte auch offline bereitzustellen.
Zusammenfassung
Mit Clienthinweisen können wir die Nutzererfahrung in einer
progressiv arbeiten. Wir können Medien basierend auf dem Gerät des Nutzers ausliefern.
sodass Sie responsive Bilder einfacher bereitstellen können,
auf <picture> und srcset, insbesondere bei komplexen Anwendungsfällen. Dadurch können wir
nicht nur den Zeit- und Arbeitsaufwand für die Entwicklung zu reduzieren, sondern
– insbesondere Bilder – so, dass sie auf die Bildschirme der Nutzenden ausgerichtet sind.
als mit
Noch wichtiger ist jedoch, dass wir schlechte Netzwerkverbindungen und Bridge- die Lücke für die Nutzer schließen, indem wir ändern, was wir senden – und wie wir sie senden. Dies kann können dazu beitragen, den Zugriff auf Websites in fragilen Netzwerken zu vereinfachen. In Kombination mit Service Workern können wir unglaublich schnelle Websites erstellen, offline verfügbar.
Clienthinweise sind zwar nur in Chrome und auf Chromium-Basis verfügbar Browser – es ist möglich, sie so zu verwenden, dass sie Browser, die sie nicht unterstützen. Mithilfe von Kundenhinweisen können Sie inklusive und anpassungsfähige Erfahrungen zu machen, bei denen die Geräte der einzelnen Nutzenden im Blick behalten werden. und den Netzwerken, mit denen sie verbunden sind. Hoffentlich können andere Browseranbieter die Wertschöpfung und die Implementierungsabsicht erkennen.
Ressourcen
- Automatische responsive Bilder mit Client Hinweise
- Client Hints und responsive Bilder – was sich in Chrome geändert hat 20
- Für Kunden: Tipps (Google Präsentationen)
- Schnelle und leichte Anwendungen mit
Save-Data
Vielen Dank an Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss und Estelle Weyl für ihre wertvolles Feedback und Änderungsvorschläge zu diesem Artikel.