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

Obsługa przeglądarek

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

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

Krótka historia prerenderowania

W przeszłości Chrome obsługiwał wskazówkę na temat zasobu <link rel="prerender" href="/next-page">, jednak nie był on powszechnie obsługiwany poza Chrome i interfejs API nie był zbyt ekspresyjny.

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 wstępne renderowanie z powrotem w tej przeglądarce. Aby uniknąć komplikacji związanych z obecnym użyciem i umożliwić przyszłe rozszerzenie prerenderowania, nowy mechanizm nie będzie używać składni <link rel="prerender"...>, która pozostaje w użyciu w przypadku pobierania z wyprzedzeniem bez stanu, z zamysłem wycofania tej opcji w przyszłości.

Jak strona jest renderowana wstępnie?

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

  1. Gdy wpiszesz URL na pasku adresu Chrome (nazywanym też „omniboksem”), Chrome może automatycznie wstępnie wyrenderować stronę, jeśli na podstawie Twojej historii przeglądania z dużym prawdopodobieństwem ją odwiedzisz.
  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 działanie usługi <link rel="prerender"...> i umożliwia witrynom proaktywne wstępne renderowanie strony na podstawie zawartych na niej 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ę.

Gdy wstępnie renderowana strona jest otwierana jako ukryta, kilka interfejsów API, które powodują uciążliwe zachowania (na przykład prompty), nie aktywuje się w tym stanie i są one opóźnione do momentu aktywacji. W niewielkiej liczbie przypadków, gdy nie jest to jeszcze możliwe, renderowanie wstępne 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

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

Przykładowy wpływ renderowania wstępnego.

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

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

Renderowanie wstępne wymaga jednak dodatkowej pamięci i przepustowości sieci. Pamiętaj, aby nie stosować nadmiernego wstępnego renderowania, co skutkuje kosztem zasobów użytkowników. Renderowanie wstępne tylko wtedy, gdy istnieje duże prawdopodobieństwo przejścia na stronę.

W sekcji Pomiar skuteczności znajdziesz więcej informacji o sposobach pomiaru rzeczywistego wpływu za pomocą statystyk.

Wyświetlanie sugestii na pasku adresu w Chrome

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

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

Zielone linie wskazują na wystarczający poziom ufności, aby aktywować renderowanie wstępne. 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 „Przewidywanie” na pasku adresu.

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

  • W przypadku poziomu ufności powyżej 50% (wskazanego na bursztynowo) Chrome aktywnie łączy się z domeną, ale nie renderuje strony wstępnie.
  • W przypadku poziomu ufności większego niż 80% (oznaczonego na zielono) Chrome wstępnie wyrenderuje adres URL.

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.

Zapał

Obsługa przeglądarek

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

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

  • immediate: ta opcja służy do spekulowania tak szybko, jak to możliwe, czyli tak szybko, jak przestrzegane są reguły spekulacji.
  • eager: działa identycznie jak ustawienie immediate, ale w przyszłości chcemy umieścić je gdzieś pomiędzy immediatemoderate.
  • 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. Za pomocą opcji moderate i conservative można ograniczyć reguły list do adresów URL, z którymi użytkownik wchodzi w interakcję, i dokonywać działań z określonej listy. W wielu przypadkach bardziej odpowiednie mogą być jednak reguły document z odpowiednim warunkiem where.

Domyślna wartość eagerness dla reguł document to conservative. 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).

To, które ustawienie eagerness należy zastosować, zależy od 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 to złoty środek. Wiele witryn może skorzystać z następującej reguły spekulacji, która wstępnie renderuje link, gdy wskaźnik znajduje się nad nim przez 200 ms, lub w zdarzeniu wskaznik wciśnięty, jako podstawowe, ale potężne rozwiązanie:

<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 w Chrome

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

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

Ustawienia moderate i conservative, które zależą od interakcji użytkownika, działają w sposób „pierwsze, pierwsze wyjście (FIFO): po osiągnięciu limitu nowa spekulacja spowoduje anulowanie najstarszej spekulacji i zastąpienie jej tą nową, 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 poprzednia spekulacja spowoduje zapisanie w pamięci podręcznej HTTP wszystkich zasobów, które można zapisać w pamięci podręcznej dla danego adresu URL, więc spekulacja przy dłuższym czasie powinna obniżyć koszty. Dlatego limit ten jest ustawiony na skromny próg wynoszący 2. Reguły list statycznych nie są wywoływane przez działanie użytkownika, dlatego mają wyższy limit, ponieważ przeglądarka nie może wiedzieć, które z nich są potrzebne i kiedy.

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

  • Zapisz dane.
  • 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 Chrome, takie jak uBlock Origin).
  • strony otwierane w kartach w tle.

Do czasu aktywacji Chrome nie renderuje też elementów iframe z innych domen na wstępnie renderowanych stronach.

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 spekulacyjne można statycznie umieszczać w kodzie HTML strony lub dynamicznie wstawiane do strony 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 spekulacyjne: mogą być oparte na logice aplikacji, personalizowane pod kątem użytkownika lub na podstawie innych danych heurystycznych.

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

Obsługa przeglądarek

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

Źródło

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

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 spekulacyjne są obsługiwane tylko w przypadku nawigacji na całej stronie zarządzanej przez przeglądarkę, a nie w przypadku stron aplikacji na jednej stronie (SPA) ani powłoki aplikacji. Architektura ta nie korzysta z pobierania dokumentów, ale z interfejsów API lub częściowego pobierania danych lub stron, które są następnie przetwarzane i prezentowane na bieżącej stronie. Dane potrzebne do tych tak zwanych „miękkich nawigacji” mogą być pobierane w aplikacji poza regułami spekulacji, ale nie można ich renderować z wyprzedzeniem.

Reguł spekulacyjnych można użyć 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 niektórych SPA. Nie można jednak prerenderować zmian trasy w aplikacji.

Debugowanie reguł spekulacyjnych

Przeczytaj specjalny post na temat debugowania reguł spekulacyjnych, aby poznać nowe funkcje Narzędzi deweloperskich w Chrome, które ułatwiają wyświetlanie i debugowanie tego nowego interfejsu API.

Wiele reguł spekulacyjnych

Na tej samej stronie możesz też dodać wiele reguł spekulacji, które zostaną dołączone do istniejących reguł. Dlatego wszystkie te metody prowadzą do wstępnego renderowania zarówno one.html, jak i two.html:

Lista adresów URL:

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

Wiele skryptów speculationrules:

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

Wiele list w ramach jednego zestawu speculationrules

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

Obsługa przeglądarek

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

Źródło

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

Na przykład parametry UTM są używane przez Google Analytics do pomiaru kampanii, ale zwykle nie powodują wyświetlania różnych stron przez serwer. Oznacza to, że page1.html?utm_content=123page1.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ąć 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 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 dowolny z tych linków przed zakończeniem pobierania z wyprzedzeniem, przeglądarka mogła 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 wybrać, czy ma pobrać link jeszcze raz, czy zaczekać na zakończenie pobierania z wyprzedzeniem, aby sprawdzić, czy 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 tej operacji wstępnego pobierania.

Ograniczenia reguł spekulacyjnych i przyszłe ulepszenia

Reguły spekulacyjne są ograniczone do stron otwartych w obrębie tej samej karty, ale pracujemy nad zmniejszeniem 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.

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 wyrenderowaną stroną korzysta z podobnego nagłówka HTTP Supports-Loading-Mode: uncredentialed-prerender.

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

Biorąc pod uwagę te ograniczenia, w miarę możliwości jeden wzorzec, który może zwiększyć wygodę użytkowników korzystających zarówno z linków wewnętrznych, jak i zewnętrznych, to wstępne renderowanie adresów URL tej samej domeny i próba pobrania 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>

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 Detect Speculation Rules API

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ą JavaScriptu

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.

Wstawienie elementu <script type = "speculationrules"> bezpośrednio do DOM przy użyciu innerHTML nie spowoduje zarejestrowania reguł spekulacyjnych ze względów bezpieczeństwa. Należy go 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 dodaje 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.

Anuluj reguły spekulacyjne

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 to reguł zawartych w początkowym kodzie HTML, więc w przypadku witryn, które używają rygorystycznego CSP, reguły muszą być wstrzykiwane przez JavaScript.

Wykrywanie i wyłączanie prerenderowania

Wstępna renderyzacja zwykle jest korzystna dla użytkowników, ponieważ 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 inaczej osiągnąć.

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

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

Wyprzedaż jest włączona tylko dla użytkowników Chrome, którzy mają ustawienie „Wczytaj strony z wyprzedzeniem” 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ę Limity w Chrome.

Wykrywanie i wyłączanie prerenderowania po stronie serwera

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

Sec-Purpose: prefetch;prerender

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

Sec-Purpose: prefetch

Serwery mogą odpowiadać na podstawie tego nagłówka, aby rejestrować żądania spekulacyjne, zwracać inne treści lub zapobiegać prerenderowaniu. Jeśli zwrócony zostanie kod odpowiedzi, który nie oznacza sukcesu (czyli nie jest to kod z zakresu 200–299 po przekierowaniach), strona nie zostanie wstępnie wyrenderowana, a każda strona z pobieraniem wstępnego w tle zostanie odrzucona. Pamiętaj też, że odpowiedzi 204 i 205 nie są 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). 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ą używać tej metody, aby zapobiegać lub opóźniać określone działania podczas wstępnego renderowania, dopóki strona nie zostanie faktycznie aktywowana.

Po aktywowaniu wstępnie 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.

Możesz użyć funkcji, która sprawdza renderowanie wstępne i wstępnie wyrenderowane strony, 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 zwrócona wartość jest różna od 0, oznacza to, że strona została wyrenderowana z wyprzedzeniem:

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

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

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

Wpływ na statystyki

Analytics służą do pomiaru korzystania z witryny, np. za pomocą Google Analytics do pomiaru odsłon i zdarzeń. Możesz też mierzyć dane o wydajności stron za pomocą Monitorowania 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 statystyk i podobnych przypadków użycia, ale w innych przypadkach może Ci się przydać wczytanie większej ilości treści. Dlatego możesz używać właściwości document.prerendering i prerenderingchange do kierowania reklam na strony z wstępnym renderowaniem.

Blokowanie innych treści podczas renderowania wstępnego

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. Na przykład po powrocie na stronę, która była w tle, wszystkie liczniki koszyka powinny zostać zaktualizowane o najnowszą liczbę produktów w koszyku. Nie jest to więc problem związany z renderowaniem wstępnym, ale po prostu sprawia, że istniejący problem jest bardziej oczywisty.

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

Pomiar wyników

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

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

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 możesz sprawdzić, ile elementów nawigacji jest wstępnie wyrenderowanych w porównaniu z innymi typami nawigacji, a także powiązać ze sobą dane o skuteczności lub działalności biznesowej z tymi różnymi rodzajami 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 oznaczać, że zbyt dużo zasobów jest renderowanych z wyprzedzeniem, co pochłania cenne zasoby użytkownika bez większej korzyści.

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

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

„Skuteczność” można wtedy oszacować na podstawie różnicy między tymi dwoma wartościami. W przypadku stron, w przypadku których do wstępnego renderowania stron używasz interfejsu Speculation Rules API, możesz odpowiednio dostosować reguły, aby zachować wysoką częstotliwość trafień i utrzymać równowagę między wykorzystaniem zasobów użytkowników w celu pomocy im a ich niepotrzebnym 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 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 dedykowany wpis na temat rozszerzeń Chrome: rozszerzanie interfejsu API w celu obsługi nawigacji błyskawicznej, w którym znajdziesz dodatkowe informacje, o których autorzy rozszerzeń powinni pamiętać w przypadku stron z renderowaniem wstępnym.

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 przekazywania opinii na temat repozytorium GitHub lub korzystania z naszego narzędzia do śledzenia problemów. Chętnie poznamy też studia przypadków dotyczące tego nowego interfejsu API.

Podziękowania

Miniatura autorstwa Marc-Olivier Jodoin na Unsplash