Ulepszenia interfejsu Speculation Rules API

Barry Pollard

Zespół Chrome pracuje nad ciekawymi aktualizacjami interfejsu Speculation Rules API, które mają na celu poprawę wydajności nawigacji przez pobieranie z wyprzedzeniem, a nawet renderowanie z wyprzedzeniem przyszłych elementów nawigacyjnych. Wszystkie te dodatkowe ulepszenia są obecnie dostępne w Chrome 122 (niektóre funkcje są dostępne w wcześniejszych wersjach).

Te zmiany znacznie upraszczają wdrażanie stron i ułatwiają im renderowanie z wyprzedzeniem stron. Mamy nadzieję, że przyczyni się to do dalszego ich stosowania.

Dodatkowe funkcje

Na początek objaśnimy nowe elementy dodane do interfejsu Speculation Rules API i wyjaśnimy, jak z nich korzystać. Następnie zaprezentujemy prezentację, która pozwoli Ci zobaczyć, jak działają.

Reguły dotyczące dokumentu

Wcześniej interfejs API reguł spekulacyjnych mógł działać, określając listę adresów URL do pobrania z wyprzedzeniem lub 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 dodać nowe skrypty reguł spekulacyjnych i usunąć stare skrypty w celu ich odrzucenia (zwróć uwagę, że aktualizacja listy urls istniejącego skryptu reguł spekulacyjnych nie powoduje zmiany w spekulacjach). Wybór adresów URL pozostawał jednak witrynie, wysyłając je z serwera w momencie żądania strony lub dynamicznie tworząc listę za pomocą kodu JavaScript po stronie klienta.

Reguły listy pozostają opcją dla prostszych przypadków użycia (gdy kolejna nawigacja pochodzi z niewielkiego zestawu oczywistych) lub bardziej zaawansowanych (gdzie lista adresów URL jest dynamicznie obliczana na podstawie heurystyki, której chce użyć właściciel witryny, a następnie wstawiana na stronie).

Zamiast tego oferujemy nową opcję automatycznego znajdowania linków za pomocą reguł dokumentów. Działa to dzięki pozyskaniu adresów URL z samego dokumentu na podstawie warunku where. Może to wynikać z samych linków:

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

Uwaga: poprzednia wersja reguł dotyczących dokumentów – dostępna w okresie testowania origin – miała bardziej złożoną href_matches, która wymagała dodatkowej składni w celu dopasowania parametrów i fragmentów adresów URL ({"href_matches": "/*\\?*#*"}). W wersji tej funkcji uprościliśmy tę funkcję.

Selektorów CSS można też używać jako alternatywnych dopasowań lub w połączeniu z dopasowaniem href, aby znaleźć linki 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 można używać jednego zestawu reguł spekulacyjnych w całej witrynie zamiast stosowania określonych reguł na stronie, co znacznie ułatwia witrynom wdrażanie reguł spekulacyjnych.

Oczywiście wstępne renderowanie wszystkich linków na stronie byłoby bezcelowe, dlatego wprowadziliśmy ustawienie eagerness.

Zachęcenie

W przypadku każdej spekulacji należy znaleźć kompromis między precyzją i czułością a czasem realizacji. Wstępne renderowanie wszystkich linków podczas wczytywania strony oznacza, że prawie na pewno wstępnie wyrenderujesz link, który kliknie użytkownik (zakładając, że kliknie on link do tej samej witryny na stronie). Długi czas oczekiwania na odpowiedź jest jednak potencjalnie ogromny i większe wykorzystanie przepustowości.

Z drugiej strony renderowanie wstępne dopiero po kliknięciu linku przez użytkownika zapobiega marnowaniu zasobów, ale wiąże się z znacznym skróceniem czasu realizacji. Oznacza to, że renderowanie wstępne prawdopodobnie nie zakończy się, zanim przeglądarka przełączy się na tę stronę.

Ustawienie eagerness pozwala określić, kiedy mają być uruchamiane spekulacje, określając, kiedy mogą być używane do spekulowania, na podstawie których adresów URL przeprowadzać spekulacje. Ustawienie eagerness jest dostępne w przypadku reguł źródłowych list i document i ma 4 ustawienia, z których korzystają następujące właściwości heurystyczne:

• immediate: umożliwia jak najszybsze spekulowanie, czyli z chwilą zastosowania reguł spekulacyjnych.
• eager: obecnie działa to tak samo jak ustawienie immediate, ale w przyszłości chcemy umieścić to ustawienie w przedziale od immediate do moderate.
• moderate: pozwala przeprowadzać spekulacje, jeśli najedziesz kursorem na link przez 200 milisekund (lub po zdarzeniu pointerdown, jeśli nastąpi to wcześniej, oraz na urządzeniach mobilnych, gdzie nie ma zdarzenia hover).
• conservative: spekuluje na podstawie wskaźnika lub przyłożenia.

Domyślna wartość eagerness w przypadku reguł list 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 interakcje, do konkretnej listy. W wielu przypadkach bardziej odpowiednie mogą być reguły document z odpowiednim warunkiem where.

Domyślna wartość eagerness w przypadku reguł document to conservative. Dokument może składać się z wielu adresów URL, dlatego należy zachować ostrożność podczas korzystania z reguły document lub immediate (zapoznaj się też z sekcją Limity Chrome).eager

Wybór ustawienia eagerness zależy od witryny. W przypadku bardzo prostej witryny statycznej takie spekulacje mogą być mało kosztowne i korzystne dla użytkowników. Witryny o bardziej złożonych architekturach i większych ładunkach stron mogą preferować redukcję ilości odpadów, spekulując rzadziej, dopóki nie uzyskasz bardziej pozytywnego sygnału dotyczącego ograniczenia ilości odpadów.

Uwaga: nadmierna spekulacja wiąże się z wyraźnymi kosztami nie tylko w przypadku kosztów przepustowości, pamięci i procesora, ale również samych witryn. Rozważanie wpływu spekulacji na użytkowników. Ustawienia eagerness pozwalają zmniejszyć prawdopodobieństwo niepotrzebnych spekulacji. Chrome nakłada też ograniczenia na spekulacje, aby zmniejszyć wpływ nadużyć.

Opcja moderate stanowi środek pośredni, a wiele witryn mogłoby skorzystać na zastosowaniu tej prostej reguły spekulacyjnej, która wstępnie wyrenderowałaby wszystkie linki po najechaniu kursorem lub kursorem w dół jako podstawową, a jednocześnie skuteczną – implementację reguł spekulacyjnych:

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

Limity dotyczące Chrome

Nawet jeśli wybierzesz eagerness, w Chrome obowiązują pewne ograniczenia, które mają zapobiegać nadużywaniu tego interfejsu API:

eagerness	Pobieranie z wyprzedzeniem	Wstępne renderowanie
immediate / eager	50	10
moderate / conservative	2 (FIFO)	2 (FIFO)

Limity spekulacji w Chrome

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

Fakt, że spekulacje moderate i conservative są wywoływane przez użytkowników, pozwala nam użyć bardziej skromnego progu wynoszącego 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 są potrzebne i kiedy są potrzebne.

Spekulacja, która jest anulowana przez wypchnięcie z kolejki FIFO, może zostać aktywowana ponownie, na przykład przez ponowne najechanie kursorem na link. Spowoduje to ponowne spekulowanie adresu URL. W tym przypadku poprzednia spekulacja prawdopodobnie spowodowała, że przeglądarka zapisała w pamięci podręcznej HTTP niektóre zasoby dla tego adresu URL, więc powtarzanie spekulacji powinno znacznie ograniczyć koszty sieciowe, a tym samym zmniejszyć koszty czasowe.

Limity immediate i eager również są dynamiczne. Usunięcie elementu skryptu reguł spekulacyjnych z użyciem tych poziomów zainteresowania stworzy możliwości przez anulowanie usuniętych spekulacji. Te adresy URL mogą zostać ponownie spekulowane, jeśli zostaną uwzględnione w nowym skrypcie adresu URL, a limit nie został osiągnięty.

Chrome uniemożliwi też używanie spekulacji w określonych warunkach, takich jak:

• Zapisz dane.
• Oszczędzanie energii.
• Ograniczenia pamięci.
• Gdy ustawienie „Wstępnie wczytuj strony” jest wyłączone (jest ono też jawnie wyłączone przez rozszerzenia do Chrome, takie jak uBlock Origin).
• Strony otwarte na kartach w tle.

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

Opcjonalny source

W Chrome 122 klucz source jest opcjonalny, ponieważ można go określić na podstawie obecności kluczy url lub where. Te dwie 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żesz też dostarczać za pomocą nagłówka HTTP Speculation-Rules, zamiast umieszczać je bezpośrednio w kodzie HTML dokumentu. Ułatwia to wdrażanie przez sieci CDN bez konieczności zmieniania zawartości dokumentów.

Nagłówek HTTP Speculation-Rules jest zwracany wraz z dokumentem i wskazuje lokalizację pliku JSON zawierającego reguły spekulacyjne:

Speculation-Rules: "/speculationrules.json"

Uwaga: cudzysłów jest ważny, ponieważ trzeba je umieścić w nagłówku, bo jest to nagłówek strukturalny.

Ten zasób musi używać prawidłowego typu MIME i, jeśli jest zasobem 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 spekulacyjnymi. Może to być szczególnie przydatne, gdy musisz wybrać niektóre lub wszystkie linki z tej samej domeny.

Lepsze ponowne używanie pamięci podręcznej

Wprowadziliśmy wiele ulepszeń w pamięci podręcznej w Chrome, aby pobieranie z wyprzedzeniem (lub nawet renderowanie wstępne) dokumentu powodowało zapisywanie i wykorzystywanie zasobów w pamięci podręcznej HTTP. Oznacza to, że spekulacje mogą przynosić korzyści w przyszłości, nawet jeśli nie zostaną one użyte.

Pozwala to też znacznie obniżyć koszty ponownej spekulacji (na przykład w przypadku reguł dotyczących dokumentów z ustawieniem stopnia zainteresowania moderate), ponieważ Chrome będzie używać pamięci podręcznej HTTP do obsługi zasobów zapisywanych w pamięci podręcznej.

Obsługujemy też nową ofertę No-Vary-Search, która ma na celu dalsze ulepszenie ponownego wykorzystywania pamięci podręcznej.

No-Vary-Search – pomoc

Podczas pobierania z wyprzedzeniem lub wstępnego renderowania strony niektóre parametry adresu URL (nazywane parametrami wyszukiwania) mogą nie mieć znaczenia dla strony rzeczywiście wyświetlanej przez serwer. Są one używane wyłącznie przez 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ą przesyłać tę samą stronę z serwera, więc tej samej strony będzie można ponownie użyć z pamięci podręcznej.

Podobnie aplikacje mogą używać innych parametrów adresu URL obsługiwanych tylko po stronie klienta.

Pakiet No-Vary-Search umożliwia serwerowi określenie parametrów, które nie różnią się od dostarczonych zasobów. Dzięki temu przeglądarka może ponownie wykorzystać wersje dokumentu przechowywane 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) w przypadku spekulacji dotyczących nawigacji z wyprzedzeniem.

Reguły spekulacyjne obsługują używanie parametru expects_no_vary_search do wskazywania miejsca, w którym ma być zwracany nagłówek HTTP No-Vary-Search. W ten sposób możesz 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 w przypadku identyfikatorów produktów 123 i 124. Jednak zawartość stron różni się ostatecznie w zależności od renderowania po stronie klienta przy użyciu JavaScriptu do pobierania danych produktów za pomocą parametru wyszukiwania id. Z wyprzedzeniem pobieramy więc 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 linków przed zakończeniem pobierania z wyprzedzeniem, przeglądarka może nie otrzymać strony /products. W takim przypadku przeglądarka nie wie, czy będzie zawierać nagłówek HTTP No-Vary-Search. Przeglądarka może zdecydować, czy pobrać link ponownie, czy też poczekać na zakończenie pobierania z wyprzedzeniem, aby sprawdzić, czy link 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 tego pobierania z wyprzedzeniem.

Wersja demonstracyjna

Na stronie https://speculative-rules.glitch.me/common-fruits.html przygotowaliśmy wersję demonstracyjną, aby zobaczyć w praktyce reguły dokumentu z ustawieniem zaangażowania w wysokości moderate:

Wersja demonstracyjna reguł spekulacyjnych

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

Gdy najedziesz kursorem na owoce, zobaczysz wstępne renderowanie stron. Po ich kliknięciu wyświetli się znacznie krótszy czas LCP niż w przypadku jednego z przepisów, które nie są wstępnie renderowane. Ta wersja demonstracyjna została również omówiona w tym filmie:

Więcej informacji o debugowaniu reguł spekulacyjnych za pomocą Narzędzi deweloperskich znajdziesz w poprzednim poście na blogu na temat debugowania reguł spekulacyjnych.

Obsługa reguł spekulacyjnych na platformie

Chociaż reguły spekulacyjne można wdrożyć stosunkowo łatwo przez wstawienie ich do elementu <script type="speculationrules">, obsługa platformy sprawia, że można to zrobić jednym kliknięciem. Współpracujemy z różnymi platformami i partnerami, aby ułatwić wdrożenie reguł spekulacyjnych.

Intensywnie pracujemy też nad ujednoliceniem tego interfejsu API w ramach grupy WICG (Web Incubator Community Group), by umożliwić innym przeglądarkom również wdrożenie tego przydatnego interfejsu.

WordPress

Zespół WordPress Core Performance (w tym deweloperzy z Google) stworzył wtyczkę reguł spekulacyjnych. Umożliwia ona łatwe dodawanie jednym kliknięciem reguł dokumentów do dowolnej witryny wykorzystującej WordPressa. Tę wtyczkę można też zainstalować za pomocą wtyczki WordPress Performance Lab. Warto ją zainstalować, aby otrzymywać najnowsze informacje o wtyczkach tego zespołu.

Dostępne są 2 grupy ustawień: Tryb spekulacyjny i Zainteresowanie:

Wtyczka WordPress Speculation Rules

Informacje o bardziej złożonych konfiguracjach, na przykład o wykluczaniu określonych adresów URL z pobierania lub renderowania z wyprzedzeniem, znajdziesz w dokumentacji.

Akamaí

Akamai to jeden z wiodących dostawców CDN na świecie, który od jakiegoś czasu aktywnie eksperymentuje z interfejsem Speculation Rules API. Firma Akamai opublikowała dokumentację, która opisuje, jak klienci mogą włączyć ten interfejs API w swoich ustawieniach CDN. Firma udostępniała też wcześniej imponujące wyniki, jakie zapewnia nowy interfejs API.

NitroPack

NitroPack to rozwiązanie optymalizujące wydajność, które wykorzystuje własną technologię Navigation AI do przewidywania, które strony należy dodać do reguł spekulacyjnych. Ma to na celu skrócenie czasu realizacji niż najechanie kursorem na link, a jednocześnie unikanie zbędnych spekulacji na temat wszystkich obserwowanych linków. Więcej informacji znajdziesz w dokumentacji interfejsu Nitropack Speculation Rules API. To innowacyjne rozwiązanie pokazało, że w połączeniu z informacjami o konkretnych witrynach nadal można wykorzystać wiele starszych reguł dotyczących list.

Zespół Chrome współpracował też z firmą NitroPack przy tworzeniu webinaru na temat interfejsu Speculation Rules API w przypadku osób, które szukają więcej informacji, w tym m.in. o tym, co należy wziąć pod uwagę między wczesnym i częstym spekulowaniem, a także późnym i rzadszym.

Astro

W ramach eksperymentu Astro dodało wstępne renderowanie stron z wykorzystaniem interfejsu Speculation Rules API w wersji 4.2, umożliwiając deweloperom korzystającym z Astro łatwe włączanie tej funkcji, a jednocześnie powracało do standardowego pobierania z wyprzedzeniem w przeglądarkach, które nie obsługują interfejsu Speculation Rules API. Więcej informacji znajdziesz w dokumentacji dotyczącej wstępnego renderowania w kliencie.

Podsumowanie

Te dodatki do interfejsu spekulacyjnego interfejsu API znacznie ułatwiają korzystanie z tej fantastycznej nowej funkcji w witrynach, która zmniejsza ryzyko zmarnowania zasobów na nieużywane spekulacje. Widzę, że platformy już wykorzystują ten interfejs API. Mamy nadzieję, że w 2024 r. ten interfejs API zostanie powszechnie akceptowany, a w rezultacie zapewnimy większą wydajność użytkownikom.

Interfejs API reguł spekulacyjnych zwiększa skuteczność i zapewnia nowe możliwości. Wyświetlanie przejść to nowy interfejs API, który umożliwia deweloperom łatwiejsze określanie przejść między opcjami nawigacji. Ta funkcja jest obecnie dostępna w aplikacjach jednostronicowych (SPA), ale pracujemy nad jej wersją wielostronicową (która jest oznaczona flagą w Chrome). Renderowanie wstępne to naturalny dodatek do tej funkcji, który eliminuje opóźnienia, które w przeciwnym razie uniemożliwiłyby zwiększenie wygody użytkowników podczas przenoszenia. Zauważyliśmy już, że witryny eksperymentują z tą kombinacją.

W 2024 roku zamierzamy nadal korzystać z interfejsu Speculation Rules API. Będziemy Cię informować o kolejnych ulepszeniach tego interfejsu.

Podziękowania

Miniatura autorstwa Robbie Down w programie Unsplash