Улучшения API правил спекуляций

Barry Pollard

Команда Chrome работала над некоторыми интересными обновлениями API-интерфейса Speculation Rules, используемого для улучшения производительности навигации за счет предварительной выборки или даже предварительной обработки будущих навигаций. Все эти дополнительные улучшения теперь доступны в Chrome 122 (некоторые функции доступны в более ранних версиях).

Эти изменения значительно упрощают развертывание и уменьшают затраты на предварительную загрузку и предварительную отрисовку страниц, что, как мы надеемся, будет способствовать дальнейшему внедрению.

Дополнительные возможности

Прежде всего, это объяснение новых дополнений, которые мы добавили в API правил спекуляций, и способов их использования. После этого мы покажем вам демо-версию , чтобы вы могли увидеть их в действии.

Правила документа

Раньше API Speculation Rules работал путем указания списка URL-адресов для предварительной выборки или предварительной обработки:

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

Правила спекуляции были полудинамическими в том смысле, что можно было добавлять новые сценарии правил спекуляции и удалять старые сценарии, чтобы отбросить эти спекуляции (обратите внимание, что обновление списка urls существующего сценария правил спекуляции не приводит к изменению спекуляций). Однако выбор URL-адресов по-прежнему оставался за сайтом, либо путем отправки их с сервера во время запроса страницы, либо путем динамического создания этого списка с помощью клиентского JavaScript.

Правила списков остаются вариантами для более простых вариантов использования (когда следующая навигация осуществляется из небольшого набора очевидных) или для более сложных случаев использования (когда список URL-адресов рассчитывается динамически на основе любой эвристики, которую хочет использовать владелец сайта). а затем вставлен на страницу).

В качестве альтернативы мы рады предложить новую опцию автоматического поиска ссылок с помощью правил документа . Это работает путем получения URL-адресов из самого документа на основе where . Это может быть основано на самих ссылках:

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

Селекторы CSS также можно использовать в качестве альтернативы или в сочетании с совпадениями href для поиска ссылок на текущей странице:

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

Это позволяет использовать один набор правил спекуляции на всем сайте, а не использовать отдельные наборы правил для каждой страницы, что значительно упрощает развертывание правил спекуляции на сайтах.

Конечно, предварительная обработка всех ссылок на странице определенно была бы расточительством, поэтому с помощью этой новой возможности мы ввели настройку eagerness .

рвение

При любых предположениях существует компромисс между точностью, отзывом и временем выполнения заказа. Предварительная обработка всех ссылок при загрузке страницы означает, что вы почти наверняка предварительно обработаете ссылку, на которую пользователь нажимает (при условии, что он нажимает ссылку на тот же сайт на странице), причем с максимально возможной задержкой, но с потенциально огромной потерей пропускной способности. .

С другой стороны, предварительный рендеринг только после того, как пользователь щелкнул ссылку, предотвращает потери, но за счет значительного сокращения времени выполнения заказа. Это означает, что предварительный рендеринг вряд ли будет завершен до того, как браузер переключится на эту страницу.

Настройка eagerness позволяет вам определить, когда следует запускать спекуляции, отделяя , когда размышлять, на каких URL-адресах проводить спекуляции. Параметр eagerness доступен как для правил источника list , так и для правил document и имеет четыре параметра, для которых Chrome имеет следующие эвристики:

• immediate : используется для спекуляции как можно скорее, то есть как только будут соблюдены правила спекуляции.
• eager : в настоящее время он ведет себя идентично immediate параметру, но в будущем мы планируем разместить его где-то между immediate и moderate .
• moderate : это выполняет спекуляции, если вы наводите курсор на ссылку в течение 200 миллисекунд (или на событии pointerdown если это происходит раньше, и на мобильных устройствах, где нет события hover ).
• conservative : это спекуляция на указателе или приземлении.

По умолчанию eagerness к использованию правил list immediate . moderate и conservative параметры можно использовать для ограничения правил list URL-адресами, с которыми взаимодействует пользователь, в определенном списке. Хотя во многих случаях правила document с соответствующим условием where могут быть более подходящими.

По умолчанию eagerness к правилам document является conservative . Поскольку документ может состоять из множества URL-адресов, следует с осторожностью использовать правила immediate или eager к document (см. также раздел «Ограничения Chrome» далее).

Какой параметр eagerness использовать, зависит от вашего сайта. Для очень простого статического сайта более активное обсуждение может иметь небольшие затраты и быть полезным для пользователей. Сайты с более сложной архитектурой и более тяжелой полезной нагрузкой страниц могут предпочесть сократить потери, реже спекулируя, пока вы не получите более положительный сигнал о намерении пользователей ограничить потери.

moderate вариант — это золотая середина, и многие сайты могут извлечь выгоду из следующего простого правила спекуляции, которое будет предварительно отображать все ссылки при наведении курсора или указателя вниз в качестве базовой, но мощной реализации правил спекуляции:

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

Ограничения Chrome

Даже при выборе « eagerness в Chrome есть ограничения, предотвращающие чрезмерное использование этого API:

moderate и conservative настройки, которые зависят от взаимодействия с пользователем, работают по принципу «первым пришел — первым обслужен» (FIFO) . После достижения предела новое предположение приведет к отмене самого старого предположения и замене его более новым для экономии памяти.

Тот факт, что пользователи вызывают moderate и conservative спекуляции, позволяет нам использовать более скромный порог 2 для экономии памяти. immediate и eager настройки не запускаются действиями пользователя и поэтому имеют более высокий предел, поскольку браузер не может знать, какие из них необходимы и когда они необходимы.

Спекуляция, которая отменена путем выталкивания из очереди FIFO, может быть инициирована снова — например, при повторном наведении указателя мыши на эту ссылку — что приведет к повторному спекуляции этого URL-адреса. В этом случае предыдущее предположение, скорее всего, приведет к тому, что браузер будет кэшировать некоторые ресурсы в HTTP-кеше для этого URL-адреса, поэтому повторение предположения должно привести к значительному сокращению сети и, следовательно, затрат времени.

immediate и eager ограничения также динамичны. Удаление элемента сценария правил спекуляций с использованием этих уровней готовности создаст пропускную способность за счет отмены удаленных спекуляций. Эти URL-адреса также можно переопределить, если они включены в новый сценарий URL-адресов и предел не был достигнут.

Chrome также предотвратит использование спекуляций в определенных условиях, включая:

• Сохранить данные .
• Экономия энергии .
• Ограничения памяти.
• Когда параметр «Предварительная загрузка страниц» отключен (который также явно отключен расширениями Chrome, такими как uBlock Origin).
• Страницы открываются в фоновых вкладках.

Все эти условия направлены на снижение воздействия чрезмерных спекуляций, когда они могут нанести вред пользователям.

Дополнительный source

Chrome 122 делает source ключ необязательным, поскольку его можно определить по наличию url where или ключей. Таким образом, эти два правила спекуляции идентичны:

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

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

HTTP-заголовок Speculation-Rules

Правила спекуляции также можно доставить с помощью HTTP-заголовка Speculation-Rules , а не включать их непосредственно в HTML-код документа. Это упрощает развертывание с помощью CDN без необходимости самостоятельно изменять содержимое документа.

HTTP-заголовок Speculation-Rules возвращается вместе с документом и указывает на расположение файла JSON, содержащего правила спекуляции:

Speculation-Rules: "/speculationrules.json"

Этот ресурс должен использовать правильный тип MIME и, если это ресурс с несколькими источниками, пройти проверку CORS.

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

Если вы хотите использовать относительные URL-адреса, вы можете включить ключ "relative_to": "document" в свои правила спекуляции. В противном случае относительные URL-адреса будут относиться к URL-адресу файла JSON правил спекуляции. Это может быть особенно полезно, если вам нужно выбрать некоторые или все ссылки одного и того же происхождения.

Лучшее повторное использование кэша

Мы внесли ряд улучшений в кэширование в Chrome, чтобы предварительная выборка (или даже предварительная обработка) документа сохраняла и повторно использовала ресурсы в HTTP-кеше. Это означает, что спекуляции все равно могут принести будущие выгоды, даже если эти спекуляции не будут использоваться.

Это также значительно удешевляет повторную спекуляцию (например, для правил документа с moderate настройкой готовности), поскольку Chrome будет использовать HTTP-кеш для кешируемых ресурсов.

Мы также поддерживаем новое предложение No-Vary-Search для дальнейшего улучшения повторного использования кэша.

Поддержка No-Vary-Search

При предварительной выборке или предварительной отрисовке страницы некоторые параметры URL-адреса (технически называемые параметрами поиска ) могут быть неважны для страницы, фактически доставляемой сервером, и использоваться только клиентским JavaScript.

Например, параметры UTM используются Google Analytics для измерения кампании, но обычно не приводят к доставке разных страниц с сервера. Это означает, что page1.html?utm_content=123 и page1.html?utm_content=456 доставят одну и ту же страницу с сервера, поэтому одну и ту же страницу можно повторно использовать из кэша.

Аналогично, приложения могут использовать другие параметры URL-адреса, которые обрабатываются только на стороне клиента.

Предложение No-Vary-Search позволяет серверу указывать параметры, которые не приводят к различиям с доставленным ресурсом, и, следовательно, позволяют браузеру повторно использовать ранее кэшированные версии документа, которые отличаются только этими параметрами. Примечание. В настоящее время это поддерживается только в Chrome (и браузерах на основе Chromium) для предположений о предварительной выборке навигации.

Правила спекуляции поддерживают использование expects_no_vary_search , чтобы указать, где ожидается возврат HTTP-заголовка No-Vary-Search . Это поможет избежать ненужных загрузок.

<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>

В этом примере HTML-код начальной страницы /products одинаков для обоих идентификаторов продукта 123 и 124 . Однако содержимое страницы в конечном итоге различается в зависимости от рендеринга на стороне клиента с использованием JavaScript для получения данных о продукте с использованием параметра поиска id . Поэтому мы предварительно извлекаем этот URL-адрес, и он должен вернуть HTTP-заголовок No-Vary-Search показывающий, что страницу можно использовать для любого параметра поиска id .

Однако если пользователь нажмет на любую из ссылок до завершения предварительной выборки, браузер может не получить страницу /products . В этом случае браузер не знает, будет ли он содержать HTTP-заголовок No-Vary-Search . Затем браузеру остается выбор: получить ли ссылку еще раз или дождаться завершения предварительной выборки, чтобы проверить, содержит ли она HTTP-заголовок No-Vary-Search . Параметр expects_no_vary_search позволяет браузеру знать, что ответ страницы, как ожидается, будет содержать HTTP-заголовок No-Vary-Search , и ждать завершения этой предварительной выборки.

Демо

Мы создали демо-версию по адресу https://speculative-rules.glitch.me/common-fruits.html , которую можно использовать для просмотра правил документа с настройкой moderate рвения в действии:

Откройте DevTools, щелкните панель «Приложение» . Затем в разделе «Фоновые службы » нажмите «Спекулятивные нагрузки» , затем панель «Спекуляции» и выполните сортировку по столбцу «Статус» .

Наведя курсор на фрукты, вы увидите предварительную визуализацию страниц. Нажатие на них покажет гораздо более быстрое время LCP, чем один из рецептов, которые не подвергаются предварительной визуализации. Эта демонстрация также объясняется в следующем видео :

Вы также можете просмотреть предыдущую публикацию в блоге о правилах спекуляции отладки, чтобы получить дополнительную информацию о том, как использовать DevTools для отладки правил спекуляции.

Поддержка платформой правил спекуляций

Хотя правила спекуляции относительно легко реализовать путем внедрения правил в элемент <script type="speculationrules"> , поддержка платформы может сделать это одним щелчком мыши. Мы работаем с различными платформами и партнерами, чтобы упростить внедрение правил спекуляции.

Мы также усердно работаем над стандартизацией API через группу сообщества Web Incubator (WICG), чтобы позволить другим браузерам также реализовать этот замечательный API, если они захотят.

WordPress

Команда WordPress Core Performance (включая разработчиков из Google) создала плагин Speculation Rules . Этот плагин позволяет простым щелчком мыши добавить поддержку правил документа на любой сайт WordPress. Этот плагин также доступен для установки через плагин WordPress Performance Lab , который вам также следует рассмотреть возможность установки, поскольку он будет держать вас в курсе соответствующих плагинов производительности от команды.

Доступны две группы настроек: режим «Спекуляция» и настройка «Рвение» :

Для более сложных настроек — например, для исключения определенных URL-адресов из предварительной выборки или предварительной обработки — прочтите документацию .

Акамай

Akamai — один из ведущих мировых провайдеров CDN, и они уже некоторое время активно экспериментируют с API Speculation Rules. Akamai выпустила документацию о том, как клиенты могут включить этот API в настройках CDN. Они также ранее рассказывали о впечатляющих результатах, возможных с помощью этого нового API .

НитроПак

NitroPack — это решение для оптимизации производительности, которое использует собственный искусственный интеллект навигации для прогнозирования того, какие страницы добавить в правила спекуляций, целью которого является обеспечение более длительного времени выполнения, чем при наведении курсора на ссылку, но без ненужных спекуляций по всем наблюдаемым ссылкам. Дополнительную информацию см. в документации по API правил спекуляций Nitropack . Это инновационное решение показывает, что старые правила списков еще многое могут предложить в сочетании с информацией, касающейся конкретного сайта.

Команда Chrome также работала с NitroPack над вебинаром по API правил спекуляций для тех, кто ищет дополнительную информацию, включая хорошее обсуждение соображений, необходимых между ранними и частыми спекуляциями, а также поздними и менее частыми.

Астро

Astro добавила предварительную отрисовку страниц с использованием API Speculation Rules в версии 4.2 на экспериментальной основе, что позволило разработчикам, использующим Astro, с легкостью включать эту функцию, одновременно возвращаясь к стандартной предварительной выборке для браузеров, которые не поддерживают API Speculation Rules. Для получения дополнительной информации прочтите документацию по предварительному рендерингу клиента .

Заключение

Эти дополнения к API правил спекуляций позволяют гораздо проще использовать эту замечательную новую функцию производительности для сайтов с меньшим риском траты ресурсов на неиспользованные спекуляции. Приятно видеть, что платформы уже используют этот API. Мы надеемся увидеть более широкое распространение этого API в 2024 году и, как следствие, повысить производительность для конечных пользователей.

Помимо повышения производительности, которое обеспечивает API Speculation Rules, мы также рады видеть, какие новые возможности это открывает. View Transitions — это новый API, который позволяет разработчикам проще указывать переходы между навигациями. В настоящее время это доступно для одностраничных приложений (SPA), но многостраничная версия находится в стадии разработки (и доступна под флагом в Chrome). Prerender — это естественное дополнение к этой функции, обеспечивающее отсутствие задержек, которые в противном случае помешали бы улучшению пользовательского опыта, которое должен обеспечить переход. Мы уже видели сайты, экспериментирующие с этой комбинацией .

Мы с нетерпением ожидаем дальнейшего внедрения API правил спекуляций в течение 2024 года и будем держать вас в курсе любых дальнейших улучшений, которые мы внесем в API.

Благодарности

Миниатюра Робби Дауна на Unsplash