Дата публикации: 2 декабря 2022 г. Последнее обновление: 29 октября 2026 г.
Команда Chrome вернула полную предварительную отрисовку страниц, на которые пользователь, скорее всего, перейдет.
Краткая история предварительной отрисовки
Раньше в Chrome поддерживалась подсказка ресурса <link rel="prerender" href="/next-page">, но она не была широко распространена за пределами этого браузера и не была очень выразительным API.
Устаревший способ предварительной отрисовки с помощью подсказки rel=prerender был заменен на предзагрузку NoState, при которой ресурсы, необходимые для будущей страницы, извлекаются, но страница не отрисовывается полностью и код JavaScript не выполняется. NoState Prefetch помогает повысить эффективность страницы за счет улучшения загрузки ресурсов, но не обеспечивает мгновенную загрузку страницы, как полная предварительная отрисовка.
Команда Chrome вернула в браузер полную предварительную отрисовку. Чтобы избежать сложностей с существующими функциями и обеспечить возможность расширения предварительной отрисовки в будущем, новый механизм не будет использовать синтаксис <link rel="prerender"...>. Он по-прежнему будет применяться для NoState Prefetch, но в будущем мы планируем отказаться от него.
Как выполняется предварительная отрисовка страницы?
Предварительная отрисовка страницы может выполняться одним из четырех способов, каждый из которых предназначен для ускорения навигации:
- Когда вы вводите URL в адресную строку Chrome (также известную как омнибокс), браузер может автоматически выполнить предварительную отрисовку страницы, если на основе истории браузера он предполагает, что вы ее посетите.
- Если вы наведете указатель на кнопку закладки на панели закладок, Chrome может автоматически выполнить предварительную отрисовку страницы.
- Когда вы вводите поисковый запрос в адресную строку Chrome, браузер может автоматически выполнить предварительную отрисовку страницы результатов поиска, если поисковая система поддерживает эту функцию.
- Сайты могут использовать Speculation Rules API, чтобы программно сообщать Chrome, какие страницы нужно предварительно отрисовывать. Она заменяет собой тег
<link rel="prerender"...>и позволяет сайтам упреждающе выполнять предварительную отрисовку страницы на основе правил упреждающей загрузки. Они могут статически существовать на страницах или динамически внедряться с помощью JavaScript по усмотрению администратора страницы.
В каждом из этих случаев предварительная отрисовка выполняется так, как если бы страница была открыта в невидимой фоновой вкладке, а затем "активирована" путем замены активной вкладки на предварительно отрисованную страницу. Если страница активируется до того, как она полностью отрисована, то ее текущее состояние – "на переднем плане", и она продолжает загружаться. Это означает, что вы все равно можете получить преимущество.
Поскольку предварительно отрисованная страница открывается в скрытом состоянии, некоторые API, вызывающие навязчивые действия (например, подсказки), не активируются в этом состоянии, а откладываются до активации страницы. В редких случаях, когда это невозможно, предварительная отрисовка отменяется. Команда Chrome работает над тем, чтобы причины отмены предварительной отрисовки можно было получать через API, а также над расширением возможностей инструментов разработчика, чтобы упростить выявление таких пограничных случаев.
Влияние предварительной отрисовки
Предварительная отрисовка позволяет загружать страницы почти мгновенно, как показано в видео ниже.
Пример сайта уже является быстрым сайтом, но даже с этим вы можете увидеть, как предварительная отрисовка улучшает пользовательский опыт. Это может напрямую повлиять на Core Web Vitals сайта: LCP будет близок к нулю, CLS снизится (поскольку CLS при загрузке происходит до первого просмотра), а INP улучшится (поскольку загрузка должна завершиться до того, как пользователь начнет взаимодействовать со страницей).
Даже если страница активируется до того, как она полностью загрузится, предварительная загрузка страницы должна улучшить процесс загрузки страницы. Если пользователь нажмет на ссылку, пока выполняется предварительная отрисовка, страница будет перемещена в основной фрейм и продолжит загружаться.
Однако при этом расходуется дополнительная память и пропускная способность сети. Будьте осторожны, чтобы не переусердствовать с предварительной отрисовкой за счет ресурсов пользователя. Используйте предварительную отрисовку только в том случае, если вероятность перехода на страницу высока.
Подробнее о том, как измерить фактическое влияние на производительность в аналитике, читайте в разделе Измерение производительности.
Как посмотреть подсказки в адресной строке Chrome
В первом случае вы можете посмотреть подсказки Chrome для URL на странице chrome://predictors.
Зеленые линии указывают на достаточную уверенность для запуска предварительной отрисовки. В этом примере при вводе буквы "s" Chrome предлагает вариант с умеренной уверенностью (желтый цвет), но когда вы вводите "sh", Chrome уже достаточно уверен, что вы почти всегда переходите на https://sheets.google.com.
Этот скриншот был сделан в относительно новой установке Chrome, и в нем отфильтрованы подсказки с нулевой достоверностью, но если вы посмотрите на свои собственные предикторы, вы, скорее всего, увидите значительно больше записей и, возможно, больше символов, необходимых для достижения достаточно высокого уровня достоверности.
Эти же предикторы отвечают за варианты, которые вы видите в адресной строке:
Chrome будет постоянно обновлять подсказки на основе того, что вы вводите и выбираете.
- Если уровень достоверности превышает 30 % (показано желтым), Chrome заранее подключается к домену, но не выполняет предварительную отрисовку страницы.
- Если уровень достоверности превышает 50 % (показан зеленым цветом), Chrome выполнит предварительную отрисовку URL.
Speculation Rules API
Чтобы использовать предварительную отрисовку с помощью Speculation Rules API, веб-разработчики могут добавить на свои страницы инструкции JSON, которые сообщают браузеру, какие URL нужно отрисовывать заранее.
Списки URL
Правила прогнозирования могут основываться на списках URL:
<script type="speculationrules">
{
"prerender": [{
"urls": ["next.html", "next2.html"]
}]
}
</script>
Правила для документов
Правила прогнозирования также могут быть "правилами документа", в которых используется синтаксис where. Она находит ссылки в документе на основе селекторов 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>
Рвение
Настройка eagerness используется, чтобы указать, когда должны срабатывать предположения. Это особенно полезно для правил документа:
conservative– спекулятивная загрузка выполняется при нажатии указателя или касании.moderate. На компьютере спекулятивная загрузка выполняется, если вы удерживаете указатель мыши на ссылке в течение 200 миллисекунд или если происходит событиеpointerdown(в зависимости от того, что наступит раньше). На мобильных устройствах, где событиеhoverне происходит, спекулятивная загрузка выполняется при событии. В августе 2025 года мы изменили способ определения видимости на мобильных устройствах. Теперь он основан на сложных эвристических алгоритмах области просмотра. Сложные эвристические алгоритмы области просмотра срабатывают через 500 мс после того, как пользователь прекратил прокрутку, для привязок в пределах 30 % вертикального расстояния от предыдущего нажатия указателя, где привязки по крайней мере в 0,5 раза больше самой большой привязки в области просмотра. Как описано в этом документе.eager. Раньше этот уровень работал так же, какimmediate, но в Chrome 143 это изменилось. На компьютере спекулятивное выполнение происходит, если вы удерживаете указатель мыши на ссылке в течение 10 миллисекунд. С января 2026 года на мобильных устройствах для этого используются простые эвристики области просмотра. Простая эвристика области просмотра срабатывает через 50 мс после того, как якорь попадает в область просмотра.immediate. Используется для прогнозирования как можно раньше, то есть как только будут соблюдены правила прогнозирования.
Для правил типа "list" по умолчанию используется eagerness "immediate". Параметры eager, moderate и conservative можно использовать, чтобы ограничить правила list URL, с которыми взаимодействует пользователь, определенным списком. Однако во многих случаях лучше использовать правила document с подходящим условием where.
Для правил типа "document" по умолчанию используется eagerness "conservative". Поскольку документ может состоять из множества URL, использовать immediate для правил document следует с осторожностью (см. также раздел Ограничения Chrome ниже).
Выбор настройки eagerness зависит от вашего сайта. Для легкого статического сайта более активное использование спекулятивных правил может быть недорогим и полезным для пользователей. Сайты со сложной архитектурой и тяжелыми страницами могут предпочесть снизить потери, реже выполняя спекулятивную загрузку, пока не получат более положительный сигнал о намерениях пользователей.
Вариант moderate – это компромиссное решение. На многих сайтах можно использовать следующее правило предположений, которое будет выполнять предварительную отрисовку ссылки, если навести на нее указатель и удерживать его в течение 200 миллисекунд или при событии pointerdown. Это простое, но эффективное решение.
<script type="speculationrules">
{
"prerender": [{
"where": {
"href_matches": "/*"
},
"eagerness": "moderate"
}]
}
</script>
Упреждающий запрос
Правила упреждающей загрузки также можно использовать только для предзагрузки страниц без полной предварительной отрисовки. Это может быть хорошим первым шагом на пути к предварительной отрисовке:
<script type="speculationrules">
{
"prefetch": [{
"urls": ["next.html", "next2.html"]
}]
}
</script>
Prerender until script
Команда Chrome также работает над добавлением prerender_until_script в Speculation Rules API (см. ошибку реализации). Это промежуточный шаг между предварительной загрузкой и предварительной отрисовкой. Он используется аналогичным образом:
<script type="speculationrules">
{
"prerender_until_script": [{
"urls": ["next.html", "next2.html"]
}]
}
</script>
Как и в случае с NoState prefetch, это позволит предварительно загрузить как HTML-документ, так и доступные в нем подресурсы. Однако он пойдет дальше и начнет предварительную отрисовку страницы, которая остановится, когда будет обнаружен первый скрипт.
Это означает, что страницы без JavaScript или с JavaScript только в нижнем колонтитуле могут быть предварительно отрисованы почти полностью. Страницы со скриптами в <head> не будут предварительно отрисовываться, но для них по-прежнему будет выполняться извлечение дополнительных ресурсов.
Это позволит избежать рисков, связанных с непредвиденными побочными эффектами от выполнения JavaScript, и при этом добиться гораздо большего повышения производительности, чем при использовании только prefetch.
Ограничения Chrome
В Chrome действуют ограничения, которые не позволяют злоупотреблять Speculation Rules API:
| рвение | Упреждающий запрос | Prerender (Предварительная обработка) |
|---|---|---|
immediate |
50 | 10 |
eager / moderate на мобильных устройствах |
6 (FIFO) | 2 (FIFO) |
eager/moderate на компьютере |
2 (FIFO) | 2 (FIFO) |
conservative |
2 (FIFO) | 2 (FIFO) |
Настройки eager, moderate и conservative, которые зависят от взаимодействия пользователя, работают по принципу метода FIFO. Когда лимит достигнут, новая спекуляция отменяет самую старую и заменяет ее, чтобы сэкономить память.
Отмененное предположение может быть запущено снова, например при повторном наведении указателя мыши на ссылку. В результате URL будет обработан заново, а самое старое предположение будет удалено. В этом случае предыдущая спекуляция сохранит все кешируемые ресурсы в кеше HTTP для этого URL, поэтому последующая спекуляция должна иметь меньшую стоимость. Поэтому по умолчанию установлено скромное ограничение – 2. Для мобильных устройств мы используем более высокое пороговое значение (6) для предзагрузки, поскольку на них нет наведения курсора, альтернативные эвристики области просмотра менее точны, а предзагрузка менее затратна, чем предварительная отрисовка (для которой мы сохраняем ограничение 2).
Правила статического списка не активируются действиями пользователя, поэтому для них установлен более высокий лимит, так как браузер не может определить, какие из них нужны и когда.
Мы также рассматриваем возможность увеличить лимит до пяти на мобильных устройствах для eager и moderate, по крайней мере для предварительной выборки, поскольку это менее точная эвристика. Разработчикам, использующим eager, рекомендуется также использовать правила conservative, когда в области просмотра доступно несколько ссылок, чтобы они по-прежнему могли предполагать, даже если они не выбраны в качестве одной из первых двух ссылок.
Лимит immediate также является динамическим, поэтому удаление элемента скрипта URL list освободит место за счет отмены удаленных предположений.
Chrome также не будет использовать предположения в некоторых случаях, например:
- Save-Data.
- Режим энергосбережения, если он включен и у устройства низкий заряд батареи.
- Ограничения памяти.
- Если отключена функция "Предзагрузка страниц" (она также отключается расширениями Chrome, такими как uBlock Origin).
- Страницы, открытые в фоновых вкладках.
Кроме того, Chrome не отрисовывает междоменные элементы iframe на предварительно отрисованных страницах до активации.
Все эти условия направлены на то, чтобы снизить влияние спекуляций, когда они могут нанести вред пользователям.
Как добавить правила прогнозирования на страницу
Правила спекуляции можно статически включить в HTML-код страницы или динамически вставить в страницу с помощью JavaScript:
- Статически включенные правила предположений. Например, новостной сайт или блог может предварительно отрисовывать самую новую статью, если пользователи часто переходят к ней. Также можно использовать правила документов с селектором
moderateилиconservative, чтобы делать предположения, когда пользователи взаимодействуют со ссылками. - Динамически вставляемые правила предположений. Они могут основываться на логике приложения, персонализироваться для пользователя или опираться на другие эвристики.
Если вы предпочитаете динамическую вставку на основе действий, например наведения указателя мыши или нажатия на ссылку (как это делалось раньше во многих библиотеках с помощью <link rel=prefetch>), рекомендуем ознакомиться с правилами документа, поскольку они позволяют браузеру обрабатывать многие из ваших вариантов использования.
Правила спекуляции можно добавить в <head> или <body> основного фрейма. Правила предположений в субфреймах не выполняются, а правила предположений на предварительно отрисованных страницах выполняются только после активации страницы.
HTTP-заголовок с атрибутом Speculation-Rules
Правила спекуляции также можно передавать с помощью HTTP-заголовка Speculation-Rules, а не включать их непосредственно в HTML-код документа. Это упрощает развертывание сетей доставки контента, поскольку не требует изменения содержимого документов.
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-файла правил предположений. Это может быть особенно полезно, если вам нужно выбрать некоторые или все ссылки одного происхождения.
Поле тега правил прогнозирования
Вы также можете добавить теги в синтаксис JSON правил спекуляции на общем уровне для всех правил спекуляции в наборе правил:
{
"tag": "my-rules",
"prefetch": [{
"urls": ["next.html"]
}],
"prerender": [{
"urls": ["next2.html"]
}]
}
или на уровне отдельного правила:
{
"prefetch": [{
"tag": "my-prefetch-rules",
"urls": ["next.html"]
}],
"prerender": [{
"tag": "my-prerender-rules",
"urls": ["next2.html"]
}]
}
Этот тег затем отражается в HTTP-заголовке Sec-Speculation-Tags, который можно использовать для фильтрации правил спекуляции на сервере. HTTP-заголовок Sec-Speculation-Tags может включать несколько тегов, если предположение охватывается несколькими правилами, как показано в следующем примере:
Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"
Некоторые CDN автоматически добавляют правила предположений, но блокируют предположения для страниц, не использующих пограничное кеширование, чтобы эта функция не приводила к увеличению нагрузки на сервер-источник. Теги позволяют им идентифицировать спекуляции, инициированные набором правил по умолчанию, но при этом разрешают передавать источнику любые правила, добавленные сайтом.
Теги наборов правил также показываются в инструментах разработчика Chrome.
Поле target_hint правил прогнозирования
Правила спекуляции также могут включать поле target_hint, которое содержит действительное название контекста просмотра или ключевое слово, указывающее, где страница ожидает активации предварительно отрисованного контента:
<script type=speculationrules>
{
"prerender": [{
"target_hint": "_blank",
"urls": ["next.html"]
}]
}
</script>
Эта подсказка позволяет обрабатывать предположения о предварительной отрисовке для ссылок target="_blank":
<a target="_blank" href="next.html">Open this link in a new tab</a>
В настоящее время в Chrome поддерживаются только значения "target_hint": "_blank" и "target_hint": "_self" (используется по умолчанию, если не указано другое значение) и только для предварительной отрисовки. Предварительная выборка не поддерживается.
target_hint требуется только для правил спекуляции urls, поскольку для правил документа target известен из самой ссылки.
Правила упреждающей загрузки и одностраничные приложения
Правила спекуляции поддерживаются только для навигации по страницам, управляемой браузером, и не поддерживаются для одностраничных приложений (SPA) или страниц с оболочкой приложения. В таких архитектурах не используется получение документов, а вместо этого выполняются вызовы API или частичное получение данных или страниц, которые затем обрабатываются и отображаются на текущей странице. Данные, необходимые для таких переходов, могут быть предварительно получены приложением без правил предположений, но не могут быть предварительно отрисованы.
Правила упреждающей загрузки можно использовать для предварительной отрисовки самого приложения с предыдущей страницы. Это может помочь компенсировать некоторые дополнительные затраты на начальную загрузку, которые есть у некоторых SPA. Однако изменения маршрута в приложении не могут быть предварительно отрисованы.
Отладка правил упреждающей загрузки
См. специальную статью об отладке правил спекуляции, посвященную новым функциям инструментов разработчика Chrome, которые помогают просматривать и отлаживать этот новый 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 Аналитикой для оценки эффективности кампаний, но обычно не приводят к тому, что сервер возвращает разные страницы. Это означает, что 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, и дождаться завершения предварительной загрузки.
Вы также можете добавить в expects_no_vary_search несколько параметров, разделенных пробелом (поскольку No-Vary-Search – это структурированный заголовок HTTP):
"expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"
Ограничения правил прогнозирования и будущие улучшения
Правила спекуляции ограничены страницами, открытыми на той же вкладке, но мы работаем над тем, чтобы снять это ограничение.
По умолчанию предварительная отрисовка ограничена страницами одного источника. Вы можете включить предварительную отрисовку перекрестных страниц одного сайта (например, 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, но все равно попытаются выполнить предварительную загрузку. Это приведет либо к напрасной предварительной загрузке, которую необходимо будет повторить, либо, что ещё хуже, к загрузке неправильной страницы.
Как определить, поддерживается ли Speculation Rules API
Вы можете определить, поддерживается ли Speculation Rules 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);
}
Посмотреть, как работает предварительная отрисовка Speculation Rules API с использованием вставки JavaScript, можно на демонстрационной странице.
Вставка элемента <script type = "speculationrules"> непосредственно в DOM с помощью innerHTML не приведет к регистрации правил спекуляции из соображений безопасности, и их необходимо добавить, как показано выше. Однако контент, вставленный динамически с помощью innerHTML и содержащий новые ссылки, будет обрабатываться существующими правилами на странице.
Аналогично, прямое редактирование панели Элементы в инструментах разработчика Chrome для добавления элемента <script type = "speculationrules"> не регистрирует правила предположений. Чтобы вставить правила, нужно запустить скрипт для динамического добавления этого элемента в DOM из консоли.
Как добавить правила спекуляции через менеджер тегов
Чтобы добавить правила спекуляции с помощью системы управления тегами, например Google Менеджера тегов, их нужно вставить через JavaScript, а не добавлять элемент <script type = "speculationrules"> напрямую через Менеджер тегов по тем же причинам, что и ранее:
Обратите внимание, что в этом примере используется var, поскольку Менеджер тегов не поддерживает const.
Отменить правила упреждающей загрузки
Если удалить правила упреждающей загрузки, предварительная отрисовка будет отменена. Однако к этому моменту ресурсы, скорее всего, уже будут потрачены на запуск предварительной отрисовки, поэтому рекомендуется не использовать ее, если есть вероятность, что ее придется отменить. С другой стороны, кэшированные ресурсы по-прежнему можно использовать повторно, поэтому отмены могут быть не полностью потрачены впустую и все равно могут принести пользу будущим предположениям и навигации.
Отменить предположения также можно с помощью HTTP-заголовка Clear-Site-Data с директивами prefetchCache и prerenderCache.
Это может быть полезно, когда состояние меняется на сервере. Например, при вызове API для добавления товара в корзину, входа в аккаунт или выхода из него.
В идеале эти обновления состояния должны передаваться на предварительно отрисованные страницы с помощью API, таких как Broadcast Channel API. Если это невозможно или пока такая логика не реализована, проще отменить предположение.
Правила спекуляции и Content Security Policy
Поскольку правила спекуляции используют элемент <script>, даже если они содержат только JSON, их необходимо включить в script-src Content-Security-Policy, если сайт использует это – либо с помощью хеша, либо с помощью одноразового номера.
В script-src можно добавить новое значение inline-speculation-rules, чтобы поддерживать элементы <script type="speculationrules">, внедренные из скриптов с хешем или одноразовым кодом. Правила, включенные в исходный HTML-код, не поддерживаются, поэтому на сайтах со строгой CSP правила должны добавляться с помощью JavaScript.
Как обнаружить и отключить предварительную отрисовку
Предварительная отрисовка обычно положительно воспринимается пользователями, поскольку позволяет быстро, а иногда и мгновенно загружать страницы. Это выгодно и пользователям, и владельцам сайтов, поскольку предварительно отрисованные страницы удобнее для посетителей, а добиться этого другими способами может быть сложно.
Однако в некоторых случаях предварительная отрисовка страниц нежелательна, например когда страницы меняют состояние на основе исходного запроса или кода JavaScript, выполняемого на странице.
Как включить или отключить предварительную отрисовку в Chrome
Предварительная отрисовка доступна только пользователям Chrome, у которых в chrome://settings/performance/ включен параметр "Предзагрузка страниц". Кроме того, предварительная отрисовка отключена на устройствах с небольшим объемом памяти, а также если операционная система находится в режимах экономии трафика или энергосбережения. Ознакомьтесь с разделом Ограничения Chrome.
Как обнаружить и отключить предварительную отрисовку на стороне сервера
Предварительно отрисованные страницы будут отправляться с HTTP-заголовком Sec-Purpose:
Sec-Purpose: prefetch;prerender
Для страниц, предзагруженных с помощью Speculation Rules API, этот заголовок будет иметь значение 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
);
}
Проще всего проверить, была ли страница предварительно отрисована (полностью или частично), открыв Инструменты разработчика после активации страницы и введя в консоли performance.getEntriesByType('navigation')[0].activationStart. Если возвращается ненулевое значение, значит страница была предварительно отрисована:
Когда пользователь открывает страницу, в document отправляется событие prerenderingchange. Это позволяет активировать действия, которые ранее запускались по умолчанию при загрузке страницы, но которые вы хотите отложить до того момента, когда пользователь действительно просмотрит страницу.
С помощью этих API клиентский код JavaScript может обнаруживать предварительно отрисованные страницы и выполнять с ними нужные действия.
Влияние на аналитику
Аналитика используется для оценки использования сайта, например, Google Аналитика используется для измерения просмотров страниц и событий. или путем измерения показателей эффективности страниц с помощью мониторинга реальных пользователей (RUM).
Предварительная отрисовка страниц должна выполняться только в том случае, если высока вероятность того, что пользователь загрузит страницу. Поэтому предварительная отрисовка вариантов в адресной строке Chrome происходит только при высокой вероятности (более 80 %).
Однако предварительно отрисованные страницы могут повлиять на аналитику, особенно при использовании Speculation Rules 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, предназначены для оценки удобства сайта для пользователей. Поэтому они измеряются на основе времени активации. Например, показатель LCP часто будет равен нулю, что говорит о значительном улучшении Core Web Vitals.
Начиная с версии 3.1.0 библиотека web-vitals была обновлена, чтобы обрабатывать переходы с предварительной отрисовкой так же, как Chrome измеряет показатели Core Web Vitals. В этой версии также помечаются переходы с предварительной отрисовкой для этих показателей в атрибуте 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')), чтобы указать, что предварительная отрисовка была запрошена. Обратите внимание, что запрос предварительной отрисовки не означает, что она была начата или завершена. Как уже говорилось, запрос – это подсказка для браузера, и он может не выполнять предварительную отрисовку в зависимости от настроек пользователя, текущего использования памяти или других эвристических факторов.
Затем вы можете сравнить количество этих событий с фактическим количеством просмотров страниц с предварительной отрисовкой. Или активируйте другое событие при активации, если это упростит сравнение.
Разница между этими двумя показателями позволяет приблизительно оценить долю успешных обращений. Если вы используете Speculation Rules API для предварительной отрисовки страниц, вы можете настроить правила так, чтобы поддерживать высокую долю попаданий и соблюдать баланс между использованием ресурсов пользователей для их удобства и напрасной тратой этих ресурсов.
Имейте в виду, что предварительная отрисовка может выполняться не только из-за правил предположений, но и из-за адресной строки. Чтобы различать эти случаи, можно проверить document.referrer (для переходов из адресной строки, в том числе с предварительной отрисовкой, это поле будет пустым).
Также обратите внимание на страницы, для которых не выполнялась предварительная отрисовка. Это может означать, что они не допущены для предварительной отрисовки, даже если пользователь вводит их URL в адресной строке. Это означает, что вы не сможете воспользоваться преимуществами, которые дает повышение эффективности. Команда Chrome планирует добавить дополнительные инструменты для тестирования соответствия требованиям предварительной отрисовки, возможно, похожие на инструмент тестирования bfcache, а также, возможно, добавить API, чтобы показывать, почему предварительная отрисовка не удалась.
Влияние на расширения
В статье Расширения Chrome: расширение API для поддержки мгновенной навигации подробно описаны дополнительные факторы, которые разработчикам расширений следует учитывать при работе с предварительно отрисованными страницами.
Как оставить отзыв
Команда Chrome активно работает над предварительной отрисовкой и планирует расширить возможности, доступные в версии Chrome 108. Мы будем рады вашим отзывам в репозитории GitHub или в системе отслеживания ошибок. Также мы с нетерпением ждем примеров использования этого нового API.
Статьи по теме
- Практическая работа по правилам прогнозирования
- Отладка правил прогнозирования
- Представляем NoState Prefetch
- Спецификация Speculation Rules API
- Репозиторий Navigational speculation на GitHub
- Расширения Chrome: расширение API для поддержки мгновенной навигации
Благодарности
Значок видео: Марк-Оливье Жодуэн (Marc-Olivier Jodoin), Unsplash