В 2021 году команда Chrome Aurora представила компонент Script для улучшения производительности загрузки сторонних скриптов в Next.js. С момента его запуска мы расширили его возможности, чтобы сделать загрузку сторонних ресурсов проще и быстрее для разработчиков.
В этой записи блога представлен обзор новых функций, которые мы выпустили, в частности библиотеки @next/third-party , а также краткое описание будущих инициатив в нашей дорожной карте.
Влияние сторонних скриптов на производительность
41% всех сторонних запросов на сайтах Next.js — это скрипты. В отличие от других типов контента, скрипты могут занимать значительное время для загрузки и выполнения, что может блокировать рендеринг и задерживать интерактивность пользователя. Данные из отчета Chrome User Experience Report (CrUX) показывают, что сайты Next.js, которые загружают больше сторонних скриптов, имеют более низкие показатели Interaction to Next Paint (INP) и Largest Contentful Paint (LCP) .
Корреляция, наблюдаемая в этой диаграмме, не подразумевает причинно-следственную связь. Однако локальные эксперименты предоставляют дополнительные доказательства того, что сторонние скрипты существенно влияют на производительность страницы. Например, на диаграмме ниже сравниваются различные лабораторные показатели, когда контейнер Google Tag Manager, содержащий 18 случайно выбранных тегов, добавляется в Taxonomy , популярный пример приложения Next.js.
Документация WebPageTest содержит подробную информацию о том, как измеряются эти тайминги. С первого взгляда становится ясно, что на все эти лабораторные показатели влияет контейнер GTM. Например, общее время блокировки (TBT) — полезный лабораторный прокси, который приблизительно соответствует INP — увеличилось почти в 20 раз.
Компонент скрипта
Когда мы отправили компонент <Script> в Next.js, мы убедились, что представляем его через удобный API, который очень похож на традиционный элемент <script> . Используя его, разработчики могут разместить сторонний скрипт в любом компоненте своего приложения, а Next.js позаботится о последовательности скрипта после загрузки критических ресурсов.
<!-- By default, script will load after page becomes interactive -->
<Script src="https://example.com/sample.js" />
<!-- Script is injected server-side and fetched before any page hydration occurs -->
<Script strategy=”beforeInteractive” src="https://example.com/sample.js" />
<!-- Script is fetched later during browser idle time -->
<Script strategy=”lazyOnload” src="https://example.com/sample.js" />
Десятки тысяч приложений Next.js, включая такие популярные сайты, как Patreon , Target и Notion , используют компонент <Script> . Несмотря на его эффективность, некоторые разработчики выразили обеспокоенность по поводу следующих вещей:
- Где разместить компонент
<Script>в приложении Next.js, следуя различным инструкциям по установке от разных сторонних поставщиков (опыт разработчика) . - Какую стратегию загрузки лучше всего использовать для различных сторонних скриптов (пользовательский опыт) .
Чтобы решить обе эти проблемы, мы запустили @next/third-parties — специализированную библиотеку, предлагающую набор оптимизированных компонентов и утилит, разработанных для популярных сторонних разработчиков.
Опыт разработчика: как упростить управление сторонними библиотеками
Многие сторонние скрипты используются на значительном проценте сайтов Next.js, при этом Google Tag Manager является самым популярным, его используют 66% сайтов соответственно . @next/third-parties строится на основе компонента <Script> , внедряя высокоуровневые оболочки, разработанные для упрощения использования в этих распространенных случаях.
import { GoogleAnalytics } from "@next/third-parties/google";
export default function RootLayout({ children }) {
return (
<html lang="en">
<body>{children}</body>
<GoogleTagManager gtmId="GTM-XYZ" />
</html>
);
}
Google Analytics — еще один широко используемый сторонний скрипт ( 52% сайтов Next.js ) — также имеет собственный выделенный компонент.
import { GoogleAnalytics } from "@next/third-parties/google";
export default function RootLayout({ children }) {
return (
<html lang="en">
<body>{children}</body>
<GoogleAnalytics gaId="G-XYZ" />
</html>
);
}
@next/third-parties упрощает процесс загрузки часто используемых скриптов, но также расширяет наши возможности по разработке утилит для других сторонних категорий, таких как встраивания. Например, встраивания Google Maps и YouTube используются на 8% и 4% веб-сайтов Next.js соответственно, и мы также отправили компоненты, чтобы упростить их загрузку.
import { GoogleMapsEmbed } from "@next/third-parties/google";
import { YouTubeEmbed } from "@next/third-parties/google";
export default function Page() {
return (
<>
<GoogleMapsEmbed
apiKey="XYZ"
height={200}
width="100%"
mode="place"
q="Brooklyn+Bridge,New+York,NY"
/>
<YouTubeEmbed videoid="ogfYd705cRs" height={400} params="controls=0" />
</>
);
}
Пользовательский опыт: ускорение загрузки сторонних библиотек
В идеальном мире каждая широко распространенная сторонняя библиотека была бы полностью оптимизирована, что сделало бы любые абстракции, которые улучшают ее производительность, ненужными. Однако, пока это не станет реальностью, мы можем попытаться улучшить их пользовательский опыт при интеграции через популярные фреймворки, такие как Next.js. Мы можем экспериментировать с различными методами загрузки, гарантировать, что скрипты упорядочены правильным образом, и в конечном итоге делиться своими отзывами со сторонними поставщиками, чтобы поощрять изменения в восходящем направлении.
Возьмем, к примеру, вставки YouTube. Где некоторые альтернативные реализации имеют гораздо лучшую производительность, чем нативная вставка. В настоящее время компонент <YouTubeEmbed> , экспортируемый @next/third-parties использует lite-youtube-embed , который, как было продемонстрировано в сравнении Next.js "Hello, World", загружается значительно быстрее.
Аналогично, для Google Maps мы включаем loading="lazy" как атрибут по умолчанию для встраивания, чтобы гарантировать, что карта загружается только на определенном расстоянии от области просмотра. Это может показаться очевидным атрибутом для включения, особенно с учетом того, что документация Google Maps включает его в свой пример фрагмента кода, но только 45% сайтов Next.js , встраивающих Google Maps, используют loading="lazy" .
Запуск сторонних скриптов в веб-воркере
Одна из передовых методик, которую мы изучаем в @next/third-parties — это упрощение выгрузки сторонних скриптов в веб-воркер. Популяризированная такими библиотеками, как Partytown , эта технология может существенно снизить влияние сторонних скриптов на производительность страницы, полностью перемещая их из основного потока.
Следующий анимированный GIF-файл показывает изменения в длительных задачах и времени блокировки основного потока при применении различных стратегий <Script> к контейнеру GTM на сайте Next.js. Обратите внимание, что, хотя переключение между вариантами стратегии только задерживает время выполнения этих скриптов, перемещение их в веб-воркер полностью исключает их время в основном потоке.
В этом конкретном примере перенос выполнения контейнера GTM и связанных с ним скриптов тегов в веб-воркер сократил TBT на 92% .
Стоит отметить, что при отсутствии должного контроля эта техника может незаметно сломать множество сторонних скриптов, что усложнит отладку. В ближайшие месяцы мы проверим, правильно ли работают сторонние компоненты, предлагаемые @next/third-parties при запуске в веб-воркере. Если да, то мы постараемся предоставить разработчикам простой и необязательный способ использования этой техники.
Следующие шаги
В процессе разработки этого пакета стало очевидно, что необходимо централизовать рекомендации по загрузке сторонних приложений, чтобы другие фреймворки также могли извлечь выгоду из тех же базовых методов, которые используются. Это привело нас к созданию Third Party Capital — библиотеки, которая использует JSON для описания методов загрузки сторонних приложений, которая в настоящее время служит основой для @next/third-parties .
В качестве наших следующих шагов мы продолжим фокусироваться на улучшении компонентов, предоставляемых для Next.js, а также расширим наши усилия по включению аналогичных утилит в другие популярные фреймворки и платформы CMS. В настоящее время мы сотрудничаем с разработчиками Nuxt и планируем выпустить аналогичные сторонние утилиты, адаптированные к их экосистеме, в ближайшем будущем.
Если один из сторонних компонентов, которые вы используете в своем приложении Next.js, поддерживается @next/third-parties , установите пакет и попробуйте! Мы будем рады услышать ваши отзывы на GitHub .