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

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 przeglądarka Chrome obsługiwała wskazówkę dotyczącą zasobów <link rel="prerender" href="/next-page">, nie była jednak powszechnie obsługiwana poza Chrome i nie była zbyt ekspresywna.

To starsze renderowanie wstępne z wykorzystaniem wskazówki link rel=prerender zostało wycofane na rzecz funkcji NoState Prefetch, która pobierała zasoby potrzebne dla przyszłej strony, ale nie w pełni renderowała strony ani nie wykonała JavaScriptu. Wstępne pobieranie NoState zwiększa wydajność strony przez usprawnienie wczytywania zasobów, ale nie zapewnia od razu wczytywania strony, jak miałoby to miejsce w przypadku pełnego renderowania wstępnego.

Zespół Chrome ponownie wprowadził pełne renderowanie wstępne w Chrome. Aby uniknąć komplikacji związanych z obecnym wykorzystaniem i umożliwić rozszerzenie renderowania wstępnego w przyszłości, ten nowy mechanizm wstępnego renderowania nie będzie używać składni <link rel="prerender"...>, która pozostaje dostępna w przypadku wstępnego pobierania NoState. Planujemy ją w przyszłości wycofać.

Jak strona jest wstępnie renderowana?

Stronę można wstępnie wyrenderować na jeden z 4 sposobów przyspieszenia nawigacji:

1. Gdy wpiszesz adres URL na pasku adresu Chrome (nazywanym też „omniboksem”), Chrome może automatycznie wstępnie wyrenderować stronę, jeśli istnieje duża szansa, że ją odwiedzisz.
2. Gdy używasz paska zakładek, Chrome może automatycznie wstępnie wyrenderować stronę, gdy przytrzymasz wskaźnik nad jednym z przycisków zakładek.
3. Gdy wpiszesz wyszukiwane hasło na pasku adresu Chrome, Chrome może automatycznie wstępnie wyrenderować stronę wyników wyszukiwania, jeśli poprosi o to wyszukiwarka.
4. Witryny mogą używać interfejsu API reguł spekulacyjnych, aby automatycznie informować Chrome o tym, które strony mają być wstępnie renderowane. Zastępuje to dotychczasowe działanie <link rel="prerender"...> i umożliwia witrynom aktywne wstępne renderowanie strony na podstawie reguł spekulacyjnych. Mogą one znajdować się statycznie na stronach lub być wstrzykiwane dynamicznie przez JavaScript zgodnie z oczekiwaniami właściciela strony.

W każdym z tych przypadków renderowanie wstępne działa tak, jakby strona została otwarta na niewidocznej karcie w tle, a następnie zostaje „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 nadal będzie się ładować, co oznacza, że nadal możesz się przygotować.

Wstępnie renderowana strona jest otwierana w ukrytym stanie, dlatego wiele interfejsów API, które powodują uciążliwe zachowania (np. prompty), nie jest w tym stanie aktywowanych i jest opóźnione do czasu aktywacji strony. W nielicznych przypadkach, gdy nie jest to jeszcze możliwe, renderowanie wstępne jest anulowane. Zespół Chrome pracuje nad udostępnieniem przyczyn anulowania renderowania wstępnego w postaci interfejsu API, a także nad ulepszeniem funkcji Narzędzi deweloperskich, aby ułatwić identyfikowanie takich przypadków skrajnych.

Wpływ renderowania wstępnego

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

Ta witryna przykładowa jest już szybka, ale nawet przy takiej witrynie możesz sprawdzić, jak renderowanie wstępne zwiększa wygodę użytkowników. Może to też mieć bezpośredni wpływ na podstawowe wskaźniki internetowe witryny – z zerowym LCP, zmniejszoną wartość CLS (ponieważ każdy CLS wczytywania ma miejsce przed widokiem początkowym) i poprawić wartość INP (ponieważ wczytywanie powinno zostać ukończone, zanim użytkownik wejdzie w interakcję).

Nawet wtedy, gdy strona aktywuje się przed jej pełnym wczytaniem, warto zacząć od wczytania strony z wyprzedzeniem, która powinna poprawić ładowanie strony. Gdy w trakcie renderowania wstępnego renderowania jest aktywny link, strona renderowania wstępnego zostanie przeniesiona do ramki głównej i będzie się dalej ładować.

Renderowanie wstępne wymaga jednak dodatkowej pamięci i przepustowości sieci. Uważaj, aby nie renderować z wyprzedzeniem zbyt wiele, może to negatywnie wpłynąć na zasoby użytkownika. Renderowanie wstępne tylko wtedy, gdy istnieje duże prawdopodobieństwo, że użytkownik wejdzie na tę stronę.

Więcej informacji o mierzeniu rzeczywistego wpływu skuteczności w statystykach znajdziesz w sekcji Pomiar skuteczności.

Wyświetlanie podpowiedzi na pasku adresu w Chrome

W pierwszym przypadku użycia możesz sprawdzić podpowiedzi Chrome dotyczące adresów URL na stronie chrome://predictors:

Zielone linie wskazują na wystarczającą pewność, aby aktywować wstępne renderowanie. W tym przykładzie wpisanie „s” daje uzasadnioną pewność (kolor bursztynowy), ale gdy wpiszesz „sh”, Chrome ma taką pewność, że prawie zawsze otwiera się https://sheets.google.com.

Ten zrzut ekranu został wykonany we stosunkowo nowej wersji instalacji Chrome i odfiltrowuje prognozy zerowe, ale jeśli wyświetlisz własne prognozy, prawdopodobnie zobaczysz znacznie więcej wpisów i potencjalnie więcej znaków wymaganych do osiągnięcia wystarczającego poziomu pewności.

Sugerowane opcje na pasku adresu, które być może widzisz, są też podstawą tych prognoz:

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

• Jeśli poziom ufności przekracza 50% (kolor bursztynowy), Chrome aktywnie nawiązuje połączenie z domeną, ale nie renderuje strony z wyprzedzeniem.
• Jeśli poziom ufności większy niż 80% (wyświetlany na zielono) jest równy 80%, Chrome wstępnie wyrenderuje adres URL.

Interfejs API reguł spekulacyjnych

W przypadku trzeciej opcji renderowania wstępnego programiści mogą wstawić na stronach instrukcje JSON, aby poinformować przeglądarkę o tym, które adresy URL mają być wstępnie renderowane:

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

Albo według reguł dokumentów (dostępnych od Chrome 121), które wstępnie renderują linki znalezione w dokumencie na podstawie selektorów href (z 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 dotyczące reguł spekulacyjnych, z którego dowiesz się, jak dodać reguły spekulacyjne do witryny.

Zachęcenie

Ustawienie eagerness służy do wskazywania, kiedy mają być uruchamiane spekulacje, co jest szczególnie przydatne w przypadku reguł dokumentów:

• immediate: umożliwia jak najszybsze spekulowanie, czyli z chwilą zastosowania reguł spekulacyjnych.
• eager: działa to tak samo jak ustawienie immediate, ale w przyszłości chcemy umieścić to ustawienie w przedziale od immediate do moderate.
• moderate: służy do przeprowadzania spekulacji, jeśli przytrzymujesz wskaźnik nad linkiem przez 200 milisekund (lub na zdarzeniu pointerdown, jeśli nastąpi to wcześniej, oraz na urządzeniach mobilnych, gdzie nie ma żadnego zdarzenia hover).
• conservative: spekuluje na podstawie wskaźnika lub przyłożenia.

Domyślna wartość eagerness w przypadku reguł list to immediate. Za pomocą opcji moderate i conservative można ograniczyć reguły list do adresów URL, z którymi użytkownik wchodzi w interakcje, do konkretnej listy. W wielu przypadkach bardziej odpowiednie mogą być reguły document z odpowiednim warunkiem where.

Domyślna wartość eagerness w przypadku reguł document to conservative. Dokument może składać się z wielu adresów URL, dlatego należy zachować ostrożność podczas korzystania z reguły document lub immediate (zapoznaj się też z sekcją Limity Chrome).eager

Wybór ustawienia eagerness zależy od witryny. W przypadku lekkiej, statycznej witryny spekulacja na podstawie dłuższych spekulacji może być niedroga i korzystna dla użytkowników. Witryny o bardziej złożonych architekturach i większych ładunkach stron mogą preferować redukcję ilości odpadów, spekulując rzadziej, dopóki nie uzyskasz bardziej pozytywnego sygnału dotyczącego ograniczenia ilości odpadów.

Opcja moderate to środek pośredni i wiele witryn może skorzystać na tej regule spekulacyjnej, która wstępnie renderuje link po przytrzymaniu wskaźnika nad linkiem przez 200 milisekund lub na zdarzeniu wskazującym jako podstawowe, a jednocześnie skuteczne wdrożenie reguł spekulacyjnych:

<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 jest to dobry pierwszy krok na drodze do wstępnego renderowania:

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

Limity dotyczące Chrome

W Chrome obowiązują pewne ograniczenia, które zapobiegają nadużywaniu interfejsu Speculation Rules API:

gorliwość	Pobieranie z wyprzedzeniem	Wstępne renderowanie
immediate / eager	50	10
moderate / conservative	2 (FIFO)	2 (FIFO)

Ustawienia moderate i conservative, które zależą od interakcji użytkownika, działają w sposób „Pierwsze wejście, pierwsze wyjście”: po osiągnięciu limitu nowa spekulacja spowoduje anulowanie najstarszej spekulacji i zastąpienie jej nowszą, aby oszczędzać pamięć. Anulowana spekulacja może zostać wywołana ponownie, na przykład przez ponowne najechanie kursorem na link. Spowoduje to ponowne zdefiniowanie tego adresu URL, co spowoduje podanie najstarszej spekulacji. W tym przypadku poprzednia spekulacja umieszczała w pamięci podręcznej HTTP wszystkie zasoby dostępne w pamięci podręcznej dla tego adresu URL, więc określenie dłuższego czasu powinno zmniejszyć koszty. Dlatego limit został ustawiony na skromną wartość progową, czyli 2. Reguły statycznej listy nie są wyzwalane przez działanie użytkownika, więc mają wyższy limit, ponieważ przeglądarka nie może stwierdzić, które z nich są potrzebne i kiedy są potrzebne.

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

Chrome uniemożliwi też używanie spekulacji w określonych warunkach, takich jak:

• Zapisz dane.
• Oszczędzanie energii, gdy jest włączone i ma niski poziom baterii.
• Ograniczenia pamięci.
• Gdy ustawienie „Wstępnie wczytuj strony” jest wyłączone (jest ono też jawnie 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 do momentu aktywacji.

Wszystkie te warunki mają na celu zmniejszenie wpływu nadmiernej spekulacji na szkodliwe dla użytkowników.

Jak umieścić na stronie reguły spekulacyjne

Reguły spekulacyjne mogą być umieszczane statycznie w kodzie HTML strony lub dynamicznie wstawiane do strony za pomocą JavaScriptu:

• Statycznie uwzględnione reguły spekulacyjne: na przykład w witrynie z wiadomościami lub na blogu można wstępnie renderować najnowszy artykuł, jeśli często jest to następna nawigacja dla dużej części użytkowników. Do spekulacji na podstawie interakcji użytkowników z linkami można też użyć reguł dokumentu z moderate lub conservative.
• Dynamiczne reguły spekulacyjne: reguły mogą być oparte na logice aplikacji, spersonalizowanej pod kątem użytkownika lub innych danych heurystycznych.

W przypadku osób preferujących dynamiczne wstawianie na podstawie działań takich jak najechanie kursorem na link lub kliknięcie linku – tak jak wiele bibliotek dawniej używało funkcji <link rel=prefetch> – zalecamy zapoznanie się z regułami dokumentów, ponieważ dzięki nim przeglądarka obsługuje wiele zastosowań.

Reguły spekulacyjne można dodawać w ramce głównej (<head> lub <body>). Nie stosuje się reguł spekulacyjnych w ramkach podrzędnych, a reguły spekulacyjne na wstępnie renderowanych stronach są stosowane dopiero po aktywacji strony.

Nagłówek HTTP Speculation-Rules

Reguły spekulacyjne możesz 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 zmieniania 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 i, jeśli jest zasobem z innych domen, musi przejść kontrolę CORS.

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

Jeśli chcesz używać względnych adresów URL, uwzględnij klucz "relative_to": "document" w regułach spekulacyjnych. W przeciwnym razie względne adresy URL będą zależne od adresu URL pliku JSON z regułami spekulacyjnymi. Może to być szczególnie przydatne, gdy musisz wybrać niektóre lub wszystkie linki z tej samej domeny.

Reguły spekulacyjne i SPA

Reguły spekulacyjne są obsługiwane tylko w przypadku nawigacji na całej stronie zarządzanej przez przeglądarkę. Nie są one obsługiwane w przypadku stron aplikacji na jednej stronie (SPA) ani stron powłoki aplikacji. W takiej architekturze nie jest stosowane pobieranie dokumentów, lecz pobieranie danych i stron przez interfejs API lub częściowe pobieranie danych bądź stron, które są następnie przetwarzane i przedstawione na bieżącej stronie. Dane potrzebne do tych tzw. „pozornych nawigacji” mogą być wstępnie pobrane przez aplikację poza regułami spekulacyjnymi, ale nie można ich wstępnie wyrenderować.

Reguły spekulacyjne mogą służyć do wstępnego renderowania aplikacji z poprzedniej strony. Może to pomóc w zrównoważeniu części dodatkowych kosztów początkowego obciążenia ponoszonego przez niektóre aplikacje jednorazowe. Zmiany tras w aplikacji nie mogą jednak być wstępnie renderowane.

Debugowanie reguł spekulacyjnych

W specjalnym poście na temat reguł spekulacyjnych na temat debugowania znajdziesz nowe funkcje Narzędzi deweloperskich w Chrome, które pomogą Ci w wyświetlaniu i debugowaniu nowego interfejsu API.

Wiele reguł spekulacyjnych

Na tej samej stronie można dodać wiele reguł spekulacyjnych. Pojawią się one w istniejących regułach. W związku z tym w przypadku wszystkich z tych powodów renderowanie wstępne odbywa się zarówno w przypadku 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 zbiorze speculationrules

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

No-Vary-Search – pomoc

Podczas pobierania z wyprzedzeniem lub wstępnego renderowania strony niektóre parametry adresu URL (nazywane parametrami wyszukiwania) mogą nie mieć znaczenia dla strony rzeczywiście wyświetlanej przez serwer. Są one używane wyłącznie przez 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 z serwera. Oznacza to, że page1.html?utm_content=123 i page1.html?utm_content=456 będą przesyłać tę samą stronę z serwera, więc tej samej strony będzie można ponownie użyć z pamięci podręcznej.

Podobnie aplikacje mogą używać innych parametrów adresu URL obsługiwanych tylko po stronie klienta.

Pakiet No-Vary-Search umożliwia serwerowi określanie parametrów, które nie powodują różnicy w dostarczanych zasobach. Dzięki temu przeglądarka może ponownie wykorzystać wersje dokumentu przechowywane wcześniej w pamięci podręcznej, 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ących nawigacji z wyprzedzeniem (planujemy tak też w przypadku renderowania wstępnego).

Reguły spekulacyjne obsługują używanie parametru expects_no_vary_search do wskazywania miejsca, w którym ma być zwracany nagłówek HTTP No-Vary-Search. W ten sposób możesz uniknąć niepotrzebnego pobierania.

<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 w przypadku identyfikatorów produktów 123 i 124. Jednak zawartość stron różni się ostatecznie w zależności od renderowania po stronie klienta przy użyciu JavaScriptu do pobierania danych produktów za pomocą parametru wyszukiwania id. Z wyprzedzeniem pobieramy więc ten adres URL z wyprzedzeniem i powinien on zwracać nagłówek HTTP No-Vary-Search pokazujący, że strony można użyć w przypadku dowolnego parametru wyszukiwania id.

Jeśli jednak użytkownik kliknie dowolny z linków przed zakończeniem pobierania z wyprzedzeniem, przeglądarka może nie otrzymać strony /products. W takim przypadku przeglądarka nie wie, czy będzie zawierać nagłówek HTTP No-Vary-Search. Przeglądarka może zdecydować, czy pobrać link ponownie, czy też poczekać na zakończenie pobierania z wyprzedzeniem, aby sprawdzić, czy link zawiera 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 tego pobierania z wyprzedzeniem.

Ograniczenia reguł spekulacyjnych i przyszłe ulepszenia

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

Domyślnie spekulacje są ograniczone do stron tej samej domeny. Spekulowanie stron z innych domen w tej samej witrynie (np. https://a.example.com może wstępnie wyrenderować stronę w witrynie https://b.example.com). Aby użyć tej spekulacji, strona spekulacyjna (w tym przykładzie https://b.example.com) musi wyrazić na to zgodę, dodając nagłówek HTTP Supports-Loading-Mode: credentialed-prerender. W przeciwnym razie Chrome anuluje spekulację.

Przyszłe wersje mogą też zezwolić na renderowanie wstępne w przypadku stron z innych domen i innych, które nie są w tej samej witrynie, o ile w przypadku wstępnie renderowanej strony nie ma plików cookie, a wstępnie renderowana strona jest dopuszczana z podobnym nagłówkiem HTTP Supports-Loading-Mode: uncredentialed-prerender.

Reguły spekulacyjne obsługują już pobieranie z wyprzedzeniem z innych domen, ale ponownie tylko wtedy, gdy nie ma plików cookie dla domen z innych domen. Jeśli istnieją pliki cookie użytkownika, który wcześniej odwiedził tę witrynę, spekulacja nie zostanie wywołana i wyświetli błąd w Narzędziach deweloperskich.

Biorąc pod uwagę te obecne ograniczenia, wzorcem, który może polepszyć wrażenia użytkowników zarówno w przypadku linków wewnętrznych, jak i linków zewnętrznych, jest wstępne renderowanie adresów URL z tej samej domeny i próba pobierania z wyprzedzeniem adresów URL z innych domen:

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

Ze względów bezpieczeństwa domyślne ograniczenie zapobiegające spekulacjom dotyczącym połączeń z innych domen w przypadku połączeń z innych domen. Jest to poprawę w stosunku do <link rel="prefetch"> w przypadku miejsc docelowych z innych domen, które nie wysyłają plików cookie, ale nadal próbują pobierać z wyprzedzeniem. Spowoduje to niepotrzebne pobieranie danych z wyprzedzeniem, które trzeba ponownie wysłać, lub, co gorsza, nieprawidłowe ładowanie stron.

Obsługa interfejsu Detect Speculation Rules API

Obsługę interfejsu Speculation Rules API możesz wykryć za pomocą standardowych mechanizmów sprawdzania kodu 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 spekulacyjnej 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);
}

Na tej stronie demonstracyjnej renderowania z wyprzedzeniem możesz zobaczyć wersję demonstracyjną wstępnego renderowania interfejsu Speculation Rules API z wykorzystaniem wstawiania JavaScriptu.

Wstawienie elementu <script type = "speculationrules"> bezpośrednio do DOM nie spowoduje zarejestrowania reguł spekulacyjnych, ponieważ należy je dodać w sposób pokazany wcześniej. Na przykład bezpośrednia edycja panelu Elementy w Narzędziach deweloperskich w Chrome w celu dodania elementu <script type = "speculationrules"> nie powoduje zarejestrowania reguł spekulacyjnych. Zamiast tego skrypt, który dynamicznie dodaje ten element do modelu DOM, musi być uruchamiany z poziomu konsoli, aby wstawić reguły.

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

Dodawanie reguł spekulacyjnych za pomocą menedżera tagów, takiego jak Menedżer tagów Google, wymaga wstawiania ich za pomocą JavaScriptu, a nie bezpośredniego dodawania elementu <script type = "speculationrules"> przez Menedżera tagów Google z tych samych powodów, co wcześniej:

W tym przykładzie użyto parametru var, ponieważ Menedżer tagów Google nie obsługuje tagu const.

Anuluj reguły spekulacyjne

Usunięcie reguł spekulacyjnych spowoduje anulowanie renderowania wstępnego, ale zanim to nastąpi, zasoby prawdopodobnie zostały już wykorzystane na zainicjowanie renderowania wstępnego. Zalecamy więc, aby tego nie robić, jeśli istnieje prawdopodobieństwo, że będzie trzeba je anulować.

Reguły spekulacyjne i Content Security Policy

Reguły spekulacyjne używają elementu <script>, chociaż zawierają tylko plik JSON, więc muszą być uwzględnione w Content-Security-Policy script-src, jeśli witryna go używa – za pomocą skrótu lub liczby jednorazowej.

Do script-src można dodać nowy element inline-speculation-rules, który umożliwia obsługę elementów <script type="speculationrules"> wstrzykiwanych z krzyżyków i skryptów jednorazowych. Nie obsługuje to reguł zawartych w początkowym kodzie HTML, dlatego w przypadku witryn, które używają rygorystycznego CSP, reguły muszą być wstrzykiwane przez JavaScript.

Wykrywanie i wyłączanie renderowania wstępnego

Wstępne renderowanie jest zwykle bardzo przydatne dla użytkowników, ponieważ umożliwia szybkie renderowanie stron – często natychmiast. Jest to korzystne zarówno dla użytkownika, jak i właściciela witryny, ponieważ wstępnie renderowane strony zapewniają użytkownikom lepsze wrażenia, co w innym wypadku mogłoby być trudne.

W pewnych sytuacjach nie chcesz, aby strony były renderowane wstępnie, np. po zmianie stanu strony – na skutek pierwotnego żądania lub po wykonaniu na stronie kodu JavaScriptu.

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

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

Wykrywanie i wyłączanie wstępnego renderowania 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 widoczny będzie tylko ten nagłówek: 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 o niepowodzeniu (czyli nie jest to 200 ani 304), strona nie zostanie wstępnie wyrenderowana, a wszystkie strony pobierania z wyprzedzeniem zostaną odrzucone.

Jeśli nie chcesz, by konkretna strona była wstępnie renderowana, to najlepszy sposób, by temu zapobiec. Aby jednak uzyskać najlepsze rezultaty, zalecamy, aby zezwolić na renderowanie wstępne, ale opóźnić wszelkie działania, które powinny wystąpić tylko wtedy, gdy strona zostanie rzeczywiście wyświetlona, za pomocą JavaScriptu.

Wykrywanie wstępnego renderowania w kodzie JavaScript

Podczas wstępnego renderowania strony interfejs API document.prerendering zwróci kod true. Mogą one służyć do zapobiegania określonym działaniom w trakcie renderowania wstępnego (lub opóźniania ich), aż strona zostanie faktycznie aktywowana.

Po aktywowaniu wstępnie renderowanego dokumentu activationStart w PerformanceNavigationTiming także zostanie ustawiony czas inny niż zero, który odpowiada czasowi między rozpoczęciem renderowania wstępnego a rzeczywistą aktywacją dokumentu.

Możesz mieć funkcję sprawdzającą wstępne renderowanie i wyrenderowane strony, na przykład:

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

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

Gdy użytkownik ją aktywuje, zdarzenie prerenderingchange będzie wysyłane w narzędziu document. Można je następnie wykorzystać do włączenia działań, które wcześniej były domyślnie uruchamiane po wczytaniu strony, ale chcesz opóźnić je do momentu, gdy użytkownik rzeczywiście wyświetli stronę.

Korzystając z tych interfejsów API, JavaScript frontendu może wykrywać wstępnie renderowane strony i podejmować dotyczące ich odpowiednie działania.

Wpływ na statystyki

Analytics służy do pomiaru wykorzystania witryny, np. Google Analytics do pomiaru wyświetleń stron i zdarzeń. Możesz też mierzyć dane o wydajności stron za pomocą narzędzia Real User Monitoring (RUM).

Strony powinny być wstępnie renderowane tylko wtedy, gdy istnieje duże prawdopodobieństwo, że zostaną one wczytane przez użytkownika. Dlatego opcje renderowania wstępnego na pasku adresu Chrome są stosowane tylko wtedy, gdy istnieje duże prawdopodobieństwo (ponad 80% przypadków).

Jednak zwłaszcza w przypadku korzystania z interfejsu Speculation Rules API – wstępnie renderowane strony mogą mieć wpływ na analitykę, a właściciele witryn mogą być zmuszeni do dodania dodatkowego kodu, aby w momencie aktywacji włączyć analitykę tylko dla wstępnie wyrenderowanych stron, ponieważ nie wszyscy dostawcy rozwiązań analitycznych mogą to robić 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 znika 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();

Możesz też opóźnić działania do momentu, gdy strona po raz pierwszy stanie się widoczna, co obejmuje zarówno przypadek renderowania wstępnego, jak i otwarcie kart w tle (np. po kliknięciu prawym przyciskiem myszy i otwarciu nowej karty):

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

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

initAnalytics();

Może to mieć sens w przypadku analityki i podobnego przypadku użycia, ale w innych przypadkach możesz potrzebować większej ilości treści w takich przypadkach – dlatego lepiej użyć elementów document.prerendering i prerenderingchange do kierowania na strony z wstępnym renderowaniem.

Mierz wyniki

Aby mierzyć dane o wydajności, analityka powinna zastanowić się, czy lepiej jest je mierzyć na podstawie czasu aktywacji, a nie czasu wczytywania strony podawanego przez interfejsy API przeglądarek.

Podstawowe wskaźniki internetowe, które mierzymy w Chrome w Raporcie na temat użytkowania Chrome, służą do pomiaru wrażeń użytkowników. Są one więc mierzone na podstawie czasu aktywacji. Często prowadzi to np. do wartości LCP trwającej 0 sekund, co pokazuje, że to świetny sposób na poprawę podstawowych wskaźników internetowych.

Od wersji 3.1.0 biblioteka web-vitals została zaktualizowana, aby obsługiwać wstępnie renderowane nawigację w taki sam sposób, w jaki Chrome mierzy podstawowe wskaźniki internetowe. Jeśli strona została wyrenderowana w całości lub częściowo, w atrybucie Metric.navigationType są również oznaczone wstępnie wyrenderowane elementy nawigacyjne na potrzeby tych danych.

Pomiar wstępnego renderowania

To, czy strona jest wstępnie renderowana, można sprawdzić z wpisem activationStart o wartości PerformanceNavigationTiming innej niż 0. Można to zarejestrować za pomocą wymiaru niestandardowego lub podobnego wymiaru podczas rejestrowania wyświetleń strony, np. 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 statystyki będą mogły sprawdzić, ile nawigacji jest wstępnie renderowanych w porównaniu z innymi rodzajami nawigacji, a także powiązać wszelkie dane o skuteczności lub dane biznesowe z tymi różnymi typami nawigacji. Szybsze wczytywanie stron oznacza szczęśliwszych użytkowników, co często może mieć realny wpływ na wyniki biznesowe, co pokazuje nasze studia przypadków.

Dokonując pomiaru wpływu wstępnego renderowania stron na potrzeby nawigacji błyskawicznej, możesz zdecydować, czy warto inwestować więcej w wykorzystanie tej technologii, aby umożliwić wstępne renderowanie większej liczby elementów nawigacyjnych, czy też sprawdzić, dlaczego strony nie są wstępnie renderowane.

Pomiar współczynników trafień

Oprócz pomiaru wpływu stron odwiedzanych po wstępnym wyrenderowaniu ważne jest też, aby mierzyć strony, które są wstępnie renderowane, a nie otwierane później. Może to oznaczać, że wstępnie renderujesz za dużo i wykorzystujesz cenne zasoby użytkownika bez żadnych korzyści.

Można to zmierzyć, uruchamiając zdarzenie Analytics po wstawieniu reguł spekulacyjnych – po sprawdzeniu, że przeglądarka obsługuje renderowanie wstępne za pomocą HTMLScriptElement.supports('speculationrules') – w celu wskazania, że zażądano renderowania wstępnego. Pamiętaj, że samo żądanie renderowania wstępnego nie oznacza, że renderowanie wstępne zostało rozpoczęte lub zakończone, ponieważ, jak już wspomniano, renderowanie wstępne jest wskazówką dla przeglądarki i może zrezygnować z renderowania stron na podstawie ustawień użytkownika, bieżącego wykorzystania pamięci lub innych danych heurystycznych.

Liczbę tych zdarzeń możesz potem porównać z rzeczywistą liczbą wyświetleń stron z renderowaniem wstępnym. Możesz też uruchamiać inne zdarzenie przy aktywacji, jeśli ułatwia to porównanie.

„Współczynnik skutecznych trafień” można oszacować, przeglądając różnicę między tymi dwoma liczbami. W przypadku stron, na których do wstępnego renderowania stron używasz interfejsu Speculation Rules API, możesz odpowiednio dostosować reguły, aby utrzymać wysoki współczynnik trafień, aby zachować równowagę między wykorzystaniem zasobów użytkowników, aby im pomagać, a niepotrzebnym używaniem ich.

Pamiętaj, że renderowanie wstępne może odbywać się ze względu na wstępne renderowanie na pasku adresu, a nie tylko na reguły spekulacyjne. Jeśli chcesz je rozróżnić, możesz zaznaczyć pole document.referrer (jest puste w przypadku nawigacji na pasku adresu oraz wstępnie renderowanych na pasku adresu).

Pamiętaj, aby przyjrzeć się też stronom, które nie korzystają z renderowania wstępnego, ponieważ może to oznaczać, że nie kwalifikują się do renderowania wstępnego, nawet z poziomu paska adresu. Może to oznaczać, że nie korzystasz z tego zwiększenia skuteczności. Zespół Chrome chce dodać dodatkowe narzędzia do testowania pod kątem możliwości renderowania wstępnego (być może podobne do narzędzia do testowania BFcache) oraz dodać interfejs API, który pokaże, dlaczego renderowanie wstępne się nie udało.

Wpływ na rozszerzenia

Przeczytaj specjalny post na temat Chrome Extensions: Extending API to obsługa błyskawicznej nawigacji. Zawiera on więcej informacji na temat dodatkowych kwestii, które autorzy rozszerzeń powinni wziąć pod uwagę w przypadku wstępnie renderowanych stron.

Prześlij opinię

Zespół Chrome aktywnie pracuje nad renderowaniem wstępnym i planuje też wiele sposobów na rozszerzenie zakresu funkcji dostępnych w wersji Chrome 108. Chętnie poznamy Twoją opinię na temat repozytorium GitHub lub naszego narzędzia do śledzenia problemów. Chętnie poznamy też przykłady tego nowego interfejsu API i pomożemy Ci je udostępnić.

Powiązane artykuły

• Ćwiczenie z programowania dotyczące reguł spekulacyjnych
• Debugowanie reguł spekulacyjnych
• Przedstawiamy NoState Prefetch
• Specyfikacja interfejsu API reguł spekulacyjnych
• Repozytorium GitHub dotyczące spekulacji nawigacyjnej
• Rozszerzenia do Chrome: rozszerzanie interfejsu API o obsługę natychmiastowej nawigacji

Podziękowania

Miniatura, której autorem jest Marc-Olivier Jodoin, Unsplash