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 najważniejszych zasobów podrzędnych.

Kenji Baheux

Barry Pollard

Opublikowano: 23 czerwca 2022 r., ostatnia aktualizacja: 10 lipca 2026 r.

Czym są wczesne wskazówki?

Z biegiem czasu witryny stały się bardziej zaawansowane. W związku z tym serwer często musi wykonać nietrywialne zadania (np. dostęp do baz danych lub CDN-ów uzyskujących dostęp do serwera pierwotnego), aby wygenerować kod HTML żądanej strony. Niestety, ten „czas myślenia serwera” powoduje dodatkowe opóźnienie, zanim przeglądarka będzie mogła rozpocząć renderowanie strony. Połączenie jest w rzeczywistości bezczynne tak długo, jak serwer przygotowuje odpowiedź.

Wczesne wskazówki to kod stanu HTTP (103 Early Hints) używany do wysyłania wstępnej odpowiedzi HTTP przed odpowiedzią końcową. Dzięki temu serwer może wysyłać do przeglądarki wskazówki dotyczące najważniejszych zasobów podrzędnych (np. arkuszy stylów strony, krytycznego kodu JavaScript) lub źródeł, które prawdopodobnie będą używane przez stronę, podczas gdy serwer generuje główny zasób. Przeglądarka może używać tych wskazówek do rozgrzewania połączeń i żądania zasobów podrzędnych podczas oczekiwania na główny zasób. Innymi słowy, wczesne wskazówki pomagają przeglądarce wykorzystać ten „czas myślenia serwera”, wykonując pewne zadania z wyprzedzeniem, co przyspiesza ładowanie stron.

W niektórych przypadkach poprawa wydajności w zakresie największego wyrenderowania treści może wynosić kilkaset milisekund, jak zaobserwowali Shopify i Cloudflare, a nawet sekundę, jak widać w tym porównaniu przed i po:

Jak używać wczesnych wskazówek

Pierwszym krokiem do wykorzystania wczesnych wskazówek jest zidentyfikowanie najważniejszych stron docelowych, czyli stron, od których użytkownicy zwykle zaczynają wizytę w Twojej witrynie. Może to być strona główna lub popularne strony z informacjami o produktach, jeśli masz wielu użytkowników, którzy trafiają do Ciebie z innych witryn. Te punkty wejścia są ważniejsze niż inne strony, ponieważ przydatność wczesnych wskazówek maleje wraz z nawigacją użytkownika po witrynie (tzn. przeglądarka ma większe szanse na to, że będzie mieć wszystkie potrzebne zasoby podrzędne podczas drugiej lub trzeciej kolejnej nawigacji). Zawsze warto też zrobić dobre pierwsze wrażenie.

Teraz, gdy masz już listę stron docelowych według priorytetu, musisz określić, które źródła lub zasoby podrzędne będą dobrymi kandydatami na wskazówki preconnect lub preload. Zwykle są to źródła i zasoby podrzędne, które mają największy wpływ na kluczowe wskaźniki użytkownika, takie jak największe wyrenderowanie treści lub pierwsze wyrenderowanie treści. Konkretnie, poszukaj zasobów podrzędnych blokujących renderowanie, takich jak synchroniczny JavaScript, arkusze stylów, a nawet czcionki internetowe. Podobnie poszukaj źródeł, które hostują zasoby podrzędne mające duży wpływ na kluczowe wskaźniki użytkownika.

Pamiętaj też, że jeśli Twoje główne zasoby używają już preconnect lub preload, możesz uznać te źródła lub zasoby za kandydatów na wczesne wskazówki. Więcej informacji znajdziesz w artykule o optymalizacji LCP. Jednak bezmyślne kopiowanie dyrektyw preconnect i preload z kodu HTML do wczesnych wskazówek może nie być optymalne.

Gdy używasz ich w kodzie HTML, zwykle chcesz preconnect lub preload zasoby, których skaner wstępnego wczytywania nie wykryje w kodzie HTML – np. czcionki lub obrazy tła, które w przeciwnym razie zostałyby wykryte z opóźnieniem. W przypadku wczesnych wskazówek nie będziesz mieć kodu HTML, więc możesz zamiast tego preconnect do najważniejszych domen lub preload najważniejsze zasoby, które w przeciwnym razie zostałyby wykryte w kodzie HTML – np. wstępne wczytywanie main.css lub app.js. Dodatkowo nie wszystkie przeglądarki obsługują preload w przypadku wczesnych wskazówek – zobacz 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ć przestarzałe lub nie są już używane przez główny zasób. Na przykład zasoby, które są często aktualizowane i wersjonowane (np. example.com/css/main.fa231e9c.css), mogą nie być najlepszym wyborem. Pamiętaj, że ten problem nie dotyczy tylko wczesnych wskazówek. Dotyczy on wszystkich elementów preload lub preconnect, gdziekolwiek się znajdują. Tego typu szczegóły najlepiej rozwiązać za pomocą automatyzacji lub szablonów (np. proces ręczny może prowadzić do niezgodności skrótów lub adresów URL wersji między preload a rzeczywistym tagiem HTML używającym zasobu).

Rozważmy na przykład ten proces:

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

Serwer przewiduje, że będzie potrzebny plik main.abcd100.css, i sugeruje jego wstępne wczytanie za pomocą wczesnych wskazówek:

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

Kilka chwil później wyświetla się strona internetowa, w tym połączony arkusz CSS. Niestety, ten zasób CSS jest często aktualizowany, a główny zasób jest już o 5 wersji nowszy (abcd105) od przewidywanego zasobu CSS (abcd100).

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

Ogólnie rzecz biorąc, wybieraj zasoby i źródła, które są dość stabilne i w dużej mierze niezależne od wyniku głównego zasobu. W razie potrzeby możesz podzielić kluczowe zasoby na 2 części: stabilną, która będzie używana z wczesnymi wskazówkami, oraz bardziej dynamiczną, która będzie pobierana po otrzymaniu przez przeglądarkę głównego zasobu:

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

Na koniec po stronie serwera wyszukaj żądania głównego zasobu wysyłane przez przeglądarki, które obsługują wczesne wskazówki, i natychmiast odpowiedz kodem 103 Early Hints. W odpowiedzi 103 uwzględnij odpowiednie wskazówki dotyczące wstępnego połączenia i wstępnego wczytania. Gdy główny zasób będzie gotowy, wyślij zwykłą odpowiedź (np. 200 OK w przypadku powodzenia). Aby zachować zgodność wsteczną, warto też uwzględnić nagłówki HTTP Link w odpowiedzi końcowej, a nawet dodać do nich najważniejsze zasoby, które stały się widoczne podczas generowania głównego zasobu (np. dynamiczną część kluczowego zasobu, jeśli zastosowano sugestię „podziel na 2 części”). Oto jak to 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ługa przeglądarek

Chociaż kod 103 Early Hints jest obsługiwany we wszystkich głównych przeglądarkach, dyrektywy, które można wysyłać w ramach wczesnych wskazówek, różnią się w zależności od przeglądarki:

Obsługa wstępnego połączenia:

Obsługa wstępnego wczytywania:

Narzędzia deweloperskie w Chrome też obsługują kod 103 Early Hints, a nagłówki Link można zobaczyć w zasobach dokumentu:

Aby używać zasobów wczesnych wskazówek, w Narzędziach deweloperskich nie można zaznaczyć opcji Disable cache (Wyłącz pamięć podręczną), ponieważ wczesne wskazówki korzystają z pamięci podręcznej przeglądarki. W przypadku wstępnie wczytanych zasobów w kolumnie Initiator (Inicjator) będzie widoczna wartość Early-hints (Wczesne wskazówki), a w kolumnie Size (Rozmiar) – (Disk cache) (Pamięć podręczna dysku):

Wymaga to też zaufanego certyfikatu do testowania HTTPS.

Firefox nie obsługuje kodu 103 Early Hints jako inicjatora w Narzędziach deweloperskich, ale zasoby wczytywane za pomocą wczesnych wskazówek są wyświetlane jako cached (w pamięci podręcznej) w kolumnie Transferred (Przesłane), a po kliknięciu mają nagłówek żądania HTTP X-Moz: early hint.

Obsługa serwerów

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

• Apache: obsługiwany za pomocą mod_http2.
• H2O: obsługiwany.
• NGINX: obsługiwany.
• Node: obsługiwany w przypadku http i http2.

Łatwiejsze włączanie wczesnych wskazówek

Jeśli używasz jednej z tych platform lub CDN-ów, być może nie musisz ręcznie implementować wczesnych wskazówek. Sprawdź, czy Twoje rozwiązanie obsługuje wczesne wskazówki, w dokumentacji online dostawcy lub na tej niepełnej liście:

• Wczesne wskazówki w Cloudflare
• Wczesne wskazówki w Fastly.
• Wczesne wskazówki w Akamai.

Jak unikać problemów u 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 kodu 103 Early Hints były one rzadko używane do ogólnego przeglądania internetu.

Wysyłanie kodu 103 Early Hints tylko w odpowiedzi na klienty, które wysyłają nagłówek żądania HTTP sec-fetch-mode: navigate, powinno powodować wysyłanie takich wskazówek tylko do nowszych klientów, którzy wiedzą, że mają czekać na kolejną odpowiedź. Dodatkowo, ponieważ wczesne wskazówki są obsługiwane tylko w przypadku żądań nawigacji (zobacz aktualne ograniczenia), pozwala to uniknąć niepotrzebnego wysyłania ich w przypadku innych żądań.

Ponadto zaleca się wysyłanie wczesnych wskazówek tylko przez połączenia HTTP/2 lub HTTP/3, a większość przeglądarek będzie je akceptować tylko w przypadku tych protokołów.

Wzorzec zaawansowany

Jeśli w pełni zastosujesz wczesne wskazówki na najważniejszych stronach docelowych i szukasz więcej możliwości, może Cię zainteresować ten wzorzec zaawansowany.

W przypadku użytkowników, którzy wysyłają n-te żądanie strony w ramach typowej ścieżki użytkownika, możesz dostosować odpowiedź wczesnych wskazówek do treści, która znajduje się niżej i głębiej na stronie, czyli używać wczesnych wskazówek w przypadku zasobów o niższym priorytecie. Może to brzmieć sprzecznie z intuicją, ponieważ zalecaliśmy skupienie się na zasobach podrzędnych lub źródłach o wysokim priorytecie, które blokują renderowanie. Jednak gdy użytkownik przez jakiś czas nawiguje po stronie, jego przeglądarka prawdopodobnie ma już wszystkie najważniejsze zasoby. Od tego momentu warto skupić się na zasobach o niższym priorytecie. Może to oznaczać np. używanie wczesnych wskazówek do wczytywania obrazów produktów lub dodatkowego kodu JS/CSS, który jest potrzebny tylko w przypadku mniej typowych interakcji użytkownika.

Aktualne ograniczenia

Oto ograniczenia wczesnych wskazówek zaimplementowanych w Chrome:

• Dostępne tylko w przypadku żądań nawigacji (czyli głównego zasobu dokumentu najwyższego poziomu).
• Obsługuje tylko preconnect i preload (czyli prefetch nie jest obsługiwany).
• Wczesne wskazówki, po których następuje przekierowanie między źródłami w odpowiedzi końcowej, spowodują, że przeglądarki odrzucą zasoby i połączenia uzyskane za pomocą wczesnych wskazówek.
• Zasoby wstępnie wczytane za pomocą wczesnych wskazówek są przechowywane w pamięci podręcznej HTTP i później pobierane z niej przez stronę. Dlatego za pomocą wczesnych wskazówek można wstępnie wczytywać tylko zasoby, które można przechowywać w pamięci podręcznej. W przeciwnym razie zasób zostanie pobrany 2 razy (raz przez wczesne wskazówki, a raz przez dokument). W Chrome pamięć podręczna HTTP jest wyłączona w przypadku niezaufanych certyfikatów HTTPS (nawet jeśli przejdziesz do wczytania strony).
• Wstępne wczytywanie obrazów responsywnych (za pomocą imagesrcset, imagesizes lub media) może nie być obsługiwane za pomocą nagłówków HTTP <link> headers, ponieważ obszar widoczny nie jest zdefiniowany, dopóki nie zostanie utworzony dokument. W najlepszym przypadku będą one czekać na otrzymanie dokumentu, co niweluje główne zalety kodu 103 Early Hints.

Inne przeglądarki mają podobne ograniczenia, a niektóre, jak wspomnieliśmy wcześniej, dodatkowo ograniczają wczesne wskazówki 103 tylko do preconnect.

Związek z H2/Push

Jeśli znasz wycofaną funkcję HTTP2/Push, możesz się zastanawiać, czym różnią się od niej wczesne wskazówki. Wczesne wskazówki wymagają podróży w obie strony, aby przeglądarka mogła rozpocząć pobieranie najważniejszych zasobów podrzędnych, natomiast w przypadku HTTP2/Push serwer może zacząć wypychanie zasobów podrzędnych wraz z odpowiedzią. Brzmi to świetnie, ale ma kluczową wadę strukturalną: w przypadku HTTP2/Push bardzo trudno było uniknąć wypychania zasobów podrzędnych, które przeglądarka już miała. Ten efekt „nadmiernego wypychania” powodował mniej efektywne wykorzystanie przepustowości sieci, co znacznie ograniczało korzyści z wydajności. Ogólnie rzecz biorąc, dane Chrome wykazały, że HTTP2/Push w rzeczywistości negatywnie wpływa na wydajność w internecie.

Z kolei wczesne wskazówki działają lepiej w praktyce, ponieważ łączą możliwość wysyłania wstępnej odpowiedzi ze wskazówkami, które pozostawiają przeglądarce decyzję o pobieraniu lub łączeniu się z tym, czego rzeczywiście potrzebuje. Chociaż wczesne wskazówki nie obejmują wszystkich przypadków użycia, które teoretycznie mogłyby być obsługiwane przez HTTP2/Push, uważamy, że wczesne wskazówki są bardziej praktycznym rozwiązaniem do przyspieszania nawigacji.

Miniatura autorstwa Pierre'a Bamin.