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

Barry Pollard

Browser Support

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

Source

Zespół Chrome przywrócił pełne wyrenderowanie 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 szeroko 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 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 funkcji w przyszłości.

Jak strona jest wstępnie renderowana?

Stronę można wyrenderować wstępnie na 4 sposoby, z których każdy ma 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 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 wstępne renderowanie strony na podstawie reguł spekulacyjnych. Mogą one być umieszczone na stronach w postaci statycznych elementów lub dynamicznie wstrzykiwane przez kod 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, co widać w tym filmie:

Przykład wpływu 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 rozpoczęcie wczytywania strony powinno poprawić komfort korzystania. Jeśli 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 (szare), średnim (pomarańczowe) i wysokim (zielone) 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% (wskazany na pomarańczowo), 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 prerenderują linki znalezione w dokumencie na podstawie selektorów href (na podstawie interfejsu URL Pattern API) lub selektorów arkusza 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ł

Browser Support

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

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 planujemy umieścić je gdzieś pomiędzy immediate a moderate.
  • moderate: ta opcja wykonuje spekulacje, jeśli 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 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 następna sekcja Limity 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 bardziej pozytywnego sygnału o zamierzeniu, który pozwoli 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 kursor znajduje się nad nim przez 200 ms, lub w przypadku zdarzenia „wskaźnik wciśnięty”. Jest to proste, ale skuteczne wdrożenie 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 wstępnego renderowania. 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 pierwszy na wejściu, pierwszy na wyjściu: po osiągnięciu limitu nowa spekulacja spowoduje anulowanie najstarszej spekulacji i jej zastąpienie nowszą, aby oszczędzać pamięć. Anulowane spekulacje można ponownie wywołać, np. przez najechanie kursorem na link. Spowoduje to ponowne spekulowanie nad tym adresem URL, co spowoduje usunięcie najstarszej spekulacji. W tym przypadku poprzednie spekulacje będą miały w buforze HTTP wszystkie zasoby, które można buforować, w przypadku tego adresu URL, więc kolejne spekulacje powinny być tańsze. Dlatego limit został ustawiony na niski 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 reguły 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 ustawienie „Wstępnie wczytaj strony” jest wyłączone (co jest również 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.
  • Reguły spekulacji dynamicznie wstawiane w ramach: mogą one być oparte na logice aplikacji, spersonalizowane pod kątem 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 w przeszłości korzystało z <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

Browser Support

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

Source

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 za pomocą 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ć w regułach spekulacji klucz "relative_to": "document". 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 aplikacji typu szkielet. Architektura ta nie korzysta z pobierania dokumentów, ale z interfejsów API lub częściowego pobierania danych bądź stron, które są następnie przetwarzane i prezentowane na bieżącej stronie. Dane potrzebne do tak zwanej „miękkiej nawigacji” mogą być pobierane w aplikacji poza regułami spekulacji, ale nie można ich renderować z wyprzedzeniem.

Reguły spekulacyjne można stosować do wstępnego renderowania 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 przypadku 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 zbioru speculationrules

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

Browser Support

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

Source

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óżnicy w dostarczanych zasobach, dzięki czemu przeglądarka może ponownie używać wcześniej zapisanych w pamięci podręcznej wersji dokumentu, które różnią się tylko tymi parametrami. Jest to obsługiwane w Chrome (i przeglądarkach opartych na Chromium) w przypadku spekulacji nawigacyjnych zarówno w przypadku wstępnego pobierania, jak i 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 treść 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 tle, 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 na 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ą będzie zawierać podobny nagłówek 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ę wstępnego renderowania interfejsu Speculation Rules API za pomocą wstawiania kodu 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ś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 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>, więc nawet jeśli zawierają tylko kod 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 wykorzystaniem skryptów z haszowanymi lub niepowtarzalnymi wartościami. Ta metoda nie obsługuje 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 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 stosować prerenderowania stron, np. gdy strony zmieniają stan na podstawie początkowego żądania lub kodu JavaScriptu 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

Wstępnie pobrane strony korzystające 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 dana strona była renderowana wstępnie, możesz to osiągnąć, zwracając kod odpowiedzi inny niż 2XX (np. 503). 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 funkcji, 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

Możesz utworzyć funkcję, która będzie sprawdzać przedwstępny renderowanie i strony z wstępnym renderowaniem, na przykład:

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ść niezerowa, oznacza to, że strona została wstępnie wyrenderowana:

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 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 powinny być renderowane 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 przypadku korzystania z interfejsu Speculation Rules API strony z renderowaniem wstępnym mogą mieć wpływ na dane analityczne, a właściciele witryn mogą potrzebować dodatkowego kodu, aby włączyć dane analityczne tylko na stronach z renderowaniem wstępnym po aktywacji, 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 statystyk i podobnych zastosowań, ale w innych przypadkach możesz chcieć wczytać więcej treści, aby docelowo kierować na strony z przedwstępnym renderowaniem. 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 (co oznacza, że zamiast funkcji whenActivated można użyć funkcji whenFirstVisible).

W wielu przypadkach stan powinien być sprawdzany w przypadku ogólnych zmian visibilitychange – np. po powrocie na stronę, która była w tle, wszystkie liczniki koszyka powinny być aktualizowane zgodnie z 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 konieczność 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 zawartość na wierzchu wymaga ręcznego opóźnienia.

Pomiar wyników

W przypadku pomiarów wydajności usługa analityczna powinna rozważyć, czy lepiej jest je mierzyć 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 poziomu serwera, można odczytać z wartości activationStart większej od 0 w PerformanceNavigationTiming. Możesz to rejestrować za pomocą wymiaru niestandardowego lub podobnego 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 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 oznacza zadowolonych użytkowników, 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 korzystanie z tej technologii, aby umożliwić wstępne renderowanie większej liczby nawigacji, lub sprawdzić, dlaczego strony nie są wstępnie 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 powoduje marnotrawienie cennych zasobów 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 z wstępnym renderowaniem. 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 2 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 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, które nie mają prerenderowania, ponieważ może to oznaczać, że nie można ich prerenderować 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. Zachęcamy do dzielenia się opiniami na temat repozytorium GitHub lub za pomocą naszego narzędzia do śledzenia problemów. Z niecierpliwością czekamy na przypadki użycia tego nowego interfejsu API.

Podziękowania

Miniatura autorstwa Marc-Olivier Jodoin na Unsplash