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

Barry Pollard

Zespół Chrome przywrócił pełne wstępne renderowanie przyszłych stron, które mogą odwiedzać użytkownicy.

Krótka historia wstępnego renderowania

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.

Starsze renderowanie wstępne korzystające z linku rel=prerender zostało wycofane i zastąpione funkcją NoState Prefetch pobieranie zasobów wymaganych przez przyszłą stronę, ale nie w pełni wstępnie wyrenderowano strony ani nie wykonało kodu JavaScript. Pobieranie z wyprzedzeniem NoState pomaga zwiększyć wydajność strony przez usprawnienie wczytywania zasobów, ale nie zapewnia natychmiastowego wczytywania strony, jak miałoby to miejsce w przypadku pełnego wstępnego renderowania.

Zespół Chrome przywrócił pełne wstępne renderowanie z powrotem w tej przeglądarce. Aby uniknąć komplikacji z dotychczasowym zastosowaniem i umożliwić rozszerzenie 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 w przyszłości wycofać tę funkcję.

Jak strona jest wstępnie renderowana?

Stronę można wstępnie wyrenderować na jeden z 4 sposobów, z których każdy ma 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 używasz paska zakładek, Chrome może automatycznie wstępnie wyrenderować stronę za Ciebie po przytrzymaniu wskaźnika nad jednym z przycisków zakładek.
3. Gdy wpiszesz wyszukiwane hasło na pasku adresu Chrome, Chrome może automatycznie wstępnie wyrenderować stronę wyników wyszukiwania, jeśli o to poprosi wyszukiwarka.
4. Witryny mogą używać interfejsu Speculation Rules API, aby automatycznie informować Chrome, które strony mają być wstępnie renderowane. 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 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 renderowanie wstępne zachowuje się tak, jakby strona została otwarta na niewidocznej karcie w tle, a potem zostaje „aktywowana” przez zastąpienie karty na pierwszym planie tą prerenderowaną stroną. Jeśli strona zostanie aktywowana, zanim zostanie w pełni wstępnie wyrenderowana, jej bieżący stan to „pierwszy plan”. i nadal się ładuje, co oznacza, że wciąż możesz zacząć z wyprzedzeniem.

Ponieważ wstępnie renderowana strona jest otwierana w stanie ukrytym, kilka interfejsów API, które powodują uciążliwe zachowania (na przykład prompty), nie jest aktywowane w tym stanie. Zamiast tego są one opóźnione do czasu aktywacji strony. W niewielkiej liczbie przypadków, gdy nie jest to jeszcze możliwe, renderowanie wstępne jest anulowane. Zespół Chrome pracuje nad ujawnieniem przyczyn anulowania renderowania wstępnego w formie interfejsu API oraz nad ulepszeniem możliwości Narzędzi deweloperskich, aby ułatwić wykrywanie takich skrajnych przypadków.

Wpływ renderowania wstępnego

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

Przykładowa witryna jest już szybka, ale nawet w takim przypadku możesz sprawdzić, jak renderowanie wstępne poprawia wrażenia użytkowników. Może to też mieć bezpośredni wpływ na podstawowe wskaźniki internetowe witryny – LCP prawie zerowy, obniżyć CLS (ponieważ wszelkie CLS obciążenia występują przed pierwszym widokiem) i na ulepszenie INP (ponieważ wczytywanie powinno być ukończone przed interakcją użytkownika).

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.

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 podpowiedzi na pasku adresu Chrome

W pierwszym przypadku użycia możesz wyświetlić prognozy Chrome dla adresów URL na stronie chrome://predictors:

Zielone linie wskazują na wystarczający poziom ufności, aby aktywować renderowanie wstępne. W tym przykładzie wpisanie „s” daje wystarczającą pewność (bursztynowy), ale po wpisaniu „sh” Chrome ma na tyle pewność, że prawie zawsze otwierasz https://sheets.google.com.

Ten zrzut ekranu został wykonany przy stosunkowo nowej instalacji Chrome i odfiltrowywał prognozy o zerowym poziomie ufności, ale jeśli wyświetlisz własne prognozy, najprawdopodobniej zobaczysz znacznie więcej pozycji, a nawet więcej znaków wymaganych do uzyskania wystarczająco wysokiego poziomu pewności.

Wspomagają one również wyświetlanie sugerowanych opcji na pasku adresu:

Chrome będzie stale aktualizować swoje prognozy na podstawie wpisywanych przez Ciebie słów i wybranych elementów.

• W przypadku poziomu ufności przekraczającego 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.

Interfejs Speculation Rules API

W przypadku opcji wstępnego renderowania interfejsu Speculation Rules API deweloperzy mogą wstawiać na swoich stronach instrukcje JSON, aby poinformować przeglądarkę o tym, które adresy URL mają być wstępnie wyrenderowane:

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

Z kolei reguły dokumentu (dostępne w Chrome 121) wstępnie renderują 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 dotyczące reguł spekulacyjnych, które przeprowadzi Cię przez proces dodawania reguł spekulacyjnych do witryny.

Chęć

Ustawienie eagerness pozwala określić, kiedy mają być uruchamiane spekulacje, co jest szczególnie przydatne w przypadku reguł dokumentów:

• immediate: służy do spekulacji najszybciej, jak to możliwe, czyli gdy tylko zostaną zastosowane reguły spekulacyjne.
• eager: działa to identycznie jak ustawienie immediate, ale w przyszłości chcemy umieścić je gdzieś pomiędzy immediate a moderate.
• moderate: powoduje to spekulacje, jeśli przytrzymujesz wskaźnik na linku przez 200 milisekund (lub przez zdarzenie pointerdown, jeśli nastąpi to wcześniej, i na urządzeniach mobilnych, gdzie nie ma zdarzenia hover).
• conservative: ta wartość określa spekulację na podstawie wskaźnika lub przyłożenia.

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. Chociaż w wielu przypadkach bardziej odpowiednie mogą być reguły document z odpowiednim warunkiem where.

Wartość domyślna eagerness w przypadku document reguł to conservative. Ponieważ dokument może zawierać wiele adresów URL, z reguły document należy korzystać z zasad immediate lub eager (zapoznaj się też z sekcją Ograniczenia Chrome w następnej kolejności).

To, które ustawienie eagerness należy zastosować, zależy od witryny. W przypadku mniej skomplikowanych, statycznych witryn spekulacje mogą być mało kosztowne i korzystne dla użytkowników. W przypadku witryn o bardziej złożonych architekturze i większych ładunkach stron mogą preferować zmniejszenie ilości odpadów za pomocą spekulacji rzadziej, dopóki nie uzyskasz od użytkowników bardziej pozytywnego sygnału wyrażającego zgodę na ograniczenie ilości odpadów.

Opcja moderate stanowi środek, a wiele witryn może skorzystać na zastosowaniu reguły spekulacyjnej, która powoduje wstępne renderowanie linku, gdy przytrzymujesz na nim wskaźnik przez 200 milisekund lub gdy wskazujesz zdarzenie wskaźnika w celu podstawowej, a zarazem skutecznej implementacji reguł spekulacyjnych:

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

Pobieranie z wyprzedzeniem

Reguł spekulacyjnych można też używać do wstępnego pobierania stron bez pełnego wstępnego renderowania. Często jest to 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:

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ęć. Anulowana spekulacja może zostać aktywowana ponownie, np. przez ponowne najechanie kursorem na link. Spowoduje to ponowne spekulowanie tego adresu URL i wypchnięcie najstarszej spekulacji. W tym przypadku poprzednia spekulacja zapisała w pamięci podręcznej HTTP wszystkie zasoby, które można zapisać w pamięci podręcznej dla danego adresu URL, więc spekulacja przedłużenia czasu powinna obniżyć koszty. Dlatego limit ten jest ustawiony na skromny próg wynoszący 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 również mają charakter dynamiczny, więc usunięcie elementu skryptu URL list spowoduje wzrost wydajności przez anulowanie tych usuniętych spekulacji.

Chrome zapobiega też używaniu spekulacji w określonych warunkach, takich jak:

• Zapisz dane.
• Oszczędzanie energii włączone i słaba bateria.
• Ograniczenia pamięci.
• Gdy opcja „Wstępnie wczytuj strony” jest wyłączone (to ustawienie jest też wyraźnie wyłączone przez rozszerzenia do Chrome, takie jak uBlock Origin).
• Strony zostały otwarte na 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 zmniejszenie wpływu nadmiernej spekulacji na szkodę użytkowników.

Jak umieścić 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 spekulacyjne: na przykład witryna z wiadomościami lub blog może wstępnie wyrenderować najnowszy artykuł, jeśli często jest to następna nawigacja dla dużej części użytkowników. Można też wykorzystać reguły dokumentów z tagiem moderate lub conservative do spekulacji podczas 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.

Ci, którzy preferują dynamiczne wstawianie treści na podstawie działań takich jak najechanie kursorem na link lub kliknięcie linku – tak jak wiele bibliotek robiło to w przeszłości za pomocą funkcji <link rel=prefetch> – zalecamy zapoznanie się z regułami dotyczącymi dokumentów, ponieważ pozwalają one przeglądarce obsługiwać różne przypadki użycia.

Reguły spekulacyjne można dodawać w elemencie <head> lub <body> w ramce głównej. Na reguły spekulacyjne w ramkach podrzędnych nie można działać, a reguły spekulacyjne na wstępnie renderowanych stronach są uwzględniane dopiero po aktywowaniu strony.

Nagłówek HTTP Speculation-Rules

Reguły spekulacyjne można też dostarczyć za pomocą nagłówka HTTP Speculation-Rules, zamiast umieszczać je bezpośrednio w kodzie HTML dokumentu. Ułatwia to wdrażanie w sieciach CDN bez konieczności samodzielnego zmieniania zawartości dokumentów.

Wraz z dokumentem zwracany jest nagłówek HTTP Speculation-Rules, który wskazuje lokalizację pliku JSON zawierającego reguły spekulacyjne:

Speculation-Rules: "/speculationrules.json"

Ten zasób musi używać prawidłowego typu MIME, a w przypadku zasobów z innych domen musi przejść kontrolę CORS.

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

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

Reguły spekulacyjne i SPA

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, 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. Dane potrzebne do tzw. „miękkiej nawigacji” mogą zostać wstępnie pobrane przez aplikację poza regułami spekulacyjnymi, ale nie mogą być wstępnie renderowane.

Reguł spekulacyjnych można użyć do wstępnego renderowania samej aplikacji z poprzedniej strony. W ten sposób możesz obniżyć koszty wczytywania początkowego w niektórych aplikacjach SPA. Nie można jednak wstępnie wyrenderować zmian tras 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

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 wstępnego pobierania lub renderowania strony niektóre parametry adresu URL (nazywane parametrami wyszukiwania) mogą być nieistotne dla strony wyświetlanej przez serwer i są 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 z serwera. Oznacza to, że page1.html?utm_content=123 i page1.html?utm_content=456 będą wyświetlać tę samą stronę z serwera, więc można użyć tej samej strony z pamięci podręcznej.

Podobnie aplikacje mogą używać innych parametrów adresów URL, które są obsługiwane tylko po stronie klienta.

Opcja No-Vary-Search pozwala serwerowi określić parametry, które nie wpływają na różnice w wyświetlanym zasobie, a tym samym pozwalają przeglądarce ponownie wykorzystać wersje dokumentu zapisane w pamięci podręcznej, które różnią się tylko tymi parametrami. Jest to obsługiwane w Chrome (i przeglądarkach opartych na Chromium) na potrzeby spekulacji dotyczących nawigacji podczas pobierania z wyprzedzeniem (chociaż zamierzamy to również obsługiwać w przypadku renderowania z wyprzedzeniem).

Reguły spekulacyjne obsługują używanie expects_no_vary_search do wskazywania, gdzie powinien 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. 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 zastrzeżeniem pobieramy ten adres URL z wyprzedzeniem i powinien on zwracać nagłówek HTTP No-Vary-Search pokazujący, że strony można użyć w przypadku dowolnego parametru wyszukiwania id.

Jeśli jednak użytkownik kliknie dowolny z tych linków przed zakończeniem pobierania z wyprzedzeniem, przeglądarka mogła nie otrzymać strony /products. W takim przypadku przeglądarka nie wie, czy zawiera 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. 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 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 tej samej domeny. Spekulacyjne strony z innych domen w tej samej witrynie (np. https://a.example.com może wstępnie wyrenderować stronę w witrynie https://b.example.com). Aby można było z nich korzystać, spekulacyjna strona (w tym przykładzie https://b.example.com) musi wyrazić na to zgodę przez dołączenie nagłówka HTTP Supports-Loading-Mode: credentialed-prerender. W przeciwnym razie Chrome anuluje spekulację.

Przyszłe wersje mogą też zezwolić na renderowanie wstępne w przypadku stron z innych 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 ponownie tylko wtedy, gdy nie istnieją pliki cookie z danej domeny. Jeśli istnieją pliki cookie użytkownika, który wcześniej odwiedził tę stronę, spekulacja nie zostanie wywołana i wykaże błąd w Narzędziach deweloperskich.

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>

Domyślnie ograniczenie zapobiegające spekulacji na temat linków z innych domen w przypadku linków z innych domen jest niezbędne ze względów bezpieczeństwa. To lepsze działanie niż <link rel="prefetch"> w przypadku miejsc docelowych z innych domen, które również nie wysyłają plików cookie, ale nadal próbują pobrać z wyprzedzeniem. Spowoduje to zmarnowane pobieranie z wyprzedzeniem i konieczność ponownego przesłania albo, co gorsza, nieprawidłowe wczytanie strony.

Reguły spekulacyjne nie są obsługiwane w przypadku pobierania z wyprzedzeniem w przypadku stron kontrolowanych przez mechanizmy Service Worker. Pracujemy nad dodaniem tej funkcji. Aby mieć dostęp do aktualnych informacji, zapoznaj się z artykułem Problem z robotem pomocy technicznej. W przypadku stron kontrolowanych przez mechanizm Service Worker obsługiwane jest wstępne renderowanie.

Obsługa interfejsu Detect Speculation Rules API

Możesz wykrywać obsługę interfejsu Speculation Rules API za pomocą standardowych testów 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 spekulacyjnej prerender za pomocą JavaScriptu:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

Na tej stronie demonstracyjnej funkcji wstępnego renderowania możesz zobaczyć wersję demonstracyjną wstępnego renderowania interfejsu Speculation Rules API za pomocą wstawiania JavaScriptu.

Wstawienie elementu <script type = "speculationrules"> bezpośrednio do modelu 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 wstawione dynamicznie za pomocą pola innerHTML, które zawierają nowe linki, zostaną odczytane przez istniejące reguły na stronie.

Podobnie bezpośrednia edycja panelu Elements w Narzędziach deweloperskich w Chrome w celu dodania elementu <script type = "speculationrules"> nie powoduje zarejestrowania reguł spekulacyjnych. Zamiast tego skrypt dynamicznie dodający tę wartość do DOM musi być uruchamiany z poziomu konsoli, aby wstawić reguły.

Dodawanie reguł spekulacyjnych w Menedżerze 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:

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

Anuluj reguły spekulacyjne

Usunięcie reguł spekulacyjnych spowoduje anulowanie renderowania wstępnego, ale do tego czasu zasoby prawdopodobnie zostały już wykorzystane na jego zainicjowanie, dlatego nie zalecamy renderowania wstępnego, jeśli istnieje prawdopodobieństwo jego anulowania.

Reguły spekulacyjne i Content Security Policy

Reguły spekulacyjne używają elementu <script>, mimo że zawierają tylko kod JSON, dlatego muszą być uwzględnione w Content-Security-Policy (Content-Security-Policy), jeśli w witrynie używany jest element <script> (za pomocą skrótu lub liczby jednorazowej).script-src

Do script-src można dodać nowy znacznik inline-speculation-rules, aby umożliwić obsługę elementów <script type="speculationrules"> wstrzykiwanych z haszowania lub niekodowanych 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 renderowania wstępnego

Wstępne renderowanie stron jest zwykle bardzo wygodne dla użytkowników, ponieważ umożliwia szybkie renderowanie stron – często natychmiast. 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 w innych okolicznościach.

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

Renderowanie wstępne jest włączone tylko dla tych użytkowników Chrome, którzy włączyli opcję „Wstępnie wczytuj strony” ustawienie w usłudze chrome://settings/performance/. Dodatkowo renderowanie wstępne jest też wyłączone w przypadku urządzeń z małą ilością pamięci lub w trybie oszczędzania danych lub oszczędzania energii. Zobacz sekcję Limity w Chrome.

Wykrywanie i wyłączanie wstępnego renderowania po stronie serwera

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

Sec-Purpose: prefetch;prerender

Wstępnie pobrane strony przy użyciu interfejsu Speculation Rules API będą miały ten nagłówek ustawiony tylko na prefetch:

Sec-Purpose: prefetch

Na podstawie tego nagłówka serwery mogą odpowiadać na żądania, aby rejestrować żądania spekulacyjne, zwracać inne treści lub zapobiegać renderowaniu wstępnemu. Jeśli zostanie zwrócony kod odpowiedzi oznaczający brak powodzenia (inny niż 200 ani 304), strona nie zostanie wstępnie wyrenderowana, a pobierana z wyprzedzeniem strona zostanie odrzucona.

Jeśli nie chcesz, aby konkretna strona była wstępnie renderowana, skorzystaj z najlepszego sposobu, aby mieć pewność, że tak się nie stanie. 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żyć, 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ść activationStart w polu PerformanceNavigationTiming również zostanie ustawiona na wartość inną niż 0, co oznacza czas między rozpoczęciem renderowania wstępnego a aktywacją 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 na sprawdzenie, czy strona została wyrenderowana (w całości lub częściowo), jest otwarcie Narzędzi deweloperskich po aktywowaniu strony i wpisanie w konsoli performance.getEntriesByType('navigation')[0].activationStart. Jeśli zwracana jest wartość inna niż zero, oznacza to, że strona została wstępnie wyrenderowana:

Gdy strona zostanie aktywowana przez użytkownika, który ją wyświetla, document zostanie wysłane zdarzenie prerenderingchange, które można następnie wykorzystać do włączenia działań, które wcześniej byłyby uruchamiane domyślnie przy wczytywaniu strony, ale chcesz opóźnić je do chwili, gdy użytkownik faktycznie wyświetli stronę.

Dzięki tym interfejsom API JavaScript frontendu może wykrywać wstępnie renderowane strony i odpowiednio na nich działać.

Wpływ na statystyki

Analytics służy do pomiaru wykorzystania witryny, np. Google Analytics do pomiaru wyświetleń stron i zdarzeń. Możesz też mierzyć dane o wydajności stron za pomocą Monitorowania użytkowników (RUM).

Strony należy renderować wstępnie tylko wtedy, gdy istnieje duże prawdopodobieństwo, że zostaną załadowane przez użytkownika. Dlatego opcje wstępnego renderowania na pasku adresu w Chrome są stosowane tylko wtedy, gdy prawdopodobieństwo jest wysokie (w ponad 80% przypadków).

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 zrobić, stosując metodę Promise, która czeka na zdarzenie prerenderingchange, jeśli dokument jest renderowany wstępnie, lub rozwiązuje problem natychmiast, jeśli jest wykonywany teraz:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

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

initAnalytics();

Możesz też opóźnić działania analityczne do momentu, gdy strona zostanie po raz pierwszy wyświetlona, co powinno obejmować zarówno renderowanie wstępne, jak i otwarte karty w tle (np. kliknięcie prawym przyciskiem myszy i otwarcie strony 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();

Choć może to być przydatne w przypadku statystyk i podobnych przypadków użycia, 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

Interfejsy API omówione wcześniej mogą być używane do blokowania innych treści na etapie wstępnego renderowania. Mogą to być określone części JavaScriptu lub całe elementy skryptu, których nie chcesz uruchamiać na etapie renderowania wstępnego.

Na przykład w przypadku tego skryptu:

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

Jest to przydatne, gdy chcesz wstrzymywać odrębne skrypty zawierające statystyki lub renderować treści na podstawie stanu bądź innych zmiennych, które mogą się zmieniać w trakcie wizyty. Na przykład rekomendacje, stan logowania czy ikony koszyka na zakupy mogą być niewidoczne, aby zapewnić dostęp do najbardziej 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ć także sprawdzany w przypadku ogólnych zmian visibilitychange – np. po powrocie na stronę, która była w tle, należy zaktualizować liczniki koszyka na zakupy 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 eliminuje część konieczności ręcznego opakowywania skryptów lub funkcji, jest wstrzymywanie niektórych interfejsów API, jak wspomniano wcześniej, oraz nierenderowanie elementów iframe innych firm, dlatego do ich wyświetlania należy ręcznie blokować ich zawartość.

Pomiar wyników

W przypadku pomiaru danych dotyczących wydajności analityka powinna rozważyć, czy lepiej jest dokonać pomiaru w oparciu o czas aktywacji, a nie na czas wczytywania strony raportowany przez interfejsy API przeglądarki.

W przypadku podstawowych wskaźników internetowych, które są mierzone przez Chrome w Raporcie na temat użytkowania Chrome, służą one do pomiaru wrażeń użytkowników. Są one mierzone na podstawie czasu aktywacji. Na przykład często wskaźnik LCP wynoszący 0 sekund będzie wskazywać, że jest to świetny sposób na poprawę podstawowych wskaźników internetowych.

Począwszy od wersji 3.1.0 biblioteka web-vitals została zaktualizowana, aby obsługiwać wstępnie renderowane elementy nawigacyjne w taki sam sposób, w jaki Chrome mierzy podstawowe wskaźniki internetowe. W atrybucie Metric.navigationType ta wersja oznacza też w atrybucie Metric.navigationType wstępnie wyrenderowane nawigacji, jeśli strona została wyrenderowana w pełni lub częściowo.

Pomiar renderowania wstępnego

Informacja o tym, czy strona została wstępnie wyrenderowana, można sprawdzić za pomocą wartości PerformanceNavigationTiming innej niż 0.activationStart Można to później rejestrować za pomocą wymiaru niestandardowego lub podobnego podczas rejestrowania wyświetleń strony, np. przy użyciu 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 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ą wszelkie dane o skuteczności lub dane biznesowe. Szybsze działanie stron oznacza zadowolenie użytkowników, co często może mieć realny wpływ na działania firmy, jak wynika z naszych studiów przypadków.

Mierząc wpływ wstępnego renderowania stron na potrzeby błyskawicznej nawigacji, możesz określić, czy warto zainwestować więcej czasu w używanie tej technologii i umożliwić wstępne wyrenderowanie większej liczby elementów nawigacyjnych, czy też sprawdzić, dlaczego strony nie są wstępnie wyrenderowane.

Mierz współczynniki trafień

Oprócz pomiaru wpływu stron odwiedzanych po wstępnym wyrenderowaniu ważne jest też, aby mierzyć strony, które zostały wstępnie wyrenderowane, a potem nie 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 zmierzyć, uruchamiając zdarzenie analityczne, gdy wstawione są reguły spekulacyjne – po sprawdzeniu, czy przeglądarka obsługuje renderowanie wstępne za pomocą funkcji HTMLScriptElement.supports('speculationrules'), aby wskazać, że zażądano renderowania wstępnego. 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 rzeczywistą liczbą wyświetleń strony z wyrenderowaniem wstępnym. Możesz też uruchomić kolejne zdarzenie przy aktywacji, aby ułatwić porównanie.

„Współczynnik udanych trafień” można następnie obliczyć w przybliżeniu przez różnicę między tymi dwiema liczbami. 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 pewne procesy renderowania mogą mieć miejsce ze względu na wstępne renderowanie na pasku adresu, a nie tylko reguły spekulacyjne. Jeśli chcesz je odróżnić, możesz zaznaczyć pole document.referrer (puste w przypadku nawigacji na pasku adresu, w tym w przypadku wstępnie renderowanej nawigacji na pasku adresu).

Zwróć też uwagę na strony bez renderowania wstępnego, ponieważ może to oznaczać, że te strony nie kwalifikują się do renderowania wstępnego, nawet z poziomu paska adresu. Może to oznaczać, że nie korzystasz z optymalizacji skuteczności. Zespół Chrome planuje dodać więcej narzędzi do testowania pod kątem możliwości renderowania wstępnego – być może podobnych do narzędzia do testowania bfcache. Może też dodać interfejs API, który będzie wyjaśniał, dlaczego renderowanie wstępne się nie powiodł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 renderowaniem wstępnym, a poza tym planujemy rozszerzyć zakres tego, co udostępniliśmy w wersji 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.

Powiązane artykuły

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

Podziękowania

Miniatura: Marc-Olivier Jodoin na kanale Unsplash