Как добавить Virtual Try-On в BigCommerce

Продавцы на BigCommerce не могут просто вставить app-block в стиле Shopify в тему и считать дело сделанным — структура шаблонов Stencil означает, что размещение скрипта и точки подключения к странице товара имеют значение. Ошибетесь с подключением — и кнопка try-on либо вообще не отрисуется, либо сломается на вашем самом продаваемом шаблоне товара. Это руководство пошагово разбирает реальные правки Stencil, чтобы день запуска не превратился в сессию отладки.

Фреймворк Stencil от BigCommerce разделяет зоны ответственности так, что это сбивает с толку команды, привыкшие к более монолитным редакторам тем: шаблоны Handlebars рендерят разметку, theme.js (или ваш кастомный бандл) отвечает за поведение, а слой виджетов Page Builder лежит поверх обоих. Virtual try-on нужна точка опоры во всех трех слоях, если вы хотите, чтобы он пережил обновление темы. Ниже — последовательность, которую мы рекомендуем продавцам, интегрирующим YourSizer или похожие инструменты try-on на BigCommerce.

Почему интеграция с BigCommerce — это не просто "вставить тег скрипта"

Универсальный скрипт встраивания, вставленный в header.html, технически загрузится, но не будет знать, какой товар просматривает покупатель, какие изображения доступны и где отрисовать триггер try-on относительно кнопки "Добавить в корзину". Страницы товаров BigCommerce передают структурированные данные через Handlebars-контекст product и глобальную переменную window.BCData, и правильно подключенный виджет try-on должен читать данные именно оттуда, а не парсить DOM.

Это важно, потому что темы Stencil (Cornerstone и его форки) периодически обновляются, и скрипты, парсящие DOM, молча ломаются, когда автор темы переставляет элементы местами. Чтение из BCData.product_attributes или встроенного в страницу JSON товара гораздо надежнее. Это небольшой дополнительный шаг при настройке, который спасет вас от тикета в поддержку через три месяца, когда поставщик темы выпустит обновление.

Подготовка темы Stencil перед правкой кода

Прежде чем что-либо редактировать, скачайте локальную копию темы через Stencil CLI (stencil pull), а не редактируйте напрямую в редакторе тем BigCommerce. Это даст вам контроль версий и путь отката, если правка шаблона сломает страницу товара.

Для интеграции try-on важнее всего два файла:

Также стоит уточнить, какой вариант шаблона товара использует ваш магазин — Cornerstone поставляется с несколькими макетами product-view, а кастомные темы часто форкают этот файл. Проверьте config.json на предмет активной темы, прежде чем предполагать, что применимы пути по умолчанию Cornerstone.

Размещение скрипта: где на самом деле загружается бандл try-on

Добавьте загрузочный скрипт try-on в templates/layout/base.html, прямо перед закрывающим тегом </body>, с условием, чтобы он загружался только на страницах товаров:

{{#if type "product"}}
  <script src="https://cdn.yoursizer.com/widget/loader.js" defer></script>
{{/if}}

Загрузка его по всему магазину с атрибутом defer обычно тоже приемлема — вес скрипта невелик, а глобальная загрузка дает виджету точку опоры и на страницах коллекций, если позже вы добавите превью "быстрый try-on" из сеток категорий. Но если вы агрессивно оптимизируете Core Web Vitals, условное {{#if type "product"}} ограничивает загрузку тем местом, где скрипт реально используется.

Не размещайте скрипт в <head>, если только он явно не построен для асинхронной, не блокирующей рендеринг загрузки — синхронный тег скрипта в <head> на странице товара — частая причина задержки Largest Contentful Paint, которую собственные отчеты о производительности Page Builder от BigCommerce обязательно отметят.

Подключение виджета к шаблону страницы товара

Это шаг, на котором большинство интеграций ошибается: кнопка-триггер должна располагаться рядом с селекторами размера/варианта, а не болтаться отдельно вверху или внизу страницы. В product-view.html найдите блок, рендерящий product.options или форму "Добавить в корзину", и вставьте контейнерный div сразу после него:

<div id="yoursizer-tryon-root"
     data-product-id="{{product.id}}"
     data-product-images="{{product.images}}">
</div>

Затем в product-details.js подключите вызов монтирования виджета к тому же жизненному циклу, который BigCommerce использует для обновления страницы при смене покупателем варианта/цвета — обычно это updateProductAttributes во вью ProductDetails или его эквивалент. Это критично: если покупатель переключается с "Красного" на "Синий", превью try-on должно перерендериться с новыми изображениями товара, а не продолжать показывать старый цвет. Пропуск этого шага — самая частая единичная ошибка, которую мы видим в ранних попытках интеграции: виджет работает при загрузке страницы, а затем молча показывает не ту вещь после смены варианта.

QA на staging перед выходом в продакшн

BigCommerce позволяет предпросмотреть изменения темы на staging-URL перед публикацией, и этот шаг не опционален для интеграции try-on — именно здесь вы отловите описанный выше баг синхронизации вариантов, а также проблемы мобильной верстки. Пройдите этот чек-лист на staging:

• Загрузите товар с несколькими вариантами цвета/размера и убедитесь, что превью try-on обновляется при смене варианта.
• Протестируйте на реальном мобильном устройстве, а не только в уменьшенном окне десктопного браузера — мобильный шаблон товара в Stencil может структурно отличаться от десктопного.
• Убедитесь, что виджет не сдвигает кнопку "Добавить в корзину" ниже видимой области на маленьких экранах.
• Проверьте товар с одним вариантом и без изображений, чтобы убедиться, что виджет корректно обрабатывает ошибку, а не выбрасывает ошибку в консоль.
• Убедитесь, что загрузка скрипта не ухудшает ваш показатель производительности Page Builder.

Только после прохождения этих проверок стоит публиковать правку темы в вашем действующем магазине. Поскольку правки на базе Stencil выполняются на уровне файлов, а не являются переключаемой установкой приложения, откат неудачного деплоя означает повторную публикацию предыдущей версии темы — так что QA на staging и есть ваша настоящая страховочная сетка, а не быстрый хотфикс в продакшне.

Где здесь место YourSizer

Интеграция YourSizer с BigCommerce построена так, чтобы читать данные товара и варианта напрямую из контекста товара Stencil, а не парсить отрендеренный HTML, что закрывает описанный выше пробел в надежности. Загрузочный скрипт монтируется в контейнерный div, который вы размещаете в product-view.html, а виджет слушает те же события смены варианта, которые нативно генерирует BigCommerce, поэтому смена цвета и размера остается синхронизированной без кастомного подключения событий с вашей стороны. Для команд, которым нужен слой рекомендации размера вместе с try-on, а не вместо него, оба работают из одного скрипта и контейнера — полезный контекст, если вы также рассматриваете как выбрать решение для рекомендации размера для того же каталога товаров. Сама настройка не требует полной переработки темы; большинство продавцов завершают описанную выше правку шаблона и прохождение QA на staging за один день.

Часто Задаваемые Вопросы

Требует ли добавление virtual try-on в BigCommerce кастомного приложения, или можно обойтись только правкой темы?

Существуют оба подхода. Интеграция на уровне темы — прямая правка product-view.html и base.html, как описано выше — дает максимальный контроль над размещением, и именно ее используют для запуска большинство команд, знакомых со Stencil. Некоторые поставщики try-on также предлагают листинг в BigCommerce App Marketplace, который устанавливается через OAuth и автоматически внедряет скрипт, обменивая часть контроля над размещением на более быструю настройку без правок кода. Если ваша команда уже поддерживает кастомную тему Stencil, ручной путь обычно проще держать согласованным с вашей дизайн-системой.

Замедлит ли virtual try-on мои страницы товаров BigCommerce?

Может, если скрипт загружается синхронно в <head> или бандл не оптимизирован для ленивой загрузки. Загрузка скрипта с defer и ограничение его только шаблонами страниц товаров, как показано выше, сводит влияние к минимуму — обычно сопоставимо с добавлением виджета чата или плагина отзывов. Стоит проверить отчет Page Builder или Core Web Vitals до и после запуска интеграции, поскольку BigCommerce нативно показывает эти данные, и это самый надежный способ убедиться, что ничего не деградировало.

Чем virtual try-on отличается от стандартной таблицы размеров на странице товара BigCommerce?

Таблица размеров — это статичная справочная таблица, которую покупатель должен соотнести со своими собственными мерками, тогда как virtual try-on генерирует визуальное превью того, как конкретная вещь выглядит на теле или аватаре. Они решают пересекающиеся, но разные задачи — одна отвечает на вопрос "подойдет ли мне это по размеру", другая — "хорошо ли это будет на мне смотреться" — и многие продавцы используют оба инструмента параллельно, а не заменяют один другим. Если вы решаете, чему отдать приоритет при ограниченном бюджете на разработку, virtual try-on против рекомендации размера разбирает этот компромисс подробнее.

Заключение

Правильная реализация virtual try-on на BigCommerce сводится к уважению того, как Stencil на самом деле рендерит и обновляет страницу товара — размещение скрипта, точки подключения к смене варианта и реальный прогон на staging важнее, чем выбор поставщика try-on. Сделайте подключение шаблона правильно один раз, и оно выдержит обновления темы и изменения каталога, не превращаясь в постоянную работу по обслуживанию; пропустите этап QA на staging — и вы, скорее всего, узнаете о баге синхронизации вариантов от клиента, а не от тестового прогона.