Wstępne renderowanie stron w Chrome na potrzeby błyskawicznego poruszania się po nich

Barry Pollard

Data publikacji: 2 grudnia 2022 r., ostatnia aktualizacja: 29 października 2026 r.

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

Zespół Chrome przywrócił pełne renderowanie wstępne przyszłych stron, które użytkownik prawdopodobnie odwiedzi.

Krótka historia renderowania wstępnego

W przeszłości Chrome obsługiwał wskazówkę dotyczącą zasobów <link rel="prerender" href="/next-page">, ale nie była ona powszechnie obsługiwana poza Chrome i nie był to zbyt ekspresyjny interfejs API.

To starsze renderowanie wstępne z użyciem wskazówki linku rel=prerender zostało wycofane na rzecz pobierania z wyprzedzeniem NoState, które pobierało zasoby potrzebne przyszłej stronie, ale nie renderowało jej wstępnie ani nie wykonywało kodu JavaScript. Pobieranie z wyprzedzeniem bez stanu pomaga zwiększyć wydajność strony dzięki ulepszeniu wczytywania zasobów, ale nie zapewnia natychmiastowego wczytywania strony, jak w przypadku pełnego renderowania wstępnego.

Zespół Chrome ponownie wprowadził do Chrome pełne renderowanie wstępne. Aby uniknąć komplikacji związanych z obecnym użyciem i umożliwić rozszerzenie renderowania wstępnego w przyszłości, ten nowy mechanizm renderowania wstępnego nie będzie używać składni <link rel="prerender"...>, która pozostanie w przypadku NoState Prefetch, z myślą o wycofaniu jej w przyszłości.

Jak strona jest renderowana wstępnie?

Stronę można wyrenderować wstępnie na 4 sposoby, które mają na celu przyspieszenie nawigacji:

  1. Gdy wpiszesz adres URL w pasku adresu Chrome (nazywanym też „omniboksem”), Chrome może automatycznie wstępnie wyrenderować stronę, jeśli na podstawie Twojej historii przeglądania uzna, że prawdopodobnie ją odwiedzisz.
  2. Gdy używasz paska zakładek, Chrome może automatycznie wstępnie wyrenderować stronę, gdy najedziesz kursorem na jeden z przycisków zakładek.
  3. Gdy wpisujesz wyszukiwane słowa na pasku adresu Chrome, przeglądarka może automatycznie wstępnie wyrenderować stronę wyników wyszukiwania, jeśli otrzyma takie polecenie od wyszukiwarki.
  4. Witryny mogą używać interfejsu Speculation Rules API, aby automatycznie informować Chrome, które strony mają być renderowane wstępnie. Zastępuje to funkcję <link rel="prerender"...> i umożliwia witrynom proaktywne renderowanie wstępne strony na podstawie reguł spekulacyjnych na stronie. Mogą one być statycznie umieszczone na stronach lub dynamicznie wstrzykiwane przez JavaScript, zgodnie z preferencjami właściciela strony.

W każdym z tych przypadków renderowanie wstępne zachowuje się tak, jakby strona została otwarta w niewidocznej karcie w tle, a następnie „aktywowana” przez zastąpienie karty na pierwszym planie tą wstępnie wyrenderowaną stroną. Jeśli strona zostanie aktywowana, zanim zostanie w pełni wyrenderowana, jej bieżący stan to „na pierwszym planie” i będzie się ona nadal ładować, co oznacza, że i tak możesz uzyskać przewagę.

Ponieważ wstępnie wyrenderowana strona jest otwierana w stanie ukrytym, szereg interfejsów API, które powodują uciążliwe zachowania (np. wyświetlanie próśb), nie jest aktywowany w tym stanie, ale dopiero po aktywowaniu strony. W niewielu przypadkach, gdy nie jest to jeszcze możliwe, renderowanie wstępne jest anulowane. Zespół Chrome pracuje nad udostępnieniem powodów anulowania renderowania wstępnego w interfejsie API, a także nad ulepszeniem Narzędzi deweloperskich, aby ułatwić identyfikowanie takich przypadków.

Wpływ renderowania wstępnego

Renderowanie wstępne umożliwia niemal natychmiastowe wczytanie strony, jak pokazano na tym filmie:

Przykładowy wpływ renderowania wstępnego.

Przykładowa witryna jest już szybka, ale nawet w tym przypadku widać, jak renderowanie wstępne poprawia wrażenia użytkowników. Może to mieć bezpośredni wpływ na Core Web Vitals witryny, ponieważ LCP będzie bliskie zeru, CLS będzie mniejsze (ponieważ CLS wczytywania występuje przed początkowym wyświetleniem), a INP będzie lepsze (ponieważ wczytywanie powinno zostać zakończone, zanim użytkownik wejdzie w interakcję).

Nawet jeśli strona zostanie aktywowana, zanim zostanie w pełni wczytana, wcześniejsze rozpoczęcie wczytywania powinno poprawić wrażenia użytkownika. Jeśli link zostanie aktywowany podczas renderowania wstępnego, strona renderowania wstępnego zostanie przeniesiona do ramki głównej i będzie nadal wczytywana.

Renderowanie wstępne wymaga jednak dodatkowej pamięci i przepustowości sieci. Uważaj, aby nie przesadzić z renderowaniem wstępnym, ponieważ może to spowodować nadmierne wykorzystanie zasobów użytkownika. Renderuj wstępnie tylko wtedy, gdy istnieje duże prawdopodobieństwo, że użytkownik przejdzie na daną stronę.

Więcej informacji o tym, jak mierzyć rzeczywisty wpływ na skuteczność w statystykach, znajdziesz w sekcji Pomiar skuteczności.

Wyświetlanie podpowiedzi na pasku adresu Chrome

W pierwszym przypadku możesz wyświetlić podpowiedzi Chrome dotyczące adresów URL na stronie chrome://predictors:

Strona podpowiedzi Chrome przefiltrowana tak, aby wyświetlać podpowiedzi o niskim (szary), średnim (bursztynowy) i wysokim (zielony) prawdopodobieństwie na podstawie wpisanego tekstu.
Strona podpowiedzi Chrome.

Zielone linie oznaczają wystarczającą pewność, aby aktywować renderowanie wstępne. W tym przykładzie wpisanie „s” daje umiarkowaną pewność (kolor bursztynowy), ale po wpisaniu „sh” Chrome ma wystarczającą pewność, że prawie zawsze przechodzisz na stronę https://sheets.google.com.

Ten zrzut ekranu został zrobiony w stosunkowo nowej instalacji Chrome i odfiltrowuje podpowiedzi o zerowym poziomie ufności, ale jeśli wyświetlisz własne podpowiedzi, prawdopodobnie zobaczysz znacznie więcej wpisów i potencjalnie więcej znaków wymaganych do osiągnięcia wystarczająco wysokiego poziomu ufności.

Te czynniki wpływają też na opcje sugerowane na pasku adresu, które możesz zauważyć:

Funkcja „Typeahead” na pasku adresu Chrome
Funkcja „Typeahead” na pasku adresu.

Chrome będzie stale aktualizować podpowiedzi na podstawie wpisywanych przez Ciebie haseł i wybieranych opcji.

  • Jeśli poziom ufności przekracza 30% (kolor bursztynowy), Chrome proaktywnie łączy się z domeną, ale nie renderuje wstępnie strony.
  • Jeśli poziom ufności przekracza 50% (kolor zielony), Chrome wstępnie wyrenderuje adres URL.

Interfejs Speculation Rules API

W przypadku opcji renderowania wstępnego interfejsu Speculation Rules API programiści stron internetowych mogą wstawiać na swoich stronach instrukcje JSON, aby informować przeglądarkę, które adresy URL mają być renderowane wstępnie.

Lista adresów URL

Reguły spekulacyjne mogą być oparte na listach adresów URL:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Reguły dotyczące dokumentów

Reguły spekulacyjne mogą też być „regułami dokumentu” używającymi składni where. Ta opcja umożliwia spekulacyjne wczytywanie linków znalezionych w dokumencie na podstawie selektorów href (opartych na interfejsie URL Pattern API) lub selektorów CSS:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

Zapał

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

Ustawienie eagerness służy do określania, kiedy powinny być uruchamiane spekulacje, co jest szczególnie przydatne w przypadku reguł dokumentu:

  • conservative: – spekuluje na temat wskaźnika lub dotknięcia.
  • moderate: na komputerze powoduje to spekulacje, jeśli przytrzymasz wskaźnik nad linkiem przez 200 milisekund (lub w przypadku zdarzenia pointerdown, jeśli nastąpi wcześniej, oraz na urządzeniach mobilnych, gdzie nie ma zdarzenia hover). Od sierpnia 2025 r. na urządzeniach mobilnych opieramy się na złożonych heurystykach dotyczących widocznego obszaru. Złożone heurystyki widocznego obszaru są aktywowane 500 ms po tym, jak użytkownik przestanie przewijać, w przypadku kotwic znajdujących się w odległości nie większej niż 30% odległości pionowej od poprzedniego kliknięcia, gdzie kotwice są co najmniej 0,5 raza większe od największej kotwicy w widocznym obszarze. Zgodnie z opisem w tym dokumencie.
  • eager: to ustawienie działało tak samo jak immediate, ale zmieniło się to w Chrome 143. Na komputerze spekulacje są wykonywane, gdy przytrzymasz wskaźnik nad linkiem przez 10 milisekund. W styczniu 2026 r. zmieniliśmy sposób określania tego na urządzeniach mobilnych na podstawie prostych heurystyk widocznego obszaru. Prosta heurystyka widocznego obszaru jest aktywowana 50 ms po wejściu elementu zakotwiczonego w widoczny obszar.
  • immediate: służy do spekulacji tak szybko, jak to możliwe, czyli od razu po zaobserwowaniu reguł spekulacyjnych.

Domyślna wartość eagerness dla reguł list to immediate. Opcje eager, moderate i conservative mogą służyć do ograniczania reguł list do adresów URL, z którymi użytkownik wchodzi w interakcję, do określonej listy. W wielu przypadkach bardziej odpowiednie mogą być jednak reguły document z odpowiednim warunkiem where.

Domyślna wartość eagerness dla reguł document to conservative. Dokument może składać się z wielu adresów URL, dlatego należy zachować ostrożność podczas używania immediate w regułach document (patrz też sekcja Limity Chrome poniżej).

To, które ustawienie eagerness wybrać, zależy od Twojej witryny. W przypadku lekkiej, statycznej witryny bardziej agresywne spekulowanie może być mało kosztowne i korzystne dla użytkowników. W przypadku witryn o bardziej złożonej architekturze i większym obciążeniu stron może być preferowane ograniczenie marnowania zasobów przez rzadsze spekulowanie, dopóki nie uzyskasz od użytkowników bardziej pozytywnego sygnału o zamiarze.

Opcja moderate to rozwiązanie pośrednie. Wiele witryn może skorzystać z poniższej reguły spekulacji, która wstępnie renderuje link, gdy wskaźnik myszy znajduje się nad nim przez 200 milisekund, lub w przypadku zdarzenia pointerdown. Jest to podstawowa, ale skuteczna implementacja reguł spekulacji:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

Pobieranie z wyprzedzeniem

Reguły spekulacyjne mogą też służyć do pobierania stron z wyprzedzeniem bez pełnego renderowania wstępnego. Często może to być dobry pierwszy krok na drodze do renderowania wstępnego:

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Prerender until script

Zespół Chrome pracuje też nad dodaniem prerender_until_script do interfejsu Speculation Rules API (patrz: błąd implementacji). Jest to krok między pobieraniem z wyprzedzeniem a renderowaniem wstępnym, który jest używany w podobny sposób:

<script type="speculationrules">
{
  "prerender_until_script": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Podobnie jak w przypadku NoState prefetch, spowoduje to pobranie z wyprzedzeniem zarówno dokumentu HTML, jak i zasobów podrzędnych dostępnych w tym dokumencie. Jednak nie tylko – zacznie też wstępnie renderować stronę, zatrzymując się po napotkaniu pierwszego skryptu.

Oznacza to, że w przypadku stron bez kodu JavaScript lub z kodem JavaScript tylko w stopce strona może zostać prawie w pełni wyrenderowana z wyprzedzeniem. Strony ze skryptami w <head> nie będą mogły być renderowane wstępnie, ale nadal będą korzystać z pobierania zasobów podrzędnych.

Pozwoli to uniknąć ryzyka niezamierzonych efektów ubocznych wykonywania kodu JavaScript, a jednocześnie zapewni znacznie większy wzrost wydajności niż samo prefetch.

Limity Chrome

Chrome ma limity, które zapobiegają nadmiernemu korzystaniu z interfejsu Speculation Rules API:

zapał Pobieranie z wyprzedzeniem Renderowanie wstępne
immediate 50 10
eager / moderate na urządzeniach mobilnych 6 (FIFO) 2 (FIFO)
eager / moderate na komputerze 2 (FIFO) 2 (FIFO)
conservative 2 (FIFO) 2 (FIFO)
Limity spekulacji w Chrome

Ustawienia eager, moderate i conservative, które zależą od interakcji użytkownika, działają w trybie FIFO (First In, First Out): po osiągnięciu limitu nowa spekulacja spowoduje anulowanie najstarszej spekulacji i zastąpienie jej nowszą, aby oszczędzać pamięć.

Anulowane spekulacje można wywołać ponownie, na przykład przez ponowne najechanie kursorem na link. Spowoduje to ponowne spekulowanie tego adresu URL i usunięcie najstarszej spekulacji. W takim przypadku poprzednie spekulacje spowodują zapisanie w pamięci podręcznej HTTP wszystkich zasobów, które można zapisać w pamięci podręcznej, więc kolejne spekulacje powinny mieć mniejszy koszt. Dlatego domyślny limit jest ustawiony na niewielką wartość 2. W przypadku pobierania wstępnego na urządzeniach mobilnych używamy wyższego progu 6, ponieważ nie ma tam „najechania kursorem”, alternatywne heurystyki widocznego obszaru na urządzeniach mobilnych są mniej dokładne, a pobieranie wstępne jest mniej kosztowne niż renderowanie wstępne (w przypadku renderowania wstępnego na urządzeniach mobilnych utrzymujemy limit 2).

Reguły listy statycznej nie są wywoływane przez działanie użytkownika, więc mają wyższy limit, ponieważ przeglądarka nie może wiedzieć, które z nich są potrzebne i kiedy.

Chrome rozważa też zwiększenie limitu do 5 na urządzeniach mobilnych w przypadku eager i moderate, przynajmniej w przypadku pobierania z wyprzedzeniem, ponieważ jest to mniej precyzyjna heurystyka. Deweloperzy korzystający z interfejsu eager mogą rozważyć dodatkowe użycie reguł conservative, gdy w obszarze widocznym na ekranie jest dostępnych wiele linków, aby nadal spekulować, nawet jeśli nie zostaną wybrane jako jeden z pierwszych 2 linków.

Limit immediate jest też dynamiczny, więc usunięcie elementu skryptu adresu URL list spowoduje zwolnienie miejsca przez anulowanie usuniętych spekulacji.

Chrome będzie też zapobiegać używaniu spekulacji w określonych warunkach, takich jak:

  • Save-Data.
  • Oszczędzanie energii, gdy jest włączone, a bateria jest bliska rozładowania.
  • ograniczenia pamięci,
  • gdy ustawienie „Wstępnie ładuj strony” jest wyłączone (co jest również wyraźnie wyłączone przez rozszerzenia do Chrome, takie jak uBlock Origin).
  • Strony otwarte na kartach w tle.

Chrome nie renderuje też elementów iframe z innych domen na wstępnie renderowanych stronach, dopóki nie zostaną aktywowane.

Wszystkie te warunki mają na celu ograniczenie wpływu nadmiernej spekulacji, gdy byłaby ona szkodliwa dla użytkowników.

Jak uwzględnić reguły spekulacyjne na stronie

Reguły spekulacji można statycznie uwzględnić w kodzie HTML strony lub dynamicznie wstawić na stronie za pomocą JavaScriptu:

  • Statycznie uwzględnione reguły spekulacji: na przykład witryna z wiadomościami lub blog może wstępnie renderować najnowszy artykuł, jeśli jest to często następna strona, którą odwiedza duża część użytkowników. Można też używać reguł dokumentu z atrybutem moderate lub conservative, aby spekulować, gdy użytkownicy wchodzą w interakcję z linkami.
  • Dynamicznie wstawiane reguły spekulacyjne: mogą być oparte na logice aplikacji, spersonalizowane pod kątem użytkownika lub oparte na innych heurystykach.

Jeśli preferujesz dynamiczne wstawianie na podstawie działań, takich jak najechanie kursorem lub kliknięcie linku (jak wiele bibliotek robiło w przeszłości z <link rel=prefetch>), zalecamy zapoznanie się z regułami dokumentu, ponieważ umożliwiają one przeglądarce obsługę wielu przypadków użycia.

Reguły spekulacji można dodawać w <head> lub <body> ramki głównej. Reguły spekulacyjne w ramkach podrzędnych nie są stosowane, a reguły spekulacyjne na stronach renderowanych wstępnie są stosowane dopiero po aktywowaniu danej strony.

Nagłówek HTTP Speculation-Rules

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

Reguły spekulacyjne można też dostarczać za pomocą nagłówka HTTP Speculation-Rules, zamiast umieszczać je bezpośrednio w kodzie HTML dokumentu. Ułatwia to wdrażanie przez sieci CDN bez konieczności zmiany zawartości dokumentów.

Nagłówek HTTP Speculation-Rules jest zwracany wraz z dokumentem i wskazuje lokalizację pliku JSON zawierającego reguły spekulacyjne:

Speculation-Rules: "/speculationrules.json"

Ten zasób musi używać prawidłowego typu MIME, a jeśli jest to zasób współdzielony, musi przejść kontrolę CORS.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

Jeśli chcesz używać względnych adresów URL, możesz uwzględnić klucz "relative_to": "document" w regułach spekulacji. W przeciwnym razie względne adresy URL będą względne względem adresu URL pliku JSON reguł spekulacyjnych. Może to być szczególnie przydatne, jeśli chcesz wybrać niektóre lub wszystkie linki z tego samego źródła.

Pole tagu reguł spekulacyjnych

Browser Support

  • Chrome: 136.
  • Edge: 136.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

Można też dodawać „tagi” w składni JSON reguł spekulacji na poziomie ogólnym dla wszystkich reguł spekulacji w zestawie reguł:

{
  "tag": "my-rules",
  "prefetch": [{
      "urls": ["next.html"]
  }],
  "prerender": [{
      "urls": ["next2.html"]
  }]
}

Możesz też to zrobić na poziomie pojedynczej reguły:

{
  "prefetch": [{
    "tag": "my-prefetch-rules",
    "urls": ["next.html"]
  }],
  "prerender": [{
    "tag": "my-prerender-rules",
    "urls": ["next2.html"]
  }]
}

Ten tag jest następnie odzwierciedlany w nagłówku HTTP Sec-Speculation-Tags, którego można używać do filtrowania reguł spekulacyjnych na serwerze. Nagłówek HTTP Sec-Speculation-Tags może zawierać wiele tagów, jeśli spekulacja jest objęta wieloma regułami, jak pokazano w tym przykładzie:

Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"

Niektóre sieci CDN automatycznie wstrzykują reguły spekulacji, ale blokują spekulacje w przypadku stron, które nie są przechowywane w pamięci podręcznej na serwerach brzegowych, aby uniknąć zwiększonego wykorzystania serwera pierwotnego. Tagi umożliwiają im identyfikowanie spekulacji zainicjowanych przez domyślny zestaw reguł, ale nadal zezwalają na przekazywanie do źródła reguł dodanych przez witrynę.

Tagi zestawu reguł są też wyświetlane w Narzędziach deweloperskich w Chrome.

Pole reguł spekulacyjnych target_hint

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

Reguły spekulacji mogą też zawierać pole target_hint, które zawiera prawidłową nazwę kontekstu przeglądania lub słowo kluczowe wskazujące, gdzie strona oczekuje aktywacji wstępnie wyrenderowanych treści:

<script type=speculationrules>
{
  "prerender": [{
    "target_hint": "_blank",
    "urls": ["next.html"]
  }]
}
</script>

Ta wskazówka umożliwia obsługę spekulacji dotyczących renderowania wstępnego w przypadku linków target="_blank":

<a target="_blank" href="next.html">Open this link in a new tab</a>

Obecnie w Chrome obsługiwane są tylko wartości "target_hint": "_blank" i "target_hint": "_self" (domyślna, jeśli nie określono inaczej) i tylko w przypadku renderowania wstępnego – pobieranie wstępne nie jest obsługiwane.

Atrybut target_hint jest potrzebny tylko w przypadku reguł spekulacyjnych urls, ponieważ w przypadku reguł dokumentu target jest znany z samego linku.

Reguły spekulacyjne i aplikacje jednostronicowe

Reguły spekulacji są obsługiwane tylko w przypadku nawigacji po całej stronie zarządzanej przez przeglądarkę, a nie w przypadku aplikacji jednostronicowych (SPA) ani stron z powłoką aplikacji. Te architektury nie używają pobierania dokumentów, ale zamiast tego pobierają dane lub strony częściowo albo za pomocą interfejsu API, a następnie przetwarzają je i prezentują na bieżącej stronie. Dane potrzebne do tzw. „miękkiej nawigacji” mogą być pobierane z wyprzedzeniem przez aplikację poza regułami spekulacji, ale nie można ich renderować wstępnie.

Reguły spekulacyjne mogą służyć do wstępnego renderowania samej aplikacji z poprzedniej strony. Może to pomóc zrekompensować niektóre dodatkowe koszty początkowego wczytywania, które występują w przypadku niektórych aplikacji jednostronicowych. Nie można jednak wstępnie renderować zmian trasy w aplikacji.

Debugowanie reguł spekulacyjnych

W poście poświęconym debugowaniu reguł spekulacyjnych znajdziesz informacje o nowych funkcjach Narzędzi deweloperskich w Chrome, które ułatwiają wyświetlanie i debugowanie tego nowego interfejsu API.

Wiele reguł spekulacyjnych

Do tej samej strony można też dodać wiele reguł spekulacji, które zostaną dołączone do istniejących reguł. Dlatego wszystkie te sposoby powodują wstępne renderowanie zarówno one.html, jak i two.html:

Lista adresów URL:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html", "two.html"]
  }]
}
</script>

Wiele skryptów speculationrules:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html"]
  }]
}
</script>
<script type="speculationrules">
{
  "prerender": [{
    "urls": ["two.html"]
  }]
}
</script>

Wiele list w jednym zestawie tagów speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Browser Support

  • Chrome: 141.
  • Edge: 141.
  • Firefox: 154.
  • Safari: not supported.

Source

Podczas pobierania lub renderowania wstępnego strony niektóre parametry adresu URL (technicznie nazywane parametrami wyszukiwania) mogą być nieistotne dla strony faktycznie dostarczanej przez serwer i używane tylko przez JavaScript po stronie klienta.

Na przykład parametry monitora UTM są używane przez Google Analytics do pomiaru skuteczności kampanii, ale zwykle nie powodują dostarczania różnych stron z serwera. Oznacza to, że page1.html?utm_content=123 i page1.html?utm_content=456 będą wyświetlać tę samą stronę z serwera, więc tę samą stronę można ponownie wykorzystać z pamięci podręcznej.

Podobnie aplikacje mogą używać innych parametrów adresu URL, które są obsługiwane tylko po stronie klienta.

Propozycja No-Vary-Search umożliwia serwerowi określenie parametrów, które nie powodują różnic w dostarczanych zasobach, dzięki czemu przeglądarka może ponownie używać wcześniej zapisanych w pamięci podręcznej wersji dokumentu, które różnią się tylko tymi parametrami. Jest to obsługiwane w Chrome (i przeglądarkach opartych na Chromium) w przypadku spekulacji nawigacyjnych zarówno w przypadku pobierania wstępnego, jak i renderowania wstępnego.

Reguły spekulacyjne obsługują użycie expects_no_vary_search, aby wskazać, gdzie powinien zostać zwrócony nagłówek HTTP No-Vary-Search. Może to pomóc w uniknięciu niepotrzebnych pobrań, zanim odpowiedzi zostaną wyświetlone.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

W tym przykładzie początkowy kod HTML strony /products jest taki sam dla obu identyfikatorów produktów: 123 i 124. Jednak zawartość strony ostatecznie różni się w zależności od renderowania po stronie klienta, które wykorzystuje JavaScript do pobierania danych o produktach za pomocą parametru wyszukiwania id. Dlatego pobieramy ten adres URL z wyprzedzeniem. Powinien on zwracać nagłówek HTTP No-Vary-Search, który wskazuje, że strona może być używana w przypadku dowolnego parametru wyszukiwania id.

Jeśli jednak użytkownik kliknie któryś z linków, zanim pobieranie wstępne zostanie zakończone, przeglądarka może nie otrzymać strony /products. W takim przypadku przeglądarka nie wie, czy będzie on zawierać nagłówek HTTP No-Vary-Search. Przeglądarka może wtedy ponownie pobrać link lub poczekać na zakończenie wstępnego pobierania, aby sprawdzić, czy zawiera on nagłówek HTTP No-Vary-Search. Ustawienie expects_no_vary_search informuje przeglądarkę, że odpowiedź strony powinna zawierać nagłówek HTTP No-Vary-Search, i że powinna poczekać na zakończenie wstępnego pobierania.

Możesz też dodać do expects_no_vary_search wiele parametrów rozdzielonych spacjami (ponieważ No-Vary-Search to uporządkowany nagłówek HTTP):

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

Ograniczenia reguł spekulacyjnych i przyszłe ulepszenia

Reguły spekulacji są ograniczone do stron otwartych na tej samej karcie, ale pracujemy nad zmniejszeniem tego ograniczenia.

Domyślnie renderowanie wstępne jest ograniczone do stron z tego samego źródła. Można włączyć wstępne renderowanie stron z innych domen w tej samej witrynie (np. https://a.example.com może wstępnie wyrenderować stronę w https://b.example.com). Aby można było korzystać z tej funkcji, strona, która ma zostać wstępnie wyrenderowana (w tym przykładzie https://b.example.com), musi wyrazić na to zgodę przez dodanie nagłówka HTTP Supports-Loading-Mode: credentialed-prerender. W przeciwnym razie Chrome anuluje wstępne renderowanie.

Przyszłe wersje mogą też zezwalać na wstępne renderowanie stron z innych witryn i domen, o ile nie istnieją pliki cookie dla wstępnie renderowanej strony, a wstępnie renderowana strona wyraża zgodę na podobny nagłówek HTTP Supports-Loading-Mode: uncredentialed-prerender.

Reguły spekulacyjne obsługują już pobieranie z wyprzedzeniem z różnych domen. W przypadku pobierania z wyprzedzeniem z różnych domen w tej samej witrynie nie ma żadnych ograniczeń. Wstępne pobieranie z innej witryny i współdzielenie jest obsługiwane tylko wtedy, gdy nie istnieją pliki cookie dla domeny współdzielenia. Jeśli istnieją pliki cookie z poprzedniej wizyty użytkownika w tej witrynie, spekulacja nie zostanie użyta i w Narzędziach deweloperskich pojawi się błąd.

Biorąc pod uwagę te ograniczenia, wzorcem, który może poprawić wrażenia użytkowników zarówno w przypadku linków wewnętrznych, jak i zewnętrznych, jest wstępne renderowanie adresów URL z tego samego źródła i próba wstępnego pobierania adresów URL z innych źródeł:

<script type="speculationrules">
  {
    "prerender": [{
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }],
    "prefetch": [{
      "where": { "not": { "href_matches": "/*" } },
      "eagerness": "moderate"
    }]
  }
</script>

Ograniczenie uniemożliwiające domyślne spekulacje dotyczące współdzielenia w przypadku linków współdzielonych jest konieczne ze względów bezpieczeństwa. Jest to ulepszenie w stosunku do <link rel="prefetch"> w przypadku miejsc docelowych w ramach współdzielenia, które również nie wysyłają plików cookie, ale nadal próbują pobrać wstępnie dane. Może to spowodować zmarnowanie pobrania wstępnego, które trzeba będzie wysłać ponownie, lub, co gorsza, nieprawidłowe wczytanie strony.

Wykrywanie obsługi interfejsu Speculation Rules API

Obsługę interfejsu Speculation Rules API możesz wykryć za pomocą standardowych testów HTML:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

Dynamiczne dodawanie reguł spekulacyjnych za pomocą JavaScriptu

Oto przykład dodawania reguły spekulacji prerender za pomocą JavaScriptu:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

Wersję demonstracyjną renderowania wstępnego za pomocą interfejsu Speculation Rules API z użyciem wstawiania kodu JavaScript możesz zobaczyć na tej stronie demonstracyjnej renderowania wstępnego.

Wstawienie elementu <script type = "speculationrules"> bezpośrednio do DOM za pomocą innerHTML nie spowoduje zarejestrowania reguł spekulacji ze względów bezpieczeństwa. Należy go dodać w sposób opisany powyżej. Jednak treści wstawiane dynamicznie za pomocą innerHTML, które zawierają nowe linki, będą objęte istniejącymi regułami na stronie.

Podobnie bezpośrednie edytowanie panelu Elementy w Narzędziach deweloperskich w Chrome w celu dodania elementu <script type = "speculationrules"> nie powoduje zarejestrowania reguł spekulacyjnych. Aby wstawić reguły, musisz uruchomić w konsoli skrypt, który dynamicznie doda je do modelu DOM.

Dodawanie reguł spekulacyjnych za pomocą menedżera tagów

Aby dodać reguły spekulacji za pomocą menedżera tagów, takiego jak Menedżer tagów Google (GTM), należy je wstawić za pomocą JavaScriptu, a nie dodawać elementu <script type = "speculationrules"> bezpośrednio przez GTM z tych samych powodów, o których wspomnieliśmy wcześniej:

Konfiguracja niestandardowego tagu HTML w Menedżerze tagów Google
Dodawanie reguł spekulacyjnych za pomocą Menedżera tagów Google

Pamiętaj, że w tym przykładzie użyto var, ponieważ Menedżer tagów Google nie obsługuje const.

Anulowanie reguł spekulacyjnych

Usunięcie reguł spekulacyjnych spowoduje anulowanie renderowania wstępnego. Jednak do tego czasu zasoby zostaną już prawdopodobnie wykorzystane do rozpoczęcia renderowania wstępnego, dlatego zalecamy, aby nie renderować wstępnie, jeśli istnieje prawdopodobieństwo, że trzeba będzie anulować renderowanie wstępne. Z drugiej strony zasoby z pamięci podręcznej mogą być nadal używane, więc anulowanie nie musi być całkowicie bezużyteczne i może przynieść korzyści w przyszłych spekulacjach i nawigacjach.

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

Spekulacje można też anulować za pomocą nagłówka HTTP Clear-Site-Data z dyrektywami prefetchCache i prerenderCache.

Może to być przydatne, gdy stan zmieni się na serwerze. Na przykład podczas wywoływania interfejsu API „dodaj do koszyka” lub interfejsu API logowania lub wylogowywania.

Najlepiej byłoby, gdyby te aktualizacje stanu były propagowane do wstępnie renderowanych stron za pomocą interfejsów API, takich jak Broadcast Channel API, ale jeśli nie jest to możliwe lub dopóki taka logika nie zostanie wdrożona, łatwiej może być anulować spekulację.

Reguły spekulacji i standard Content Security Policy

Reguły spekulacji używają elementu <script>, mimo że zawierają tylko kod JSON, dlatego muszą być uwzględnione w nagłówku script-src Content-Security-Policy, jeśli witryna go używa – za pomocą skrótu lub liczby jednorazowej.

Do script-src można dodać nową wartość inline-speculation-rules, aby umożliwić obsługę elementów <script type="speculationrules"> wstrzykiwanych ze skryptów z hashem lub liczbą jednorazową. Nie obsługuje to reguł zawartych w początkowym kodzie HTML, więc w przypadku witryn, które używają rygorystycznych zasad CSP, reguły muszą być wstrzykiwane przez JavaScript.

Wykrywanie i wyłączanie renderowania wstępnego

Renderowanie wstępne jest zwykle pozytywnym doświadczeniem dla użytkowników, ponieważ umożliwia szybkie renderowanie strony – często natychmiastowe. Przynosi to korzyści zarówno użytkownikowi, jak i właścicielowi witryny, ponieważ wstępnie renderowane strony zapewniają większą wygodę, którą trudno byłoby osiągnąć w inny sposób.

Może się jednak zdarzyć, że nie chcesz, aby strony były renderowane wstępnie, np. gdy strony zmieniają stan na podstawie początkowego żądania lub kodu JavaScript wykonywanego na stronie.

Włączanie i wyłączanie renderowania wstępnego w Chrome

Wstępne renderowanie jest włączone tylko u tych użytkowników Chrome, którzy mają włączone ustawienie „Wstępne wczytywanie stron” w chrome://settings/performance/. Renderowanie wstępne jest też wyłączone na urządzeniach z małą ilością pamięci oraz gdy system operacyjny jest w trybie oszczędzania danych lub energii. Zobacz sekcję Limity w Chrome.

Wykrywanie i wyłączanie renderowania wstępnego po stronie serwera

Wstępnie renderowane strony będą wysyłane z nagłówkiem HTTP Sec-Purpose:

Sec-Purpose: prefetch;prerender

W przypadku stron pobranych z wyprzedzeniem za pomocą interfejsu Speculation Rules API ten nagłówek będzie miał wartość prefetch:

Sec-Purpose: prefetch

Serwery mogą odpowiadać na podstawie tego nagłówka, aby rejestrować żądania spekulacyjne, zwracać inne treści lub zapobiegać renderowaniu wstępnemu. Jeśli zostanie zwrócony kod odpowiedzi końcowej inny niż kod powodzenia, czyli nie z zakresu 200–299 po przekierowaniach, strona nie zostanie wstępnie wyrenderowana, a wszystkie strony pobrane z wyprzedzeniem zostaną odrzucone. Pamiętaj też, że odpowiedzi 204 i 205 nie są prawidłowe w przypadku renderowania wstępnego, ale są prawidłowe w przypadku pobierania z wyprzedzeniem.

Jeśli nie chcesz, aby dana strona była renderowana wstępnie, zwróć kod odpowiedzi inny niż 2XX (np. 503). To najlepszy sposób, aby temu zapobiec. Aby jednak zapewnić użytkownikom jak najlepsze wrażenia, zalecamy zezwolenie na renderowanie wstępne, ale opóźnienie za pomocą JavaScriptu wszelkich działań, które powinny mieć miejsce tylko wtedy, gdy strona jest rzeczywiście wyświetlana.

Wykrywanie renderowania wstępnego w kodzie JavaScript

Interfejs API document.prerendering będzie zwracać wartość true, gdy strona będzie renderowana wstępnie. Strony mogą używać tego interfejsu, aby zapobiegać pewnym działaniom podczas renderowania wstępnego lub je opóźniać, dopóki strona nie zostanie faktycznie aktywowana.

Po aktywowaniu wstępnie renderowanego dokumentu właściwość activationStart interfejsu PerformanceNavigationTiming zostanie ustawiona na wartość niezerową, która reprezentuje czas między rozpoczęciem wstępnego renderowania a faktyczną aktywacją dokumentu.

Możesz użyć funkcji, która sprawdza renderowanie wstępne i wstępnie wyrenderowane strony, np.:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

Najprostszym sposobem sprawdzenia, czy strona została wstępnie wyrenderowana (w całości lub częściowo), jest otwarcie Narzędzi deweloperskich po aktywowaniu strony i wpisanie w konsoli performance.getEntriesByType('navigation')[0].activationStart. Jeśli zwrócona zostanie wartość inna niż 0, oznacza to, że strona została wstępnie wyrenderowana:

Konsola w Narzędziach deweloperskich w Chrome z pozytywnym wynikiem activationStart wskazującym, że strona została wstępnie wyrenderowana
Testowanie renderowania wstępnego w konsoli

Gdy użytkownik wyświetli stronę, zdarzenie prerenderingchange zostanie wysłane do document. Można go użyć do włączenia działań, które wcześniej byłyby domyślnie uruchamiane po wczytaniu strony, ale które chcesz opóźnić do momentu, gdy użytkownik faktycznie wyświetli stronę.

Dzięki tym interfejsom API JavaScript interfejsu użytkownika może wykrywać wstępnie wyrenderowane strony i odpowiednio na nie reagować.

Wpływ na statystyki

Analityka służy do pomiaru korzystania z witryny, np. Google Analytics mierzy odsłony i zdarzenia. Możesz też mierzyć wskaźniki skuteczności stron za pomocą monitorowania rzeczywistych użytkowników (RUM).

Strony powinny być renderowane wstępnie tylko wtedy, gdy istnieje duże prawdopodobieństwo, że użytkownik je wczyta. Dlatego opcje renderowania wstępnego na pasku adresu Chrome są dostępne tylko wtedy, gdy prawdopodobieństwo jest tak wysokie (ponad 80%).

Jednak – zwłaszcza w przypadku korzystania z interfejsu Speculation Rules API – wstępnie wyrenderowane strony mogą mieć wpływ na statystyki, a właściciele witryn mogą potrzebować dodatkowego kodu, aby włączyć statystyki dla wstępnie wyrenderowanych stron tylko po aktywacji, ponieważ nie wszyscy dostawcy statystyk robią to domyślnie.

Można to osiągnąć, używając Promise, który czeka na zdarzenie prerenderingchange, jeśli dokument jest renderowany wstępnie, lub rozwiązuje się natychmiast, jeśli jest teraz:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

Innym podejściem jest opóźnienie działań analitycznych do momentu, gdy strona zostanie po raz pierwszy wyświetlona. Obejmuje to zarówno renderowanie wstępne, jak i otwieranie kart w tle (np. przez kliknięcie prawym przyciskiem myszy i wybranie opcji otwarcia w nowej karcie):

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

Może to być przydatne w przypadku statystyk i podobnych zastosowań, ale w innych przypadkach możesz chcieć załadować więcej treści. Możesz wtedy użyć document.prerendering i prerenderingchange, aby kierować reklamy na strony renderowane wstępnie.

Wstrzymywanie innych treści podczas renderowania wstępnego

Te same interfejsy API, które zostały omówione wcześniej, mogą służyć do wstrzymywania innych treści podczas fazy renderowania wstępnego. Mogą to być określone części kodu JavaScript lub całe elementy skryptu, których nie chcesz uruchamiać na etapie renderowania wstępnego.

Na przykład w przypadku tego skryptu:

<script src="https://example.com/app/script.js" async></script>

Możesz to zmienić na dynamicznie wstawiany element skryptu, który jest wstawiany tylko na podstawie poprzedniej funkcji whenActivated:

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

Może to być przydatne do wstrzymywania różnych skryptów, które obejmują statystyki lub renderują treści na podstawie stanu lub innych zmiennych, które mogą się zmieniać podczas wizyty. Na przykład rekomendacje, stan logowania lub ikony koszyka mogą być wstrzymywane, aby zapewnić wyświetlanie najbardziej aktualnych informacji.

Chociaż może się to zdarzać częściej w przypadku renderowania wstępnego, te warunki dotyczą też stron wczytywanych na kartach w tle, o których wspomnieliśmy wcześniej (funkcji whenFirstVisible można więc używać zamiast whenActivated).

W wielu przypadkach stan powinien być też sprawdzany pod kątem ogólnych zmian visibilitychange – na przykład po powrocie na stronę, która była w tle, wszystkie liczniki koszyka powinny zostać zaktualizowane o najnowszą liczbę produktów w koszyku. Nie jest to więc problem związany z renderowaniem wstępnym, ale renderowanie wstępne sprawia, że istniejący problem jest bardziej widoczny.

Jednym ze sposobów, w jaki Chrome ogranicza potrzebę ręcznego opakowywania skryptów lub funkcji, jest wstrzymywanie niektórych interfejsów API, o czym wspomnieliśmy wcześniej, a także brak renderowania elementów iframe innych firm, więc ręcznie trzeba wstrzymywać tylko treści, które są na nich umieszczone.

pomiar wyników,

W przypadku pomiaru wskaźników skuteczności należy rozważyć, czy lepiej jest mierzyć je na podstawie czasu aktywacji, czy czasu wczytywania strony, który podają interfejsy API przeglądarki.

Core Web Vitals, mierzone przez Chrome w Raporcie na temat użytkowania Chrome, służą do oceny wygody użytkowników. Są one więc mierzone na podstawie czasu aktywacji. Często skutkuje to na przykład wartością LCP na poziomie 0 sekund, co pokazuje, że jest to świetny sposób na poprawę Core Web Vitals.

Od wersji 3.1.0 biblioteka web-vitals została zaktualizowana, aby obsługiwać wstępnie renderowane nawigacje w taki sam sposób, w jaki Chrome mierzy podstawowe wskaźniki internetowe. Ta wersja oznacza też wstępnie wyrenderowane nawigacje dla tych danych w atrybucie Metric.navigationType, jeśli strona została w pełni lub częściowo wstępnie wyrenderowana.

Pomiar renderowania wstępnego

To, czy strona jest renderowana wstępnie, można sprawdzić, gdy wpis activationStart w PerformanceNavigationTiming jest różny od zera. Można to następnie zarejestrować za pomocą wymiaru niestandardowego lub podobnego podczas rejestrowania odsłon, na przykład za pomocą opisanej wcześniej funkcji pagePrerendered:

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

Dzięki temu w statystykach będzie można zobaczyć, ile nawigacji jest renderowanych wstępnie w porównaniu z innymi typami nawigacji, a także powiązać dowolne wskaźniki skuteczności lub wskaźniki biznesowe z tymi różnymi typami nawigacji. Szybsze strony oznaczają większe zadowolenie użytkowników, co często ma realny wpływ na wyniki biznesowe, jak pokazują nasze studia przypadków.

Gdy mierzysz wpływ renderowania wstępnego stron na wyniki biznesowe, możesz zdecydować, czy warto zainwestować więcej wysiłku w korzystanie z tej technologii, aby umożliwić renderowanie wstępne większej liczby stron, czy też zbadać, dlaczego strony nie są renderowane wstępnie.

Pomiar współczynników trafień

Oprócz mierzenia wpływu stron, które są odwiedzane po renderowaniu wstępnym, ważne jest też mierzenie stron, które są renderowane wstępnie, ale nie są później odwiedzane. Może to oznaczać, że renderujesz wstępnie zbyt wiele elementów i zużywasz cenne zasoby użytkownika, nie dając mu w zamian zbyt wielu korzyści.

Można to zmierzyć, uruchamiając zdarzenie analityczne po wstawieniu reguł spekulacyjnych – po sprawdzeniu, czy przeglądarka obsługuje renderowanie wstępne za pomocą HTMLScriptElement.supports('speculationrules') – aby wskazać, że zażądano renderowania wstępnego. (Pamiętaj, że samo żądanie renderowania wstępnego nie oznacza, że zostało ono rozpoczęte lub zakończone. Jak wspomnieliśmy wcześniej, renderowanie wstępne jest wskazówką dla przeglądarki, która może zdecydować, że nie będzie wstępnie renderować stron, biorąc pod uwagę ustawienia użytkownika, bieżące wykorzystanie pamięci lub inne heurystyki).

Możesz wtedy porównać liczbę tych zdarzeń z rzeczywistą liczbą wyświetleń wstępnie wyrenderowanych stron. Możesz też wywołać inne zdarzenie podczas aktywacji, jeśli ułatwi to porównanie.

„Współczynnik udanych trafień” można następnie oszacować, sprawdzając różnicę między tymi 2 liczbami. W przypadku stron, na których używasz interfejsu Speculation Rules API do renderowania wstępnego, możesz odpowiednio dostosować reguły, aby utrzymać wysoki współczynnik trafień i zachować równowagę między wykorzystywaniem zasobów użytkowników do pomocy im a niepotrzebnym ich marnowaniem.

Pamiętaj, że renderowanie wstępne może się odbywać nie tylko na podstawie reguł spekulacji, ale też na podstawie renderowania wstępnego paska adresu. Jeśli chcesz je rozróżnić, możesz sprawdzić document.referrer (który będzie pusty w przypadku nawigacji na pasku adresu, w tym nawigacji na pasku adresu z renderowaniem wstępnym).

Pamiętaj, aby sprawdzić też strony, które nie mają renderowania wstępnego, ponieważ może to oznaczać, że nie kwalifikują się one do renderowania wstępnego, nawet z paska adresu. Może to oznaczać, że nie korzystasz z tego ulepszenia zwiększającego skuteczność. Zespół Chrome chce dodać dodatkowe narzędzia do testowania kwalifikacji do renderowania wstępnego, być może podobne do narzędzia do testowania bfcache, a także potencjalnie dodać interfejs API, który będzie ujawniać, dlaczego renderowanie wstępne się nie powiodło.

Wpływ na rozszerzenia

Zapoznaj się z postem na temat rozszerzeń do Chrome: rozszerzanie interfejsu API w celu obsługi natychmiastowej nawigacji, w którym szczegółowo opisano dodatkowe kwestie, które autorzy rozszerzeń mogą wziąć pod uwagę w przypadku wstępnie renderowanych stron.

Prześlij opinię

Zespół Chrome aktywnie rozwija renderowanie wstępne i planuje rozszerzyć zakres funkcji udostępnionych w Chrome 108. Chętnie poznamy Twoją opinię w repozytorium GitHub lub za pomocą naszego narzędzia Issue Tracker. Z niecierpliwością czekamy na studia przypadków dotyczące tego nowego, ekscytującego interfejsu API.

Podziękowania

Miniatura: Marc-Olivier Jodoin na Unsplash