Dostosowywanie się do użytkowników za pomocą wskazówek dotyczących klienta

Tworzenie witryn, które szybko się wczytują wszędzie, może być trudne. Różnorodność funkcji urządzeń i jakość sieci, z którymi się łączą, mogą sprawić, że zadanie to wydaje się niemożliwe do wykonania. Możemy wykorzystać funkcje przeglądarki, aby poprawić wydajność wczytywania, ale skąd mamy wiedzieć, jakie są możliwości urządzenia użytkownika lub jaka jest jakość jego połączenia sieciowego? Rozwiązaniem są wskazówki dotyczące klienta.

Wskazówki klienta to zestaw nagłówków żądań HTTP, które dają nam wgląd w te aspekty urządzenia użytkownika i sieci, z którą jest połączone. Dzięki wykorzystaniu tych informacji po stronie serwera możemy zmienić sposób dostarczania treści w zależności od urządzenia lub warunków sieciowych. Dzięki temu możemy tworzyć bardziej inkluzywne usługi.

Wszystko zależy od negocjacji treści

Wskazówki dotyczące klienta to kolejna metoda negocjacji treści, która polega na zmianie odpowiedzi dotyczących treści na podstawie nagłówków żądań przeglądarki.

Jednym z przykładów negocjacji treści jest nagłówek żądania Accept. Opisuje typy treści, które przeglądarka rozumie, a które serwer może wykorzystać do negocjowania odpowiedzi. W przypadku żądań obrazów zawartość nagłówka Accept Chrome to:

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

Wszystkie przeglądarki obsługują formaty plików graficznych takie jak JPEG, PNG i GIF, ale w tym przypadku nagłówek Accept informuje, że przeglądarka obsługuje również formaty WebP i APNG. Na podstawie tych informacji możemy wynegocjować najlepsze typy obrazów dla każdej przeglądarki:

<?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!">

Podobnie jak Accept, wskazówki dotyczące klienta to kolejny sposób negocjowania treści, ale w kontekście możliwości urządzenia i warunków sieciowych. Dzięki wskazówkom dotyczącym klienta możemy podejmować decyzje dotyczące wydajności po stronie serwera na podstawie indywidualnych doświadczeń użytkownika, np. decydować, czy zasoby niekrytyczne powinny być udostępniane użytkownikom, którzy mają słabe połączenie z siecią. W tym przewodniku opisujemy wszystkie dostępne wskazówki i sposoby ich wykorzystania, aby dostarczanie treści było bardziej przyjazne dla użytkowników.

Włączanie opcji

W przeciwieństwie do nagłówka Accept wskazówki klienta nie pojawiają się same (z wyjątkiem Save-Data, które omówimy później). Aby ograniczyć liczbę nagłówków żądań do minimum, musisz wybrać, które wskazówki dotyczące klienta chcesz otrzymywać, wysyłając nagłówek Accept-CH, gdy użytkownik żąda zasobu:

Accept-CH: Viewport-Width, Downlink

Wartość Accept-CH to lista rozdzielona przecinkami żądanych wskazówek, których witryna będzie używać do określania wyników kolejnych żądań zasobów. Gdy klient odczytuje ten nagłówek, otrzymuje informację „ta witryna chce wskazówek dotyczących klienta Viewport-Width i Downlink”. Nie przejmuj się konkretnymi wskazówkami. Za chwilę do nich przejdziemy.

Te nagłówki zgody możesz ustawić w dowolnym języku backendu. Możesz na przykład użyć funkcji header w języku PHP. Możesz nawet ustawić te nagłówki akceptacji za pomocą atrybutu http-equiv w tagu <meta>:

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

Wszystkie wskazówki dotyczące klienta.

Wskazówki dotyczące klienta opisują jedną z 2 rzeczy: urządzenie, którego używają użytkownicy, oraz sieć, której używają do uzyskiwania dostępu do Twojej witryny. Omówmy krótko wszystkie dostępne wskazówki.

Wskazówki dotyczące urządzenia

Niektóre wskazówki dotyczące klienta opisują cechy urządzenia użytkownika, zwykle cechy ekranu. Niektóre z nich mogą pomóc Ci wybrać optymalny zasób multimedialny dla ekranu danego użytkownika, ale nie wszystkie muszą być skoncentrowane na multimediach.

Zanim przejdziemy do listy, warto poznać kilka kluczowych terminów używanych do opisywania ekranów i rozdzielczości multimediów:

Rozmiar wewnętrzny: rzeczywiste wymiary zasobu multimedialnego. Jeśli na przykład otworzysz obraz w Photoshopie, wymiary widoczne w oknie rozmiaru obrazu opisują jego rozmiar wewnętrzny.

Rozmiar wewnętrzny skorygowany pod kątem gęstości: wymiary zasobu multimedialnego po skorygowaniu pod kątem gęstości pikseli. Jest to rozmiar wewnętrzny obrazu podzielony przez współczynnik pikseli urządzenia. Weźmy na przykład te znaczniki:

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

Załóżmy, że w tym przypadku rzeczywisty rozmiar obrazu 1x to 320 x 240, a obrazu 2x – 640 x 480. Jeśli te znaczniki zostaną przeanalizowane przez klienta zainstalowanego na urządzeniu ze współczynnikiem pikseli urządzenia wynoszącym 2 (np. ekran Retina), zostanie wysłane żądanie obrazu 2x. Rozmiar wewnętrzny po korekcie gęstości obrazu 2x wynosi 320 × 240, ponieważ 640 × 480 podzielone przez 2 to 320 × 240.

Rozmiar zewnętrzny: rozmiar zasobu multimedialnego po zastosowaniu CSS i innych czynników układu (takich jak atrybuty width i height). Załóżmy, że masz element <img>, który wczytuje obraz o rozmiarze wewnętrznym skorygowanym pod kątem gęstości wynoszącym 320 x 240, ale ma też właściwości CSS width i height z odpowiednio wartościami 256px i 192px. W tym przykładzie rozmiar zewnętrzny elementu <img> wynosi 256 x 192.

Ilustracja przedstawiająca rozmiar wewnętrzny i zewnętrzny. Wyświetla się pole o rozmiarze 320 x 240 pikseli z etykietą ROZMIAR WEWNĘTRZNY. Wewnątrz znajduje się mniejsze pole o wymiarach 256 x 192 piksele, które reprezentuje element HTML img z zastosowanym stylem CSS. To pole jest oznaczone jako EXTRINSIC SIZE. Po prawej stronie znajduje się pole zawierające kod CSS zastosowany do elementu, który modyfikuje układ elementu img, tak aby jego rozmiar zewnętrzny różnił się od rozmiaru wewnętrznego.
Rysunek 1. Ilustracja przedstawiająca rozmiar pierwotny i zewnętrzny. Obraz uzyskuje rozmiar zewnętrzny po zastosowaniu czynników układu. W tym przypadku zastosowanie reguł CSS width: 256px; i height: 192px; przekształca obraz o rozmiarze wewnętrznym 320 x 240 w obraz o rozmiarze zewnętrznym 256 x 192.

Skoro znamy już terminologię, przejdźmy do listy wskazówek klienta dotyczących urządzeń, które są dostępne.

Viewport-Width

Viewport-Width to szerokość widocznego obszaru użytkownika w pikselach CSS:

Viewport-Width: 320

Można jej używać z innymi wskazówkami dotyczącymi ekranu, aby wyświetlać różne wersje (np. przycięte) obrazu, które są optymalne dla konkretnych rozmiarów ekranu (np. kierunek artystyczny), lub pomijać zasoby, które są niepotrzebne w przypadku bieżącej szerokości ekranu.

DPR

DPR, czyli współczynnik pikseli urządzenia, to stosunek liczby pikseli fizycznych do liczby pikseli CSS na ekranie użytkownika:

DPR: 2

Ta wskazówka jest przydatna przy wybieraniu źródeł obrazu, które odpowiadają gęstości pikseli ekranu (jak deskryptory x w atrybucie srcset).

Szerokość

Wskazówka Width pojawia się w żądaniach zasobów graficznych wywoływanych przez tagi <img> lub <source> za pomocą atrybutu sizes. sizes informuje przeglądarkę, jaki będzie rozmiar zewnętrzny zasobu, a Width używa tego rozmiaru zewnętrznego, aby zażądać obrazu o rozmiarze wewnętrznym, który jest optymalny dla bieżącego układu.

Załóżmy na przykład, że użytkownik prosi o stronę z ekranem o szerokości 320 pikseli CSS i współczynnikiem DPR równym 2. Urządzenie wczytuje dokument z elementem <img> zawierającym wartość atrybutu sizes równą 85vw (czyli 85% szerokości widocznego obszaru dla wszystkich rozmiarów ekranu). Jeśli wskazówka Width została włączona, klient wyśle tę wskazówkę Width do serwera z żądaniem dotyczącym src elementu <img>:

Width: 544

W tym przypadku klient podpowiada serwerowi, że optymalna szerokość wewnętrzna żądanego obrazu wynosi 85% szerokości widocznego obszaru (272 piksele) pomnożone przez współczynnik DPR ekranu (2), co daje 544 piksele.

Ta wskazówka jest szczególnie przydatna, ponieważ nie tylko uwzględnia szerokość ekranu po korekcie gęstości, ale też uzgadnia tę kluczową informację z zewnętrznym rozmiarem obrazu w układzie. Dzięki temu serwery mogą negocjować odpowiedzi dotyczące obrazów, które są optymalne zarówno dla ekranu, jak i układu.

Content-DPR

Wiesz już, że ekrany mają współczynnik pikseli urządzenia, ale zasoby też mają własne współczynniki pikseli. W najprostszych przypadkach użycia wyboru zasobów współczynniki pikseli między urządzeniami i zasobami mogą być takie same. Ale… W przypadkach, gdy używane są oba nagłówki (DPR i Width), rozmiar zewnętrzny zasobu może powodować sytuacje, w których te 2 nagłówki się różnią. W tym miejscu przydaje się wskazówka Content-DPR.

W przeciwieństwie do innych wskazówek klienta Content-DPR nie jest nagłówkiem żądania, który ma być używany przez serwery, ale nagłówkiem odpowiedzi, który serwery muszą wysyłać, gdy do wyboru zasobu używane są wskazówki DPR i Width. Wartość Content-DPR powinna być wynikiem tego równania:

Content-DPR = [rozmiar wybranego zasobu obrazu] / ([Width] / [DPR])

Gdy wysyłany jest nagłówek żądania Content-DPR, przeglądarka wie, jak skalować dany obraz pod kątem współczynnika pikseli urządzenia i układu. Bez niego obrazy mogą nie skalować się prawidłowo.

Device-Memory

Właściwość Device-Memory, która technicznie jest częścią interfejsu Device Memory API, ujawnia przybliżoną ilość pamięci, jaką dysponuje bieżące urządzenie (w GiB):

Device-Memory: 2

Możliwym zastosowaniem tej wskazówki jest zmniejszenie ilości kodu JavaScript wysyłanego do przeglądarek na urządzeniach z ograniczoną pamięcią, ponieważ JavaScript jest najbardziej zasobochłonnym typem treści, który zwykle wczytują przeglądarki. Możesz też wysyłać obrazy o niższym współczynniku DPR, ponieważ ich dekodowanie wymaga mniejszej ilości pamięci.

Wskazówki dotyczące sieci

Network Information API udostępnia inną kategorię wskazówek dotyczących klienta, które opisują wydajność połączenia sieciowego użytkownika. Moim zdaniem to najbardziej przydatny zestaw wskazówek. Dzięki nim możemy dostosowywać wrażenia użytkowników, zmieniając sposób dostarczania zasobów klientom z wolnymi połączeniami.

RTT

Wskazówka RTT podaje przybliżony czas błądzenia w milisekundach w warstwie aplikacji. Wskazówka RTT, w przeciwieństwie do czasu RTT w warstwie transportowej, obejmuje czas przetwarzania przez serwer.

RTT: 125

Ta wskazówka jest przydatna ze względu na rolę, jaką czas oczekiwania odgrywa w wydajności wczytywania. Korzystając ze wskazówki RTT, możemy podejmować decyzje na podstawie czasu odpowiedzi sieci, co może pomóc przyspieszyć dostarczanie całej usługi (np. przez pominięcie niektórych żądań).

Chociaż opóźnienie jest ważne dla wydajności wczytywania, przepustowość również ma znaczenie. Wskazówka Downlink, wyrażona w megabitach na sekundę (Mb/s), ujawnia przybliżoną szybkość pobierania danych przez połączenie użytkownika:

Downlink: 2.5

W połączeniu z RTT interfejs Downlink może być przydatny do zmiany sposobu dostarczania treści użytkownikom na podstawie jakości połączenia sieciowego.

ECT

Wskazówka ECT oznacza efektywny typ połączenia. Jego wartość jest jedną z wyliczonych na liście typów połączeń, z których każdy opisuje połączenie w określonych zakresach wartości RTT i Downlink.

Ten nagłówek nie wyjaśnia, jaki jest rzeczywisty typ połączenia – na przykład nie informuje, czy brama jest stacją bazową czy punktem dostępu Wi-Fi. Zamiast tego analizuje opóźnienie i przepustowość bieżącego połączenia i określa, który profil sieciowy najbardziej przypomina. Jeśli na przykład łączysz się przez Wi-Fi z wolną siecią, zmienna ECT może mieć wartość 2g, która jest najbliższym przybliżeniem efektywnego połączenia:

ECT: 2g

Prawidłowe wartości parametru ECT to 4g, 3g, 2g i slow-2g. Tej wskazówki można użyć jako punktu wyjścia do oceny jakości połączenia, a następnie doprecyzować ją za pomocą wskazówek RTT i Downlink.

Save-Data

Save-Data nie jest wskazówką opisującą warunki sieciowe, ale preferencją użytkownika, która określa, że strony powinny wysyłać mniej danych.

Wolę klasyfikować Save-Data jako wskazówkę sieciową, ponieważ wiele rzeczy, które można z nią zrobić, jest podobnych do innych wskazówek sieciowych. Użytkownicy mogą też chcieć włączyć tę funkcję w środowiskach o dużych opóźnieniach lub małej przepustowości. Ta wskazówka, jeśli jest dostępna, zawsze wygląda tak:

Save-Data: on

W Google mówiliśmy o tym, co możesz zrobić z Save-Data. Może to mieć ogromny wpływ na skuteczność. To sygnał, że użytkownicy dosłownie proszą o wysyłanie mniejszej liczby wiadomości. Jeśli weźmiesz pod uwagę ten sygnał i odpowiednio zareagujesz, użytkownicy to docenią.

Jak zastosować teorię w praktyce

To, co zrobisz ze wskazówkami dotyczącymi klienta, zależy od Ciebie. Ponieważ zawierają tak wiele informacji, masz wiele opcji. Aby znaleźć nowe pomysły, zobaczmy, co wskazówki dotyczące klienta mogą zrobić dla Sconnie Timber, fikcyjnej firmy zajmującej się drewnem, która znajduje się na obszarach wiejskich w górnej części Środkowego Zachodu. Jak to często bywa na obszarach oddalonych, połączenia sieciowe mogą być niestabilne. W takich przypadkach technologia taka jak wskazówki dotyczące klienta może naprawdę pomóc użytkownikom.

Obrazy elastyczne

Wszystkie przypadki użycia elastycznych obrazów, z wyjątkiem tych najprostszych, mogą być skomplikowane. Co zrobić, jeśli masz wiele wersji i wariantów tych samych obrazów dla różnych rozmiarów ekranu i różnych formatów? Te znaczniki bardzo szybko stają się bardzo skomplikowane. Łatwo jest popełnić błąd, zapomnieć o ważnych pojęciach (takich jak sizes) lub źle je zrozumieć.

Chociaż <picture> i srcset to bez wątpienia świetne narzędzia, ich tworzenie i utrzymywanie w przypadku złożonych zastosowań może być czasochłonne. Możemy zautomatyzować generowanie znaczników, ale jest to trudne, ponieważ funkcje <picture> i srcset są na tyle złożone, że ich automatyzacja musi być przeprowadzona w sposób, który zachowuje ich elastyczność.

Wskazówki dotyczące klienta mogą to uprościć. Negocjowanie odpowiedzi dotyczących obrazów za pomocą wskazówek dotyczących klienta może wyglądać mniej więcej tak:

  1. Jeśli dotyczy to Twojego przepływu pracy, najpierw wybierz sposób przetwarzania obrazu (np. obraz z reżyserią artystyczną), zaznaczając wskazówkę Viewport-Width.
  2. Wybierz rozdzielczość obrazu, sprawdzając wskazówkę Width i wskazówkę DPR, a następnie wybierz źródło, które pasuje do rozmiaru układu obrazu i gęstości ekranu (podobnie jak deskryptory x i w w srcset).
  3. Wybierz najbardziej optymalny format pliku obsługiwany przez przeglądarkę (w większości przeglądarek pomaga w tym Accept).

W przypadku mojej fikcyjnej firmy produkującej drewno opracowałem w PHP prostą procedurę wyboru obrazu elastycznego, która korzysta ze wskazówek dotyczących klienta. Oznacza to, że zamiast wysyłać ten znacznik do wszystkich użytkowników:

<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>

Udało mi się ograniczyć tę listę do poniższych opcji na podstawie obsługi przez poszczególne przeglądarki:

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

W tym przykładzie adres URL /image to skrypt PHP, po którym następują parametry przepisane przez mod_rewrite. Przyjmuje nazwę pliku obrazu i dodatkowe parametry, aby pomóc skryptowi backendu wybrać najlepszy obraz w danych warunkach.

Pewnie chcesz zapytać: „Ale czy to nie jest po prostu ponowne wdrożenie <picture> i srcset w backendzie?”.

W pewnym sensie tak, ale z jedną ważną różnicą: gdy aplikacja używa wskazówek dotyczących klienta do tworzenia odpowiedzi multimedialnych, większość (jeśli nie wszystkie) zadań jest znacznie łatwiejsza do zautomatyzowania, co może obejmować usługę (np. CDN), która może to zrobić w Twoim imieniu. W przypadku rozwiązań HTML trzeba napisać nowy znacznik, aby obsłużyć każdy przypadek użycia. Oczywiście, możesz zautomatyzować generowanie znaczników. Jeśli jednak zmieni się projekt lub wymagania, prawdopodobnie w przyszłości trzeba będzie ponownie przeanalizować strategię automatyzacji.

Wskazówki dotyczące klienta umożliwiają rozpoczęcie od bezstratnego obrazu o wysokiej rozdzielczości, którego rozmiar można następnie dynamicznie zmieniać, aby był optymalny dla każdej kombinacji ekranu i układu. W przeciwieństwie do srcset, który wymaga podania stałej listy możliwych obrazów, spośród których przeglądarka może wybierać, to podejście może być bardziej elastyczne. srcset wymusza oferowanie przeglądarkom ograniczonego zestawu wariantów – np. 256w, 512w, 768w i 1024w – natomiast rozwiązanie oparte na wskazówkach klienta może obsługiwać wszystkie szerokości bez konieczności stosowania ogromnej ilości znaczników.

Oczywiście nie musisz samodzielnie pisać logiki wyboru obrazu. Cloudinary używa wskazówek dotyczących klienta do tworzenia odpowiedzi dotyczących obrazów, gdy używasz parametru w_auto. Zaobserwowano, że użytkownicy pobierali średnio o 42% mniej bajtów, gdy korzystali z przeglądarek obsługujących wskazówki dotyczące klienta.

Uważaj jednak! Zmiany w wersji Chrome 67 na komputery spowodowały usunięcie obsługi współdzielenia wskazówek klienta. Na szczęście te ograniczenia nie mają wpływu na mobilne wersje Chrome i zostaną całkowicie zniesione na wszystkich platformach, gdy zakończymy prace nad zasadami dotyczącymi funkcji.

Pomoc użytkownikom z wolnymi połączeniami sieciowymi

Wydajność adaptacyjna to koncepcja, zgodnie z którą możemy dostosowywać sposób dostarczania zasobów na podstawie informacji udostępnianych nam przez wskazówki dotyczące klienta, a konkretnie informacji dotyczących bieżącego stanu połączenia sieciowego użytkownika.

W przypadku witryny Sconnie Timber podejmujemy działania mające na celu zmniejszenie obciążenia, gdy sieci są wolne. W naszym kodzie backendu sprawdzamy nagłówki Save-Data, ECT, RTT i Downlink. Następnie generujemy wynik jakości sieci, który pozwala nam określić, czy powinniśmy interweniować, aby poprawić wrażenia użytkownika. Wynik sieci mieści się w zakresie od 0 do 1, gdzie 0 oznacza najgorszą możliwą jakość sieci, a 1 – najlepszą.

Najpierw sprawdzamy, czy Save-Data jest obecny. Jeśli tak, wynik jest ustawiany na 0, ponieważ zakładamy, że użytkownik chce, abyśmy zrobili wszystko, co konieczne, aby strona działała szybciej i była lżejsza.

Jeśli jednak nie ma wskazówki Save-Data, przechodzimy dalej i bierzemy pod uwagę wartości wskazówek ECT, RTT i Downlink, aby obliczyć wynik opisujący jakość połączenia sieciowego. Kod źródłowy generowania oceny sieci jest dostępny na GitHubie. Wniosek jest taki, że jeśli w jakiś sposób wykorzystamy wskazówki dotyczące sieci, możemy poprawić wrażenia użytkowników, którzy korzystają z wolnych sieci.

Porównanie witryny, która nie używa wskazówek klienta do dostosowywania się do wolnego połączenia sieciowego (po lewej), i tej samej witryny, która ich używa (po prawej).
Rysunek 2. Strona „O nas” w witrynie firmy działającej lokalnie. Podstawowa wersja obejmuje czcionki internetowe, kod JavaScript do obsługi karuzeli i akordeonu oraz obrazy. Możemy pominąć te elementy, gdy sieć działa zbyt wolno, aby szybko je wczytać.

Gdy witryny dostosowują się do informacji dostarczanych przez wskazówki dotyczące klienta, nie musimy stosować podejścia „wszystko albo nic”. Możemy inteligentnie decydować, które zasoby wysłać. Możemy zmodyfikować logikę wyboru obrazów elastycznych, aby wysyłać obrazy o niższej jakości na dany wyświetlacz i przyspieszyć wczytywanie, gdy jakość sieci jest niska.

W tym przykładzie widzimy, jak wskazówki dotyczące klienta wpływają na poprawę wydajności witryn w wolniejszych sieciach. Poniżej znajduje się wodospad WebPagetest witryny w wolnej sieci, która nie dostosowuje się do wskazówek dotyczących klienta:

Wodospad WebPagetest witryny Sconnie Timber, która wczytuje wszystkie zasoby przy wolnym połączeniu sieciowym.
Rysunek 3. Witryna wymagająca dużej ilości zasobów, która wczytuje obrazy, skrypty i czcionki przy wolnym połączeniu.

A teraz wodospad dla tej samej witryny na tym samym wolnym połączeniu, ale tym razem witryna używa wskazówek dotyczących klienta do eliminowania niekrytycznych zasobów strony:

Wodospad WebPagetest witryny Sconnie Timber, która używa wskazówek dotyczących klienta, aby nie wczytywać niekrytycznych zasobów przy wolnym połączeniu sieciowym.
Rysunek 4. Ta sama witryna na tym samym połączeniu, ale bez zasobów, które nie są niezbędne, dzięki czemu wczytuje się szybciej.

Wskazówki dotyczące klienta skróciły czas wczytywania strony z ponad 45 sekund do mniej niż 1/10 tego czasu. Korzyści płynące ze wskazówek dotyczących klienta w tym scenariuszu są nie do przecenienia i mogą być bardzo przydatne dla użytkowników, którzy szukają ważnych informacji w wolnych sieciach.

Można też używać wskazówek dotyczących klienta bez zakłócania działania przeglądarek, które ich nie obsługują. Jeśli na przykład chcemy dostosować dostarczanie zasobów za pomocą wartości wskazówki ECT, a jednocześnie zapewnić pełną funkcjonalność w przeglądarkach, które nie obsługują tej wskazówki, możemy ustawić powrót do wartości domyślnej w ten sposób:

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

W tym przypadku "4g" reprezentuje połączenie sieciowe o najwyższej jakości, które opisuje nagłówek ECT. Jeśli zainicjujemy $ect na "4g", nie będzie to miało wpływu na przeglądarki, które nie obsługują wskazówek klienta. Opt-in FTW!

Uważaj na pamięci podręczne.

Za każdym razem, gdy zmieniasz odpowiedź na podstawie nagłówka HTTP, musisz pamiętać o tym, jak pamięci podręczne będą obsługiwać przyszłe pobrania tego zasobu. Nagłówek Vary jest tu niezbędny, ponieważ przypisuje wpisy w pamięci podręcznej do wartości podanych w nagłówkach żądania. Mówiąc prościej, jeśli modyfikujesz odpowiedź na podstawie danego nagłówka żądania HTTP, prawie zawsze musisz uwzględnić ten nagłówek żądania w Vary w ten sposób:

Vary: DPR, Width

Jest jednak duże zastrzeżenie: nigdy nie należy Vary odpowiedzi, które można zapisać w pamięci podręcznej, w często zmieniającym się nagłówku (np. Cookie), ponieważ te zasoby stają się niemożliwe do zapisania w pamięci podręcznej. W związku z tym warto unikać Vary nagłówków wskazówek dotyczących klienta, takich jak RTT lub Downlink, ponieważ są to czynniki związane z połączeniem, które mogą się często zmieniać. Jeśli chcesz zmodyfikować odpowiedzi w tych nagłówkach, rozważ użycie klucza tylko w nagłówku ECT, co zminimalizuje liczbę braków w pamięci podręcznej.

Oczywiście dotyczy to tylko sytuacji, gdy buforujesz odpowiedź. Na przykład nie będziesz przechowywać w pamięci podręcznej zasobów HTML, jeśli ich zawartość jest dynamiczna, ponieważ może to pogorszyć wrażenia użytkownika podczas kolejnych wizyt. W takich przypadkach możesz zmodyfikować odpowiedzi na podstawie dowolnych kryteriów, które uznasz za konieczne, i nie musisz się przejmować Vary.

Wskazówki dotyczące klienta w skryptach service worker

Negocjowanie treści nie jest już tylko dla serwerów. Skrypty service worker działają jako serwery proxy między klientami a serwerami, dzięki czemu masz kontrolę nad tym, jak zasoby są dostarczane przez JavaScript. Obejmuje to wskazówki dotyczące klienta. W zdarzeniu fetch skryptu service worker możesz użyć metody request.headers.get obiektu event, aby odczytać nagłówki żądania zasobu w ten sposób:

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!
    })(),
  );
});

W ten sposób można odczytać każdy nagłówek wskazówek dotyczących klienta, który wybierzesz. Nie jest to jednak jedyny sposób na uzyskanie niektórych z tych informacji. Wskazówki dotyczące sieci można odczytać w tych odpowiednich właściwościach JavaScriptu w obiekcie navigator:

Wskazówka dotycząca klienta Odpowiednik w JS
`ECT` `navigator.connection.effectiveType`
`RTT` `navigator.connection.rtt`
`Save-Data` `navigator.connection.saveData`
`Downlink` `navigator.connection.downlink`
Device-Memory `navigator.deviceMemory`
Wtyczki Imagemin do różnych typów plików.

Te interfejsy API nie są dostępne wszędzie, dlatego musisz sprawdzić, czy dana funkcja jest dostępna, za pomocą operatora in:

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

Możesz tu użyć logiki podobnej do tej, której używasz na serwerze, z tą różnicą, że nie potrzebujesz serwera do negocjowania treści za pomocą wskazówek dotyczących klienta. Skrypty service worker mogą przyspieszyć działanie aplikacji i zwiększyć jej odporność na błędy, ponieważ umożliwiają wyświetlanie treści, gdy użytkownik jest offline.

Już kończę

Dzięki wskazówkom dotyczącym klienta możemy przyspieszyć działanie witryn dla użytkowników w sposób w pełni progresywny. Możemy wyświetlać multimedia na podstawie możliwości urządzenia użytkownika w sposób, który ułatwia wyświetlanie obrazów elastycznych w porównaniu z używaniem atrybutów <picture> i srcset, zwłaszcza w przypadku złożonych zastosowań. Dzięki temu możemy nie tylko skrócić czas i zmniejszyć nakład pracy po stronie programistów, ale też zoptymalizować zasoby – zwłaszcza obrazy – w sposób, który pozwala lepiej dopasować je do ekranów użytkowników, niż jest to możliwe przy użyciu tagów i srcset.

Co ważniejsze, możemy wykrywać słabe połączenia sieciowe i pomagać użytkownikom, modyfikując to, co wysyłamy, i sposób, w jaki to robimy. Może to znacznie ułatwić dostęp do witryn użytkownikom korzystającym z niestabilnych sieci. W połączeniu ze skryptami service worker możemy tworzyć niesamowicie szybkie witryny, które są dostępne offline.

Wskazówki dotyczące klienta są dostępne tylko w Chrome i przeglądarkach opartych na Chromium, ale można ich używać w taki sposób, aby nie obciążały przeglądarek, które ich nie obsługują. Rozważ użycie wskazówek dotyczących klienta, aby tworzyć naprawdę inkluzywne i elastyczne rozwiązania, które uwzględniają możliwości urządzeń wszystkich użytkowników i sieci, z którymi się łączą. Mamy nadzieję, że inni dostawcy przeglądarek dostrzegą ich wartość i będą chcieli je wdrożyć.

Zasoby

Dziękujemy Ilyi Grigorikowi, Ericowi Portisowi, Jeffowi Posnickowi, Yoavowi Weissowi i Estelle Weyl za cenne uwagi i poprawki do tego artykułu.