

Миграция на Hyvä-тему для Magento: технические особенности и что нужно знать бизнесу
Миграция на Hyvä — это не косметическое обновление темы и не «сделать красивее». Это замена всего фронтенда Magento 2: старый стек Luma (Knockout.js, RequireJS, jQuery, LESS) убирается полностью, а на его место приходят Tailwind CSS и Alpine.js. Для бизнеса это означает одно — страницы, которые загружаются в 4–5 раз легче, и фронтенд, который годами не превращается в технический долг.
Мы смотрим на миграцию не как на разовую задачу «переехать на новую тему», а как на решение, которое напрямую влияет на скорость, конверсию и стоимость дальнейшего развития магазина. Luma-фронтенд, который Magento тянет за собой с 2015 года, — это главная причина, почему даже хорошо сделанные магазины медленны на мобильных и дороги в поддержке. Hyvä убирает именно эту причину, а не её симптомы.
Техническая реализация всегда адаптируется под конкретный проект: объём каталога, набор расширений, кастомную логику и бюджет. Но задача всегда одна — чтобы магазин быстрее загружался, легче развивался и лучше конвертировал трафик, который вы уже оплачиваете.
В этой статье мы разберём:
Миграция на Hyvä подходит магазинам, которые уже имеют трафик и продажи, но упираются в скорость, дорогую поддержку фронтенда или низкую мобильную конверсию. Если ваш Magento «в целом работает», но каждая доработка стоит дорого и долго, а PageSpeed на мобильных держится в красной зоне — это типичная ситуация, где Hyvä даёт наибольший эффект.
Что такое Hyvä и чем она отличается от Luma


Стандартный фронтенд Magento 2 (Luma) построен на тяжёлом стеке: Knockout.js для реактивности, RequireJS для загрузки модулей, jQuery, UI-компоненты и LESS. Каждая из этих технологий когда-то была оправданной, но сегодня вместе они дают медленный, раздутый и сложный в поддержке фронтенд. Страница товара на Luma весит около 0.9 МБ JS/CSS ещё до того, как загрузится контент.
Hyvä — это полная замена фронтенда. Она выбрасывает весь этот стек и заменяет его на два инструмента: Tailwind CSS для стилей и Alpine.js для интерактивности. Результат — та же страница товара весит около 0.15 МБ, то есть в 4–5 раз меньше кода. Lighthouse-показатели стабильно держатся выше 90, а разработка становится проще и дешевле, потому что код чистый и читабельный.
Важно понимать границу: Hyvä меняет только фронтенд. Бэкенд Magento, каталог, заказы, интеграции, админка — всё остаётся тем же самым. Вы не мигрируете данные и не переписываете бизнес-логику. Вы заменяете слой, который отвечает за то, что видит и чувствует пользователь.
Актуальная версия на 2026 год — Hyvä 1.4.x, которая уже работает на Tailwind CSS v4 и новом движке сборки Oxide (написанном на Rust), что существенно ускоряет билды. Это зрелая технология: за ней стоят сотни агентств-партнёров и тысячи совместимых расширений.
Что изменилось в 2026: ядро Hyvä теперь бесплатное
Это самое важное изменение, о котором многие ещё не знают. До недавнего времени Hyvä стоила единоразово €1000 за один магазин — и именно эта плата была главным барьером для входа.
С 10 ноября 2025 года ядро Hyvä стало open-source и бесплатным (лицензии OSL 3.0 / AFL 3.0 — те же, что и у Magento Open Source). Тема доступна бесплатно через GitHub и Composer-ключи в Hyvä Portal. Плата €1000 за стор отменена полностью.
Что осталось платным — отдельные коммерческие продукты, и их стоит закладывать в бюджет осознанно:
Hyvä UI — набор готовых UI-компонентов, €250 единоразово.
Hyvä Checkout — отдельная быстрая checkout-система на Alpine.js + Magewire, около €1000 единоразово (или подписка ~€250/год). Не обязательна: можно оставить стандартный Magento checkout через Luma fallback.
Hyvä Enterprise / премиум-поддержка — для крупных проектов, отдельно.
Для бизнеса вывод простой: сама тема больше ничего не стоит, но миграция — стоит. Основная инвестиция теперь не в лицензию, а в работу разработчиков: перевёрстку, адаптацию разработок и проверку совместимости расширений. Об этом — далее.
Что бизнес реально получает от миграции
Скорость. Страницы в 4–5 раз легче, Core Web Vitals в зелёной зоне, PageSpeed выше 90 — особенно заметно на мобильных, где и теряется большинство конверсии.
Более высокая конверсия. Чистый код на Tailwind и Alpine означает, что каждая новая доработка делается быстрее и дешевле. Технический долг Luma перестаёт накапливаться.
Более дешёвая поддержка. Чистий код на Tailwind і Alpine означає, що кожна нова доробка робиться швидше і дешевше. Технічний борг Luma перестає накопичуватись.
Лучший SEO.Google учитывает Core Web Vitals в ранжировании. Лёгкий фронтенд — это не только UX, но и позиции в выдаче.
Более простой найм и развитие.Tailwind и Alpine — современный, распространённый стек. Найти разработчика под него легче, чем под Knockout/RequireJS, которые мало кто хочет поддерживать.
Подходы к миграции: что работает на разных этапах
Формат миграции зависит от того, насколько кастомный ваш текущий магазин, сколько на нём сторонних расширений и можно ли позволить себе паузу в развитии. Мы выбираем подход исходя из реальной ситуации, а не по шаблону.
01. Полная миграция (Full Rebuild)
Фронтенд перевёрстывается с нуля на Hyvä сразу для всего магазина. Это самый чистый результат: никаких остатков Luma, максимальная скорость, единый стек по всему сайту.
Такой подход выбирают, когда магазин либо относительно стандартный (меньше кастомных разработок = меньше рисков), либо когда бизнес готов инвестировать в полное переосмысление фронтенда вместе с редизайном. Это дороже и дольше на старте, но даёт лучшую базу для масштабирования. Ключевое условие — на время работ развитие текущего фронтенда фактически ставится на паузу.
02. Поэтапная миграция (Phased)
Магазин переезжает по частям: сначала самые критичные для конверсии страницы (главная, каталог, карточка товара), потом остальные. На переходный период часть сайта работает на Hyvä, часть — ещё на Luma.
Это снижает риски и позволяет бизнесу не останавливать продажи. Вы видите эффект от самых важных страниц раньше, а сложные кастомные куски мигрируете последними, когда команда уже «в теме». Минус — временная гибридность и чуть больший общий объём работ из-за двойной поддержки на переходный период.
03. Гибрид: Hyvä на конверсионном ядре, Luma для legacy-контента
Это вариант, который мы отдельно рекомендуем магазинам с большим количеством кастомного контента — и именно он позволяет получить основные плюсы Hyvä без переписывания темы «от корки до корки».
Идея простая. Вы переносите на Hyvä то, что реально влияет на скорость и продажи — конверсионное ядро: каталог (PLP), карточку товара (PDP), корзину, главную, а также общие header и footer. А страницы, которые дорого и долго переписывать, оставляете работать на Luma. Технически это делается через официальный модуль theme fallback (hyva-themes/magento2-theme-fallback): для явно настроенных routes или URL Hyvä-тема на этих страницах отключается, и они рендерятся традиционной Luma-темой. Для пользователя переход незаметен.
Чаще всего на Luma логично оставить:
Checkout- самая кастомная и самая рискованная страница, завязанная на платёжные и доставочные интеграции.
Legacy CMS-сторінки на PageBuilder - старые лендинги и промо-страницы, собранные из кастомных PageBuilder-компонентов, у которых свой JS и своя стилизация.
Сторінки акаунту - низкий трафик, низкий приоритет.
Почему это выгодно именно для CMS-тяжёлых проектов. Если на магазине десятки CMS-страниц, собранных из кастомных PageBuilder-компонентов или контента в html-разметке, пересохранённого в настройки страницы, их переписывание под Hyvä — это недели работы, потому что каждый нестандартный компонент со своим JS/CSS нужно портировать вручную. При этом такие страницы на Luma не тянут самые тяжёлые product-скрипты — то есть они и так относительно лёгкие. Вопрос всегда в размере: платить неделями разработки за переписывание десятков лендингов ради прироста скорости именно на них — часто экономически нецелесообразно.
Главное преимущество подхода: вы ничего не теряете.. Старые лендинги как работали, так и работают — их контент остаётся валидным нативным PageBuilder-форматом в базе, и его можно спокойно редактировать через админку (пересохранение страницы ничего не ломает и не «конвертирует»). А все новые лендинги вы делаете уже сразу под Hyvä — это чистые Tailwind-страницы, которые не плодят новый legacy. То есть вы проводите чёткую линию: старое доживает на Luma, новое строится на Hyvä, а конверсионное ядро уже быстрое.
Честный размен. Страницы, оставшиеся на Luma, прироста скорости не получают — они и дальше грузят весь Luma-бандл (RequireJS, jQuery, Knockout). Плюс на переходный период вы поддерживаете два стека, а общие header/footer нужно держать визуально идентичными в обоих, чтобы не было «скачка» при переходах. Но взамен вы получаете быстрое ядро и экономите недели разработки на контенте, который этого не стоит. Если же какая-то из legacy-страниц — это реальная точка входа с платного трафика, её стоит вынести в отдельный приоритет и всё же перенести на Hyvä; остальное пусть спокойно доживает на Luma.
Это не «недомиграция», а осознанная стратегия: начать получать выгоду от Hyvä быстро, а полную миграцию контента делать постепенно или не делать вообще — там, где она не окупается.
Нюанс про нативний PageBuilder. Если ваши CMS-страницы собраны на стандартном Magento PageBuilder (без кастомных компонентов), их держать на Luma не обязательно — Hyvä рендерит нативные PageBuilder-элементы «из коробки» (compat встроен в тему). На Luma-fallback есть смысл оставлять именно страницы с кастомными компонентами, у которых собственный JS/CSS без Hyvä-рендера. Что именно у вас — определяет инвентаризация PageBuilder-компонентов на этапе аудита.
Кому стоит рассмотреть этот подход
Гибрид даёт больше всего выгоды конкретному профилю бизнеса:
Контент-тяжёлые бренды с большим legacy на PageBuilder. Fashion, косметика, электроника, decor — те, кто годами собирал сезонные лендинги, брендзоны, промо и гайды на кастомных PageBuilder-компонентах. Десятки-сотни CMS-страниц, полная миграция которых — недели или месяцы переписывания без прямой отдачи.
Магазины, где деньги делаются в каталоге, а не в контенте. Конверсия идёт через PLP → PDP → checkout, а CMS — вторичный слой. Ускорять надо ядро, контент может подождать.
Бизнесы с ограниченным бюджетом или сроком, которым нужен результат быстро Вместо месяцев полного ребилда — быстрое ядро за недели, прирост конверсии там, где он важнее всего, а дальше решение по данным.
Команды, где маркетинг и разработка не должны блокировать друг друга. Маркетологи дальше собирают лендинги на привычном PageBuilder, пока разработчики мигрируют ядро. Новые лендинги при этом уже делаются под Hyvä — legacy не растёт.
Кому гибрид подходит хуже (и это стоит учесть):
Если коротко: гибрид — для зрелых, контент-насыщенных магазинов, которые хотят быстро ускорить то, что приносит деньги, не оплачивая переписывание того, что денег не приносит.
Небольшим магазинам с малым кастомом - им дешевле и чище сразу перейти полностью на Hyvä; гибрид лишь добавит накладных расходов на два стека.
Магазинам, где контентные страницы — ключевая точка входа с платного трафика — тогда их скорость критична, и держать их на Luma означает терять деньги именно там, куда льётся реклама. Здесь уже стоит вложить фокус внимания и в CMS-страницы, а не давать им доживать на Luma.
Тем, кому нужен максимальный перфоманс по всему сайту - гибрид сознательно оставляет часть на Luma.
Этапы миграции на Hyvä
Независимо от выбранного подхода, мы не начинаем с вёрстки. Сначала — понимание того, что есть, потом — план, и только после этого — реализация.


Аудит текущего магазина. Разбираем, сколько на сайте кастомных разработок, какие сторонние расширения используются и какие из них имеют Hyvä-совместимость. Именно здесь становится понятен реальный объём работ и главные риски. Это самый важный этап — он определяет сроки и бюджет.
Аудит совместимости расширений. Составляем перечень всех модулей и делим их на три группы: те, что уже имеют официальную Hyvä-совместимость; те, для которых нужен отдельный compat-модуль; и те, которые придётся переписывать или заменять. Это главный фактор сложности всей миграции.
Настройка Hyvä и базовая структура. Устанавливаем тему, настраиваем Tailwind-конфиг под бренд (цвета, типографика, отступы как design tokens), поднимаем процесс сборки.
Перевёрстка шаблонов. Головна, категорії, картка товару, статичні сторінки, header/footer переносяться на Hyvä. Кастомна логіка, що була на jQuery/Knockout, переписується на Alpine.js.
Checkout. Отдельное решение: оставить стандартный Magento checkout через Luma fallback или внедрить Hyvä Checkout. Это зависит от того, насколько кастомный ваш текущий checkout и какие там интеграции (оплата, доставка).
Интеграции и аналитика. Проверяем, что все трекинги (GA4, Meta Pixel/CAPI, GTM), CRM-интеграции и сторонние скрипты работают на новом фронтенде. Это частое место, где что-то «отваливается» после миграции, если не проконтролировать.
Тестирование и запуск. Кросс-браузерное и мобильное тестирование, проверка скорости, корректности checkout и всех сценариев покупки. Сравниваем метрики до и после.
Технические нюансы и подводные камни
Это та часть, которую бизнесу важно понимать заранее, чтобы не было сюрпризов.
Совместимость расширений — главный фактор сложности. Не все сторонние модули имеют Hyvä-версию фронтенда. Для популярных расширений compat-модули обычно есть (экосистема большая — более 700 партнёров и тысячи совместимых расширений). Но если у вас редкий или сильно кастомизированный модуль — его фронтенд придётся переписывать отдельно. Именно поэтому аудит расширений делается первым.
Кастомный JS придётся переписывать. Вся кастомизированная (уникальная) логика, написанная под jQuery/Knockout/RequireJS, на Hyvä не работает. Её нужно переписать на Alpine.js. Для простых вещей это быстро, для сложных интерактивных компонентов — отдельная работа, которую надо закладывать в оценку. Однако обычно таких виджетов/функционала на проектах относительно немного.
Общие блоки в гибриде (мини-корзина, header, footer) требуют внимания. В гибридном сценарии данные корзины синхронизируются автоматически — и Hyvä, и Luma читают тот же Magento customer-data (секции), поэтому содержимое и суммы корзины совпадают на обоих типах страниц. Но визуально это две разные реализации: на Hyvä-страницах мини-корзина — это Alpine-компонент, на Luma — старый Knockout-виджет. Их надо держать одинаковыми, чтобы при переходе между зонами не было «скачка» в шапке. Отдельно тестируется работа ESI-блоков (page_cache/block/esi) на проде с Varnish/FPC — при неправильной настройке theme fallback мини-корзина может «залипать» и не обновляться, причём это видно только на проде с включённым кешем, а не на dev. Если на legacy-страницах есть кнопки «добавить в корзину» — их тоже проверяют отдельно.
Аналитика и трекинг требуют синхронизации. Поскольку меняется весь фронтенд и DOM, скрипты, привязанные к старым селекторам или событиям Luma, могут перестать срабатывать. GA4 e-commerce события, dataLayer, пиксели — всё надо проверить и при необходимости перепривязать после миграции. Мы уделяем этому отдельное внимание.
Что нужно знать бизнесу перед стартом
Самая большая ошибка — воспринимать миграцию на Hyvä как «поставить новую бесплатную тему». Тема действительно бесплатна, но ценность и стоимость — в качественной реализации.
Лицензия теперь €0, реализация — нет. Бюджет миграции — это преимущественно работа разработчиков: перевёрстка, переписывание кастомной логики и адаптация расширений. Плюс при необходимости отдельные продукты (Hyvä Checkout, Hyvä UI).
ROI считается не в лицензии, а в конверсии и поддержке. Более быстрый сайт конвертирует лучше, а более дешёвая поддержка экономит бюджет месяц за месяцем. Именно здесь Hyvä окупается, а не на экономии на теме.
Аудит перед стартом — обязателен. Без него невозможно честно назвать ни сроки, ни бюджет. Каждый магазин имеет свой набор расширений и кастома, и именно он определяет сложность. Любой, кто даёт точную оценку без аудита совместимости — угадывает.
Миграция — это точка входа, а не финал. После переезда фронтенд становится легче в развитии, и именно тогда имеет смысл закладывать следующий этап: оптимизацию конверсии, A/B-тесты и постепенное улучшение UX на уже быстрой базе.
FAQ
Сколько времени занимает миграция на Hyvä?
Зависит от объёма кастома и количества сторонних расширений. Простой магазин — несколько недель, сложный eCommerce с большим каталогом и многими интеграциями — месяцы. Точную оценку даёт аудит.
Нужно ли платить за Hyvä сейчас?
Ядро темы с ноября 2025 года бесплатное (open-source). Платными остаются отдельные продукты — Hyvä UI (€250), Hyvä Checkout (~€1000) и премиум-поддержка. Основная инвестиция — это работа по реализации.
Потеряю ли я данные или функционал при миграции?
Нет. Hyvä меняет только фронтенд. Каталог, заказы, клиенты, интеграции и админка остаются без изменений. Функционал переносится, а не переписывается с нуля.
Что будет с моими расширениями?
Популярные расширения обычно имеют Hyvä-совместимость или compat-модули. Редкие или сильно кастомные могут потребовать доработки фронтенда. Это определяется на этапе аудита совместимости.
Обязательно ли покупать Hyvä Checkout?
Нет. Можно оставить стандартный Magento checkout на Luma через официальный модуль theme fallback. Hyvä Checkout имеет смысл, когда важна максимальная скорость и упрощение оформления заказа.
Можно ли мигрировать постепенно, не останавливая магазин?
Да. Поэтапный подход позволяет переносить страницы частями, а theme fallback — держать часть сайта на Luma на переходный период. Продажи при этом не останавливаются.
Что делать с CMS-страницами на PageBuilder?
Зависит от того, из чего они собраны. Нативные PageBuilder-элементы Hyvä рендерит «из коробки», так что такие страницы переносятся вместе со всеми. А страницы с кастомными компонентами (свой JS/CSS) переписывать под Hyvä долго и дорого — их рационально оставить на Luma через theme fallback, а новые лендинги делать уже сразу под Hyvä. Это наш рекомендуемый гибридный подход для проектов с большим количеством кастомного контента.
Не сломается ли контент, если редактировать «люмовскую» страницу в админке?
Нет. PageBuilder хранит контент в нативном формате в базе независимо от фронтенд-темы. Редактор работает в админке и не знает о Hyvä, поэтому пересохранение страницы ничего не конвертирует и не ломает.