Tworzenie witryn, które są szybkie wszędzie, może być trudne. Mnóstwo możliwości urządzeń i jakość sieci, z którymi się łączą, mogą sprawiać, że wydaje się to nie do końca wyzwanie. Chociaż możemy korzystać z funkcji przeglądarki, aby poprawić wydajność wczytywania, jak możemy określić możliwości urządzenia użytkownika lub jakość jego połączenia z internetem? Rozwiązaniem są wskazówki dla klienta.
Wskazówki klienta to zestaw nagłówków żądań HTTP, które umożliwiają nam uzyskanie informacji o tych aspektach urządzenia użytkownika i sieci, z którą jest połączony. Korzystając z tych informacji po stronie serwera, możemy zmienić sposób dostarczania treści na podstawie warunków na urządzeniu lub w sieci. Pomoże nam to tworzyć bardziej zintegrowane usługi.
Wszystko zależy od negocjacji treści
Wskazówki klienta to kolejna metoda negocjowania treści, która polega na zmianie odpowiedzi treści na podstawie nagłówków żądań przeglądarki.
Przykładem negocjacji treści jest nagłówek żądania Accept. Opisuje typy treści odczytywane przez przeglądarkę, których serwer może użyć do negocjowania odpowiedzi. W przypadku żądań obrazów zawartość nagłówka Accept w Chrome to:
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Wszystkie przeglądarki obsługują formaty graficzne, takie jak JPEG, PNG i GIF, jednak Accept informuje, że w tym przypadku przeglądarka również obsługuje WebP i APNG. Dzięki tym informacjom możemy negocjować najlepsze typy obrazów dla poszczególnych przeglądarek:
<?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 klienta to kolejna droga do negocjowania treści, ale w kontekście możliwości urządzenia i warunków sieci. Dzięki wskazówkom 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ć dostarczane użytkownikom w warunkach złej jakości sieci. W tym przewodniku opisujemy wszystkie dostępne wskazówki i sposoby ich wykorzystania, aby ułatwić użytkownikom odbiór treści.
Włączanie opcji
W przeciwieństwie do nagłówka Accept podpowiedzi klienta nie pojawiają się magicznie (z wyjątkiem Save-Data, o którym opowiemy później). Aby ograniczyć liczbę nagłówków żądania, musisz określić, które wskazówki klienta chcesz otrzymywać, wysyłając nagłówek Accept-CH, gdy użytkownik zażąda zasobu:
Accept-CH: Viewport-Width, Downlink
Wartość parametru Accept-CH to lista wskazówek żądanych przez witrynę, oddzielonych przecinkami, których będzie używać do określania wyników kolejnych żądań zasobów. Gdy klient odczytuje ten nagłówek, zobaczy informację „ta witryna chce korzystać z wskazówek klienta Viewport-Width i Downlink”. Nie musisz się martwić o konkretne wskazówki.
Zajmiemy się nimi za chwilę.
Te nagłówki zgody możesz skonfigurować w dowolnym języku obsługiwanym na zapleczu. Możesz na przykład użyć funkcji header w PHP.
Możesz też ustawić te nagłówki z opcją opt-in 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 klienta opisują 1 z 2 rzeczy: urządzenie, którego używają użytkownicy, oraz sieć, której używają, aby uzyskać dostęp do Twojej witryny. Omówmy pokrótce wszystkie dostępne wskazówki.
Wskazówki dotyczące urządzeń
Niektóre wskazówki klienta opisują cechy urządzenia użytkownika, zwykle cechy ekranu. Niektóre pomagają wybrać optymalne zasoby multimedialne dla danego ekranu użytkownika, ale nie wszystkie muszą być skoncentrowane na multimediach.
Zanim przejdziemy do tej listy, warto poznać kilka kluczowych terminów używanych do opisu ekranów i rozdzielczości multimediów:
Pierwotny rozmiar: rzeczywiste wymiary zasobu multimedialnego. Jeśli na przykład otworzysz obraz w Photoshopie, wymiary widoczne w oknie dialogowym z rozmiarem obrazu opisują jego właściwy rozmiar.
Rozmiar wewnętrzny z poprawioną gęstością: wymiary zasobu multimedialnego po jego korekcie pod kątem gęstości pikseli. Jest to rozmiar wewnętrzny obrazu podzielony przez stosunek liczby pikseli urządzenia. Weźmy na przykład ten znacznik:
<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 rozmiar obrazu 1x w tym przypadku wynosi 320 x 240, a obrazu 2x – 640 x 480. Jeśli ten znacznik jest analizowany przez klienta zainstalowanego na urządzeniu o współczynniku pikseli ekranu równym 2 (np. ekran Retina), wysyłane jest żądanie obrazu 2x. Rozmiar wewnętrzny z poprawioną gęstością obrazu 2x to 320 x 240, ponieważ 640 x 480 podzielony przez 2 to 320 x 240.
Rozmiar zewnętrzny: rozmiar zasobu multimedialnego po zastosowaniu do niego 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 320 x 240 z poprawioną gęstością, ale ma też właściwości CSS width i height z zastosowanymi odpowiednio wartościami 256px i 192px. W tym przykładzie zewnętrzny rozmiar elementu <img> wynosi 256 x 192.
width: 256px; i height: 192px; spowoduje przekształcenie obrazu o właściwym rozmiarze 320 x 240 w obraz o zewnętrznym rozmiarze 256 x 192.Po zapoznaniu się z terminologią przejdźmy do listy podpowiedzi dotyczących klienta dostępnych na poszczególnych urządzeniach.
Szerokość widocznego obszaru
Viewport-Width to szerokość widocznego obszaru w pikselach CSS:
Viewport-Width: 320
Ten hint może być używany z innymi hintami dotyczącymi ekranu w celu wyświetlania różnych wersji obrazu (np. przycięć) optymalnych dla określonych rozmiarów ekranu (np. kierunek artystyczny) lub pomijania zasobów, które nie są potrzebne przy bieżącej szerokości ekranu.
DPR
DPR, czyli skrót od współczynnika pikseli urządzenia, podaje stosunek fizycznych pikseli do pikseli CSS ekranu użytkownika:
DPR: 2
Ten podpowiedź jest przydatny podczas wybierania źródeł obrazów, które odpowiadają gęstości pikseli ekranu (jak w przypadku atrybutów x w atrybucie srcset).
Szerokość
Wskazówka Width pojawia się w przypadku zapytań o zasoby obrazów wywołanych przez tagi <img> lub <source> za pomocą atrybutu sizes.
sizes informuje przeglądarkę, jaki będzie rozmiar zewnętrzny zasobu;
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 żąda strony o szerokości 320 pikseli CSS i współczynniku DPR 2. Urządzenie wczytuje dokument z elementem <img> zawierającym wartość atrybutu sizes równą 85vw (np. 85% szerokości widocznego obszaru w przypadku wszystkich rozmiarów ekranu). Jeśli opcja Width jest włączona, klient wyśle Width do serwera z prośbą o src:
Width: 544
W tym przypadku klient sugeruje serwerowi, że optymalna szerokość bezwzględna żądanego obrazu powinna wynosić 85% szerokości widoku (272 piksele) pomnożonej przez DPR ekranu (2), co daje 544 piksele.
Ten podpowiedź jest szczególnie skuteczny, ponieważ bierze pod uwagę nie tylko szerokość ekranu skorygowaną pod kątem gęstości, ale też dopasowuje tę ważną informację do rozmiaru zewnętrznego obrazu w ramach układu. Umożliwia to serwerom negocjowanie odpowiedzi obrazów, które są optymalne zarówno dla ekranu, jak i dla układu.
Content-DPR
Wiesz już, że ekrany mają współczynnik pikseli urządzenia, ale zasoby mają też własne współczynniki pikseli. W najprostszych przypadkach wyboru zasobów współczynniki pikseli między urządzeniami a zasobami mogą być takie same. Ale! W sytuacjach, gdy uwzględniane są zarówno nagłówki DPR, jak i Width, rozmiar zewnętrzny zasobu może powodować scenariusze, w których te dwa warunki się różnią. Wtedy przydaje się podpowiedź Content-DPR.
W odróżnieniu od innych wskazówek klienta Content-DPR nie jest nagłówkiem żądania, który serwery mogą używać, ale nagłówkiem odpowiedzi, który serwery muszą wysyłać, gdy do wybrania zasobu używane są wskazówki DPR i Width. Wartość Content-DPR powinna być wynikiem tego równania:
Content-DPR = [wybrany rozmiar zasobu obrazu] / ([Width] / [DPR])
Gdy zostanie wysłany nagłówek żądania Content-DPR, przeglądarka wie, jak przeskalować dany obraz pod kątem współczynnika pikseli urządzenia i układu ekranu. Bez niego obrazy mogą nie skalować się prawidłowo.
Pamięć urządzenia
Technicznie jest to część interfejsu API dotyczącego pamięci urządzenia, Device-Memory, która ujawnia przybliżoną ilość pamięci w GB na bieżącym urządzeniu:
Device-Memory: 2
Możliwe zastosowanie tego podpowiedzi to ograniczenie ilości kodu JavaScript przesyłanego do przeglądarek na urządzeniach z ograniczoną pamięcią, ponieważ JavaScript to typ treści, który zużywa najwięcej zasobów. Możesz też wysyłać obrazy o niższym DPR, ponieważ zajmują one mniej pamięci podczas dekodowania.
Wskazówki dotyczące sieci
Interfejs Network Information API udostępnia kolejną kategorię wskazówek klienta, które opisują wydajność połączenia z siecią 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 o wolnych połączeniach.
RTT
Wskazówka RTT podaje przybliżony czas błądzenia w milisekundach w warstwie aplikacji. Wskazówka RTT, w przeciwieństwie do RTT w warstwie transportu, uwzględnia czas przetwarzania serwera.
RTT: 125
Ten podpowiedź jest przydatny, ponieważ opóźnienie ma wpływ na wydajność wczytywania.
Dzięki wskazówce RTT możemy podejmować decyzje na podstawie responsywności sieci, co może pomóc w przyspieszeniu dostarczenia całego doświadczenia (np. przez pominięcie niektórych żądań).
Link do strony docelowej
Czas oczekiwania jest ważny w kontekście wczytywania, ale na wydajność ma również wpływ przepustowość. Wskazówka Downlink, wyrażona w megabitach na sekundę (Mb/s), pokazuje przybliżoną prędkość przesyłania danych w dół przez połączenie użytkownika:
Downlink: 2.5
W połączeniu z RTT funkcja Downlink może być przydatna do zmiany sposobu dostarczania treści użytkownikom na podstawie jakości połączenia z internetem.
ECT
Wskazówka ECT oznacza użyty typ połączenia. Jego wartość jest jedną z wymienionych na liście typów połączeń, z których każdy opisuje połączenie w określonym zakresie wartości RTT i Downlink.
Ten nagłówek nie wyjaśnia rzeczywistego typu połączenia, np. nie informuje o tym, czy brama to nadajnik telefonii komórkowej czy punkt dostępu Wi-Fi. Analizuje on natomiast opóźnienie i przepustowość bieżącego połączenia oraz określa, który profil sieci najbardziej przypomina ten profil. Jeśli na przykład połączysz się przez Wi-Fi z wolną siecią, ECT może zostać wypełnione wartością 2g, która jest najbliższym przybliżeniem skutecznego połączenia:
ECT: 2g
Prawidłowe wartości dla ECT to 4g, 3g, 2g i slow-2g. Ten podpowiedź może służyć jako punkt wyjścia do oceny jakości połączenia, a następnie do dopracowania za pomocą podpowiedzi RTT i Downlink.
Save-Data
Save-Data to nie tyle wskazówka dotycząca warunków w sieci, ile preferencja użytkownika, która mówi, że strony powinny wysyłać mniej danych.
Uważam, że Save-Data należy zaklasyfikować jako podpowiedź sieci, ponieważ wiele czynności, które można z nią wykonać, jest podobnych do innych podpowiedzi sieci. Użytkownicy mogą też włączać tę funkcję w środowiskach o dużej przepustowości lub małej przepustowości. Ta wskazówka zawsze wygląda tak:
Save-Data: on
W Google rozmawialiśmy o tym, co możesz zrobić za pomocą Save-Data.
Ich wpływ na skuteczność reklam może być ogromny. To sygnał, że użytkownicy dosłownie proszą o mniejszą liczbę wiadomości. Jeśli weźmiesz pod uwagę ich opinie i zaczniesz działać zgodnie z nimi, użytkownicy to docenią.
Jak zastosować teorię w praktyce
To, co zrobisz z podpowiedziami klienta, zależy od Ciebie. Ponieważ zawierają one tak dużo informacji, masz wiele opcji. Aby zainspirować Cię do tworzenia, zastanówmy się, jak wskazówki dotyczące klienta mogą pomóc Sconnie Timber, fikcyjnej firmie zajmującej się wyrębem drzewa, która działa na obszarach wiejskich w środkowej części USA. Jak to często bywa w odległych miejscach, połączenia sieciowe mogą być niestabilne. Właśnie w takich sytuacjach technologie takie jak wskazówki dotyczące klienta mogą naprawdę pomóc użytkownikom.
Obrazy elastyczne
Wszystkie przypadki użycia obrazów elastycznych, z wyjątkiem najprostszych, mogą być skomplikowane. Co zrobić, jeśli masz wiele metod i wariantów tych samych obrazów na różne rozmiary ekranu oraz w różnych formatach? Ten znacznik staje się bardzo skomplikowany bardzo
szybko.
Łatwo popełnić błąd, zapomnieć lub źle zrozumieć ważne pojęcia (np. sizes).
Chociaż <picture> i srcset to niewątpliwie ś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 udostępniane przez <picture> i srcset są na tyle złożone, że ich automatyzacja musi być przeprowadzona w sposób, który zachowuje ich elastyczność.
Możesz to uprościć, korzystając ze wskazówek klienta. Negocjowanie odpowiedzi na obrazy za pomocą podpowiedzi klienta może wyglądać tak:
- Jeśli jest to odpowiednie w Twoim przypadku, najpierw wybierz sposób wyświetlania obrazu (np. obraz kierowany przez artystę), zaznaczając podpowiedź
Viewport-Width. - Wybierz rozdzielczość obrazu, zaznaczając podpowiedź
WidthiDPRoraz wybierając źródło, które pasuje do rozmiaru układu obrazu i gęstości ekranu (podobnie jak w przypadku opisuxiwwsrcset). - Wybierz optymalny format pliku obsługiwany przez przeglądarkę (co
Acceptpomaga nam w większości przeglądarek).
Niepokoiło to mojego fikcyjnego klienta, który tworzy drewno, i stworzyłem w języku PHP rutynę doboru obrazów elastycznych, która korzysta ze wskazówek dla klientów. Oznaczało to, że zamiast wysyłać te znaczniki 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ć je do następujących wartości dostosowanych do obsługi poszczególnych przeglądarek:
<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 zastąpione przez mod_rewrite. Pobiera ona nazwę pliku graficznego i dodatkowe parametry, które pozwalają skryptowi backendu wybrać najlepszy obraz w danych warunkach.
Zakładam, że Twoje pierwsze pytanie brzmi „Czy to tylko ponowne wdrożenie funkcji <picture> i srcset na zapleczu?”.
W pewnym sensie tak, ale z ważną różnicą: gdy aplikacja używa podpowiedzi klienta do tworzenia odpowiedzi medialnych, 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. Natomiast w przypadku rozwiązań HTML trzeba utworzyć nowe znaczniki, żeby uwzględnić je w każdym przypadku użycia. Oczywiście możesz zautomatyzować generowanie znaczników. Jeśli jednak zmienisz projekt lub wymagania, być może w przyszłości będziesz musiał ponownie zastanowić się nad strategią automatyzacji.
Wskazówki klienta umożliwiają rozpoczęcie od bezstratnego obrazu w wysokiej rozdzielczości, którego rozmiar można następnie dynamicznie zmieniać, aby uzyskać optymalne rozwiązanie dla dowolnej kombinacji ekranu i schematu. W przeciwieństwie do funkcji srcset, która wymaga wyliczenia stałej listy możliwych obrazów do wyboru przez przeglądarkę, ta metoda może być bardziej elastyczna. Podczas gdy srcset zmusza Cię do oferowania przeglądarkom nieprecyzyjnego zestawu wersji, np. 256w, 512w, 768w i 1024w, rozwiązanie oparte na wskazówkach klienta może wyświetlać wszystkie szerokości bez konieczności stosowania ogromnej ilości znaczników.
Oczywiście nie musisz samodzielnie pisać logiki wyboru obrazu. Cloudinary używa podpowiedzi klienta do tworzenia odpowiedzi obrazowych, gdy używasz parametru w_auto. Zauważyliśmy, że średnio użytkownicy pobierają o 42% mniej bajtów, gdy korzystają z przeglądarek obsługujących podpowiedzi klienta.
Tylko uważaj! Zmiany w wersji na komputery stacjonarne Chrome 67 spowodowały wycofanie obsługi podpowiedzi klienta w innych domenach. Na szczęście te ograniczenia nie dotyczą wersji mobilnych przeglądarki Chrome, a zostaną całkowicie zniesione na wszystkich platformach, gdy zakończymy prace nad zasadami dotyczącymi funkcji.
Pomoc dla użytkowników korzystających z powolnych sieci
Adaptacyjna wydajność to koncepcja polegająca na dostosowywaniu sposobu dostarczania zasobów na podstawie informacji udostępnianych przez klienta. Chodzi tu konkretnie o informacje dotyczące bieżącego stanu połączenia z siecią użytkownika.
W przypadku witryny Sconnie Timber podejmujemy działania, aby zmniejszyć obciążenie sieci, gdy są one wolne. W naszym kodzie back-endu sprawdzamy nagłówki Save-Data, ECT, RTT i Downlink. Następnie generujemy wynik jakości sieci, który pozwala nam określić, czy należy podjąć działania w celu poprawy jakości. Wynik ten mieści się w zakresie od 0 do 1, gdzie 0 to najgorsza możliwa jakość sieci, a 1 – najlepsza.
Najpierw sprawdzamy, czy występuje Save-Data. Jeśli tak jest, wynik jest ustawiony na 0, ponieważ zakładamy, że użytkownik chce, abyśmy zrobili wszystko, co jest konieczne, aby korzystanie z aplikacji było lżejsze i szybsze.
Jeśli jednak nie ma atrybutu Save-Data, przechodzimy dalej i uwzględniamy wartości atrybutów ECT, RTT i Downlink, aby obliczyć wynik opisujący jakość połączenia z siecią. Kod źródłowy służący do generowania wyników sieci jest dostępny na GitHubie. Pamiętaj, że jeśli w pewny sposób użyjemy wskazówek dotyczących sieci, będziemy mogli poprawić wrażenia użytkowników korzystających z wolniejszych sieci.
Kiedy witryny dostosowują się do informacji podanych przez klienta, nie musimy stosować modelu „wszystko albo nic”. Możemy inteligentnie decydować, które zasoby wysłać. Możemy zmodyfikować naszą logikę wyboru obrazów dostosowanych do wyświetlacza, aby przesyłać obrazy o niższej jakości dla danego wyświetlacza, co przyspieszy wczytywanie, gdy jakość sieci jest niska.
W tym przykładzie widać wpływ wskazówek klienta na poprawę wydajności witryn w wolniejszych sieciach. Poniżej znajduje się kaskada WebPagetest witryny w wolnej sieci, która nie dostosowuje się do wskazówek klienta:
A teraz kaskada dla tej samej witryny na tym samym wolnym połączeniu, ale tym razem witryna używa wskazówek klienta, aby wyeliminować niekrytyczne zasoby strony:
Wskazówki klienta skróciły czas wczytywania strony z ponad 45 sekund do mniej niż jednej dziesiątej tego czasu. W tym scenariuszu trudno przecenić zalet podpowiedzi klienta, które mogą być bardzo przydatne dla użytkowników szukających ważnych informacji w wolnych sieciach.
Ponadto w przypadku przeglądarek, które nie obsługują wskazówek klienta, można używać tych wskazówek bez wpływu na wrażenia użytkowników. Jeśli na przykład chcemy dostosować dostarczanie zasobów, korzystając z wartości podpowiedzi ECT, a jednocześnie zapewnić pełną funkcjonalność w nieobsługiwanych przeglądarkach, możemy ustawić wartość domyślną 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 najwyższą jakość połączenia sieciowego, jak opisano w nagłówku ECT. Jeśli zainicjujemy $ect w "4g", nie wpłynie to na przeglądarki, które nie obsługują wskazówek dla klienta. Zaakceptuj, to jest to!
Uważaj na skrytki!
Zawsze, gdy zmieniasz odpowiedź na podstawie nagłówka HTTP, musisz wiedzieć, jak bufory będą obsługiwać przyszłe pobieranie tego zasobu. Nagłówek Vary jest tutaj niezbędny, ponieważ służy do kluczowania wpisów w pamięci podręcznej do wartości nagłówków żądania. Krótko mówiąc, jeśli modyfikujesz jakąkolwiek odpowiedź na podstawie danego nagłówka żądania HTTP, prawie zawsze musisz uwzględnić ten nagłówek w Varyna przykład:
Vary: DPR, Width
Istnieje jednak poważne zastrzeżenie: nigdy nie chcesz Varybuforować odpowiedzi w często zmieniającym się nagłówku (np. Cookie), ponieważ tych zasobów nie można zapisywać w pamięci podręcznej. Mając to na uwadze, możesz unikać Varyw nagłówkach wskazówek klienta, takich jak RTT czy Downlink, ponieważ są to czynniki połączenia, które mogą się dość często zmieniać. Jeśli chcesz zmodyfikować odpowiedzi na podstawie tych nagłówków, rozważ wpisanie tylko nagłówka ECT, co zminimalizuje błędy pamięci podręcznej.
Oczywiście dotyczy to tylko sytuacji, gdy odpowiedź jest przechowywana w pamięci podręcznej.
Nie zapisuj np. w pamięci podręcznej zasobów HTML, jeśli ich zawartość jest dynamiczna, ponieważ może to negatywnie wpłynąć na wrażenia użytkownika przy kolejnych wizytach. W takich przypadkach możesz modyfikować takie odpowiedzi w dowolny sposób, nie martwiąc się o to, czy Vary.
Wskazówki dotyczące klienta w usługach działających w tle
Negocjacje treści nie dotyczą już tylko serwerów. Ponieważ serwisowe workery działają jako serwery proxy między klientami a serwerami, masz kontrolę nad tym, jak zasoby są dostarczane za pomocą JavaScriptu. Obejmuje to wskazówki klienta. W zdarzeniu service workerfetch 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żesz odczytywać każdy nagłówek ze wskazówkami dla klienta. To nie jedyny sposób, aby uzyskać te informacje. Wskazówki specyficzne dla sieci można odczytywać w tych równoważnych właściwościach JavaScript w obiekcie navigator:
| Wskazówka dotycząca klienta | Odpowiednik w JS |
|---|---|
| `ECT` | `navigator.connection.effectiveType` |
| `RTT` | `navigator.connection.rtt` |
| Zapisz dane | `navigator.connection.saveData` |
| `Downlink` | `navigator.connection.downlink` |
| `Device-Memory` | `navigator.deviceMemory` |
Te interfejsy API nie są dostępne wszędzie, dlatego przed użyciem danej funkcji skontaktuj się z inoperatorem:
if ('connection' in navigator) {
// Work with netinfo API properties in JavaScript!
}
Tutaj możesz użyć logiki podobnej do tej, której używasz na serwerze, z tą różnicą, że nie musisz negocjować treści z podpowiedziami klienta. Same mechanizmy Service Worker mogą przyspieszyć działanie i zwiększyć odporność na działanie związane z dodatkową możliwością wyświetlania treści, gdy użytkownik jest offline.
Podsumowanie
Dzięki wskazówkom klienta możemy przyspieszyć działanie aplikacji w sposób stopniowy. Możemy wyświetlać multimedia na podstawie możliwości urządzenia użytkownika w sposób, który ułatwia wyświetlanie elastycznych obrazów niż <picture> i srcset, zwłaszcza w złożonych przypadkach użycia. Dzięki temu możemy nie tylko skrócić czas i wysiłek po stronie programisty, lecz także zoptymalizować zasoby – w szczególności obrazy – w sposób precyzyjniejszy niż
Co ważniejsze, możemy wykrywać słabe połączenia sieciowe i zapewnić użytkownikom płynność działania, zmieniając to, co i jak wysyłamy. W ten sposób możemy ułatwić dostęp do witryn użytkownikom korzystającym z niestabilnych sieci. W połączeniu ze swoimi mechanizmami Service Worker możemy tworzyć niezwykle szybkie witryny dostępne offline.
Wskazówki 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ć przeglądarek, które ich nie obsługują. Zastanów się nad użyciem wskazówek klienta, aby tworzyć naprawdę wszechstronne i elastyczne rozwiązania, które uwzględniają możliwości urządzeń użytkowników i sieci, z którymi się łączą. Mamy nadzieję, że inni producenci przeglądarek dostrzegą ich wartość i zdecydują się na ich wdrożenie.
Zasoby
- Automatyczne elastyczne obrazy z podpowiedziami dla klienta
- Wskazówki dla klienta i obrazy elastyczne – co się zmieniło w Chrome 67
- Wskazówka dla klienta (Prezentacje)
- Tworzenie szybkich i lekkich aplikacji za pomocą
Save-Data
Dziękujemy Ilya Grigorik, Ericowi Porisowi, Jeffowi Posnickowi, Yoavowi Weissowi i Estelle Weyl za cenne opinie i poprawki dotyczące tego artykułu.