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

Барри Поллард

Поддержка браузера

  • 109
  • 109
  • Икс
  • Икс

Команда 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, Chrome может автоматически предварительно отобразить страницу результатов поиска, если поисковая система даст вам указание сделать это.
  3. Сайты могут использовать API Speculation Rules , чтобы программно сообщать Chrome, какие страницы следует обрабатывать. Это заменяет то, что раньше делал <link rel="prerender"...> и позволяет сайтам заранее выполнять предварительную обработку страницы на основе спекулятивных правил на странице. Они могут статически существовать на страницах или динамически внедряться с помощью JavaScript по усмотрению владельца страницы.

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

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

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

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

Пример влияния предварительного рендеринга.

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

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

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

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

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

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

Снимок экрана: страница предикторов Chrome, отфильтрованная таким образом, чтобы отображать низкие (серые), средние (желтые) и высокие (зеленые) прогнозы на основе введенного текста.
Страница предсказателей Chrome.

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

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

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

Снимок экрана: функция «Ввод текста» в адресной строке
Функция «Ввод текста» в адресной строке.

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

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

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

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

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

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

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel=nofollow]"}}
      ]
    }
  }]
}
</script>

Рвение

Поддержка браузера

  • 121
  • 121
  • Икс
  • Икс

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

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

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

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

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

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

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

рвение Предварительная выборка Пререндер
immediate / eager 50 10
moderate / conservative 2 (ФИФО) 2 (ФИФО)
Ограничения спекуляций в Chrome.

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

Поддержка браузера

  • 121
  • 121
  • Икс
  • Икс

Источник

Правила спекуляции также можно доставить с помощью 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>

Поддержка браузера

  • 121
  • 121
  • Икс
  • Икс

Источник

При предварительной загрузке или предварительной отрисовке страницы определенные параметры 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 отменит предварительную обработку.

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

Поддержка 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> , даже если они содержат только 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 или 304), то страница не будет предварительно обработана, и любая страница предварительной выборки будет отброшена.

Если вы не хотите, чтобы определенная страница подвергалась предварительной обработке, это лучший способ гарантировать, что этого не произойдет. Однако для обеспечения наилучшего взаимодействия рекомендуется вместо этого разрешить предварительную отрисовку, но отложить любые действия, которые должны выполняться только после фактического просмотра страницы, с использованием 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 . Если возвращается ненулевое значение, вы знаете, что страница была предварительно обработана:

Консоль в Chrome DevTools показывает положительную активацию. Начало указывает на то, что страница была предварительно обработана.
Тестирование пререндера в консоли.

Когда страница активируется пользователем, просматривающим страницу, в 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 whenActivated = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

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

initAnalytics();

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

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

Для измерения показателей производительности аналитикам следует подумать, лучше ли измерять их на основе времени активации, а не времени загрузки страницы, о котором сообщают 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 планирует добавить дополнительные инструменты для проверки возможности предварительного рендеринга, возможно, аналогичные инструменту тестирования bfcache , а также потенциально добавить API, чтобы выяснить, почему не удалось выполнить предварительный рендеринг.

Влияние на расширения

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

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

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

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

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