На этой странице
Стандартные интеграции тем Shopify предполагают шаблон Liquid и тег
<script>, размещенный вtheme.liquid. В витринах Hydrogen их нет ни того, ни другого — это приложения React Router, работающие на Oxygen с серверной отрисовкой и границами гидратации, для которых большинство встраиваемых виджетов никогда не были разработаны. Если вы неправильно выполните интеграцию, вы сломаете страницу для сканеров и пользователей с медленным соединением или выпустите кнопку виртуальной примерки, которая мигает, двойно отрисовывается или никогда полностью не загружается.
Принятие headless Shopify быстро растет среди мода-брендов среднего и корпоративного уровня, которые хотят большего контроля над производительностью и дизайном витрины, чем позволяют темы Liquid. Hydrogen, официальный фреймворк React Shopify для этого, сочетается с хостингом Oxygen и серверной отрисовкой в стиле Remix. Эта архитектура отлично подходит для скорости и гибкости, но она изменяет правила для любого стороннего виджета — включая опыт виртуальной примерки или рекомендации размера — который предполагает обычную HTML-страницу с jQuery, доступным на window.
Почему стандартные скрипты встраивания не работают в Hydrogen
Типичный виджет электронной коммерции поставляется как один тег <script src="...">, который автоматически монтируется путем запроса DOM один раз после загрузки страницы. Этот паттерн зависит от двух вещей, которые Hydrogen не гарантирует: стабильного и полностью отрисованного DOM в момент выполнения скрипта и одного прохода отрисовки на клиенте.
Hydrogen сначала отрисовывает страницы товаров на сервере, передает HTML в браузер, а затем гидратирует React на клиенте для добавления интерактивности. Если скрипт виртуальной примерки запросит document.querySelector('#product-image') до завершения гидратации, он может присоединиться к узлу DOM, который React собирается заменить, что приведет к отсоединенному виджету или двойному монтажу. Хуже того, если скрипт выполнится во время SSR (потому что он не был защищен), он сразу же дает ошибку, так как window и document не существуют на сервере.
Исправление не является экзотичным — это та же дисциплина, которую любой разработчик React применяет к коду, зависящему от третьей стороны в DOM — но это должно быть намеренным. Рассматривайте опыт виртуальной примерки как компонент React только на стороне клиента, а не тег скрипта, и монтируйте его внутри существующего дерева компонентов Hydrogen, а не крепите снаружи.
Паттерн интеграции на основе компонентов
Вместо того, чтобы внедрять скрипт, оберните кнопку виртуальной примерки и модаль в выделенный компонент, который маршрут товаров Hydrogen отрисовывает непосредственно:
// app/components/TryOnButton.client.tsx
import { Suspense, lazy } from 'react';
const TryOnWidget = lazy(() => import('./TryOnWidget'));
export function TryOnButton({ productId, imageUrl }) {
return (
<Suspense fallback={<button disabled>Загрузка виртуальной примерки…</button>}>
<TryOnWidget productId={productId} imageUrl={imageUrl} />
</Suspense>
);
}Здесь имеет значение несколько вещей. Суффикс .client.tsx (или эквивалентный обертка ClientOnly, если проект использует его) сообщает фреймворку, что этот компонент не должен пытаться отрисовываться на сервере. lazy() откладывает загрузку пакета JavaScript виджета до тех пор, пока он действительно не потребуется, что удерживает его вне критического пути отрисовки для покупателей, которые никогда не нажимают кнопку виртуальной примерки. Suspense дает вам реальное состояние fallback вместо смещения макета, когда пакет завершит загрузку.
Этот паттерн также означает, что триггер виртуальной примерки отрисовывается как часть обычной разметки страницы товаров — одна и та же позиция каждый раз, без ожидания отдельного скрипта, чтобы найти и изменить DOM после факта. Опыт виртуальной примерки становится просто еще одним компонентом React в дереве, а не посторонним объектом, прикрепленным к нему.
Управление гидратацией без смещения макета
Смещение макета — это наиболее распространенный видимый симптом плохой headless-интеграции. Если контейнер кнопки виртуальной примерки не имеет зарезервированного размера до того, как компонент монтируется, страница прыгает, когда он появляется — причиняя вред как опыту покупателя, так и Cumulative Layout Shift, одному из Core Web Vitals Google.
Надежное исправление состоит в том, чтобы зарезервировать пространство с помощью CSS перед любым выполнением JavaScript, а не позволять реальным размерам кнопки определять макет после факта:
| Подход | Риск смещения макета | Примечания |
|---|---|---|
| Кнопка с внедренным скриптом, без заполнителя | Высокий | Распространенная причина штрафов CLS на PDP |
| Контейнер фиксированной высоты + компонент lazy | Низкий | Зарезервируйте высоту в пикселях в CSS перед монтажом |
| Плейсхолдер, отрисованный сервером + обмен клиента | Минимальный | Требует статический, неинтерактивный fallback SSR |
Для большинства витрин Hydrogen контейнера flex с фиксированной высотой вокруг границы Suspense достаточно — вам не нужен полный SSR самого интерфейса виртуальной примерки, так как кнопка и модаль по своей природе интерактивны и добавляют мало к HTML, отрисовываемому на сервере, который индексируют поисковые системы.
Сохранение производительности страницы товаров
Oxygen и Hydrogen построены на основе быстрого Time to First Byte и агрессивного кэширования, и легко аннулировать это преимущество с помощью плохо ограниченного пакета третьей стороны. Несколько практических защитных мер:
- Загружайте пакет виртуальной примерки только на маршруты товаров и коллекций, а не глобально в корневой макет, чтобы страницы без точки входа "попробовать" не несли затраты на загрузку.
- Отложите получение ресурсов изображений/моделей (доступ к камере, файлы модели тела, отрисовки одежды) до тех пор, пока покупатель не откроет модаль виртуальной примерки, а не при загрузке страницы.
- Убедитесь, что виджет не регистрирует глобальные прослушиватели событий, которые пережив переходы маршрутов — маршрутизация на стороне клиента Hydrogen означает, что компоненты монтируются и демонтируются гораздо чаще, чем в традиционной многостраничной теме Liquid, и пропущенный прослушиватель накапливается в течение сеанса.
Эта последняя точка обманывает интеграции, построенные для статических сайтов: они предполагают, что страница перезагружается между товарами, поэтому очистка никогда не была проблемой. В одностраничном приложении это так.
Где встраивается YourSizer
Виджет YourSizer построен как набор встраиваемых компонентов React/JS, которые естественно отображаются на модель компонента Hydrogen вместо того, чтобы требовать глобального внедрения скрипта. Для витрины Hydrogen это обычно означает импорт триггера виртуальной примерки и рекомендации размера как компонента только на стороне клиента на маршруте товаров, передачу ID товаров и ссылки на изображение как параметры и позволить ему лениво загружать свой пакет за границей Suspense — тот же паттерн, описанный выше.
Поскольку интеграция не зависит от хуков шаблонов Liquid, она работает одинаково независимо от того, находится ли витрина на Oxygen, Vercel или другой цели хостинга для headless-сборки. Команды, оценивающие более широкое решение для рекомендации размера для миграции headless, обычно обнаруживают, что техническая интеграция — это простая часть — более сложная работа заключается в том, чтобы решить, где в потоке покупок (PDP, корзина или оба) должна находиться точка входа виртуальной примерки, что является решением мерчендайзинга, а не инженерного решения.
Часто задаваемые вопросы
Замедляет ли виртуальная примерка Core Web Vitals витрины Hydrogen?
Нет, если интеграция правильно ограничена. Основной риск для Largest Contentful Paint и Cumulative Layout Shift исходит от загрузки полного пакета виртуальной примерки с нетерпением на каждый загрузку страницы и отсутствия резервирования пространства макета для кнопки триггера. Ленивая загрузка компонента за импортом, специфичным для маршрута, и зарезервирование фиксированного размера контейнера в CSS удерживают функцию виртуальной примерки вне метрик, которые Google использует для сигналов опыта страницы.
Может ли виджет виртуальной примерки быть отрисован на сервере в Hydrogen?
Интерактивные части — захват камеры, отрисовка одежды, логика размера — обычно не могут быть значимо отрисованы на сервере, поскольку они зависят от API браузера и состояния клиента. То, что может и должно быть отрисовано на сервере, это статическая оболочка вокруг него: метка кнопки, ее позиция в макете и любые структурированные данные товаров. Рассмотрение интерактивного виджета как компонента только на стороне клиента при позволении остальной части страницы нормально отрисовываться на сервере является стандартным подходом.
Является ли миграция headless Shopify хорошим временем для добавления инструментов виртуальной примерки или рекомендации размера?
Это разумное время для планирования интеграции, поскольку команда уже работает с шаблонами страниц товаров и выбирает архитектуру компонента. Некоторые бренды предпочитают сначала запустить витрину headless с функциональной паритетностью с существующей темой, а затем добавить виртуальную примерку в качестве следующего шага, как только новая архитектура стабилизируется. Оба порядка работают; то, что имеет значение, это то, что интеграция разработана как собственный компонент, а не перенесена как тег скрипта эры Liquid, что является источником большей части трения, описанного выше.
Чем это отличается от добавления виртуальной примерки к стандартной теме Shopify Liquid?
На теме Liquid интеграция обычно представляет собой тег скрипта и фрагмент, вставленные в product.liquid, с виджетом, локализирующим свою точку монтажа через запросы DOM после загрузки страницы. В Hydrogen эквивалентная точка монтажа — это ссылка на компонент React, которая передает явные параметры, и собственный цикл отрисовки фреймворка — не прослушиватель DOMContentLoaded — определяет, когда и как появляется виджет. Конечный опыт пользователя может выглядеть одинаково; основной договор интеграции различен.
Заключение
Headless Shopify вознаграждает команды, которые рассматривают каждую функцию витрины, включая виртуальную примерку, как часть первого класса дерева компонентов, а не как побочную мысль, прикрепленную к странице. Технические требования — отрисовка только на стороне клиента, ленивая загрузка, резервирование макета — не являются ни экзотичными, ни сложными, но они должны обрабатываться целенаправленно во время сборки Hydrogen, а не ретрофитированы позже. Бренды, которые делают это правильно, получают опыт виртуальной примерки, который загружается быстро, не смещает страницу и естественно вписывается в витрину, как любой другой компонент React, что в конечном итоге и должна была обеспечить миграция headless в первую очередь.