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

Barry Pollard

Опубликовано: 2 декабря 2022 г., Последнее обновление: 17 августа 2025 г.

Команда 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 правил спекуляции , чтобы программно сообщать 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 Speculation Rules веб-разработчики могут вставлять на свои страницы инструкции JSON, чтобы информировать браузер о том, какие URL-адреса следует предварительно визуализировать:

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

Или с помощью правил документа (доступных в Chrome 121), которые предварительно отображают ссылки, найденные в документе, на основе селекторов href (на основе URL Pattern API ) или селекторов 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 , но с версии Chrome 141 время наведения курсора меняется на 5 мм, а в дальнейшем планируется заменить его на простую эвристику области просмотра на мобильных устройствах.
• moderate : на настольных компьютерах это приводит к спекуляциям, если указатель мыши удерживается над ссылкой в течение 200 миллисекунд (или при наведении указателя мыши на ссылку в течение события pointerdown , если оно происходит раньше, а на мобильных устройствах, где событие hover отсутствует). На мобильных устройствах мы внедряем изменение, которое будет базироваться на сложной эвристике области просмотра .
• conservative : это предположение о приземлении или касании.

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

По умолчанию установлено conservative eagerness for document rules» (немедленное или активное). Учитывая, что документ может содержать множество URL-адресов, следует с осторожностью использовать правила « immediate for document rules» (немедленное или eager ) (см. также раздел « Ограничения 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> 

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

В Chrome установлены ограничения для предотвращения чрезмерного использования API Speculation Rules:

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

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

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

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

Chrome также не отображает кросс-доменные iframes на предварительно отрисованных страницах до активации.

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

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

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

Поле тега правил спекуляции

Также можно добавлять «теги» в синтаксис JSON правил спекуляции на уровне отдельных правил:

{   "prefetch": [     "urls": ["next.html"],     "tag": "my-prefetch-rules"   ],   "prerender": [     "urls": ["next2.html"],     "tag": "my-prerender-rules"   ], } 

или на общем уровне для всех правил спекуляции в наборе правил:

{   "tag": "my-rules",   "prefetch": [     "urls": ["next.html"]   ],   "prerender": [     "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 автоматически внедряют правила спекуляции, но блокируют спекуляции для страниц, не кэшированных на периферийных серверах, чтобы избежать этой функции, приводящей к повышенной нагрузке на исходный сервер. Теги позволяют им идентифицировать спекуляции, инициированные их набором правил по умолчанию, но при этом позволяют любым правилам, добавленным сайтом, передаваться на исходный сервер.

Теги также могут быть полезны в инструментах, например , мы хотим добавить теги в DevTools .

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

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

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

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

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

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

Поддержку API Speculation Rules можно обнаружить с помощью стандартных проверок 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 .

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

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

Спекуляции также можно отменить с помощью HTTP-заголовка Clear-Site-Data с директивами prefetchCache и prerenderCache .

Это может быть полезно при изменении состояния сервера. Например, при вызове API «добавить в корзину» или API входа/выхода.

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

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

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

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

Этого можно добиться с помощью 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'); 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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