Data publikacji: 7 marca 2025 r.
Interfejs Speculation Rules API pozwala użytkownikom korzystać z ulepszonego działania dzięki pobieraniu z wyprzedzeniem lub wstępnemu renderowaniu przyszłych nawigacji po stronach, co umożliwia szybsze, a nawet natychmiastowe przełączanie się między stronami.
Interfejs API został zaprojektowany z myślą o łatwości wdrożenia, ale przed jego użyciem należy wziąć pod uwagę kilka kwestii, zwłaszcza w przypadku witryn złożonych. Ten przewodnik pomaga właścicielom witryn zrozumieć te kwestie.
Planowanie
Zanim zaczniesz stosować reguły spekulacji, zastanów się, jak zaimplementować interfejs API (do wyboru jest kilka opcji), a także jakie są koszty spekulacji (co powinno Ci pomóc w określeniu, na których stronach chcesz spekulować).
Wybieranie sposobu wdrażania reguł spekulacyjnych
Jedną z pierwszych decyzji, które musisz podjąć, jest sposób wdrożenia w swojej witrynie zasad spekulacji. Możesz użyć różnych metod:
- bezpośrednio w kodzie HTML strony;
- Za pomocą JavaScriptu
- Korzystanie z nagłówka HTTP
Ostatecznie każda metoda ma ten sam skutek, ale mogą występować różnice w łatwości wdrożenia i elastyczności.
Witryny powinny wybrać opcję, która najbardziej im odpowiada, a w razie potrzeby mogą nawet użyć kombinacji tych opcji. Można je też zaimplementować za pomocą wtyczki (np. wtyczki Speculative Loading do WordPressa) lub bibliotek i platform, które mogą dokonać wyboru za Ciebie. Warto jednak znać dostępne opcje.
Dodanie reguł spekulacyjnych bezpośrednio w kodzie HTML strony
Reguły spekulacji można stosować bezpośrednio na stronie, dodając element <script type="speculationrules"> do kodu HTML. W przypadku witryn statycznych z wykorzystaniem szablonów można je dodać w czasie kompilacji, a w przypadku serwera – w czasie wykonywania, gdy żądana jest strona. Mogą one być nawet wstrzykiwane w HTML przez pracowników na urządzeniach brzegowych (chociaż metoda nagłówka HTTP, o której mowa w dalszej części tego przewodnika, jest prawdopodobnie łatwiejsza).
Umożliwia to uwzględnienie reguł statycznych w całej witrynie, ale reguły dokumentu mogą być nadal dynamiczne, ponieważ umożliwiają wybranie adresów URL do wyrenderowania ze strony za pomocą reguł, które mają być wywoływane przez klasy CSS:
<script type="speculationrules">
{
"prerender": [{
"where": { "selector_matches": ".prerender" }
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch" }
}]
}
</script>
Poprzedni skrypt będzie renderować wstępnie linki z klasą prerender i w podobny sposób pobierać wstępnie linki z klasą prefetch. Dzięki temu deweloperzy mogą uwzględniać te klasy w kodzie HTML, aby wywoływać spekulacje.
Oprócz umieszczania linków do tych klas w początkowym kodzie HTML strony, linki będą też tworzone dynamicznie przez aplikację, co pozwoli jej uruchamiać (i usuwać) spekulacje w miarę potrzeby. Może to być prostsze niż tworzenie lub usuwanie bardziej szczegółowych reguł spekulacji. Możesz też uwzględnić kilka reguł spekulacji na stronę, jeśli chcesz użyć reguły podstawowej na większości stron i reguł na konkretne strony.
Jeśli jednak potrzebujesz bardziej szczegółowych reguł spekulacji, możesz utworzyć reguły dotyczące konkretnych stron lub szablonów, aby stosować różne reguły w przypadku określonych stron lub typów stron.
Wreszcie strony renderowane po stronie serwera mogą mieć też więcej reguł dynamicznych opartych na informacjach dostępnych dla serwera, takich jak informacje analityczne o tej stronie lub typowe ścieżki użytkowników prowadzące do określonych stron.
Dodawanie reguł spekulacyjnych za pomocą JavaScriptu
Alternatywą dla umieszczania reguł w skrypcie na stronie jest wstrzyknięcie ich za pomocą JavaScriptu. Może to wymagać mniejszej liczby aktualizacji szablonów stron. Na przykład menedżer tagów może szybko wstrzyknąć reguły (co pozwala też w razie potrzeby szybko je wyłączyć).
Ta opcja umożliwia też stosowanie dynamicznych reguł po stronie klienta na podstawie interakcji użytkownika z tą stroną. Jeśli np. użytkownik doda produkt do koszyka, możesz zrenderować stronę płatności. Można go też użyć do wywołania spekulacji na podstawie określonych warunków. Interfejs API zawiera ustawienie „szybkości”, które umożliwia stosowanie podstawowych reguł opartych na interakcjach, a JavaScript pozwala deweloperom korzystać z własnej logiki, aby decydować, kiedy i na których stronach mają być stosowane spekulacje.
Jak już wspomnieliśmy, alternatywą dla wstawiania nowych reguł jest użycie na stronie reguły dokumentu podstawowego i uruchomienie reguł dokumentu za pomocą kodu JavaScriptu przez dodanie odpowiednich klas do linków, które powodują ich dopasowanie do reguły.
Dodawanie reguł spekulacyjnych za pomocą nagłówka HTTP
Ostatnią opcją dla deweloperów jest dołączenie reguł za pomocą nagłówka HTTP:
Speculation-Rules: "/speculationrules.json"
Istnieją dodatkowe wymagania dotyczące sposobu dostarczania i używania zasobu reguł (w tym przykładzie /speculationrules.json).
Ta opcja umożliwia łatwiejsze wdrażanie za pomocą sieci CDN bez konieczności zmiany treści dokumentu. Oznacza to, że nie można dynamicznie zmieniać reguł spekulacji za pomocą JavaScriptu. Reguły dotyczące dokumentów z triggerami selektora CSS mogą jednak nadal umożliwiać wprowadzanie zmian dynamicznych, np. przez usunięcie klasy prerender z linku.
Podobnie jak w przypadku opcji JavaScript, wdrażanie reguł spekulacji za pomocą nagłówka HTTP umożliwia ich wdrażanie niezależnie od treści witryny, co ułatwia dodawanie i usuwanie reguł bez konieczności całkowitego przebudowy witryny.
Rozważ konsekwencje finansowe
Zanim zastosujesz reguły spekulacji, warto poświęcić trochę czasu na zastanowienie się nad kosztami, jakie mogą ponieść użytkownicy i Twoja witryna w związku z tym interfejsem API. Koszty te obejmują przepustowość (kosztuje zarówno użytkowników, jak i witryny) oraz koszty przetwarzania (po stronie klienta i serwera).
Weź pod uwagę koszty ponoszone przez użytkowników
Ładowanie spekulacyjne polega na szacowaniu, dokąd użytkownik może przejść. Jeśli jednak nie dojdzie do takiej nawigacji, możesz zmarnować zasoby. Dlatego musisz mieć świadomość wpływu na użytkowników, w szczególności:
- Dodatkowa przepustowość wykorzystywana do pobierania danych na potrzeby przyszłej nawigacji – zwłaszcza na urządzeniach mobilnych, gdzie przepustowość może być bardziej ograniczona.
- dodatkowe koszty przetwarzania związane z renderowaniem tych stron podczas korzystania z prerenderowania;
W przypadku całkowicie dokładnych prognoz nie ma dodatkowych kosztów, ponieważ użytkownicy odwiedzą te strony w kolejności, a jedyną różnicą jest to, że koszty są naliczane z wyprzedzeniem. Nie jest jednak możliwe przewidywanie przyszłości z całkowitą dokładnością, a im bardziej agresywna jest strategia spekulacyjna, tym większe ryzyko strat.
W Chrome dokładnie przeanalizowaliśmy ten problem, a interfejs API zawiera kilka funkcji, dzięki którym koszt jest znacznie niższy, niż mogłoby się wydawać. Korzystając z pamięci podręcznej HTTP i nie wczytując elementów iframe w innych domenach, możesz znacznie zmniejszyć koszt wstępnego renderowania nawigacji na tej samej stronie. Koszt ten jest często znacznie mniejszy niż koszt pełnej strony bez zasobów w pamięci podręcznej. Dzięki temu wczytywanie spekulatywne jest tańsze, niż można by przypuszczać.
Mimo tych zabezpieczeń właściciele witryn powinni jednak dokładnie przemyśleć, które strony będą prowadzić do spekulacji, oraz koszty ponoszone przez użytkowników z powodu takich spekulacji. Dobrze nadającymi się do spekulatywnego wczytywania są te strony, które można z wysoką skutecznością przewidzieć (np. na podstawie analityki lub typowych ścieżek użytkowników) i których koszt jest niski (np. strony o mniejszej zawartości).
Możesz też rozważyć, które elementy kodu JavaScript powinny być opóźnione do momentu aktywacji. Podobnie jak w przypadku opóźnionego wczytywania treści do momentu, gdy są potrzebne, może to obniżyć koszty wstępnego renderowania, a zarazem znacznie poprawić wrażenia użytkowników. Dzięki tańszym spekulacjom możesz częściej lub chętniej spekulować.
Jeśli to niemożliwe, zalecamy zastosowanie mniej agresywnej strategii z umiarkowanymi lub konserwatywnymi regułami natężenia. Możesz też użyć prerenderowania, które jest znacznie tańsze niż prerenderowanie, gdy poziom pewności jest niski, a następnie przejść do pełnego prerenderowania, gdy poziom pewności wzrośnie, np. gdy użytkownik najedzie kursorem na link lub go kliknie.
dodatkowe obciążenie backendu,
Oprócz dodatkowych kosztów po stronie użytkownika właściciele witryn powinni wziąć pod uwagę własne koszty infrastruktury. Jeśli każda strona powoduje 2, 3 lub więcej załadowań strony, korzystanie z tego interfejsu API może zwiększyć koszty działania backendu.
Zapewnienie możliwości buforowania stron i zasobów znacznie zmniejszy ilość wczytywania z źródła, a tym samym ogólne ryzyko. Po połączeniu z siecią CDN serwery źródłowe powinny odczuwać minimalne obciążenie dodatkowe, ale należy wziąć pod uwagę ewentualne wzrosty kosztów CDN.
Serwer lub CDN może też służyć do kontrolowania wyników spekulacji, które są identyfikowane przez nagłówek HTTP sec-purpose. Na przykład usługa Speed Brain firmy Cloudflare umożliwia spekulacje tylko w przypadku danych, które są już zapisane w pamięci podręcznej na serwerze brzegowym sieci CDN, i nie wysyła żądań z powrotem do punktu początkowego.
Jednak ponieważ spekulacyjne wczytywanie jest zwykle używane do wczytywania stron z tego samego źródła, użytkownicy mają już współdzielone zasoby w pamięci podręcznej przeglądarki (o ile można je w ogóle przechowywać w pamięci podręcznej), więc spekulacja zwykle nie jest tak kosztowna jak pełne wczytywanie strony.
Znajdź równowagę między zbyt dużym a zbyt małym spekulowaniem
Kluczem do korzystania z interfejsu Speculation Rules API jest znalezienie równowagi między zbyt dużą spekulacją (czyli gdy koszty są niepotrzebnie ponoszone, a spekulacje nie są wykorzystywane) a zbyt konserwatywnym podejściem (czyli gdy koszty są zbyt małe lub gdy spekulacje są stosowane zbyt późno, co powoduje niewielkie korzyści).
W przypadku niskich kosztów (np. małych, statycznie generowanych stron przechowywanych w pamięci podręcznej w węzłach peryferyjnych CDN) możesz sobie pozwolić na bardziej agresywne spekulacje.
W przypadku większych, bogatszych stron, które nie mogą być przechowywane w pamięci podręcznej na brzegu sieci CDN, należy zachować większą ostrożność. Podobnie strony wymagające wielu zasobów mogą zużywać przepustowość sieci lub moc obliczeniową, co może negatywnie wpłynąć na bieżącą stronę. Celem interfejsu API jest poprawa wydajności, więc regresja wydajności jest dla nas niekorzystna. To kolejny powód, dla którego warto ograniczyć liczbę stron do maksymalnie 1 lub 2 stron (pamiętaj też, że Chrome ogranicza liczbę wstępnie renderowanych stron do 2 lub 10 naraz w zależności od szybkości).
Etapy wdrażania reguł spekulacyjnych
Gdy zdecydujesz, jak zastosować reguły spekulacji, musisz zaplanować, co i jak spekulować. Prostsze witryny, takie jak statyczne blogi osobiste, mogą być przetwarzane w pełni przed wyświetleniem, ale w przypadku bardziej złożonych witryn należy wziąć pod uwagę dodatkowe czynniki.
Zacznij od wstępnego pobierania
W przypadku większości witryn wdrożenie pobierania wstępnego jest zwykle stosunkowo bezpieczne. Jest to też początkowe podejście stosowane przez wielu dostawców, w tym w przypadku wdrożeń na dużą skalę, np. Cloudflare i WordPress.
Najważniejsze kwestie, o których należy pamiętać, to to, że pobieranie wstępnie adresu URL może spowodować zmiany stanu i koszty po stronie serwera, zwłaszcza w przypadku stron, których nie można zapisać w pamięci podręcznej. Zmiany stanu (np. wstępny odczyt strony /logout) nie powinny być implementowane jako linki GET, ale niestety w internecie często tak się dzieje.
Takie adresy URL można wykluczyć z reguł:
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Pobieranie w poprzednim planie możesz ograniczyć do zwykłego przechodzenia z jednej strony na drugą lub do wszystkich linków z tej samej domeny po najechaniu kursorem lub kliknięciu, używając opcji moderate lub conservative eagerness. Ustawienie conservative wiąże się z najmniejszym ryzykiem, ale też z najmniejszym potencjałem zarobkowym. Jeśli zaczynasz od tego poziomu, postaraj się przejść co najmniej do moderate, a najlepiej do eager, aby uzyskać większą wydajność (a potem, jeśli to ma sens, przejdź do prerender).
Wstępna renderyzacja o niskim ryzyku
Spekulacje pobierania z wyprzedzeniem są łatwiejsze do wdrożenia, ale największą korzyścią dla interfejsu API jest prerenderowanie. Może to wymagać dodatkowych działań, jeśli strona nie zostanie odwiedzona w krótkim czasie po spekulacjach (omówimy je w następnej sekcji), ale z użyciem wstępnego renderowania moderate lub conservative, gdzie nawigacja nastąpi prawdopodobnie wkrótce, może być stosunkowo bezpiecznym następnym krokiem.
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Pobieranie wstępnie najpopularniejszych stron, aby poprawić niewymagające wstępnego renderowania.
Jedną z popularnych taktyk jest wstępne pobieranie mniejszej liczby często odwiedzanych kolejnych stron podczas wczytywania z użyciem ustawienia eager (poprzez ich określenie na liście adresów URL lub użycie selector_matches), a następnie renderowanie z użyciem ustawienia moderate. W momencie, gdy użytkownik najedzie kursorem na link, prawdopodobnie zakończy się pobieranie wstępne HTML, co przyspieszy proces w porównaniu z wstępnym renderowaniem po najechaniu bez pobierania wstępnego.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["next.html", "next2.html"],
"eagerness": "eager"
}],
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Wcześniejsze przerenderowania
Chociaż reguły dotyczące dokumentów moderate umożliwiają stosunkowo bezpieczne korzystanie z interfejsu API przy łatwej implementacji, często nie wystarcza to na pełne prerenderowanie. Aby uzyskać natychmiastową nawigację, którą umożliwia ten interfejs API, prawdopodobnie trzeba będzie pójść dalej i bardziej aktywnie przetwarzać strony wstępnie.
Można to osiągnąć za pomocą statycznej listy adresów URL (jak w przykładzie wcześniejszego pobierania w poprzednim kroku) lub za pomocą selector_matches, aby zidentyfikować niewielką liczbę adresów URL (najlepiej jedną lub dwie strony), a pozostałe adresy URL objęte regułami dokumentu:
<script type="speculationrules">
{
"prerender": [
{
"where": {
"selector_matches": : ".prerender"
},
"eagerness": "eager",
},
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}
]
}
</script>
Może to wymagać analizy ruchu, aby zwiększyć prawdopodobieństwo dokładnego przewidywania następnej nawigacji. Poznanie typowych ścieżek klientów w Twojej witrynie może też pomóc w zidentyfikowaniu odpowiednich kandydatów do spekulatywnego wczytywania.
Przejście na bardziej zaawansowane wyrenderowanie wstępnie może też wymagać uwzględnienia statystyk, reklam i JavaScriptu oraz potrzeby utrzymywania aktualności strony wyrenderowanej wstępnie, a nawet anulowania lub odświeżania spekulacji w przypadku zmian stanu.
Analytics, reklamy i JavaScript
W przypadku witryn bardziej złożonych należy też wziąć pod uwagę wpływ prerenderowania na analitykę. Zwykle nie rejestrujesz wyświetlenia strony (ani reklamy), gdy jest ona spekulowana, tylko gdy jest aktywna.
Niektórzy dostawcy usług analitycznych (np. Google Analytics) i dostawcy reklam (np. tag Google Publisher Tag) obsługują już reguły spekulacji i nie rejestrują wyświetleń, dopóki strona nie zostanie aktywowana. Inni dostawcy lub wdrożona przez Ciebie niestandardowa analityka mogą jednak wymagać dodatkowej uwagi.
Do kodu JavaScript możesz dodawać mechanizmy kontroli, aby zapobiegać wykonywaniu określonych fragmentów kodu do momentu aktywacji lub wyświetlenia stron, a nawet oznaczać takimi mechanizmami całe elementy <script>. Jeśli strony używają menedżerów tagów do wstrzykiwania takich skryptów, możesz je zablokować jednym ruchem, opóźniając sam skrypt menedżera tagów.
Platformy do zarządzania zgodą użytkowników umożliwiają też opóźnienie uruchamiania skryptów innych firm do momentu aktywacji. Google współpracuje z różnymi platformami tego typu, aby umożliwić im obsługę prerenderowania. Chętnie pomożemy też innym, którzy chcą skorzystać z tej funkcji. PubTech to jedna z takich firm, która pozwala deweloperom na uruchamianie lub blokowanie kodu JavaScript podczas prerenderowania.
W przypadku kodu aplikacji możesz w podobny sposób dodać zmianę, aby opóźnić wykonanie kodu do momentu jego aktywacji, zwłaszcza gdy strona nie wymaga renderowania kodu JavaScript. Jest to szybsza i bezpieczniejsza opcja, ale oznacza, że cały kod zostanie uruchomiony od razu po aktywacji. Może to wymagać dużo pracy w czasie aktywacji, co może mieć wpływ na INP, zwłaszcza że strona może wyglądać na w pełni załadowaną i gotową do interakcji.
Dodatkowo, jeśli jakiekolwiek treści zależą od JavaScriptu (np. treści renderowane po stronie klienta), opóźnienie zmniejszy pozytywny wpływ wstępnego renderowania na LCP i CLS. Bardziej ukierunkowane podejście, które pozwoli na uruchomienie większej liczby skryptów JavaScriptu na etapie wstępnego renderowania, zapewni lepsze wrażenia, ale może być trudniejsze do wdrożenia.
W przypadku bardziej złożonych witryn dobrym rozwiązaniem może być całkowite opóźnienie wielu tagów skryptów. Jednak aby w pełni korzystać z interfejsu API, należy umożliwić uruchamianie jak największej ilości kodu JavaScript podczas prerenderowania.
W przypadku witryn, w których występują problemy z statystykami lub reklamami, warto zacząć od prerenderowania, ponieważ w tym przypadku te problemy nie są tak istotne. W tym czasie można się zastanowić, co trzeba zrobić, aby obsługiwać prerenderowanie.
Aktualizowanie spekulacji prerenderowania
Wstępne renderowanie stron przed nawigacją wiąże się z ryzykiem, że wstępnie renderowana strona stanie się nieaktualna. Na przykład w witrynie e-commerce strona z renderowaniem wstępnym może zawierać koszyk na etapie płatności – może to być pełny koszyk z produktami lub tylko licznik pokazujący liczbę produktów w koszyku na innych stronach. Jeśli do koszyka zostanie dodanych więcej produktów, a następnie użytkownik przejdzie na stronę z wyrenderowanymi elementami, może się pogubić, gdy zobaczy stary stan płatności.
To nie jest nowy problem. Gdy użytkownicy mają otwarte w przeglądarce wiele kart, występuje ten sam problem. W przypadku stron z renderowaniem wstępnym jest to jednak bardziej prawdopodobne i nieoczekiwane, ponieważ użytkownik nie wiedział, że renderowanie wstępne zostało uruchomione.
Interfejs Broadcast Channel API to jeden ze sposobów na to, aby jedna strona w przeglądarce mogła przekazywać takie informacje innym stronom. Rozwiązałoby to też problem z wieloma kartami. Strony z zarenderowanymi stronami mogą odsłuchiwać wiadomości, ale nie mogą wysyłać własnych wiadomości, dopóki nie zostaną aktywowane.
Alternatywnie, strony wyrenderowane wstępnie mogą być aktualizowane przez serwer (za pomocą okresowego połączenia fetch() lub połączenia WebSocket), ale z potencjalnym opóźnieniem.
Anulowanie lub odświeżanie spekulacji prerenderowania
Aktualizowanie wstępnie renderowanych stron jest zalecanym sposobem na dalsze korzystanie z tych stron przy jednoczesnym unikaniu wprowadzania użytkowników w błąd. Jeśli nie jest to możliwe, możesz anulować spekulacje.
Może to być też wykorzystywane do zachowania limitów Chrome, jeśli witryny chcą wstępnie renderować inne strony, które są bardziej prawdopodobne do odwiedzenia.
Aby anulować spekulacje, musisz usunąć reguły spekulacyjne ze strony lub usunąć klasy lub inne kryteria dopasowywania, jeśli korzystasz z tego rozwiązania. Może też wywołać funkcję window.close(), jeśli wykryje, że nie jest już aktualna. Jeśli jednak strona jest w stanie wykryć ten problem, lepszym rozwiązaniem będzie zaktualizowanie jej stanu.
Można też ponownie wstawić te reguły (lub kryteria dopasowania), aby strony mogły zostać ponownie wyrenderowane (chociaż w tym przypadku również lepszym rozwiązaniem jest zwykle utrzymywanie aktualności istniejącej strony, ponieważ pozwala to uniknąć marnotrażenia zasobów). Po usunięciu reguł spekulacji ponowne wstawienie musi zostać wykonane w ramach nowego mikrozadania lub później, aby przeglądarka mogła zauważyć usunięcia i anulować spekulacje. Poniżej przedstawiamy jeden ze sposobów usuwania wszystkich skryptów reguł spekulacyjnych:
async function refreshSpeculations() {
const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');
for (const speculationScript of speculationScripts) {
// Get the current rules as JSON text
const ruleSet = speculationScript.textContent;
// Remove the existing script to reset prerendering
speculationScript.remove();
// Await for a microtask before re-inserting.
await Promise.resolve();
// Reinsert rule in a new speculation rules script
const newScript = document.createElement('script');
newScript.type = 'speculationrules';
newScript.textContent = ruleSet;
console.log(newScript);
// Append the new script back to the document
document.body.appendChild(newScript);
}
}
Usunięcie reguł spowoduje anulowanie istniejących pretendentów (lub wstępnego pobierania), ale ponowne wstawienie reguł będzie spekulować tylko reguły natychmiastowe lub szybkie (w tym reguły listy adresów URL, które używają domyślnej reguły natychmiastowej). Jednak spekulacje o umiarkowanym lub ostrożnym zainteresowaniu zostaną usunięte, ale nie zostaną automatycznie ponownie wywołane, dopóki nie nastąpi ponowna interakcja z linkiem.
Ta opcja odświeżania nie jest ograniczona do reguł wstawianych za pomocą kodu JavaScript. Reguły statyczne zawarte w pliku HTML można też usuwać lub zmieniać w taki sam sposób, ponieważ jest to standardowa zmiana DOM. Reguł spekulacji HTTP nie można usunąć, ale kryteria dopasowywania (np. klasy prerender) można usunąć i ponownie dodać za pomocą kodu JavaScript.
Chrome rozważa też dodanie obsługi nagłówka Clear-Site-Header, aby odpowiedzi serwera mogły anulować prerenderowanie (na przykład, gdy zostanie wysłane żądanie aktualizacji koszyka).
Pomiar wpływu
Po wdrożeniu reguł spekulacji należy zmierzyć skuteczność, a nie zakładać, że jest ona automatycznie szybsza. Jak już wspomnieliśmy, nadmierne spekulowanie może spowodować pogorszenie wydajności, jeśli klient lub serwer są przeciążone.
W przypadku wdrażania z wieloma krokami (pobieranie w poprzednim planie, wstępne renderowanie z małym ryzykiem, a potem wczesne wstępne renderowanie) należy mierzyć każdy krok.
Jak mierzyć skuteczność
Reguły spekulacji powinny mieć pozytywny wpływ na kluczowe dane dotyczące skuteczności, takie jak LCP (a być może także CLS i INP), ale mogą nie być widoczne w ogólnych danych na poziomie witryny. Dzieje się tak, ponieważ witryny mogą składać się głównie z innych typów nawigacji (np. stron docelowych) lub dlatego, że nawigacja w ramach tego samego źródła jest już na tyle szybka, że nawet znaczna poprawa jej wydajności może nie wpłynąć na dane w 75. percentylu podawane w Raporcie na temat użytkowania Chrome (CrUX).
Możesz użyć typów nawigacji w CrUX, aby sprawdzić, jaki odsetek nawigacji to navigate_cache lub prerender oraz czy ta liczba rośnie z czasem. Jednak do szczegółowej analizy może być konieczne użycie Monitorowania użytkowników rzeczywistych, aby podzielić dane na grupy według przewidywanej nawigacji i sprawdzić, o ile szybsze są one od innych nawigacji.
Jak mierzyć wykorzystanie i straty
Kolejną ważną kwestią jest sprawdzenie, czy spekulujesz na odpowiednich stronach. Pozwala to uniknąć marnotracenia zasobów i zapewnia, że kierujesz reklamy na najlepsze strony, aby czerpać korzyści z tego interfejsu API.
Strona inicjująca spekulacje nie może bezpośrednio sprawdzić stanu prób spekulacji. Nie można też zakładać, że próby zostały wywołane, ponieważ przeglądarka może w pewnych okolicznościach wstrzymać się od spekulacji. Dlatego należy je mierzyć na stronie. Wymaga to też sprawdzenia 2 interfejsów API, aby sprawdzić, czy strona zawiera spekulacje lub zawierała je w przeszłości:
if (document.prerendering) {
console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
console.log("Page has already prerendered");
} else {
console.log("This page load was not using prerendering");
}
Ta strona może następnie zarejestrować próbę spekulacji na serwerach backendu.
Jednym z problemów związanych z statystykami są dostawcy (np. Google Analytics), którzy obsługują renderowanie wstępne i ignorują wywołania usług analitycznych, dopóki strona nie zostanie aktywowana (nawet wywołania zdarzeń). Dlatego użytkownicy Google Analytics muszą użyć innej opcji rejestrowania po stronie serwera.
Jest to też możliwe po stronie klienta, gdzie każda strona z renderowaniem wstępnym rejestruje renderowanie wstępne w pamięci współdzielonej, a strona wywołująca odczytuje te dane. localStorage sprawdza się najlepiej, ponieważ można go odczytać po opuszczeniu strony (uwaga: nie można używać sessionStorage, ponieważ ma on specjalne przetwarzanie w przypadku stron z wyrenderowaniem wstępnym). Pamiętaj jednak, że localStorage nie jest bezpieczne pod względem transakcji, a jeśli wiele stron jest renderowanych w tym samym czasie, inne strony mogą być aktualizowane w tym samym czasie. Ten demo używa unikalnego hasha i indywidualnych wpisów, aby uniknąć problemów.
Podsumowanie
Reguły spekulacji mogą znacznie zwiększyć skuteczność strony. W tym przewodniku znajdziesz porady dotyczące wdrażania tego interfejsu API, które pomogą Ci uniknąć potencjalnych problemów i najlepiej wykorzystać jego możliwości.
Planowanie wdrożenia z wyprzedzeniem pozwoli uniknąć konieczności ponownego wykonania pracy. W przypadku bardziej złożonych witryn należy wdrożyć tę funkcję w wielu krokach, zaczynając od wstępnego pobierania, a potem przechodząc do wstępnego renderowania o niskim ryzyku, a następnie wczesnego wstępnego renderowania. Na koniec warto zmierzyć efekty ulepszeń oraz ich wykorzystanie i straty, aby mieć pewność, że korzystasz z interfejsu API w optymalny sposób.