Szybsze wczytywanie stron dzięki funkcji wczesnych podpowiedzi z serwera

Dowiedz się, jak serwer może wysyłać do przeglądarki wskazówki dotyczące zasobów podrzędnych.

Czym są wczesne wskazówki?

Z czasem witryny internetowe stały się bardziej zaawansowane. Dlatego nie jest niczym niezwykłym, że serwer musi wykonywać proste czynności (na przykład uzyskiwać dostęp do baz danych lub sieci CDN uzyskujących dostęp do serwera pierwotnego), aby wygenerować kod HTML żądanej strony. Taki „czas myślenia serwera” powoduje dodatkowe opóźnienie, zanim przeglądarka zacznie renderować stronę. Połączenie pozostaje nieaktywne tak długo, jak długo serwer potrzebuje czasu na przygotowanie odpowiedzi.

Obraz przedstawiający 200-ms różnicy w czasie oczekiwania między wczytaniem strony a wczytaniem innych zasobów.
Bez wczesnej podpowiedzi: na serwerze wszystko jest blokowane przy określaniu odpowiedzi dla zasobu głównego.

Wczesne wskazówki to kod stanu HTTP (103 Early Hints) używany do wysyłania wstępnej odpowiedzi HTTP przed ostateczną odpowiedzią. Dzięki temu serwer może wysyłać do przeglądarki wskazówki dotyczące zasobów podrzędnych (np. arkuszy stylów strony, krytyczny kod JavaScript) lub źródeł, które prawdopodobnie będą używane przez stronę, gdy serwer jest zajęty generowaniem zasobu głównego. Przeglądarka może wykorzystać te wskazówki, aby przyspieszyć połączenia i poprosić o zasoby podrzędne podczas oczekiwania na zasób główny. Innymi słowy, funkcja Early Hints pomaga przeglądarce wykorzystać „czas myślenia serwera” przez wykonanie pewnych czynności z wyprzedzeniem, co przyspiesza wczytywanie strony.

Obraz pokazujący, jak funkcja Early Hints umożliwia stronie wysyłanie częściowych odpowiedzi.
W przypadku wczesnej podpowiedzi: serwer może wyświetlać częściową odpowiedź ze wskazówkami dotyczącymi zasobów, gdy określa ostateczną odpowiedź.

W niektórych przypadkach poprawa wydajności największego wyrenderowania treści może trwać nawet kilkaset milisekund (ze względu na Shopify i Cloudflare) lub nawet o sekundę szybciej, jak widać w porównaniu przed i po:

Porównanie dwóch witryn.
Porównanie wczesnych wskazówek w witrynie testowej wykonanej za pomocą narzędzia WebPageTest (Moto G4 – DSL)

Jak korzystać z funkcji wczesnych wskazówek

Pierwszym krokiem do skorzystania z wczesnych wskazówek jest wskazanie najpopularniejszych stron docelowych, czyli stron, od których zwykle rozpoczynają się użytkownicy po odwiedzeniu Twojej witryny. Może to być strona główna lub strony z popularnymi informacjami o produktach, jeśli wielu użytkowników odwiedza inne witryny. Punkty wejścia mają większe znaczenie niż inne strony, ponieważ przydatność wczesnych wskazówek maleje, gdy użytkownik porusza się po witrynie (czyli przy drugiej lub trzeciej kolejnej nawigacji przeglądarka ma więcej zasobów podrzędnych). Zawsze warto zrobić dobre pierwsze wrażenie.

Po przygotowaniu listy priorytetowej dla stron docelowych następnym krokiem jest określenie, które źródła lub zasoby podrzędne nadają się do wyświetlania w przypadku wskazówek preconnect lub preload. Zwykle są to źródła i zasoby podrzędne, które najbardziej wpływają na kluczowe wskaźniki dotyczące użytkowników, takie jak Największe wyrenderowanie treści czy Pierwsze wyrenderowanie treści. Dokładniej rzecz ujmując, poszukaj zasobów podrzędnych blokujących renderowanie, takich jak synchroniczny kod JavaScript, arkusze stylów, a nawet czcionki internetowe. Poszukaj też źródeł hostujących zasoby podrzędne, które w dużym stopniu wpływają na kluczowe dane o użytkownikach.

Pamiętaj też, że jeśli Twoje główne zasoby korzystają już z preconnect lub preload, możesz wziąć pod uwagę te źródła lub zasoby wśród kandydatów do wczesnych wskazówek. Więcej informacji znajdziesz w artykule o optymalizowaniu LCP. Jednak naiwne kopiowanie dyrektyw preconnect i preload z języka HTML do sekcji Wczesne wskazówki może nie być optymalne.

Gdy używasz ich w kodzie HTML, zazwyczaj zalecamy preconnect lub preload zasobów, których Preload Scanner nie wykrywa w kodzie HTML, na przykład czcionek czy obrazów tła, które w przeciwnym razie zostałyby wykryte za późno. W przypadku wczesnej wersji kod HTML jest niedostępny, więc lepiej preconnect przekierowywać do krytycznych domen lub preload krytycznych zasobów, które w przeciwnym razie byłyby wykrywane na wczesnym etapie kodu HTML. Przykładem może być wstępne wczytywanie main.css lub app.js. Poza tym nie wszystkie przeglądarki obsługują funkcję preload we wczesnej fazie obsługi – więcej informacji znajdziesz w sekcji Obsługa przeglądarek.

Drugi etap polega na zminimalizowaniu ryzyka używania wczesnych wskazówek w przypadku zasobów lub źródeł, które mogą być nieaktualne lub nieużywane przez zasób główny. Na przykład zasoby, które są często aktualizowane i mają różne wersje (np. example.com/css/main.fa231e9c.css), mogą nie być najlepszym wyborem. Pamiętaj, że problem nie dotyczy wczesnych wskazówek i dotyczy wszystkich elementów preload i preconnect, niezależnie od tego, gdzie się znajdują. Jest to rodzaj szczegółu, który najlepiej się sprawdza w przypadku automatyzacji lub tworzenia szablonów (np. w przypadku procesów ręcznych istnieje większe prawdopodobieństwo, że doprowadzi to do niezgodności haszu lub adresu URL wersji między ciągiem preload a rzeczywistym tagiem HTML korzystającym z zasobu).

Weźmy jako przykład taki przepływ:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]

Serwer przewiduje, że będzie potrzebny main.abcd100.css, i sugeruje wstępne wczytanie go przy użyciu wczesnych wskazówek:

103 Early Hints
Link: </main.abcd100.css>; rel=preload; as=style
[...]

Po kilku chwilach wyświetla się strona internetowa wraz z podlinkowaną usługą porównywania cen. Ten zasób CSS jest często aktualizowany, a główny zasób jest już o 5 wersji przed prognozowanym zasobem CSS (abcd100) (abcd105).

200 OK
[...]
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.abcd105.css">

Ogólnie staraj się wybierać zasoby i źródła, które są stosunkowo stabilne i w dużej mierze niezależne od wyniku działania głównego zasobu. W razie potrzeby możesz podzielić zasoby kluczowe na 2: część stabilną przeznaczoną do użytku we wczesnej wersji wskazówek i częściową bardziej dynamiczną, która zostanie pobrana po odebraniu głównego zasobu przez przeglądarkę:

<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">

Na koniec po stronie serwera poszukaj żądań głównych zasobów wysyłanych przez przeglądarki, o których wiadomo, że obsługują wczesne wskazówki, i odpowiedz natychmiast, korzystając z 103 wczesnych wskazówek. W odpowiedzi 103 umieść odpowiednie wskazówki dotyczące wstępnego połączenia i wstępnego wczytywania. Gdy zasób główny będzie gotowy, wyślij zwykłą odpowiedź (np. „200 OK, jeśli operacja się uda). Aby zapewnić zgodność wsteczną, warto też w ostatecznej odpowiedzi umieścić nagłówki HTTP Link, a nawet dodać do nich zasoby kluczowe, które stały się widoczne podczas generowania zasobu głównego (np. w przypadku użycia sugestii „podział na dwa”). Jak to będzie wyglądać:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
103 Early Hints
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script

Kilka chwil później:

200 OK
Content-Length: 7531
Content-Type: text/html; charset=UTF-8
Content-encoding: br
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Link: </experimental.3eab3290.css>; rel=preload; as=style
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">
   <script src="/common.js"></script>
   <link rel="preconnect" href="https://fonts.googleapis.com">

Obsługiwane przeglądarki

Chociaż funkcja „103 wczesnych wskazówek” jest obsługiwana przez wszystkie popularne przeglądarki, dyrektywy, które można wysłać w ramach wczesnej podpowiedzi, różnią się w zależności od przeglądarki:

Obsługa przed połączeniem:

Obsługa przeglądarek

  • 103
  • 103
  • 120
  • 17

Wstępne wczytywanie:

Obsługa przeglądarek

  • 103
  • 103
  • 123
  • x

Narzędzia deweloperskie w Chrome obsługują też obsługę wczesnych podpowiedzi 103.

Obsługa serwerów

Oto krótkie podsumowanie poziomu obsługi wczesnych wskazówek w popularnym oprogramowaniu serwerowym HTTP typu open source:

Włącz wczesne wskazówki w łatwiejszy sposób

Jeśli korzystasz z jednej z poniższych sieci CDN lub platform, nie musisz ręcznie wdrażać wczesnych wskazówek. Aby dowiedzieć się, czy obsługuje on wczesne wskazówki, zapoznaj się z dokumentacją online dostawcy rozwiązania lub zapoznaj się z niepełną listą tutaj:

Jak unikać problemów w przypadku klientów, którzy nie obsługują wczesnych wskazówek

Informacyjne odpowiedzi HTTP z zakresu 100 są częścią standardu HTTP, ale niektóre starsze klienty lub boty mogą mieć z nimi problemy, ponieważ przed wprowadzeniem „103 wczesnych wskazówek” były one rzadko używane do ogólnego przeglądania internetu.

Wysyłanie tylko wczesnych wskazówek 103 w odpowiedzi klientom wysyłającym nagłówek żądania HTTP sec-fetch-mode: navigate powinno mieć pewność, że wskazówki będą wysyłane tylko w przypadku nowszych klientów, które rozumieją, że czekają na kolejną odpowiedź. Poza tym wczesne wskazówki są obsługiwane tylko w przypadku żądań nawigacji (zobacz bieżące ograniczenia), więc dodatkową zaletą jest unikanie niepotrzebnego wysyłania ich w przypadku innych żądań.

Dodatkowo zalecamy, aby wczesne wskazówki były wysyłane tylko przez połączenia HTTP/2 lub HTTP/3.

Wzór zaawansowany

Jeśli używasz wczesnej wersji wskazówek na swoich kluczowych stronach docelowych i szukasz kolejnych możliwości, może zainteresuje Cię ten zaawansowany wzorzec.

W przypadku użytkowników, którzy w trakcie typowej podróży użytkownika przesyła nth żądanie strony, możesz dostosować odpowiedź z wczesnymi wskazówkami do treści znajdujących się niżej i w dalszej części strony, czyli używając wczesnej podpowiedzi przy zasobach o niższym priorytecie. Może to wydawać się sprzeczne z intuicją, ponieważ zalecamy skupienie się na zasobach podrzędnych lub źródłach blokujących renderowanie o wysokim priorytecie. Jednak gdy upłynie trochę czasu od nawigacji, jest bardzo prawdopodobne, że w jego przeglądarce są już wszystkie niezbędne zasoby. Następnie warto przekierować uwagę na zasoby o niższym priorytecie. Może to być na przykład korzystanie z funkcji Wczesne wskazówki do wczytywania obrazów produktów albo dodatkowych plików JS/CSS, które są potrzebne tylko w przypadku mniej typowych interakcji użytkowników.

Bieżące ograniczenia

Oto ograniczenia funkcji wczesnych podpowiedzi zaimplementowanych w Chrome:

  • Dostępne tylko w przypadku żądań nawigacyjnych (czyli głównego zasobu dokumentu najwyższego poziomu).
  • Obsługiwane są tylko wartości preconnect i preload (czyli prefetch nie jest obsługiwane).
  • Wczesna podpowiedź, po której w ostatecznej odpowiedzi następuje przekierowanie między domenami, spowoduje, że Chrome pominie zasoby i połączenia uzyskane przy użyciu wczesnych wskazówek.

Inne przeglądarki mają podobne ograniczenia, a niektóre jeszcze bardziej ograniczają wczesne wskazówki dotyczące funkcji 103 tylko do preconnect.

Co dalej?

W zależności od zainteresowania społeczności możemy rozszerzyć wdrażanie wczesnych wskazówek o następujące możliwości:

  • Wysłano wczesne wskazówki dotyczące żądań zasobów podrzędnych.
  • Wczesne wskazówki zostały wysłane do żądań zasobów głównych elementów iframe.
  • Obsługa pobierania z wyprzedzeniem we Wczesnej podpowiedzi.

Chętnie poznamy Twoją opinię na temat tego, które aspekty należy traktować priorytetowo i jak możemy jeszcze bardziej ulepszyć wczesne wskazówki.

Relacja z H2/Push

Jeśli znasz wycofaną funkcję HTTP2/Push, możesz zastanawiać się, czym różni się funkcja Wczesne wskazówki. Wczesne wskazówki wymagają, aby przeglądarka mogła rozpocząć pobieranie newralgicznych zasobów podrzędnych. Z kolei przy użyciu protokołu HTTP2/Push serwer może rozpocząć wypychanie zasobów podrzędnych razem z odpowiedzią. Brzmi to niesamowicie, ale miało to znaczącą wadę strukturalną – w przypadku protokołu HTTP2/Push bardzo trudno było uniknąć przekazywania zasobów podrzędnych, które posiadała już przeglądarka. Ten efekt „nadmiernego przekazywania” spowodował mniej efektywne wykorzystanie przepustowości sieci, co znacznie obniżało wydajność. Ogólnie dane Chrome wykazały, że protokół HTTP2/Push miał rzeczywiście negatywny wpływ na wydajność w internecie.

Wczesne wskazówki dają z kolei większą skuteczność w praktyce, ponieważ łączą możliwość wysłania wstępnej odpowiedzi ze wskazówkami, dzięki którym przeglądarka samodzielnie pobiera lub łączy to, czego potrzebuje. Choć wczesne wskazówki nie obejmują wszystkich przypadków użycia, w których HTTP2/Push może teoretycznie rozwiązać, uważamy, że ta funkcja jest bardziej praktycznym rozwiązaniem, które przyspiesza nawigację.

Miniatura: Pierre Bamin.