Ulepszenia interfejsu Speculation Rules API

Barry Pollard

Zespół Chrome pracuje nad ciekawymi aktualizacjami interfejsu Speculation Rules API, które mają poprawić wydajność nawigacji przez pobieranie z wyprzedzeniem, a nawet wstępne renderowanie przyszłych elementów nawigacyjnych. Te dodatkowe ulepszenia są teraz dostępne w Chrome 122 (niektóre funkcje były dostępne we wcześniejszych wersjach).

Dzięki tym zmianom wdrażanie z wyprzedzeniem i wstępnym renderowaniem stron jest znacznie łatwiejsze i ogranicza marnowanie zasobów, co mamy nadzieję zachęcić do dalszego stosowania.

Dodatkowe funkcje

Na początek wyjaśnimy, co dodaliśmy do interfejsu Speculation Rules API i jak z nich korzystać. Następnie udostępnimy Ci prezentację, aby zobaczyć je w praktyce.

Reguły dokumentu

Wcześniej interfejs Speculation Rules API umożliwiał określanie listy adresów URL do pobrania z wyprzedzeniem lub do renderowania z wyprzedzeniem:

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

Reguły spekulacyjne były półdynamiczne, ponieważ można było dodawać nowe skrypty reguł spekulacyjnych, a starsze skrypty zostały usunięte w celu ich odrzucenia (uwaga: aktualizacja listy urls istniejącego skryptu reguł spekulacyjnych nie wywołuje zmiany w spekulacjach). Z kolei wybór adresów URL pozostawał witrynie – wysyłaj je z serwera w momencie żądania strony lub dynamicznie tworząc tę listę za pomocą JavaScriptu po stronie klienta.

Reguły listy pozostają opcją w przypadkach prostszych zastosowań (gdy następna nawigacja pochodzi z niewielkiego zbioru oczywistych reguł) lub bardziej zaawansowanych (gdzie lista adresów URL jest obliczana dynamicznie na podstawie heurystyki wybranej przez właściciela witryny, a następnie umieszczana na stronie).

W zamian możemy zaoferować nową opcję automatycznego wyszukiwania linków na podstawie reguł dokumentów. Pozyskiwanie adresów URL odbywa się z poziomu dokumentu na podstawie warunku where. Może to być możliwe na podstawie samych linków:

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

Selektorów arkusza CSS można też użyć alternatywnej lub w połączeniu z dopasowaniami href w celu znalezienia linków na bieżącej stronie:

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "and": [
        { "selector_matches": ".prerender" },
        { "not": {"selector_matches": ".do-not-prerender"}}
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

Dzięki temu jeden zestaw reguł spekulacyjnych można stosować w całej witrynie, zamiast stosować konkretne reguły na stronie. Bardzo ułatwia to wdrażanie reguł spekulacyjnych.

Oczywiście wstępne renderowanie wszystkich linków na stronie byłoby zdecydowanie niepotrzebne, więc dzięki tej nowej możliwości wprowadziliśmy ustawienie eagerness.

Chęć

W przypadku każdej spekulacji istnieje kompromis między precyzją i czułością a czasem realizacji. Wstępne renderowanie wszystkich linków podczas wczytywania strony oznacza, że niemal na pewno wstępnie wyrenderujesz link, który kliknie użytkownik (zakładając, że kliknie on link do tej samej strony na stronie) i będzie jak najdłużej szybciej pozostawiać tę stronę, ale może to wiązać się z potencjalnie dużym stratem przepustowości.

Z drugiej strony renderowanie wstępne tylko wtedy, gdy użytkownik kliknie link, zapobiega zmarnowaniu zasobów, ale znacznie krótszy czas realizacji. Oznacza to, że jest mało prawdopodobne, że renderowanie wstępne zostanie ukończone, zanim przeglądarka przełączy się na tę stronę.

Ustawienie eagerness pozwala określić, kiedy mają być uruchamiane spekulacje, oddzielając czas na spekulowanie, z których adresów URL chcesz przeprowadzać spekulacje. Ustawienie eagerness jest dostępne zarówno w przypadku reguł źródłowych list, jak i document. Ma 4 ustawienia, dla których Chrome stosuje te reguły heurystyczne:

• immediate: służy do spekulacji najszybciej, jak to możliwe, czyli gdy tylko zostaną zastosowane reguły spekulacyjne.
• eager: obecnie działa to identycznie jak ustawienie immediate, ale w przyszłości planujemy umieścić je gdzieś pomiędzy immediate a moderate.
• moderate: powoduje to spekulacje, jeśli najedziesz kursorem na link przez 200 milisekund (lub po najechaniu na zdarzenie pointerdown, jeśli nastąpi to wcześniej, oraz 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 bardzo prostej witryny statycznej bardziej świadome spekulacje mogą mieć niewielkie koszty i przynosić korzyści użytkownikom. 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 punkt pośredni, dlatego w przypadku wielu witryn ta prosta reguła spekulacyjna mogłaby spowodować wstępne renderowanie wszystkich linków po najechaniu kursorem na reklamę lub w kierunku kursorem w celu podstawowej, a zarazem skutecznej implementacji reguł spekulacyjnych:

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

Limity w Chrome

Nawet jeśli wybierzesz eagerness, w Chrome obowiązują pewne limity, które zapobiegają nadużywaniu tego interfejsu API:

Ustawienia moderate i conservative, które zależą od interakcji użytkownika, działają w sposób pierwszeństwa, pierwszego wyjścia (FIFO). Po osiągnięciu limitu nowa spekulacja spowoduje anulowanie najstarszej spekulacji i zastąpienie jej nową, aby oszczędzać pamięć.

Fakt, że spekulacje dotyczące parametrów moderate i conservative są wywoływane przez użytkowników, pozwala nam zastosować bardziej skromny próg równy 2, aby oszczędzać pamięć. Ustawienia immediate i eager 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.

Spekulacja, która została anulowana przez wypchnięcie z kolejki FIFO, może zostać wywołana ponownie (np. przez ponowne najechanie kursorem na link), co spowoduje ponowne spekulowanie tego adresu URL. W takim przypadku poprzednie spekulacje prawdopodobnie spowodują, że przeglądarka buforuje niektóre zasoby dla tego adresu URL w pamięci podręcznej HTTP, więc powtórzenie spekulacji powinno znacznie ograniczyć koszty sieci, a co za tym idzie – mniej czasu.

Limity immediate i eager też są dynamiczne. Usunięcie elementu skryptu reguł spekulacyjnych za pomocą tych poziomów niecierpliwości spowoduje utworzenie możliwości przez anulowanie tych usuniętych spekulacji. Te adresy URL mogą też być ponownie spekulowane, jeśli zostały uwzględnione w nowym skrypcie adresu URL, a limit nie został osiągnięty.

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

• Zapisz dane.
• Oszczędzanie energii
• 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.

Wszystkie te warunki mają na celu zmniejszenie wpływu nadmiernej spekulacji na szkodę użytkowników.

Opcjonalny source

W Chrome 122 klucz source jest opcjonalny, ponieważ można to wywnioskować na podstawie obecności kluczy url lub where. Te 2 reguły spekulacyjne są więc identyczne:

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

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

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 dla adresu URL pliku JSON reguł spekulacyjnych. Może to być szczególnie przydatne, gdy chcesz wybrać niektóre lub wszystkie linki tego samego źródła.

Lepsze ponowne wykorzystanie pamięci podręcznej

Wprowadziliśmy wiele ulepszeń dotyczących buforowania w Chrome, dzięki czemu podczas wstępnego wczytywania (a nawet renderowania) dokumentu będą przechowywane i wykorzystywane ponownie zasoby w pamięci podręcznej HTTP. Oznacza to, że spekulacje mogą przynosić korzyści w przyszłości, nawet jeśli nie korzystasz z tej spekulacji.

Dzięki temu ponowne spekulacje (na przykład w przypadku reguł z ustawieniem gotowości moderate) są znacznie tańsze, ponieważ Chrome będzie używać pamięci podręcznej HTTP na potrzeby zasobów, które można zapisać w pamięci podręcznej.

Popieramy również nową propozycję No-Vary-Search, aby jeszcze bardziej usprawnić ponowne korzystanie z pamięci podręcznej.

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óżnicę w wyświetlanym zasobie, a tym samym pozwalają przeglądarce na ponowne korzystanie z wersji dokumentu zapisanej wcześniej w pamięci podręcznej, które różnią się tylko tymi parametrami. Uwaga: obecnie ta funkcja jest obsługiwana tylko w Chrome (i przeglądarkach opartych na Chromium) na potrzeby spekulacji dotyczących nawigacji pobierania 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.

Prezentacja

Opublikowaliśmy wersję demonstracyjną na stronie https://speculative-rules.glitch.me/common-fruits.html, w której można zobaczyć reguły dotyczące dokumentów z ustawieniem gotowości moderate w praktyce:

Otwórz Narzędzia deweloperskie i kliknij panel Aplikacja. Następnie w sekcji Usługi w tle kliknij Wczytywanie spekulacyjne, panel Spekulacje i posortuj dane według kolumny Stan.

Gdy najedziesz kursorem na owoce, zobaczysz wstępnie renderowane strony. Kliknięcie ich spowoduje wyświetlenie dużo szybszego LCP niż w przypadku przepisu, który nie jest wstępnie renderowany. Sposób działania trybu demonstracyjnego można też znaleźć w tym filmie:

Aby dowiedzieć się więcej o używaniu Narzędzi deweloperskich do debugowania reguł spekulacyjnych, możesz też przeczytać poprzedni post na blogu dotyczący reguł spekulacyjnych debugowania.

Obsługa reguł spekulacyjnych na platformie

Chociaż reguły spekulacyjne można stosunkowo łatwo wdrożyć przez wstawienie ich do elementu <script type="speculationrules">, obsługa platformy umożliwia obsługę 1 kliknięciem. Współpracujemy z różnymi platformami i partnerami, aby ułatwić wdrażanie reguł spekulacyjnych.

Pracujemy również nad ujednoliceniem interfejsu API przy użyciu Web Incubator Community Group (WICG), aby w razie potrzeby inne przeglądarki mogły też wdrożyć ten interfejs.

WordPress

Zespół WordPress Core Performance (w tym deweloperzy z Google) stworzył wtyczkę reguł spekulacyjnych. Ta wtyczka umożliwia proste dodawanie obsługi reguł dokumentów do dowolnej witryny WordPress jednym kliknięciem. Wtyczka jest również dostępna do zainstalowania przy użyciu wtyczki WordPress Performance Lab. Warto ją zainstalować, aby otrzymywać od zespołu aktualne informacje o odpowiednich wtyczkach zwiększających wydajność.

Dostępne są 2 grupy ustawień: Tryb spekulacji i Zaangażowanie:

Jeśli chcesz dowiedzieć się więcej o bardziej złożonych konfiguracjach, na przykład aby wykluczyć niektóre adresy URL z wstępnego pobierania lub renderowania, zapoznaj się z dokumentacją.

Akamai

Akamai to jeden z wiodących dostawców CDN na świecie, który już od jakiegoś czasu aktywnie eksperymentuje z interfejsem Speculation Rules API. Firma Akamai opublikowała dokumentację informującą, jak klienci mogą włączyć ten interfejs API w swoich ustawieniach CDN. Wcześniej podzielili się też imponującymi wynikami, jakie zapewnia ten nowy interfejs API.

NitroPack

NitroPack to rozwiązanie do optymalizacji wydajności, które wykorzystuje własne rozwiązanie Navigation AI do przewidywania, które strony dodać do reguł spekulacyjnych. W ten sposób można wydłużyć czas wprowadzania danych niż najechanie kursorem na link, ale nie marnuje się niepotrzebnie spekulacji na temat wszystkich obserwowanych linków. Więcej informacji znajdziesz w dokumentacji interfejsu API reguł spekulacyjnych Nitropack (w języku angielskim). To innowacyjne rozwiązanie pokazuje, że w połączeniu ze statystykami dotyczącymi konkretnych witryn jest jeszcze wiele do zaoferowania starsze reguły list.

Zespół Chrome współpracował też z NitroPack przy tworzeniu webinaru dotyczącego interfejsu Speculation Rules API dla osób poszukujących dodatkowych informacji, w tym ciekawej dyskusji na temat tego, co należy wziąć pod uwagę podczas spekulacji wczesnej i częstotliwej, spóźnionej i rzadszej.

Astro

W wersji 4.2 firma Astro dodała w wersji eksperymentalnej wstępne renderowanie stron za pomocą interfejsu Speculation Rules API, co pozwoliło deweloperom korzystającym z platformy Astro łatwo włączyć tę funkcję, a jednocześnie korzystać ze standardowego pobierania z wyprzedzeniem w przypadku przeglądarek, które nie obsługują interfejsu Speculation Rules API. Więcej informacji znajdziesz w jego dokumentacji wstępnego renderowania klienta.

Podsumowanie

Te nowości w interfejsie Speculation Rules API znacznie ułatwiają korzystanie z tej nowej funkcji poprawiającej wydajność witryn i zmniejszają ryzyko marnowania zasobów na podstawie nieużywanych spekulacji. Cieszymy się, że platformy już korzystają z tego interfejsu API. Mamy nadzieję, że w 2024 roku nastąpi szersze wdrożenie tego interfejsu API, co w rezultacie spowoduje wzrost wydajności dla użytkowników.

Oprócz poprawy wydajności, jaki zapewnia interfejs Speculation Rules API, chętnie poznamy też nowe możliwości, jakie daje ten interfejs. View przejśćs to nowy interfejs API, który umożliwia programistom łatwiejsze określanie przejść między elementami nawigacyjnymi. Obecnie ta funkcja jest dostępna w aplikacjach jednostronicowych (SPA), ale trwa wersja wielostronicowa (w Chrome dostępna jest flaga). Wstępne renderowanie to naturalny dodatek do tej funkcji, który zapewnia brak opóźnień, które w przeciwnym razie mogłyby poprawić wrażenia użytkowników w ramach zamierzonego przejścia. Widzieliśmy już witryny eksperymentujące z tą kombinacją.

W 2024 roku planujemy dalej korzystać z interfejsu Speculation Rules API. Będziemy na bieżąco informować o kolejnych ulepszeniach tego interfejsu.

Podziękowania

Miniatura: Robbie Down na kanale Unsplash