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

Barry Pollard

Obsługa przeglądarek

  • Chrome: 109.
  • Edge: 109.
  • Firefox: nieobsługiwane.
  • Safari: nieobsługiwane.

Zespół Chrome przywrócił pełne prerenderowanie przyszłych stron, do których użytkownik może przejść.

Krótka historia prerenderowania

W przeszłości Chrome obsługiwało podpowiedź zasobu <link rel="prerender" href="/next-page">, ale nie było ona powszechnie obsługiwana poza Chrome i nie była zbyt rozbudowanym interfejsem API.

Starszy sposób wstępnego renderowania za pomocą podpowiedzi linku rel=prerender został wycofany na rzecz wstępnego pobierania bez stanu, który zamiast tego pobierał zasoby potrzebne na przyszłej stronie, ale nie przeprowadzał wstępnego renderowania strony w pełni ani nie wykonywał kodu JavaScript. Pobieranie z ignorowaniem stanu pomaga poprawić wydajność strony dzięki szybszemu wczytywaniu zasobów, ale nie zapewnia natychmiastowego wczytania strony, jak w przypadku pełnego renderowania wstępnego.

Zespół Chrome przywrócił pełne prerenderowanie w Chrome. Aby uniknąć komplikacji związanych z obecnym użyciem i umożliwić przyszłe rozszerzenie prerenderowania, nowy mechanizm nie będzie używać składni <link rel="prerender"...>, która pozostaje w użyciu w przypadku pobierania z wyprzedzeniem bez stanu, z zamysłem wycofania tej opcji w przyszłości.

Jak strona jest renderowana wstępnie?

Stronę można wyrenderować w jednym z 4 sposobów, które mają na celu przyspieszenie nawigacji:

  1. Gdy wpiszesz adres URL w pasku adresu Chrome (zwanym też „omniboksem”), Chrome może automatycznie wstępnie wyrenderować stronę, jeśli na podstawie Twojej historii przeglądania uzna, że jest to prawdopodobne.
  2. Gdy korzystasz z paska zakładek, Chrome może automatycznie renderować stronę, gdy najedziesz kursorem na jeden z przycisków zakładek.
  3. Gdy wpiszesz wyszukiwane hasło na pasku adresu Chrome, przeglądarka może automatycznie wyrenderować stronę wyników wyszukiwania, jeśli wyszukiwarka wskaże, że ma to zrobić.
  4. Witryny mogą używać interfejsu Speculation Rules API, aby programowo informować Chrome, które strony mają być renderowane z wyprzedzeniem. Zastępuje to, co robiła funkcja <link rel="prerender"...>, i pozwala witrynom na proaktywne prerenderowanie strony na podstawie reguł spekulacji. Mogą one być umieszczone na stronach w postaci statycznych elementów lub dynamicznie wstrzykiwane przez JavaScript w miarę potrzeb właściciela strony.

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

Ponieważ strona wstępnie wyrenderowana jest otwierana w stanie ukrytym, wiele interfejsów API, które powodują natrętne zachowania (np. prompty), nie są w tym stanie aktywowane, lecz opóźnione do czasu aktywacji strony. W niewielkiej liczbie przypadków, gdy nie jest to jeszcze możliwe, wstępne renderowanie jest anulowane. Zespół Chrome pracuje nad udostępnieniem przyczyn anulowania prerenderowania w ramach interfejsu API oraz ulepszaniem możliwości Narzędzi dla programistów, aby ułatwić identyfikowanie takich szczególnych przypadków.

Wpływ prerenderowania

Dzięki prerenderowaniu strona wczytuje się niemal natychmiast, jak widać w tym filmie:

Przykładowy wpływ prerenderowania.

Witryna przykładowa jest już szybka, ale nawet w tym przypadku możesz zauważyć, jak prerenderowanie poprawia wrażenia użytkowników. Może to mieć bezpośredni wpływ na podstawowe wskaźniki internetowe witryny, ponieważ LCP będzie bliski zera, CLS będzie mniejszy (ponieważ CLS wczytywania występuje przed pierwszym wyświetleniem) i zwiększy się INP (ponieważ wczytywanie powinno zostać ukończone, zanim użytkownik wejdzie w interakcję).

Nawet jeśli strona aktywuje się, zanim zostanie w pełni wczytana, to samo wczesne rozpoczęcie wczytywania powinno poprawić komfort wczytywania. Gdy link zostanie aktywowany, gdy wstępna renderyzacja jest nadal w toku, strona wstępnie renderowana przejdzie do ramki głównej i będzie kontynuować wczytywanie.

Wstępna renderyzacja wykorzystuje jednak dodatkową pamięć i przepustowość sieci. Uważaj, aby nie przerenderować zasobów w zbyt dużym stopniu kosztem zasobów użytkownika. Wstępnie renderuj tylko wtedy, gdy istnieje duże prawdopodobieństwo przejścia na daną stronę.

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

Wyświetlanie sugestii na pasku adresu w Chrome

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

Strona Prognozy Chrome, na której wyświetlane są prognozy o niskim (szarym), średnim (pomarańczowym) i wysokim (zielonym) prawdopodobieństwie na podstawie wpisanego tekstu.
Strona „Predictors” w Chrome.

Zielone linie wskazują wystarczającą pewność, aby uruchomić prerenderowanie. W tym przykładzie wpisanie „s” daje rozsądne prawdopodobieństwo (pomarańczowe), ale gdy wpiszesz „sh”, Chrome ma wystarczająco duże prawdopodobieństwo, że prawie zawsze przechodzisz do https://sheets.google.com.

Ten zrzut ekranu został zrobiony w przypadku stosunkowo nowej instalacji Chrome i z odfiltrowanymi prognozami o zerowym poziomie ufności. Jeśli jednak wyświetlisz własne predyktory, 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 sugerowane opcje na pasku adresu, które możesz zauważyć:

Funkcja „Autouzupełnianie” na pasku adresu w Chrome
Funkcja „Wyświetlanie sugestii” na pasku adresu.

Chrome będzie stale aktualizować swoje predyktory na podstawie tego, co wpisujesz i wybierasz.

  • Jeśli poziom pewności przekracza 50% (oznaczony na żółto), Chrome aktywnie nawiązuje wstępnie połączenie z domeną, ale nie renderuje strony wstępnie.
  • Jeśli poziom ufności przekracza 80% (oznaczony na zielono), Chrome zrenderuje adres URL z wyprzedzeniem.

Speculation Rules API

W przypadku opcji prerenderowania interfejsu API Speculation Rules deweloperzy witryn mogą wstawiać na swoich stronach instrukcje w formacie JSON, aby informować przeglądarkę, które adresy URL mają być prerenderowane:

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

Albo za pomocą reguł dokumentu (dostępnych od wersji Chrome 121), które wstępnie renderują linki znalezione w dokumencie na podstawie selektorów href (na podstawie interfejsu 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>

Zespół Chrome przygotował ćwiczenie z programowania Speculation Rules Codelab, które poprowadzi Cię przez proces dodawania reguł spekulacji do witryny.

Zapał

Obsługa przeglądarek

  • Chrome: 121.
  • Edge: 121.
  • Firefox: nieobsługiwane.
  • Safari: nieobsługiwane.

Ustawienie eagerness służy do wskazywania, kiedy mają się uruchamiać spekulacje. Jest to szczególnie przydatne w przypadku reguł dotyczących dokumentów:

  • immediate: ta opcja służy do spekulowania tak szybko, jak to możliwe, czyli tak szybko, jak przestrzegane są reguły spekulacji.
  • eager: działa identycznie jak ustawienie immediate, ale w przyszłości chcemy umieścić je gdzieś pomiędzy immediate a moderate.
  • moderate: ta funkcja wykonuje spekulacje, gdy wskaźnik myszki znajduje się nad linkiem przez 200 ms (lub w przypadku zdarzenia pointerdown, jeśli nastąpi to wcześniej, oraz na urządzeniach mobilnych, na których nie ma zdarzenia hover).
  • conservative: spekulacje dotyczące wskaźnika lub dotknięcia.

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

Domyślna wartość eagerness dla reguł document to conservative. Ponieważ dokument może zawierać wiele adresów URL, należy zachować ostrożność przy stosowaniu reguł immediate lub eager w regułach document (patrz także następna sekcja Ograniczenia w Chrome).

Które ustawienie eagerness należy użyć, zależy od Twojej witryny. W przypadku lekkiej, statycznej witryny spekulowanie może nie wiązać się z wysokimi kosztami, a może być korzystne dla użytkowników. Właściciele witryn o bardziej złożonej architekturze i większym ładunku strony mogą preferować ograniczanie marnotrawstwa przez rzadsze spekulowanie, dopóki nie otrzymają od użytkowników więcej pozytywnych sygnałów o ich zamiarach, które pozwolą ograniczyć marnotrawstwo.

Opcja moderate to kompromis. Wiele witryn może skorzystać z następującej reguły spekulacji, która wstępnie renderuje link, gdy wskaźnik znajduje się nad nim przez 200 ms, lub w zdarzeniu wskaźnik wciśnięty, co stanowi podstawową, ale skuteczną implementację reguł spekulacji:

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

Pobieranie z wyprzedzeniem

Reguły spekulacyjne można też stosować do pobierania z wyprzedzeniem tylko stron, bez pełnego prerenderowania. Może to być dobry pierwszy krok na drodze do wstępnego renderowania:

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

Limity Chrome

Chrome ma limity, które zapobiegają nadużywaniu interfejsu Speculation Rules API:

chęć Pobieranie z wyprzedzeniem Renderowanie wstępne
immediate/eager 50 10
moderate/conservative 2 (FIFO) 2 (FIFO)
Ograniczenia spekulacji w Chrome

Ustawienia moderate i conservative, które zależą od interakcji użytkownika, działają w sposób pierwsze wejść, pierwsze wyjść (FIFO): po osiągnięciu limitu nowa spekulacja spowoduje anulowanie najstarszej spekulacji i jej zastąpienie nowszą, aby oszczędzać pamięć. Anulowane przypuszczenie może zostać ponownie wywołane, np. przez ponowne najechanie kursorem na link. Spowoduje to ponowne spekulowanie nad tym adresem URL, co spowoduje usunięcie najstarszego przypuszczenia. W tym przypadku poprzednie spekulacje powinny mieć zapisane w pamięci podręcznej w ramach pamięci podręcznej HTTP wszystkie zasoby, które można zapisać w pamięci podręcznej, dla tego adresu URL. Dzięki temu kolejne spekulacje powinny być tańsze. Dlatego limit został ustawiony na umiarkowany próg 2. Reguły list statycznych nie są wywoływane przez działanie użytkownika, dlatego mają wyższy limit, ponieważ przeglądarka nie może wiedzieć, które z nich są potrzebne i kiedy.

Limity immediate i eager są też dynamiczne, więc usunięcie elementu skryptu adresu URL list spowoduje utworzenie pojemności przez anulowanie tych usuniętych spekulacji.

Chrome będzie też zapobiegać spekulacjom w pewnych warunkach, w tym:

  • Oszczędzanie danych.
  • Oszczędzanie energii, gdy jest włączone i bateria jest rozładowana.
  • Ograniczenia dotyczące pamięci.
  • gdy wyłączone jest ustawienie „Wstępnie wczytuj strony” (które jest też wyraźnie wyłączane przez rozszerzenia do Chrome, takie jak uBlock Origin);
  • strony otwierane w kartach w tle.

Chrome nie renderuje też ramek iframe z innych domen na stronach wstępnych, dopóki nie zostaną one aktywowane.

Wszystkie te warunki mają na celu ograniczenie wpływu nadmiernych spekulacji, które mogą być szkodliwe dla użytkowników.

Jak uwzględnić reguły spekulacyjne na stronie

Reguły spekulacji mogą być statycznie uwzględniane w kodzie HTML strony lub dynamicznie wstawiane na stronie przez JavaScript:

  • 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ępny krok w przypadku dużej liczby użytkowników. Można też użyć reguł dokumentu z wartością moderate lub conservative, aby spekulować na temat interakcji użytkowników z linkami.
  • Dynamicznie wstawiane reguły spekulacji: mogą one być oparte na logice aplikacji, spersonalizowane dla użytkownika lub oparte na innych heurystycznych metodach.

Osoby, które preferują dynamiczne wstawianie na podstawie działań takich jak najechanie kursorem lub kliknięcie linku (jak wiele bibliotek robiło to w przeszłości w przypadku <link rel=prefetch>), powinny zapoznać 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 ramach <head> lub <body> w ramce głównej. Reguły spekulacyjne w ramkach podrzędnych nie są uruchamiane, a reguły spekulacyjne na stronach z renderowaniem wstępnym są uruchamiane dopiero po aktywowaniu strony.

Nagłówek HTTP Speculation-Rules

Obsługa przeglądarek

  • Chrome: 121.
  • Edge: 121.
  • Firefox: nieobsługiwane.
  • Safari: nieobsługiwane.

Źródło

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

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

Speculation-Rules: "/speculationrules.json"

Ten zasób musi używać prawidłowego typu MIME, a jeśli jest to zasób między domenami, musi przejść weryfikację CORS.

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

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

Reguły spekulacyjne i usługi spekulacyjne

Reguły spekulacji są obsługiwane tylko w przypadku pełnej nawigacji na stronie zarządzanej przez przeglądarkę, a nie w przypadku aplikacji jednostronicowych (SPA) ani stron opakowania aplikacji. Architektura ta nie korzysta z pobierania dokumentów, ale z interfejsów API lub częściowego pobierania danych lub stron, które są następnie przetwarzane i prezentowane na bieżącej stronie. Dane potrzebne do tych tak zwanych „miękkich nawigacji” mogą być pobierane wstępnie przez aplikację poza regułami spekulacji, ale nie można ich renderować wstępnie.

Reguły spekulacji można wykorzystać do wstępnego wyrenderowania aplikacji z poprzedniej strony. Może to pomóc w zrównoważenie niektórych dodatkowych kosztów początkowego wczytywania, które występują w niektórych SPA. Nie można jednak prerenderować zmian trasy w aplikacji.

Debugowanie reguł spekulacyjnych

Aby dowiedzieć się więcej o nowych funkcjach narzędzi deweloperskich w Chrome, które ułatwiają wyświetlanie i debugowanie tego nowego interfejsu API, przeczytaj ten artykuł na temat debugowania reguł spekulacji.

Wiele reguł spekulacyjnych

Na tej samej stronie możesz też dodać wiele reguł spekulacji, które zostaną dołączone do istniejących reguł. Dlatego wszystkie te metody prowadzą do wstępnego renderowania 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 ramach jednego zestawu speculationrules

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

Obsługa przeglądarek

  • Chrome: 121.
  • Edge: 121.
  • Firefox: nieobsługiwane.
  • Safari: nieobsługiwane.

Źródło

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

Na przykład parametry UTM są używane przez Google Analytics do pomiaru kampanii, ale zwykle nie powodują wyświetlania różnych stron przez serwer. Oznacza to, że page1.html?utm_content=123 i page1.html?utm_content=456 będą dostarczać tę samą stronę z serwera, więc można ponownie użyć tej samej strony 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 temu 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. Ta funkcja jest obsługiwana w Chrome (i przeglądarkach opartych na Chromium) w przypadku spekulacji dotyczącej wstępnego pobierania nawigacji (chociaż rozważamy obsługę tej funkcji w przypadku wstępnego renderowania).

Reguły spekulacji obsługują użycie elementu expects_no_vary_search do wskazania, gdzie ma zostać zwrócony nagłówek HTTP No-Vary-Search. Pomoże to uniknąć niepotrzebnych pobrań.

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

Jeśli jednak użytkownik kliknie którykolwiek z linków przed zakończeniem pobierania w ramach przewidywania zapytań, przeglądarka może nie otrzymać strony /products. W tym przypadku przeglądarka nie wie, czy zawiera on nagłówek HTTP No-Vary-Search. Przeglądarka może wtedy ponownie pobrać link lub poczekać na zakończenie pobierania w ramach przewidywania zapytań, 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 czeka na zakończenie tej operacji wstępnego pobierania.

Ograniczenia reguł spekulacyjnych i przyszłe ulepszenia

Reguły spekulacji są ograniczone do stron otwieranych w tej samej karcie, ale pracujemy nad zniesieniem tego ograniczenia.

Domyślnie spekulacje są ograniczone do stron z tego samego źródła. Strony spekulacyjne w tym samym miejscu w różnych domenach (np. https://a.example.com może wstępnie wyrenderować stronę w https://b.example.com). Aby korzystać z tej funkcji, strona spekulacyjna (w tym przykładzie https://b.example.com) musi wyrazić zgodę, dodając nagłówek HTTP Supports-Loading-Mode: credentialed-prerender. W przeciwnym razie Chrome anuluje spekulację.

W przyszłych wersjach możliwe będzie wstępne renderowanie stron z innych witryn, o ile nie zawierają one plików cookie, a strona z wstępnie renderowaną korzysta z podobnego nagłówka HTTP Supports-Loading-Mode: uncredentialed-prerender.

Reguły spekulacji obsługują już wstępne pobieranie z innych źródeł, ale znowu tylko wtedy, gdy pliki cookie dla domeny z innego źródła nie istnieją. Jeśli istnieją pliki cookie, które wskazują, że użytkownik odwiedził już tę witrynę, nie zostanie uruchomione przypuszczenie i w DevTools pojawi się komunikat o błędzie.

Z uwagi na te ograniczenia, aby poprawić wrażenia użytkowników w przypadku linków wewnętrznych i zewnętrznych, warto w miarę możliwości wstępnie renderować adresy URL w tej samej domenie i próbować pobierać wstępne adresy URL z innej domeny:

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

Ograniczenie, które domyślnie zapobiega spekulacjom w przypadku linków między domenami, jest niezbędne ze względów bezpieczeństwa. Jest to ulepszenie w porównaniu z <link rel="prefetch"> w przypadku docelów w innych domenach, które również nie wysyłają plików cookie, ale próbują wczytać strony z zapowiedzi, co spowoduje albo zmarnowanie zasobów na wczytywanie z zapowiedzi, które trzeba będzie ponownie wysłać, albo – co gorsza – nieprawidłowe wczytywanie strony.

Reguły spekulacji nie są obsługiwane w przypadku wstępnego pobierania stron kontrolowanych przez serwisy workerów. Pracujemy nad dodaniem tej funkcji. Aby otrzymywać informacje o tym problemie, śledź ten problem z usługą wątek pracy. Wstępny renderowanie jest obsługiwane w przypadku stron kontrolowanych przez skrypt service worker.

Obsługa interfejsu API reguł spekulacyjnych

Obsługę interfejsu API Reguł spekulacji możesz wykryć za pomocą standardowych kontroli HTML:

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

Dodawanie reguł spekulacyjnych dynamicznie za pomocą kodu JavaScript

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

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);
}

Na tej stronie demonstracyjnej wstępnego renderowania możesz obejrzeć demonstrację interfejsu Speculation Rules API, która wykorzystuje wstawianie JavaScriptu.

Wstawianie elementu <script type = "speculationrules"> bezpośrednio do DOM za pomocą innerHTML nie spowoduje zarejestrowania reguł spekulacji ze względów bezpieczeństwa. Należy je dodać w sposób pokazany wcześniej. Jednak treści wstawiane dynamicznie za pomocą innerHTML, które zawierają nowe linki, będą wykrywane przez istniejące reguły na stronie.

Podobnie bezpośrednia edycja panelu Elementy w Narzędziach deweloperskich Chrome w celu dodania elementu <script type = "speculationrules"> nie rejestruje reguł spekulacji. Aby wstawić reguły, należy uruchomić skrypt, który dynamicznie doda element do DOM.

Dodawanie reguł spekulacji za pomocą Menedżera tagów

Aby dodać reguły spekulacji za pomocą menedżera tagów, np. Menedżera tagów Google (GTM), musisz je wstawiać za pomocą kodu JavaScript, a nie dodawać elementu <script type = "speculationrules"> bezpośrednio w Menedżerze tagów z tych samych powodów, o których była mowa wcześniej:

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

Pamiętaj, że w tym przykładzie używamy var, ponieważ GTM nie obsługuje const.

Anulowanie reguł spekulacyjnych

Usunięcie reguł spekulacji spowoduje anulowanie prerenderowania, ale do tego czasu zasoby zostaną prawdopodobnie już wykorzystane do zainicjowania prerenderowania, dlatego zalecamy anulowanie prerenderowania, jeśli istnieje prawdopodobieństwo, że będzie trzeba je anulować.

Zasady dotyczące spekulacji i zasady bezpieczeństwa treści

Reguły spekulacji używają elementu <script>, mimo że zawierają tylko JSON, dlatego muszą być uwzględnione w elementach script-src Content-Security-Policy, jeśli witryna ich używa – za pomocą hasha lub nonce.

Do script-src można dodać nowy element inline-speculation-rules, aby umożliwić obsługę elementów <script type="speculationrules"> wstrzykiwanych z szyfrowanych lub szyfrowanych szyfrem jednorazowym skryptów. Ta metoda nie obsługuje reguł zawartych w początkowym kodzie HTML, więc w przypadku witryn, które używają rygorystycznego CSP, reguły muszą być wstrzykiwane przez JavaScript.

Wykrywanie i wyłączanie prerenderowania

Wstępna renderyzacja zwykle jest korzystna dla użytkowników, ponieważ umożliwia szybkie renderowanie strony, często natychmiastowe. Jest to korzystne zarówno dla użytkownika, jak i właściciela witryny, ponieważ strony z renderowaniem wstępnym zapewniają lepsze wrażenia użytkowników, których trudno byłoby osiągnąć w inny sposób.

Mogą jednak wystąpić sytuacje, w których nie chcesz, aby strony były renderowane wstępnie, np. gdy zmieniają stan – na podstawie początkowego żądania lub kodu JavaScript wykonywanego na stronie.

Włączanie i wyłączanie prerenderowania w Chrome

Wyprzedaż jest włączona tylko dla użytkowników Chrome, którzy mają ustawienie „Przelewaj strony” w chrome://settings/performance/. Dodatkowo prerenderowanie jest wyłączone na urządzeniach z małą ilością pamięci lub jeśli system operacyjny jest w trybie oszczędzania danych lub oszczędzania energii. Zobacz sekcję Ograniczenia Chrome.

Wykrywanie i wyłączanie prerenderowania po stronie serwera

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

Sec-Purpose: prefetch;prerender

Strony z wstępnie pobranym kodem, które korzystają z interfejsu Speculation Rules API, będą miały ten nagłówek ustawiony tylko na prefetch:

Sec-Purpose: prefetch

Serwery mogą odpowiadać na podstawie tego nagłówka, aby rejestrować żądania spekulacyjne, zwracać inne treści lub zapobiegać prerenderowaniu. Jeśli zwrócony zostanie kod odpowiedzi, który nie oznacza sukcesu (czyli nie jest to kod z zakresu 200–299 po przekierowaniach), strona nie zostanie wstępnie wyrenderowana, a każda strona z pobieraniem wstępnego w tle zostanie odrzucona. Pamiętaj też, że odpowiedzi 204 i 205 nie są prawidłowe w przypadku prerenderowania, ale są prawidłowe w przypadku wstępnego pobierania.

Jeśli nie chcesz, aby dana strona była renderowana wstępnie, możesz zwrócić kod odpowiedzi inny niż 2XX (np. 503), aby tego uniknąć. Aby jednak zapewnić użytkownikom jak najlepsze wrażenia, zalecamy zamiast tego zezwolenie na prerenderowanie, ale opóźnienie za pomocą kodu JavaScript wszelkich działań, które powinny nastąpić dopiero po wyświetleniu strony.

Wykrywanie wstępnie renderowania w JavaScript

Podczas wstępnego renderowania strony interfejs API document.prerendering zwróci wartość true. Strony mogą używać tej metody, aby zapobiegać lub opóźniać określone działania podczas wstępnego renderowania, dopóki strona nie zostanie faktycznie aktywowana.

Po aktywowaniu wstępnie wyrenderowanego dokumentu wartość atrybutu PerformanceNavigationTiming zostanie ustawiona na wartość niezerową, która będzie reprezentować czas od rozpoczęcia wstępnego renderowania do faktycznego aktywowania dokumentu.activationStart

Funkcja może sprawdzać przedwstępny renderowanie i przedwstępnie wyrenderowane strony, takie jak te:

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

Najprostszym sposobem sprawdzenia, czy strona została wstępnie wyrenderowana (w pełni lub częściowo), jest otwarcie Narzędzi deweloperskich po jej aktywacji i wpisanie w konsoli performance.getEntriesByType('navigation')[0].activationStart. Jeśli zwracana jest wartość różna od 0, oznacza to, że strona została wyrenderowana z wyprzedzeniem:

Konsola w Narzędziach deweloperskich w Chrome, która pokazuje pozytywny stan aktywacji wskazujący, że strona została wstępnie wyrenderowana
Testowanie prerenderowania w konsoli.

Gdy strona zostanie aktywowana przez użytkownika, który ją wyświetla, na document zostanie wysłane zdarzenie prerenderingchange, które można wykorzystać do włączenia działań, które wcześniej były uruchamiane domyślnie po wczytaniu strony, ale teraz chcesz opóźnić do momentu, gdy użytkownik faktycznie ją wyświetli.

Dzięki tym interfejsom API front-end JavaScript może wykrywać wstępnie wyrenderowane strony i odpowiednio na nie reagować.

Wpływ na statystyki

Analytics służą do pomiaru korzystania z witryny, np. za pomocą Google Analytics do pomiaru odsłon i zdarzeń. Możesz też mierzyć wskaźniki wydajności stron za pomocą monitorowania prawdziwych użytkowników (RUM).

Strony należy renderować wstępnie tylko wtedy, gdy istnieje duże prawdopodobieństwo, że użytkownik je wczyta. Dlatego opcje prerenderowania paska adresu w Chrome są dostępne tylko wtedy, gdy prawdopodobieństwo jest wysokie (ponad 80% czasu).

Jednak w pewnych przypadkach, np. gdy korzystasz z interfejsu Speculation Rules API, strony z renderowaniem wstępnym mogą mieć wpływ na analitykę. Właściciele witryn mogą więc potrzebować dodatkowego kodu, aby włączyć analitykę tylko na stronach z renderowaniem wstępnym, ponieważ nie wszyscy dostawcy usług analitycznych mogą to zrobić domyślnie.

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

// 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();

Alternatywnym podejściem jest opóźnienie działań analitycznych do momentu, gdy strona stanie się widoczna. Obejmuje to zarówno wstępny render, jak i otwieranie kart w tle (np. przez kliknięcie prawym przyciskiem myszy i wybranie opcji Otwórz 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 analityki i podobnych zastosowań, ale w innych przypadkach możesz chcieć załadować więcej treści, aby docelowo kierować na strony z przedrenderowaniem. W tym celu możesz użyć tagów document.prerendering i prerenderingchange.

Wstrzymanie innych treści podczas wstępnego renderowania

Te same interfejsy API, o których była mowa wcześniej, można wykorzystać do wstrzymania innych treści na etapie wstępnego renderowania. Mogą to być konkretne fragmenty kodu JavaScript lub całe elementy skryptu, których nie chcesz uruchamiać na etapie wstępnego renderowania.

Na przykład w tym skrypcie:

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

Możesz zmienić to na dynamicznie wstawiany element skryptu, który wstawia się 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, aby wstrzymać skrypty, które zawierają funkcje analityczne, lub renderować treści na podstawie stanu lub innych zmiennych, które mogą się zmieniać w trakcie wizyty. Na przykład rekomendacje, stan logowania czy ikony koszyka mogą być wstrzymywane, aby zapewnić wyświetlanie aktualnych informacji.

Chociaż jest to bardziej prawdopodobne w przypadku korzystania z prerenderowania, te warunki są również prawdziwe w przypadku stron wczytywanych na kartach w tle (czyli zamiast funkcji whenActivated można użyć funkcji whenFirstVisible).

W wielu przypadkach stan powinien być sprawdzany w przypadku 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 problem związany z wstępnym renderowaniem, ale wstępny render tylko uwypuklił istniejący problem.

Jednym ze sposobów, w jaki Chrome ogranicza potrzebę ręcznego otaczania skryptów lub funkcji, jest opóźnianie niektórych interfejsów API, jak wspomniano wcześniej. Ponadto elementy iframe innych firm nie są renderowane, więc tylko treści na ich wierzchu wymagają ręcznego opóźnienia.

Pomiar wyników

W przypadku pomiarów wydajności usługa analityczna powinna rozważyć, czy lepiej jest mierzyć je na podstawie czasu aktywacji, a nie czasu wczytywania strony, który jest raportowany przez interfejsy API przeglądarki.

Podstawowe wskaźniki internetowe są mierzone przez Chrome w Raporcie na temat użytkowania Chrome i mają na celu pomiar wygody korzystania. Są one mierzone na podstawie czasu aktywacji. Często powoduje to, że czas LCP wynosi 0 sekund, co jest świetnym sposobem na poprawę podstawowych wskaźników internetowych.

Od wersji 3.1.0 biblioteka web-vitals została zaktualizowana, aby obsługiwać nawigację z wyrenderowanymi wcześniej elementami w taki sam sposób, w jaki Chrome mierzy wskaźniki Core Web Vitals. Ta wersja zawiera też flagi z danymi dotyczącymi wstępnie wyrenderowanej nawigacji w atrybucie Metric.navigationType, jeśli strona została wstępnie wyrenderowana w całości lub częściowo.

Pomiar wstępnego renderowania

Informację o tym, czy strona została wyrenderowana z wyprzedzeniem, można sprawdzić, gdy w tagu activationStart PerformanceNavigationTiming występuje wartość różna od 0. Dane te można rejestrować za pomocą wymiaru niestandardowego lub podobnego podczas rejestrowania wyświetleń strony, np. za pomocą funkcji pagePrerendered opisanej wcześniej:

// 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 zobaczysz, ile elementów nawigacji jest renderowanych wstępnie w porównaniu z innymi typami elementów nawigacji. Będziesz też mieć możliwość powiązania dowolnych danych o skuteczności lub danych biznesowych z różnymi typami elementów nawigacji. Szybsze wczytywanie stron sprawia, że użytkownicy są zadowoleni, co może mieć realny wpływ na wskaźniki biznesowe, jak pokazują nasze przykłady.

Po zmierzeniu wpływu wstępnego renderowania stron na potrzeby natychmiastowej nawigacji możesz zdecydować, czy warto zainwestować więcej wysiłku w wykorzystanie tej technologii, aby umożliwić wstępne renderowanie większej liczby nawigacji, czy też sprawdzić, dlaczego strony nie są wstępnej renderowane.

Pomiar współczynników trafień

Oprócz pomiaru wpływu stron, które są odwiedzane po wstępnym renderowaniu, ważne jest też pomiar stron, które są wstępnie renderowane, ale nie są później odwiedzane. Może to oznaczać, że zbyt dużo zasobów jest renderowanych z wyprzedzeniem, co pochłania cenne zasoby użytkownika bez większej korzyści.

Można to mierzyć, uruchamiając zdarzenie Analytics, gdy wstawiane są reguły spekulacji (po sprawdzeniu, czy przeglądarka obsługuje prerenderowanie za pomocą HTMLScriptElement.supports('speculationrules')), aby wskazać, że żądanie prerenderowania zostało wysłane. (pamiętaj, że fakt, że przesłano żądanie renderowania wstępnego, nie oznacza, że zostało ono rozpoczęte lub zakończone, ponieważ jak już wspomnieliśmy, jest to tylko sugestia dla przeglądarki, która może nie stosować renderowania wstępnego w zależności od ustawień użytkownika, bieżącego wykorzystania pamięci lub innych heurystycznych metod).

Następnie możesz porównać liczbę tych zdarzeń z liczbą rzeczywistych wyświetleń stron przed wyrenderowaniem. Możesz też uruchomić inne zdarzenie po aktywacji, jeśli ułatwi Ci to porównanie.

„Skuteczność” można wtedy oszacować na podstawie różnicy między tymi dwoma wartościami. W przypadku stron, w przypadku których do wstępnego renderowania stron używasz interfejsu Speculation Rules API, możesz odpowiednio dostosować reguły, aby zachować wysoką częstotliwość trafień i utrzymać równowagę między wykorzystaniem zasobów użytkowników w celu pomocy im a niepotrzebnym ich zużyciem.

Pamiętaj, że niektóre renderowanie wstępne może być wykonywane z powodu renderowania wstępnego paska adresu, a nie tylko z powodu reguł spekulacji. Jeśli chcesz je rozróżnić, możesz sprawdzić pole document.referrer (które będzie puste w przypadku nawigacji na pasku adresu, w tym w przypadku wstępnie wyrenderowanych elementów nawigacji na pasku adresu).

Zwróć też uwagę na strony, które nie mają prerenderowania, ponieważ może to oznaczać, że nie można ich przerenderować wstępnie, nawet z poziomu paska adresu. Może to oznaczać, że nie korzystasz z tej poprawy wydajności. Zespół Chrome planuje dodać dodatkowe narzędzia do testowania kwalifikacji do wstępnego renderowania, podobnych do narzędzia do testowania bfcache, a także potencjalnie dodać interfejs API, który będzie informować, dlaczego wstępne renderowanie się nie udało.

Wpływ na rozszerzenia

Przeczytaj dedykowany wpis na temat rozszerzeń Chrome: rozszerzanie interfejsu API w celu obsługi nawigacji błyskawicznej, w którym znajdziesz dodatkowe informacje, które mogą być przydatne autorom rozszerzeń w przypadku stron z zabezpieczeniami.

Prześlij opinię

Zespół Chrome aktywnie pracuje nad funkcją wstępnego renderowania. Planujemy też rozszerzyć zakres funkcji udostępnionych w wersji Chrome 108. Czekamy na opinie na temat repozytorium GitHub lub w naszym narzędziu do śledzenia problemów. Z niecierpliwością czekamy na przypadki użycia tego nowego, ekscytującego interfejsu API.

Podziękowania

Miniatura autorstwa Marc-Olivier Jodoin na Unsplash