Предварительная обработка страниц в Chrome для мгновенной навигации по страницам

Barry Pollard

Команда Chrome вернула полную предварительную отрисовку будущих страниц, на которые, скорее всего, перейдет пользователь.

Краткая история пререндера

Раньше Chrome поддерживал подсказку ресурса <link rel="prerender" href="/next-page"> , однако он не получил широкой поддержки за пределами Chrome и не был очень выразительным API.

Этот устаревший предварительный рендеринг с использованием подсказки по ссылке rel=prerender был устаревшим в пользу NoState Prefetch , который вместо этого извлекал ресурсы, необходимые для будущей страницы, но не выполнял полную предварительную визуализацию страницы и не выполнял JavaScript. NoState Prefetch действительно помогает повысить производительность страницы за счет улучшения загрузки ресурсов, но не обеспечивает мгновенную загрузку страницы, как это сделал бы полный предварительный рендеринг.

Команда Chrome снова вернула полную предварительную отрисовку в Chrome. Чтобы избежать осложнений при существующем использовании и обеспечить возможность дальнейшего расширения предварительной отрисовки, этот новый механизм предварительной отрисовки не будет использовать синтаксис <link rel="prerender"...> , который остается в силе для NoState Prefetch, с целью отмену этого в какой-то момент в будущем.

Как происходит предварительная обработка страницы?

Страницу можно предварительно отобразить одним из четырех способов, каждый из которых направлен на ускорение навигации:

1. Когда вы вводите URL-адрес в адресную строку Chrome (также известную как «омнибокс»), Chrome может автоматически предварительно отрисовать страницу для вас, если он имеет высокую уверенность в том, что вы посетите эту страницу, на основе вашей предыдущей истории посещений.
2. Когда вы используете панель закладок, Chrome может автоматически предварительно отрисовать страницу, если навести указатель на одну из кнопок закладок.
3. Когда вы вводите поисковый запрос в адресную строку Chrome, Chrome может автоматически предварительно отобразить страницу результатов поиска, если поисковая система даст вам указание сделать это.
4. Сайты могут использовать API Speculation Rules , чтобы программно сообщать Chrome, какие страницы следует обрабатывать. Это заменяет то, что раньше делал <link rel="prerender"...> , и позволяет сайтам заранее выполнять предварительную обработку страницы на основе спекулятивных правил на странице. Они могут статически существовать на страницах или динамически внедряться с помощью JavaScript по усмотрению владельца страницы.

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

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

Влияние предварительного рендеринга

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

Сайт-пример уже является быстрым сайтом, но даже с его помощью вы можете увидеть, как предварительный рендеринг улучшает взаимодействие с пользователем. Таким образом, это также может оказать прямое влияние на основные веб-показатели сайта: LCP практически нулевой, уменьшен CLS (поскольку любая загрузка CLS происходит до первоначального просмотра) и улучшенный INP (поскольку загрузка должна быть завершена до взаимодействия с пользователем).

Даже если страница активируется до того, как она полностью загружена, наличие форы в загрузке страницы должно улучшить процесс загрузки. Если ссылка активирована во время предварительного рендеринга, страница предварительного рендеринга переместится в основной фрейм и продолжит загрузку.

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

Дополнительную информацию о том, как измерить фактическое влияние производительности в вашей аналитике, см. в разделе «Измерение производительности».

Просмотр подсказок в адресной строке Chrome

В первом случае вы можете просмотреть прогнозы Chrome для URL-адресов на странице chrome://predictors :

Зеленые линии указывают на достаточную уверенность для запуска предварительного рендеринга. В этом примере ввод «s» дает достаточную уверенность (желтый), но как только вы наберете «sh», Chrome будет достаточно уверен, что вы почти всегда переходите на https://sheets.google.com .

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

Эти предсказатели также управляют предлагаемыми опциями адресной строки, которые вы, возможно, заметили:

Chrome будет постоянно обновлять свои прогнозы на основе вашего ввода и выбора.

• При уровне достоверности более 50 % (отображается желтым цветом) Chrome заранее подключается к домену, но не выполняет предварительную обработку страницы.
• При уровне достоверности более 80 % (показано зеленым) Chrome предварительно визуализирует URL-адрес.

API правил спекуляций

Для опции предварительной визуализации API правил спекуляции веб-разработчики могут вставлять инструкции JSON на свои страницы, чтобы информировать браузер о том, какие URL-адреса следует обрабатывать:

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

Или с помощью правил документа (доступных в Chrome 121), которые предварительно отображают ссылки, найденные в документе, на основе селекторов href (на основе API шаблонов URL ) или селекторов CSS:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

Команда Chrome подготовила лабораторию правил спекуляции , которая поможет вам добавить правила спекуляции на сайт.

рвение

Настройка eagerness используется для указания того, когда должны сработать спекуляции, что особенно полезно для правил документа:

• 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 вариант — это золотая середина, и многие сайты могли бы извлечь выгоду из следующего правила спекуляции, которое будет предварительно отображать ссылку при удержании указателя над ссылкой в ​​течение 200 миллисекунд или при событии указателя вниз в качестве базовой, но мощной реализации правил спекуляции:

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

Предварительная выборка

Правила спекуляции также можно использовать для предварительной загрузки страниц без полной предварительной обработки. Часто это может быть хорошим первым шагом на пути к предварительному рендерингу:

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

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

В Chrome есть ограничения, позволяющие предотвратить чрезмерное использование API правил спекуляций:

moderate и conservative настройки, которые зависят от взаимодействия с пользователем, работают по принципу «первым пришел — первым вышел» (FIFO) : после достижения предела новое предположение приведет к отмене самого старого предположения и замене его более новым для экономии памяти. . Отмененное предположение может быть инициировано снова — например, путем повторного наведения указателя мыши на эту ссылку — что приведет к повторному рассмотрению этого URL-адреса, выталкивая самые старые предположения. В этом случае предыдущее предположение будет кэшировать все кэшируемые ресурсы в HTTP-кеше для этого URL-адреса, поэтому дальнейшее предположение должно иметь меньшие затраты. Вот почему для ограничения установлено скромное пороговое значение, равное 2. Правила статического списка не запускаются действиями пользователя и поэтому имеют более высокий предел, поскольку браузер не может знать, какие из них необходимы и когда они необходимы.

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

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

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

Chrome также не отображает iframe из разных источников на предварительно обработанных страницах до активации.

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

Как включить правила спекуляции на странице

Правила спекуляции могут быть статически включены в HTML-код страницы или динамически вставлены на страницу с помощью JavaScript:

• Статически включенные правила спекуляций : например, новостной сайт или блог могут предварительно отображать новейшую статью, если это часто следующая навигация для большой части пользователей. Альтернативно, правила документа с moderate или conservative могут использоваться для спекуляций как пользователи взаимодействуют со ссылками.
• Динамически вставляемые правила спекуляции : они могут быть основаны на логике приложения, персонализированы для пользователя или на основе других эвристик.

Тем, кто предпочитает динамическую вставку, основанную на таких действиях, как наведение курсора мыши или нажатие на ссылку (как это делали многие библиотеки в прошлом с помо��ью <link rel=prefetch> , рекомендуется просмотреть правила документа, поскольку они позволяют браузеру обрабатывать многие из ваших вариантов использования.

Правила спекуляции можно добавлять либо в <head> , либо в <body> основного фрейма. Правила предположения в подкадрах не применяются, а правила предположения на предварительно обработанных страницах применяются только после активации этой страницы.

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 правил спекуляции. Это может быть особенно полезно, если вам нужно выбрать некоторые или все ссылки одного и того же происхождения.

Правила спекуляций и SPA

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

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

Отладка правил спекуляций

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

Несколько правил спекуляции

На одну и ту же страницу также можно добавить несколько правил спекуляции, и они присоединятся к существующим правилам. Таким образом, следующие различные способы приводят к предварительному рендерингу как one.html , ��ак и two.html :

Список URL-адресов:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html", "two.html"]
    }
  ]
}
</script>

Несколько сценариев speculationrules :

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    }
  ]
}
</script>
<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Несколько списков в одном наборе speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Поддержка 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://a.example.com может предварительно отрисовать страницу на https://b.example.com ). Чтобы использовать это, предполагаемая страница (в данном примере https://b.example.com ) должна согласиться, включив HTTP-заголовок Supports-Loading-Mode: credentialed-prerender иначе Chrome отменит предположение.

Будущие версии также могут поддерживать предварительную обработку для страниц с разными источниками, находящихся на разных сайтах, при условии, что файлы cookie не существуют для предварительно обработанной страницы и предварительно обработанная страница соглашается на использование аналогичного HTTP-заголовка Supports-Loading-Mode: uncredentialed-prerender .

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

Учитывая эти текущие ограничения, один из шаблонов, который может улучшить взаимодействие ваших пользователей как с внутренними, так и с внешними ссылками, где это возможно, — это предварительная обработка URL-адресов одного и того же происхождения и попытка предварительной выборки URL-адресов из разных источников:

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

Ограничение по предотвращению спекуляций ме��ду источниками для ссылок между источниками по умолчанию необходимо для обеспечения безопасности. Это улучшение по сравнению с <link rel="prefetch"> для мест назначения с несколькими источниками, которые также не будут отправлять файлы cookie, но все равно будут пытаться выполнить предварительную выборку, что либо приведет к ненужной предварительной выборке, которую придется отправить повторно, либо, что еще хуже, к некорректная загрузка страницы.

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

Поддержка API правил обнаружения спекуляций

Вы можете обнаружить поддержку API правил спекуляции с помощью стандартных проверок HTML:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

Динамическое добавление правил спекуляции с помощью JavaScript

Это пример добавления правила prerender рендеринга с помощью JavaScript:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

Вы можете просмотреть демонстрацию предварительной визуализации API Speculation Rules с использованием вставки JavaScript на этой демонстрацио��ной странице предварительной визуализации .

Вставка элемента <script type = "speculationrules"> непосредственно в DOM с помощью innerHTML не регистрирует правила спекуляции по соображениям безопасности , и его необходимо добавить, как показано ранее. Однако контент, вставленный динамически с помощью innerHTML и содержащий новые ссылки, будет обрабатываться существующими правилами на странице.

Аналогично, прямое редактирование панели «Элементы» в Chrome DevTools для добавления элемента <script type = "speculationrules"> не регистрирует правила спекуляции, и вместо этого сценарий для динамического добавления этого в DOM должен быть запущен из консоли, чтобы вставить правила.

Добавьте правила спекуляции через менеджер тегов

Чтобы добавить правила спекуляции с помощью диспетчера тегов, такого как Google Tag Manager (GTM), необходимо вставить их через JavaScript, а не добавлять элемент <script type = "speculationrules"> непосредственно через GTM по тем же причинам, что упоминалось ранее:

Обратите внимание, что в этом примере используется var поскольку GTM не поддерживает const .

Отменить правила спекуляций

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

Правила спекуляции и Политика безопасности контента

Поскольку в правилах спекуляций используется элемент <script> , хотя они содержат только JSON, их необходимо включить в Content-Security-Policy script-src если сайт использует его — либо с использованием хеша, либо nonce.

В script-src можно добавить новые inline-speculation-rules позволяющие поддерживать элементы <script type="speculationrules"> внедренные из хэш-скриптов или неиспользуемых скриптов. Это не поддерживает правила, включенные в исходный HTML, поэтому правила необходимо внедрять с помощью JavaScript для сайтов, использующих строгий CSP.

Обнаружить и отключить предварительный рендеринг

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

Однако могут быть случаи, когда вы не хотите, чтобы предварительная обработка страниц выполнялась , например, когда страницы меняют состояние — либо на основе первоначального запроса, либо на основе выполнения JavaScript на странице.

Включить и отключить предварительную обработку в Chrome

Предварительная обработка включена только для тех пользователей Chrome, у которых есть настройка «Предварительная загрузка страниц» в chrome://settings/performance/ . Кроме того, предварительная визуализация также отключена на устройствах с низким объемом памяти или если операционная система находится в режимах сохранения данных или энергосбережения. См. раздел «Ограничения Chrome» .

Обнаружить и отключить предварительный рендеринг на стороне сервера

Предварительно обработанные страницы будут отправлены с HTTP-заголовком Sec-Purpose :

Sec-Purpose: prefetch;prerender

На страницах с предварительной выборкой, использующих API Speculation Rules, этот заголовок будет иметь значение «просто prefetch :

Sec-Purpose: prefetch

Серверы могут отве��ать на основе этого заголовка, регистрировать запросы на предположения, возвращать другой контент или предотвращать предварительный рендеринг. Если после перенаправления возвращается код неуспешного окончательного ответа (то есть не в диапазоне 200–299), то страница не будет предварительно обработана, и любая страница предварительной выборки будет отброшена. Также обратите внимание, что ответы 204 и 205 также недопустимы для предварительной обработки , но действительны для предварительной выборки.

Если вы не хотите, чтобы определенная страница предварительно отображалась, возврат кода ответа, отличного от 2XX (например, 503), — лучший способ гарантировать, что этого не произойдет. Однако для обеспечения наилучшего взаимодействия рекомендуется вместо этого разрешить предварительную отрисовку, но отложить любые действия, которые должны происходить только после фактического просмотра страницы, с использованием JavaScript.

Обнаружение пререндеринга в JavaScript

API document.prerendering вернет true во время предварительного рендеринга страницы. Страницы могут использовать это для предотвращения или задержки определенных действий во время предварительной визуализации до фактической активации страницы.

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

У вас может быть функция для проверки предварительной визуализации и предварительно обработанных страниц, например:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

Самый простой способ узнать, была ли страница предварительно обработана (полностью или частично), — открыть DevTools после активации страницы и ввести в консоли performance.getEntriesByType('navigation')[0].activationStart . Если возвращается ненулевое значение, вы знаете, что страница была предварительно обработана:

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

Используя эти API, интерфейсный JavaScript может обнаруживать предварительно обработанные страницы и действовать на них соответствующим образом.

Влияние на аналитику

Аналитика используется для измерения использования веб-сайта, например, с помощью Google Analytics для измерения просмотров страниц и событий. Или путем измерения показателей производительности страниц с помощью Real User Monitoring (RUM) .

Страницы следует предварительно визуализировать только в том случае, если существует высокая вероятность того, что страница будет загружена пользователем. Вот почему параметры предварительной отрисовки адресной строки Chrome используются то��ько тогда, когда существует такая высокая вероятность (более 80% случаев).

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

Этого можно добиться с помощью Promise который ожидает события prerenderingchange , если документ выполняет предварительную отрисовку, или разрешает немедленно, если это происходит сейчас:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

Альтернативный подход — отложить аналитические действия до тех пор, пока страница впервые не станет видимой, что будет охватывать как случай предварительной отрисовки, так и случа�� открытия вкладок в фоновом режиме (например, при щелчке правой кнопкой мыши и открытии в новой вкладке):

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

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

Сдерживайте другой контент во время предварительного рендеринга

Те же API, которые обсуждались ранее, можно использовать для сдерживания другого контента на этапе предварительной отрисовки. Это могут быть отдельные части JavaScript или целые элементы сценария, которые вы предпочитаете не запускать на этапе предварительной отрисовки.

Например, учитывая этот скрипт:

<script src="https://example.com/app/script.js" async></script>

Вы можете изменить это на динамически вставляемый элемент сценария, который вставляется только на основе предыдущей функции whenActivated :

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

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

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

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

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

Измерение производительности

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

Основные веб-показатели, измеряемые Chrome с помощью отчета об опыте пользователей Chrome , предназначены для измерения пользовательского опыта. Таким образом, они измеряются на основе времени активации. Например, это часто приводит к 0-секундному LCP, показывая, что это отличный способ улучшить ваши основные веб-показатели.

Начиная с версии 3.1.0, библиотека web-vitals была обновлена ​​и теперь обрабатывает предварительно обработанную навигацию таким же образом, как Chrome измеряет основные веб-показатели. Эта версия также помечает предварительно обработанную навигацию для этих метрик в атрибуте Metric.navigationType если страница была полностью или частично предварительно обработана.

Измерение пререндеринга

О том, выполняется ли предварительная обработка страницы, можно узнать с помощью ненулевой записи activationStart в PerformanceNavigationTiming . Затем это можно зарегистрировать с помощью специального измерения или аналогичного средства при регистрации просмотров страниц, например, с помощью функции pagePrerendered описанной ранее :

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

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

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

Измерьте процент попаданий

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

Это можно измерить, запуская событие аналитики при вставке правил спекуляции (после проверки того, что браузер поддерживает предварительную отрисовку с помощью HTMLScriptElement.supports('speculationrules') , чтобы указать, что предварительная отрисовка была запрошена. (Обратите внимание, что тот факт, что была запрошена предварительная отрисовка, не означает, что предварительная отрисовка была начата или завершена, поскольку, как отмечалось ранее, предварительная отрисовка является подсказкой для браузера, и он может отказаться от предварительной отрисовки страниц в настройках пользователя, текущем использовании памяти, или другие эвристики.)

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

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

Имейте в виду, что некоторая предварительная обработка может происходить из-за предварительной обработки адресной строки, а не только из-за ваших правил предположения. Вы можете проверить document.referrer (который будет пустым для навигации по адресу адресной строки, включая предварительную навигацию по адресу адреса), если вы хотите дифференцировать их.

Не забудьте также смотреть на страницы, на которых нет прерандеров, так как это может указывать на то, что эти страницы не имеют права на презривание, даже из адресной панели. Это может означать, что вы не получаете выгоду от этого повышения производительности. Команда Chrome стремится добавить дополнительные инструменты для проверки на право на получение Prerender, возможно, аналогично инструменту тестирования BFCache , а также потенциально добавить API, чтобы раскрыть, почему прерандер потерпел неудачу.

Воздействие на расширения

См. Выделенный пост о расширениях Chrome: расширение API для поддержки мгновенной навигации , в которой подробно описываются некоторые дополнительные соображения, которые авторы расширения, возможно, должны подумать о предварительных страницах.

Обратная связь

Презендеринг находится в активном развитии команды Chrome, и есть много планов по расширению объема того, что было доступно в выпуске Chrome 108. Мы приветствуем любые отзывы о репо GitHub или использовали наш трекер выпуска , и с нетерпением ждем возможности слушать и поделиться тематическими исследованиями этого захватывающего нового API.

Ссылки по теме

• Правила спекуляций CodeLab
• Отладка правил спекуляций
• Представление предварительной перефшиции ностата
• Правила спекуляций спецификация API
• Навигационные спекуляции GitHub Repo
• Расширения Chrome: расширение API для поддержки мгновенной навигации

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

Миниатюра изображение Марка-Оливье Джодон на Unsplash