Опубликовано: 7 марта 2025 г.
API Speculation Rules позволяет пользователям получать выгоду от повышения производительности за счет предварительной выборки или предварительной обработки будущих переходов по страницам, чтобы обеспечить более быструю или даже мгновенную навигацию по страницам.
API был специально разработан с учетом простоты реализации, но есть некоторые соображения, которые особенно необходимо учитывать перед его использованием на сложных сайтах. Это руководство поможет владельцам сайтов понять эти соображения.
Планирование
Прежде чем внедрять правила спекуляций, стоит подумать о том, как реализовать API (поскольку есть несколько вариантов), а также о стоимости спекуляций (что должно помочь вам определить, на каких страницах спекулировать).
Решите, как реализовать правила спекуляции
Одно из первых решений, которое вам необходимо принять, — это как реализовать правила спекуляции на вашем сайте, поскольку вы можете использовать различные методы:
- Непосредственно в HTML-странице
- Использование JavaScript
- Использование HTTP-заголовка
В конечном счете, каждый метод имеет одинаковый эффект, но могут иметь преимущества с точки зрения простоты реализации и гибкости.
Сайты должны выбирать тот вариант, который им подходит лучше всего, и при необходимости могут даже использовать комбинацию этих вариантов. Альтернативно, они могут быть реализованы с помощью плагина (например, плагина Speculative Loading для WordPress) или библиотек или платформ, которые могут сделать выбор за вас, но все равно стоит знать о доступных вариантах.
Включите правила спекуляции непосредственно в HTML-код страницы.
Правила спекуляции можно реализовать непосредственно на странице, включив элемент <script type="speculationrules"> в ее HTML. Это можно добавить либо во время сборки статических сайтов с использованием шаблонов, либо во время выполнения сервером, когда страница запрашивается. Их даже можно внедрить в HTML пограничными работниками (хотя метод HTTP-заголовка, обсуждаемый далее в этом руководстве, вероятно, для этого проще).
Это позволяет вам включать статические правила по всему сайту, но правила документа по-прежнему могут быть динамическими, позволяя вам выбирать URL-адреса для отображения со страницы, используя правила, которые инициируются классами CSS:
<script type="speculationrules">
{
"prerender": [{
"where": { "selector_matches": ".prerender" }
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch" }
}]
}
</script>
Предыдущий скрипт выполняет предварительную обработку ссылок с помощью класса prerender и аналогичным образом выполняет предварительную выборку, когда ссылка имеет класс prefetch . Это позволяет разработчикам включать эти классы в HTML, чтобы вызвать предположения.
Помимо включения ссылок на эти классы в исходный HTML-код страницы, ссылки также будут предполагаться, если эти классы добавляются вашим приложением динамически, что позволяет вашему приложению инициировать (и удалять) спекуляции по мере необходимости. Это может быть проще, чем создавать или удалять более конкретные правила спекуляции. Также можно включить несколько правил спекуляции на страницу, если вы хотите, чтобы базовое правило использовалось большей частью сайта, а также правила, специфичные для каждой страницы.
В качестве альтернативы, если вам все же необходимо использовать более конкретные правила спекуляции, то правила, специфичные для страницы или шаблона, могут разрешать разные правила для определенных страниц или типов страниц.
Наконец, страницы, отображаемые на стороне сервера, также могут иметь более динамические правила, основанные на любой информации, доступной серверу, например, аналитической информации для этой страницы или обычных действиях пользователя для определенных страниц.
Добавьте правила спекуляции с помощью JavaScript
Альтернативой включению правил в скрипт на странице является внедрение их с помощью JavaScript. Это может потребовать меньше обновлений шаблонов страниц. Например, внедрение правил с помощью диспетчера тегов может быть быстрым способом внедрения правил спекуляции (а также позволяет быстро их отключить при необходимости).
Этот параметр также позволяет использовать динамические правила на стороне клиента, основанные на том, как пользователь взаимодействует со страницей. Например, если пользователь добавляет товар в корзину, вы можете предварительно отобразить страницу оформления заказа. Альтернативно, это можно использовать для запуска спекуляций, основанных на определенных условиях. В то время как API включает настройку рвения , которая позволяет использовать базовые правила взаимодействия, JavaScript позволяет разработчикам использовать свою собственную логику, чтобы решить, когда и на каких страницах размышлять.
Как упоминалось ранее, альтернативный подход к вставке новых правил состоит в том, чтобы иметь базовое правило документа на странице и запускать правила документа JavaScript путем добавления соответствующих классов к ссылкам, заставляя их соответствовать правилу.
Добавьте правила спекуляции, используя HTTP-заголовок
Последний вариант для разработчиков — включить правила с помощью HTTP-заголовка:
Speculation-Rules: "/speculationrules.json"
Существуют некоторые дополнительные требования к тому, как доставляется и используется ресурс правил ( /speculationrules.json в этом примере).
Эта опция позволяет упростить развертывание с помощью CDN без необходимости изменять содержимое документа. Это означает, что динамическое изменение правил спекуляции с использованием JavaScript не является вариантом. Однако правила документа с триггерами селектора CSS по-прежнему могут допускать динамические изменения — например, удаляя класс prerender из ссылки.
Как и в случае с JavaScript, реализация правил спекуляции с помощью HTTP-заголовка позволяет реализовать их независимо от содержимого сайта, что упрощает добавление и удаление правил без полной перестройки сайта.
Учитывайте финансовые последствия
Прежде чем внедрять правила спекуляции, стоит потратить немного времени на то, чтобы оценить финансовые последствия использования этого API как для ваших пользователей, так и для вашего сайта. Затраты включают в себя пропускную способность (стоимость которой стоит как пользователям, так и сайтам!) и затраты на обработку (как на стороне клиента, так и на стороне сервера).
Учитывайте стоимость для пользователей
Спекулятивная загрузка означает обоснованное предположение о том, куда пользователь может перейти к новому. Однако если такой навигации не происходит, возможно, вы потратили ресурсы впустую. Вот почему вы должны осознавать влияние на пользователей, в частности:
- Дополнительная полоса пропускания используется для загрузки будущей навигации, особенно на мобильных устройствах, где пропускная способность может быть более ограничена.
- Дополнительные затраты на обработку для рендеринга этих страниц при использовании предварительного рендеринга.
При абсолютно точных прогнозах не возникает никаких дополнительных затрат, поскольку посетители будут посещать эти страницы следующими, с той лишь разницей, что эти затраты оплачиваются заранее. Однако предсказать будущее с полной точностью невозможно, и чем агрессивнее стратегия спекуляций, тем выше риск потерь.
Chrome тщательно рассмотрел эту проблему, и API включает в себя ряд функций , которые означают, что стоимость намного ниже, чем вы думаете . В частности, за счет повторного использования HTTP-кэша и отсутствия загрузки iframe из разных источников стоимость предварительной визуализации навигации на одном и том же сайте часто значительно меньше, чем полная страница без кэшированных ресурсов, что делает спекулятивную загрузку менее дорогостоящей, чем можно предположить.
Однако даже при наличии этих мер безопасности сайтам следует тщательно учитывать, на каких страницах можно спекулировать, а также цену таких спекуляций для пользователей. Хорошими кандидатами для спекулятивной загрузки являются те, которые можно разумно предсказать с высокой степенью уверенности (возможно, на основе аналитики или обычных действий пользователя) и при низкой стоимости (например, менее насыщенные страницы).
Вы также можете рассмотреть, какой JavaScript следует отложить до активации. Подобно отложенной загрузке контента до тех пор, пока он не понадобится, это может удешевить предварительный рендеринг, но обеспечить гораздо лучший пользовательский опыт. При более дешевых спекуляциях вы можете чувствовать себя комфортно, спекулируя чаще и охотнее.
Там, где это невозможно, рекомендуется менее агрессивная стратегия, использующая умеренные или консервативные правила рвения . В качестве альтернативы вы можете использовать предварительную выборку, которая обходится значительно дешевле, чем предварительная отрисовка, когда достоверность низкая, а затем перейти на полную предварительную отрисовку, если достоверность возрастает — например, при наведении указателя мыши или фактическом нажатии ссылки.
Учитывайте дополнительную нагрузку на серверную часть
Помимо учета дополнительных затрат пользователя, владельцы сайтов должны учитывать свои собственные затраты на инфраструктуру. Если каждая страница приводит к загрузке двух, трех или даже более страниц, то затраты на серверную часть могут увеличиться при использовании этого API.
Обеспечение кэширования ваших страниц и ресурсов значительно уменьшит объем исходной нагрузки и, следовательно, общий риск. В сочетании с CDN ваши исходные серверы должны испытывать минимальную дополнительную нагрузку, однако учитывайте любое увеличение стоимости CDN.
Сервер или CDN также могут использоваться для управления результатами спекуляций, определяемыми HTTP-заголовком sec-цели . Например, продукт Speed Brain от Cloudflare допускает только предположения, которые уже кэшированы на пограничном сервере CDN, и не отправляет запросы обратно в источник.
Однако, поскольку спекулятивные загрузки обычно используются для загрузки страниц одного и того же источника, пользователи уже будут иметь общие ресурсы в кеше своего браузера (при условии, что они вообще кэшируются), поэтому, опять же, спекуляция обычно не так затратна, как полная загрузка страницы.
Найдите баланс между слишком большим или слишком малым количеством спекуляций.
Ключом к максимальному использованию API правил спекуляций является нахождение баланса между слишком большими спекуляциями (то есть, когда затраты оплачиваются без необходимости и спекуляция не используется) и слишком консервативным подходом (слишком мало или слишком поздно, когда реализуется небольшая выгода).
Там, где затраты невелики (например, небольшие статически генерируемые страницы, кэшированные на пограничных узлах CDN), вы можете позволить себе быть более агрессивными в спекуляциях.
Однако для более крупных и насыщенных страниц, которые, возможно, невозможно кэшировать на границе CDN, следует проявлять больше осторожности. Аналогичным образом, ресурсоемкие страницы могут использовать пропускную способность сети или вычислительную мощность, что может негативно повлиять на текущую страницу. Целью API является повышение производительности, поэтому снижение производительности определенно не то, что нам нужно! Это еще одна причина ограничить предварительный рендеринг максимум одной или двумя страницами (обратите также внимание, что Chrome ограничивает два или десять предварительных рендерингов одновременно, в зависимости от желания).
Шаги по внедрению правил спекуляции
После того, как вы решили, как реализовать правила спекуляции, вам нужно спланировать, чем спекулировать и как это реализовать. Более простые сайты, такие как статические личные блоги, могут сразу перейти к полной предварительной визуализации определенных страниц, но более сложные сайты имеют дополнительные сложности, которые следует учитывать.
Начните с предварительной выборки
Предварительную выборку обычно относительно безопасно реализовать для большинства сайтов, и это первоначальный подход, используемый многими, включая крупномасштабные развертывания, такие как Cloudflare и WordPress .
Основные проблемы, о которых следует знать, заключаются в том, что предварительная выборка URL-адреса приведет к каким-либо изменениям состояния и затратам на стороне сервера, особенно для некэшируемых страниц. В идеале изменения состояния — например, предварительная выборка страницы /logout — не должны реализовываться как ссылки GET , но, к сожалению, это не редкость в Интернете.
Такие URL-адреса можно специально исключить из правил:
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Предварительная загрузка может быть ограничена обычным переходом с одной страницы на другую или для всех ссылок одного и того же происхождения при наведении или щелчке с использованием moderate или conservative настройки eagerness . conservative подход несет в себе самый низкий риск, но также и самое низкое потенциальное вознаграждение. Если начать с этого, то постарайтесь перейти хотя бы к moderate , но в идеале — к « eager », который даст больший выигрыш в производительности (а затем к дальнейшему обновлению до prerender , где это имеет смысл).
Пререндеры с низким уровнем риска
Спекуляции с предварительной выборкой легче развернуть, но максимальный выигрыш в производительности для API достигается за счет предварительной визуализации. Это может иметь некоторые дополнительные соображения, когда страница не посещается вскоре после предположения (о чем мы поговорим в следующем разделе), но при moderate или conservative предварительном рендеринге, когда навигация, скорее всего, произойдет вскоре после этого, может быть следующим шагом с относительно низким риском.
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Предварительная выборка общих страниц для улучшения неактивной предварительной обработки
Одна из распространенных тактик — предварительная выборка меньшего количества часто посещаемых следующих страниц при загрузке с eager настройкой (либо путем указания их в списке URL-адресов, либо с помощью selector_matches ), а затем предварительная отрисовка с moderate настройкой. Поскольку предварительная выборка HTML, скорее всего, завершится к моменту наведения ссылки, это дает преимущество по сравнению с простой предварительной отрисовкой при наведении без предварительной выборки.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["next.html", "next2.html"],
"eagerness": "eager"
}],
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Более ранние пререндеры
Хотя moderate правила документа позволяют использовать API с относительно низким уровнем риска и связанной с этим простотой реализации, этого времени часто недостаточно для полной предварительной визуализации. Чтобы добиться мгновенной навигации, которую позволяет этот API, вам, вероятно, придется пойти дальше и более активно выполнять предварительную обработку страниц.
Это достигается с помощью статического списка URL-адресов (как в примере с предварительной выборкой ранее) или с помощью selector_matches идентифицирующего небольшое количество URL-адресов (в идеале одну или две страницы), с правилами документа, охватывающими другие URL-адреса:
<script type="speculationrules">
{
"prerender": [
{
"where": {
"selector_matches": : ".prerender"
},
"eagerness": "eager",
},
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}
]
}
</script>
Для этого может потребоваться анализ трафика, чтобы дать наилучшие шансы точно спрогнозировать следующую навигацию. Понимание типичных путешествий клиентов по вашему сайту также может помочь выявить хороших кандидатов для спекулятивной загрузки.
Переход к более активному предварительному рендерингу может также привести к появлению дополнительных соображений, касающихся аналитики, рекламы и JavaScript, а также необходимости поддерживать предварительно обработанную страницу в актуальном состоянии или даже отменять или обновлять предположения об изменениях состояния.
Аналитика, реклама и JavaScript
При использовании предварительной визуализации на более сложных сайтах также необходимо учитывать влияние на аналитику. Обычно вы не хотите регистрировать просмотр страницы (или объявления), когда страница спекулируется, а только тогда, когда спекуляция активирована.
Некоторые поставщики аналитики (например, Google Analytics) и поставщики рекламы (например, Google Publisher Tag) уже поддерживают правила спекуляций и не регистрируют просмотры, пока страница не будет активирована. Однако другие поставщики или внедрённая вами пользовательская аналитика могут потребовать дополнительного рассмотрения.
Вы можете добавить проверки в JavaScript, чтобы предотвратить выполнение определенных фрагментов кода до тех пор, пока страницы не будут активированы или станут видимыми , и даже обернуть в такие проверки целые элементы <script> . Если страницы используют менеджеры тегов для внедрения таких сценариев, возможно, удастся решить все эти проблемы за один раз, отложив выполнение самого сценария менеджера тегов.
Аналогичным образом, менеджеры согласия дают возможность отложить сторонние скрипты до активации, и Google работает с различными платформами менеджеров согласия, чтобы сделать их поддерживающими предварительную отрисовку, и мы рады помочь другим, кто хочет сделать то же самое. PubTech — одна из таких компаний, которая предлагает разработчикам возможность запускать или блокировать свой JavaScript во время предварительного рендеринга .
Для кода приложения вы можете аналогичным образом добавить изменение, чтобы задержать выполнение кода до активации, особенно если для отображения страницы не требуется код JavaScript. Это более быстрый и безопасный вариант, но он означает, что весь код будет запущен сразу при активации. Это может привести к большому объему работы во время активации, что может повлиять на INP , особенно если страница может выглядеть полностью загруженной и готовой к взаимодействию.
Кроме того, если какой-либо контент зависит от JavaScript (например, контент, отображаемый на стороне клиента), задержка этого уменьшит положительное влияние на LCP и CLS , которое может оказать предварительная отрисовка. Более целенаправленный подход, позволяющий запускать больше JavaScript на этапе предварительной отрисовки, приведет к улучшению взаимодействия, но его реализация может оказаться менее тривиальной.
Начать с полной задержки большого количества тегов скриптов может быть хорошей стратегией на начальном этапе для более сложных сайтов. Однако, чтобы получить максимальную выгоду от API, конечной целью должно быть разрешение запуска как можно большего количества JavaScript во время предварительного рендеринга.
Сайты, у которых есть проблемы с аналитикой или рекламой, также могут начать с предварительной выборки , где это не так важно, пока они рассматривают, что необходимо сделать для поддержки предварительной отрисовки.
Обновление предположений о предварительном рендеринге
При предварительной визуализации страниц перед навигацией существует риск того, что предварительно обработанная страница устареет. Например, на сайте электронной коммерции предварительно обработанная страница может включать корзину для оформления заказа — либо полную корзину товаров, либо даже просто счетчик, показывающий количество товаров в корзине на других страницах. Если в корзину добавляется больше товаров, а затем осуществляется переход на предварительно обработанную страницу, пользователю будет сложно увидеть старое состояние оформления заказа.
Это не новая проблема, и когда у пользователей открыто несколько вкладок в браузере, они сталкиваются с той же проблемой. Однако для предварительно обработанных страниц это более вероятно и более неожиданно, поскольку пользователь сознательно не инициировал предварительную обработку.
API широковещательного канала — это один из способов разрешить одной странице браузера транслировать подобные обновления на другие страницы. Это также решит проблему нескольких вкладок. Предварительно обработанные страницы могут прослушивать широковещательные сообщения, но не могут отправлять собственные широковещательные сообщения, пока они не активированы.
Альтернативно, предварительно обработанные страницы могут получать обновления с помощью сервера (с использованием периодического fetch() или соединения WebSocket ), но с потенциальной задержкой обновлений.
Отменить или обновить предположения о предварительной визуализации
Обновление предварительно обработанных страниц — рекомендуемый подход, позволяющий продолжать использовать предварительно обработанные страницы, избегая при этом путаницы для пользователей. Там, где это невозможно, можно отменить спекуляции.
Это также можно использовать, чтобы оставаться в пределах ограничений Chrome, если сайты хотят предварительно отрисовать другие страницы, которые с большей вероятностью будут посещены.
Чтобы отменить спекуляции, вам необходимо удалить правила спекуляций со страницы или удалить классы или другие критерии соответствия, если вы используете этот подход. Альтернативно, предполагаемая страница может вызвать window.close() если обнаружит, что она больше не актуальна. Хотя, если страница способна это обнаружить, лучшим вариантом будет обновить ее состояние, чтобы вернуть его в актуальное состояние.
Также возможно повторно вставить эти правила (или критерии соответствия), чтобы страницы можно было повторно отображать (хотя, опять же, поддержание существующей страницы в актуальном состоянии обычно является лучшим вариантом, поскольку это менее расточительно). После удаления правил спекуляции повторная вставка должна быть завершена в новой микрозадаче или позже, чтобы позволить браузеру заметить удаления и отменить спекуляции. Один из подходов к удалению и удалению всех сценариев правил спекуляции показан в следующем примере:
async function refreshSpeculations() {
const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');
for (const speculationScript of speculationScripts) {
// Get the current rules as JSON text
const ruleSet = speculationScript.textContent;
// Remove the existing script to reset prerendering
speculationScript.remove();
// Await for a microtask before re-inserting.
await Promise.resolve();
// Reinsert rule in a new speculation rules script
const newScript = document.createElement('script');
newScript.type = 'speculationrules';
newScript.textContent = ruleSet;
console.log(newScript);
// Append the new script back to the document
document.body.appendChild(newScript);
}
}
Удаление правил приведет к отмене существующих претендентов (или предварительной выборки), но повторная вставка правил будет только предполагать немедленные или активные правила (включая правила списка URL-адресов, использующие значение по умолчанию немедленного). Однако умеренные или консервативные предположения будут удалены, но не будут автоматически возобновлены до тех пор, пока ссылка не будет снова использована.
Эта опция обновления не ограничивается правилами, вставленными в JavaScript. Статические правила, включенные в HTML, также можно удалять или изменять таким же образом, поскольку это стандартное изменение DOM. Правила спекуляции HTTP нельзя удалить, но критерии соответствия (например, классы prerender ) можно удалить и повторно добавить с помощью JavaScript.
Chrome также рассматривает возможность добавления поддержки Clear-Site-Header , чтобы позволить ответам сервера отменять предварительные рендеринги (например, при запросе корзины обновлений).
Измерение воздействия
После внедрения правил спекуляции вам следует измерить успех, а не просто предполагать, что он автоматически стал быстрее. Как упоминалось ранее, чрезмерные предположения могут фактически вызвать снижение производительности, если клиент или сервер перегружены.
При реализации с несколькими шагами (предварительная выборка, предварительная обработка с низким уровнем риска, а затем ранняя предварительная обработка) следует проводить измерения на каждом этапе.
Как измерить успех
Правила спекуляций должны оказывать положительное влияние на ключевые показатели производительности, такие как LCP (и, возможно, также на CLS и INP), но это может быть неочевидно в общих показателях на уровне сайта. Это связано с тем, что сайты могут преимущественно состоять из других типов навигации (например, целевые страницы) или потому, что навигация одного и того же источника уже достаточно быстрая, поэтому даже резкое ее улучшение может не повлиять на показатели 75-го процентиля, как указано в отчете Chrome User Experience (CrUX) .
Вы можете использовать типы навигации по страницам в CrUX, чтобы проверить, какой процент переходов является navigate_cache или prerender и увеличивается ли он с течением времени. Однако для детального анализа вам может потребоваться использовать мониторинг реальных пользователей, чтобы сегментировать ваши данные по предполагаемым переходам и увидеть, насколько они быстрее, чем другие способы навигации.
Как измерить использование и потери
Еще одним ключевым моментом является определение того, правильно ли вы размышляете на правильных страницах. Это позволяет избежать потерь и гарантирует, что вы нацеливаетесь на лучшие страницы, которые можно получить от этого API.
К сожалению, страница, инициирующая спекуляции, не может напрямую видеть статус попыток спекуляций. Кроме того, нельзя предполагать, что попытки были инициированы, поскольку при определенных обстоятельствах браузер может сдерживать спекуляции . Поэтому их необходимо измерять на самой странице. Это также требует проверки двух API, чтобы увидеть, спекулирует ли страница или уже спекулировала:
if (document.prerendering) {
console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
console.log("Page has already prerendered");
} else {
console.log("This page load was not using prerendering");
}
Затем на этой странице можно зарегистрировать попытки спекуляций на внутренних серверах.
Одной из сложностей с аналитикой являются поставщики (такие как Google Analytics), которые поддерживают предварительную визуализацию и игнорируют вызовы аналитики до тех пор, пока страница не будет активирована, даже отдельные вызовы событий. Поэтому пользователи Google Analytics должны использовать другой вариант ведения журнала на стороне сервера.
Это также возможно на стороне клиента, при этом каждая предварительно обработанная страница регистрирует предварительную обработку в общем хранилище, и вызывающая страница считывает ее. localStorage работает лучше всего, поскольку его можно прочитать при выходе со страницы (обратите внимание, что sessionStorage нельзя использовать, поскольку он имеет специальную обработку для предварительно обработанных страниц ). Однако имейте в виду, что localStorage не является транзакционно безопасным, и другие страницы могут обновлять его одновременно, если несколько страниц предварительно обрабатываются. В этой демонстрации используется уникальный хэш и отдельные записи, чтобы избежать проблем с этим.
Заключение
Правила спекуляции предлагают возможность значительного повышения производительности вашей страницы. В этом руководстве даются советы по реализации этого API, чтобы избежать любых потенциальных проблем, а также получить максимальную отдачу от API.
Заблаговременное планирование реализации позволит избежать переделок. В частности, для более сложных сайтов за этим должно последовать многоэтапное развертывание, начиная с предварительной выборки, а затем переходя к предварительному рендерингу с низким уровнем риска, а затем к раннему предварительному рендерингу. Наконец, важно измерять улучшения, а также любое использование и потери, чтобы гарантировать оптимальное использование API.