Ulepszenia interfejsu Speculation Rules API

Barry Pollard

Zespół Chrome pracował nad ekscytującymi aktualizacjami interfejsu Speculation Rules API, który służy do poprawy wydajności nawigacji przez wstępne pobieranie lub nawet wstępne renderowanie przyszłych elementów nawigacyjnych. Wszystkie te dodatkowe ulepszenia są teraz dostępne w Chrome 122 (niektóre funkcje są dostępne w starszych wersjach).

Dzięki tym zmianom wdrożenie i korzystanie z prefetchingu i prerenderingu stron jest znacznie łatwiejsze i mniej kosztowne, co mamy nadzieję zachęci do dalszego korzystania z tych funkcji.

Dodatkowe funkcje

Najpierw wyjaśnimy nowe funkcje, które dodaliśmy do interfejsu Speculation Rules API, i sposób ich używania. Następnie pokażemy Ci prezentację, aby pokazać, jak to działa.

Reguły dotyczące dokumentów

Wcześniej interfejs Speculation Rules API działał na podstawie listy adresów URL, które miały być pobrane lub wyrenderowane z wyprzedzeniem:

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

Reguły spekulacji były częściowo dynamiczne, ponieważ można było dodawać nowe skrypty reguł spekulacji i usuwać stare skrypty, aby odrzucić te spekulacje (pamiętaj, że zaktualizowanie listy urls w istniejącym skrypcie reguł spekulacji nie powoduje zmiany spekulacji). Nadal jednak wybór adresów URL pozostawiano stronie, wysyłając je z serwera w momencie żądania strony lub tworząc tę listę dynamicznie za pomocą kodu JavaScript po stronie klienta.

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

Jako alternatywę oferujemy nową opcję automatycznego znajdowania linków za pomocą reguł dokumentu. Ta funkcja pobiera adresy URL z dokumentu na podstawie warunku where. Może to być spowodowane samymi linkami:

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

Selektory CSS mogą być używane jako alternatywa dla dopasowań href lub w połączeniu z nimi w celu znajdowania 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 można stosować jedną regułę spekulacji w całej witrynie zamiast stosować osobne reguły na każdej stronie, co znacznie ułatwia wdrażanie reguł spekulacji.

Oczywiście wstępna renderyzacja wszystkich linków na stronie byłaby nieuzasadnionym marnotrawstwem zasobów, dlatego w ramach tej nowej funkcji wprowadziliśmy ustawienie eagerness.

Zapał

W przypadku każdego rodzaju spekulacji występuje kompromis między precyzją i czułością a czasem dostawy. Wstępne renderowanie wszystkich linków podczas wczytywania strony oznacza, że prawie na pewno wstępnie renderujesz link, który użytkownik kliknie (zakładając, że kliknie link na stronie w tej samej witrynie), i to z jak największym wyprzedzeniem, ale przy potencjalnie dużym marnotrawieniu przepustowości.

Z drugiej strony, prerenderowanie tylko po kliknięciu linku zapobiega marnotrawieniu zasobów, ale wiąże się z znacznym skróceniem czasu oczekiwania na potencjalnego klienta. Oznacza to, że przedwstępna renderyzacja prawdopodobnie nie zostanie ukończona, zanim przeglądarka przełączy się na tę stronę.

Ustawienie eagerness pozwala określić, kiedy mają być wykonywane spekulacje, oddzielając kiedy od adresów URL, dla których mają być wykonywane spekulacje. Ustawienie eagerness jest dostępne w przypadku reguł list i document dotyczących źródeł. Ma 4 ustawienia, dla których Chrome stosuje te heurystyki:

• immediate: ta opcja służy do spekulowania tak szybko, jak to możliwe, czyli tak szybko, jak przestrzegane są reguły spekulacji.
• eager: obecnie działa identycznie jak ustawienie immediate, ale w przyszłości chcemy umieścić je gdzieś pomiędzy immediate a moderate.
• moderate: ta opcja wykonuje spekulacje, gdy najedziesz kursorem na link przez 200 ms (lub w przypadku zdarzenia pointerdown, jeśli nastąpi to wcześniej, oraz na urządzeniach mobilnych, gdy nie ma zdarzenia hover).
• conservative: spekulacje dotyczące wskaźnika lub dotknięcia.

Domyślna wartość eagerness dla reguł list to immediate. Opcji moderate i conservative można używać do ograniczania stosowania reguł list do adresów URL, z którymi użytkownik wchodzi w interakcję na określonej liście. W wielu przypadkach bardziej odpowiednie mogą być jednak reguły document z odpowiednim warunkiem where.

Domyślna wartość eagerness dla reguł document to conservative. Ponieważ dokument może zawierać wiele adresów URL, należy zachować ostrożność przy stosowaniu reguł immediate lub eager w regułach document (patrz także następna sekcja Ograniczenia w Chrome).

Które ustawienie eagerness należy użyć, zależy od Twojej witryny. W przypadku bardzo prostej witryny statycznej spekulowanie może być mało kosztowne i przynosić korzyści użytkownikom. Właściciele witryn o bardziej złożonej architekturze i większym ładunku strony mogą preferować ograniczanie marnotrawstwa przez rzadsze spekulowanie, dopóki nie otrzymają od użytkowników więcej pozytywnych sygnałów o ich zamiarach, które pozwolą ograniczyć marnotrawstwo.

Opcja moderate to kompromis. Wiele witryn może skorzystać z tej prostej reguły spekulacji, która wstępnie renderuje wszystkie linki po najechaniu kursorem lub wciśnięciu przycisku. Jest to proste, ale skuteczne wdrożenie reguł spekulacji:

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

Limity Chrome

Nawet w przypadku opcji eagerness w Chrome obowiązują limity, które zapobiegają nadużywaniu tego interfejsu API:

Ustawienia moderate i conservative, które zależą od interakcji użytkownika, działają zgodnie z zasadą najpierw przyszło, najpierw wyszło (ang. first in, first out, FIFO). Po osiągnięciu limitu nowa spekulacja spowoduje anulowanie najstarszej spekulacji i jej zastąpienie 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 2 dla oszczędzania pamięci. Ustawienia immediate i eager nie są wywoływane przez działanie użytkownika, dlatego mają wyższy limit, ponieważ przeglądarka nie może wiedzieć, które ustawienia są potrzebne i kiedy.

Spekulacja, która została anulowana przez wypchnięcie z kolejki FIFO, może zostać ponownie wywołana – na przykład przez najechanie kursorem na link – co spowoduje ponowne przeprowadzenie spekulacji. W takim przypadku poprzednie przypuszczenia prawdopodobnie spowodowały, że przeglądarka zapisała w pamięci podręcznej HTTP niektóre zasoby dla tego adresu URL. Powtórzenie tych przypuszczeń powinno znacznie zmniejszyć koszty związane z siecią i czas potrzebny na wykonanie operacji.

Limity immediate i eager są też dynamiczne. Usunięcie elementu skryptu reguł spekulacji przy użyciu tych poziomów żarliwości spowoduje utworzenie pojemności przez anulowanie usuniętych spekulacji. Te adresy URL mogą też zostać ponownie zaproponowane, jeśli są uwzględnione w nowym skrypcie URL i nie został jeszcze osiągnięty limit.

Chrome będzie też zapobiegać spekulacjom w pewnych warunkach, w tym:

• Oszczędzanie danych.
• Oszczędzanie energii.
• Ograniczenia dotyczące pamięci.
• gdy wyłączone jest ustawienie „Wstępnie wczytuj strony” (które jest też wyraźnie wyłączane przez rozszerzenia do Chrome, takie jak uBlock Origin);
• strony otwierane w kartach w tle.

Wszystkie te warunki mają na celu ograniczenie wpływu nadmiernych spekulacji, gdy mogą one zaszkodzić użytkownikom.

Opcjonalnie source

W Chrome 122 klawisz source jest opcjonalny, ponieważ można go wywnioskować z obecności klawiszy 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 spekulacji można też dostarczać za pomocą nagłówka HTTP Speculation-Rules, zamiast umieszczać je bezpośrednio w kodzie HTML dokumentu. Umożliwia to łatwiejsze wdrażanie przez sieci CDN bez konieczności zmiany zawartości dokumentu.

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

Speculation-Rules: "/speculationrules.json"

Ten zasób musi używać prawidłowego typu MIME, a jeśli jest to zasób między domenami, musi przejść weryfikację CORS.

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

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

Lepsze ponowne wykorzystanie pamięci podręcznej

Wprowadziliśmy kilka ulepszeń w zakresie pamięci podręcznej w Chrome, aby w przypadku pobierania wstępnego (lub nawet prerenderowania) dokumentu zasoby były przechowywane i wykorzystywane ponownie w pamięci podręcznej HTTP. Oznacza to, że spekulacje mogą przynieść korzyści w przyszłości, nawet jeśli nie zostaną wykorzystane.

Dzięki temu ponowne spekulowanie (np. w przypadku reguł dotyczących dokumentów z ustawieniem moderate) jest znacznie tańsze, ponieważ Chrome będzie używać pamięci podręcznej HTTP do zasobów, które można zapisać w pamięci podręcznej.

Popieramy też nową propozycję No-Vary-Search, która ma na celu dalsze polepszanie ponownego wykorzystania pamięci podręcznej.

No-Vary-Search – pomoc

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

Na przykład parametry UTM są używane przez Google Analytics do pomiaru kampanii, ale zwykle nie powodują wyświetlania różnych stron z serwera. Oznacza to, że page1.html?utm_content=123 i page1.html?utm_content=456 będą dostarczać tę samą stronę z serwera, więc można ponownie użyć tej samej strony z pamięci podręcznej.

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

Propozycja No-Vary-Search umożliwia serwerowi określenie parametrów, które nie powodują różnic w dostarczanych zasobach. Dzięki temu przeglądarka może ponownie używać wcześniej zapisanych w pamięci podręcznej wersji dokumentu, które różnią się tylko tymi parametrami. Uwaga: obecnie ta funkcja jest obsługiwana tylko w Chrome (i w przeglądarkach opartych na Chromium) w przypadku spekulacji na temat nawigacji w ramach pobierania wstępnego.

Reguły spekulacji obsługują użycie elementu expects_no_vary_search, aby wskazać, gdzie ma zostać zwrócony nagłówek HTTP No-Vary-Search. Pomoże to uniknąć niepotrzebnych pobrań.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products*"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

W tym przykładzie kod HTML strony początkowej /products jest taki sam dla identyfikatorów produktów 123 i 124. Jednak zawartość strony może się różnić w zależności od renderowania po stronie klienta, które wykorzystuje JavaScript do pobierania danych o produktach za pomocą parametru wyszukiwania id. Dlatego z wyprzedzeniem pobieramy ten adres URL i powinien on zwracać nagłówek HTTP No-Vary-Search, który wskazuje, że strona może być używana do dowolnego parametru wyszukiwania id.

Jeśli jednak użytkownik kliknie którykolwiek z linków przed zakończeniem pobierania w tle, przeglądarka może nie otrzymać strony /products. W tym przypadku przeglądarka nie wie, czy zawiera on nagłówek HTTP No-Vary-Search. Przeglądarka może wtedy ponownie pobrać link lub poczekać na zakończenie pobierania w ramach przewidywania zapytań, aby sprawdzić, czy zawiera on nagłówek HTTP No-Vary-Search. Ustawienie expects_no_vary_search informuje przeglądarkę, że odpowiedź strony powinna zawierać nagłówek HTTP No-Vary-Search, i czeka na zakończenie tej operacji wstępnego pobierania.

Prezentacja

Utworzyliśmy wersję demonstracyjną dostępną pod adresem https://speculative-rules.glitch.me/common-fruits.html, która pozwala zobaczyć działanie reguł dokumentu z użyciem ustawienia moderate z wysoką żarliwością:

Otwórz Narzędzia deweloperskie i kliknij panel Aplikacja. Następnie w sekcji Usługi działające w tle kliknij Wstępne wczytywanie, a potem panel Wstępne wczytywanie i posortuj dane według kolumny Stan.

Gdy najedziesz kursorem na owoce, zobaczysz ich podgląd. Po kliknięciu tych elementów czas LCP będzie znacznie krótszy niż w przypadku jednej z metod, która nie jest renderowana wstępnie. To demo zostało również omówione w tym filmie:

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

Obsługa platformy w przypadku reguł spekulacyjnych

Chociaż reguły spekulacyjne są stosunkowo proste do wdrożenia, ponieważ wystarczy je wstrzyknąć do elementu <script type="speculationrules">, platforma obsługuje to jednym kliknięciem. Współpracowaliśmy z różnymi platformami i partnerami, aby ułatwić wdrażanie zasad dotyczących spekulacji.

Pracujemy też nad standaryzacją interfejsu API w ramach grupy społecznościowej Web Incubator Community Group (WICG), aby umożliwić innym przeglądarkom implementację tego ekscytującego interfejsu API (jeśli tylko zechcą).

WordPress

Zespół WordPress Core Performance (w tym programiści z Google) opracował wtyczkę Speculation Rules. Ta wtyczka umożliwia łatwe dodanie obsługi reguł dokumentów jednym kliknięciem do dowolnej witryny WordPress. Wtyczkę można też zainstalować za pomocą wtyczki WordPress Performance Lab, którą warto też zainstalować, ponieważ będziesz dzięki niej na bieżąco otrzymywać informacje o powiązanych wtyczkach dotyczących wydajności od zespołu.

Dostępne są 2 grupy ustawień: tryb spekulacji i ustawienie Pośpiechliwości:

W przypadku bardziej skomplikowanych konfiguracji, np. aby wykluczyć określone adresy URL z pobierania wstępnego lub prerenderowania, zapoznaj się z tą dokumentacją.

Akamai

Akamai to jeden z największych na świecie dostawców sieci CDN, który od jakiegoś czasu aktywnie eksperymentuje z interfejsem Speculation Rules API. Akamai opublikowała dokumentację, która wyjaśnia, jak klienci mogą włączyć ten interfejs API w ustawieniach CDN. Udostępniliśmy też imponujące wyniki, jakie można uzyskać dzięki temu nowemu interfejsowi API.

NitroPack

NitroPack to rozwiązanie do optymalizacji skuteczności, które korzysta z własnej sztucznej inteligencji do nawigacji, aby przewidywać, które strony dodać do reguł spekulacji. Ma to na celu wydłużenie czasu oczekiwania na wyświetlenie informacji niż w przypadku najechania kursorem na link, ale bez zbędnego spekulowania na temat wszystkich obserwowanych linków. Więcej informacji znajdziesz w dokumentacji interfejsu API Speculation Rules Nitropack. To innowacyjne rozwiązanie pokazuje, że starsze reguły listy nadal mogą być przydatne, gdy zostaną połączone z statystykami dotyczącymi konkretnych witryn.

Zespół Chrome współpracował też z firmą NitroPack przy organizacji webinaru na temat interfejsu Speculation Rules API, który jest przeznaczony dla osób, które chcą dowiedzieć się więcej o tym, co należy wziąć pod uwagę, aby spekulować wcześnie i często, a co późno i rzadko.

Astro

W wersji 4.2 w Astro dodano przedrenderowanie stron za pomocą interfejsu Speculation Rules API w ramach eksperymentu. Dzięki temu deweloperzy korzystający z Astro mogą łatwo włączyć tę funkcję, a w przypadku przeglądarek, które nie obsługują interfejsu Speculation Rules API, stosować standardowe wstępne pobieranie. Aby dowiedzieć się więcej, zapoznaj się z dokumentacją dotyczącą prerenderowania klienta.

Podsumowanie

Te dodatki do interfejsu Speculation Rules API umożliwiają znacznie prostsze korzystanie z tej ekscytującej nowej funkcji dotyczącej wydajności witryn, przy jednoczesnym zmniejszeniu ryzyka marnowania zasobów na niewykorzystane spekulacje. Cieszymy się, że platformy już korzystają z tego interfejsu API. Mamy nadzieję, że w 2024 r. interfejs API będzie używany na większą skalę, co w efekcie przełoży się na większą skuteczność dla użytkowników końcowych.

Oprócz wzrostu wydajności, jaki zapewnia interfejs Speculation Rules API, jesteśmy też bardzo ciekawi, jakie nowe możliwości się dzięki niemu otworzą. Przejścia między widokami to nowy interfejs API, który ułatwia deweloperom określanie przejść między widokami. Obecnie jest to możliwe w przypadku aplikacji jednostronicowych (SPA), ale wersja wielostronicowa jest w trakcie tworzenia (i jest dostępna w Chrome za pomocą flagi). Wstępne renderowanie jest naturalnym uzupełnieniem tej funkcji, ponieważ pozwala uniknąć opóźnień, które uniemożliwiałyby poprawę wrażeń użytkowników, do której zmierza przejście. Zauważyliśmy już, że niektóre witryny eksperymentują z tą kombinacją.

W 2024 r. planujemy dalsze wdrażanie interfejsu Speculation Rules API. Będziemy informować Cię o każdych kolejnych ulepszeniach interfejsu API.

Podziękowania

Miniatura autorstwa Robbie Down z Unsplash