Міграція на 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 - особливо помітно на мобільних, де і втрачається більшість конверсії.
Вища конверсія. Швидкість напряму впливає на показник відмов і на кількість людей, що доходять до checkout. Це приріст без збільшення рекламного бюджету.
Дешевша підтримка. Чистий код на 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ä, тому перезбереження сторінки нічого не конвертує і не ламає.