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

Barry Pollard

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ło to zbyt rozbudowane 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 z dotychczasowym zastosowaniem i umożliwić rozszerzanie możliwości renderowania wstępnego w przyszłości, nowy mechanizm renderowania wstępnego nie będzie korzystać ze składni <link rel="prerender"...>, która pozostaje w przypadku funkcji pobierania z wyprzedzeniem NoState, co pozwoli na wycofanie tej funkcji w przyszłości.

Jak strona jest renderowana wstępnie?

Stronę można wyrenderować w ramach prerenderowania w jeden 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 bardzo prawdopodobne, że ją otworzysz.
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 automatycznie informować Chrome, które strony mają być wstępnie renderowane. Zastępuje to, co robiła funkcja <link rel="prerender"...>, i pozwala witrynom na proaktywne prerenderowanie strony na podstawie reguł spekulacji. Mogą one znajdować się statycznie na stronach lub być dynamicznie wstrzykiwane przez JavaScript według uznania 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 wstępnie wyrenderowana, jej obecny stan to „na pierwszym planie” i wciąż będzie się wczytywać, co oznacza, że możesz zacząć z niego korzystać.

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 renderowania wstępnego

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

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 wtedy, gdy strona aktywuje się przed pełnym wczytaniem, proces wczytywania powinien nastąpić wcześniej. Gdy link zostanie aktywowany w trakcie renderowania wstępnego, strona renderowania zostanie przeniesiona do ramki głównej i będzie kontynuować wczytywanie.

Wstępna renderyzacja wykorzystuje jednak dodatkową pamięć i przepustowość sieci. Pamiętaj, aby nie stosować nadmiernego wstępnego renderowania, co skutkuje kosztem zasobów użytkowników. 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:

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ć:

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ępne 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 Reguły spekulacji programiści 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.

Chęć

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: służy do spekulacji najszybciej, jak to możliwe, czyli gdy tylko zostaną zastosowane reguły spekulacyjne.
• 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: wskazuje na to, że kursor lub palce dotykają ekranu.

Wartość domyślna eagerness w przypadku list reguł to immediate. Opcji moderate i conservative można używać do ograniczania 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 przypadku witryn o bardziej złożonej architekturze i większym ładunku strony warto ograniczyć generowanie reklam bez dopasowania, dopóki nie otrzymasz od użytkowników bardziej pozytywnego sygnału o ich zamiarach, który pozwoli ograniczyć marnotrawstwo.

Opcja moderate stanowi punkt pośredni, a w przypadku wielu witryn ta reguła spekulacyjna, która spowodowałaby wstępne renderowanie linku, gdy przytrzymano na nim wskaźnik przez 200 milisekund lub gdy byłby on kierowany na zdarzenie wskaźnika, była podstawowa, a zarazem skuteczna, implementacja reguł spekulacyjnych:

<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:

Ustawienia moderate i conservative, które zależą od interakcji użytkownika, działają w trybie 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 będą miały w pamięci podręcznej pamięci podręcznej HTTP wszystkie zasoby, które można przechowywać w pamięci podręcznej, dla tego adresu URL, więc kolejne spekulacje powinny być tańsze. Dlatego limit został ustawiony na umiarkowany próg 2. Statyczne reguły listy nie są wywoływane przez działanie użytkownika, więc mają wyższy limit, ponieważ przeglądarka nie jest w stanie określić, które z nich są potrzebne, a 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 zapobiega też używaniu spekulacji w określonych warunkach, takich jak:

• Oszczędzanie danych.
• Oszczędzanie energii, gdy jest włączone i bateria jest rozładowana.
• Ograniczenia dotyczące pamięci.
• Gdy ustawienie „Wstępnie wczytuj strony” jest wyłączone (jest wyłączone również 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 wolą 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

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.

Wraz z dokumentem zwracany jest nagłówek HTTP Speculation-Rules, który 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 z innego źródła, 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. Ta architektura nie korzysta z pobierania dokumentów, lecz za pomocą interfejsu API lub częściowego pobierania danych bądź stron, które są następnie przetwarzane i prezentowane na bieżącej stronie. Aplikacja może wstępnie pobierać dane potrzebne do tzw. „miękkiej nawigacji”, poza regułami spekulacyjnymi, ale nie można ich wstępnie renderować.

Reguły spekulacji można wykorzystać do wstępnego wyrenderowania samej 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 Chrome ułatwiających wyświetlanie i debugowanie tego nowego interfejsu API, przeczytaj ten artykuł na temat debugowania reguł spekulacji.

Wiele reguł spekulacyjnych

Do tej samej strony można dodać wiele reguł spekulacyjnych i dołączyć je do istniejących reguł. W związku z tym oba te różne sposoby skutkują renderowaniem wstępnego 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 zbiorze speculationrules

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

No-Vary-Search – pomoc

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 na temat wstępnego pobierania nawigacji (chociaż rozważamy obsługę 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. Zawartość strony może się jednak różnić w zależności od renderowania po stronie klienta za pomocą JavaScriptu do pobierania danych produktów 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 albo pobrać link ponownie, albo poczekać na zakończenie pobierania w ramach przewidywania zapotrzebowania, aby sprawdzić, czy zawiera on nagłówek HTTP No-Vary-Search. Dzięki ustawieniu expects_no_vary_search przeglądarka może wiedzieć, że odpowiedź na stronę 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 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 witrynie w innych domenach (na przykład https://a.example.com może wstępnie wyrenderować stronę w witrynie https://b.example.com). Aby skorzystać 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 spekulacje.

Przyszłe wersje mogą też zezwolić na renderowanie wstępne w przypadku stron z innych witryn, które nie są w tej samej witrynie i z innych domen, pod warunkiem że w przypadku wstępnie renderowanej strony nie będą dostępne pliki cookie, a wstępnie renderowana strona wyrazi zgodę z podobnym nagłówkiem HTTP Supports-Loading-Mode: uncredentialed-prerender.

Reguły spekulacyjne obsługują już pobieranie z wyprzedzeniem z innych domen, ale także wtedy, gdy nie istnieją pliki cookie z danej domeny. 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ć dane w poprzednim wczytaniu. Może to spowodować zmarnowanie wczytywania w poprzednim wczytaniu, które trzeba będzie ponownie wysłać, lub – co gorsza – nieprawidłowe wczytanie strony.

Reguły spekulacji nie są obsługiwane w przypadku wstępnego pobierania stron kontrolowanych przez usługowe workery. Pracujemy nad dodaniem tej funkcji. Aby otrzymywać informacje o tym problemie, śledź ten problem z usługą wątek pracy. Wstępna renderyzacja jest obsługiwana 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 wstawione dynamicznie za pomocą atrybutu innerHTML, który zawiera nowe linki, zostaną odczytane przez istniejące reguły na stronie.

Podobnie bezpośrednie edytowanie 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 dodaje element do DOM.

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

Aby dodać reguły spekulacyjne za pomocą Menedżera tagów, takiego jak Menedżer tagów Google, trzeba je wstawiać za pomocą JavaScriptu, a nie dodawać element <script type = "speculationrules"> bezpośrednio przez Menedżera tagów Google z tych samych powodów co poprzednio:

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>, więc nawet jeśli zawierają tylko JSON, muszą być uwzględnione w elementach script-src Content-Security-Policy, jeśli witryna ich używa – za pomocą hasha lub losowego ciągu znaków.

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. Nie obsługuje ona reguł zawartych w pierwotnym 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ż pozwala na szybkie renderowanie strony, często natychmiastowe. Jest to korzystne zarówno dla użytkownika, jak i dla właściciela witryny, ponieważ wstępnie renderowane strony zapewniają większą wygodę użytkowników, co może być trudne do osiągnięcia.

Może się jednak zdarzyć, że nie chcesz, aby wstępne renderowanie stron miało miejsce – na przykład gdy strona zmieni stan – w odpowiedzi na wstępne żądanie lub na podstawie wykonania kodu JavaScriptu na stronie.

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

Renderowanie wstępne jest włączone tylko dla tych użytkowników Chrome, którzy mają w usłudze chrome://settings/performance/ ustawienie „Wstępnie wczytuj strony”. 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

Wstępnie renderowane strony 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ą dodatkowo prawidłowe w przypadku prerenderowania, ale są prawidłowe w przypadku wstępnego pobierania.

Jeśli nie chcesz, aby konkretna strona była wstępnie renderowana, najlepszym sposobem, by tak się nie stało, jest zwrócenie kodu odpowiedzi innego niż 2XX (np. 503). Jednak ze względu na wygodę użytkowników zalecamy używanie JavaScriptu zamiast zezwalania na renderowanie wstępne z opóźnieniem w przypadku działań, które powinny zostać wykonane dopiero wtedy, gdy strona zostanie rzeczywiście wyświetlona.

Wykrywanie wstępnego renderowania w JavaScript

Podczas wstępnego renderowania strony interfejs API document.prerendering zwróci wartość true. Strony mogą go używać, aby zapobiegać niektórym czynnościom podczas wstępnego renderowania (lub opóźniać je) do momentu, aż strona faktycznie zostanie aktywowana.

Po aktywowaniu wstępnie renderowanego dokumentu wartość atrybutu PerformanceNavigationTiming zostanie ustawiona na wartość niezerową, która będzie reprezentować czas między rozpoczęciem wstępnego renderowania a faktycznym aktywowaniem dokumentu.

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 zwrócona wartość jest różna od 0, oznacza to, że strona została wyrenderowana z wyprzedzeniem:

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 (powyżej 80% czasu).

Jednak w szczególności w przypadku korzystania z interfejsu Speculation Rules API wstępnie renderowane strony mogą mieć wpływ na analitykę, a właściciele witryn mogą wymagać dodania dodatkowego kodu, aby umożliwić analizę wstępnie renderowanych stron przy aktywacji, ponieważ nie wszyscy dostawcy usług analitycznych robią to 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ępną prerenderyzację, 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

Interfejsy API omówione wcześniej mogą być używane do blokowania 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 to zmienić 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ż może tak być częściej w przypadku korzystania z renderowania wstępnego, te warunki obowiązują również w przypadku stron wczytywanych na kartach w tle, o których wspomniano wcześniej (dlatego 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 eliminuje część konieczności ręcznego pakowania skryptów lub funkcji, jest wstrzymanie niektórych interfejsów API w sposób opisany powyżej, a także nierenderowanie elementów iframe innych firm, dlatego do ich wyświetlania należy ręcznie blokować ich zawartość.

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.

W przypadku podstawowych wskaźników internetowych mierzonych przez Chrome w Raporcie na temat użytkowania Chrome mają one 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 wartość parametru activationStart jest różna od zera (PerformanceNavigationTiming). 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 case study.

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 sugerować, że renderowanie wstępne jest za duże i że zużywasz cenne zasoby użytkownika z niewielką 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 nawet gdy zażądano renderowania wstępnego, nie oznacza to, że renderowanie wstępne zostało rozpoczęte lub zakończone zgodnie z wcześniejszymi wskazówkami, że jest ono wskazówką dla przeglądarki i może nie zdecydować się na wstępne renderowanie stron na podstawie ustawień użytkownika, bieżącego wykorzystania pamięci lub innych metod heurystycznych.

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, na których używasz interfejsu Speculation Rules API do wstępnego renderowania stron, możesz odpowiednio dostosować reguły, aby utrzymać wysoki współczynnik trafień i zachować równowagę między wykorzystaniem zasobów użytkowników, którzy mogą im pomagać, a niepotrzebnym korzystaniem z nich.

Pamiętaj, że niektóre procesy renderowania wstępnego mogą mieć miejsce ze względu na wstępne renderowanie na pasku adresu, a nie tylko z powodu reguł spekulacyjnych. Jeśli chcesz je odróż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 bez wstępnego renderowania, 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 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 specjalny post na temat rozszerzeń do Chrome: Extending API w celu obsługi błyskawicznej nawigacji, w którym omawiamy dodatkowe kwestie, które autorzy rozszerzeń powinni wziąć pod uwagę w przypadku wstępnie renderowanych stron.

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.

Powiązane artykuły

• Ćwiczenie z programowania dotyczące reguł spekulacyjnych
• Debugowanie reguł spekulacyjnych
• Przedstawiamy wstępne pobieranie NoState
• Specyfikacja interfejsu API reguł spekulacji
• Repozytorium GitHub spekulacji na temat nawigacji
• Rozszerzenia do Chrome: rozszerzenie interfejsu API w celu obsługi błyskawicznej nawigacji

Podziękowania

Miniatura autorstwa Marc-Olivier Jodoin na Unsplash