Shopify Hydrogen vs Next.js Commerce: яку архітектуру обрати для магазину у 2026

У headless-розробці на Shopify зараз домінують два React-підходи: Shopify Hydrogen - думкований, нативний для Shopify фреймворк на Remix (React Router v7), який розгортається виключно на Oxygen (edge-платформі Shopify поверх Cloudflare Workers), і Next.js Commerce - композовна референсна реалізація Vercel на Next.js App Router з React Server Components, яку можна розгорнути на будь-якому Node.js-хостингу.

Я порівнюю їх за шістьма вимірами: модель рантайму й деплою, будова шару даних, стратегія кешування, польові дані CrUX, досвід розробника і повна вартість володіння разом із ризиком вендор-локіну. У кінці - практичний фреймворк вибору, прив'язаний до реальних ситуацій команд і бізнесу.

Частина I - Ландшафт headless-комерції

Headless-підхід відокремлює фронтенд від комерційного бекенду - каталогу, кошика, чекауту, залишків і даних покупців. Фронтенд отримує комерційні примітиви через API, а не відмальовує шаблони, якими керує платформа.

Це розділення дає два стратегічні результати. Перший - повний інженерний контроль над продуктивністю і досвідом користувача, незалежно від того, як рендерить сама комерційна платформа. Другий - свобода збирати найкраще у своєму класі: Algolia для пошуку, Nosto для персоналізації, Yotpo для відгуків, - не озираючись на вбудований набір функцій платформи. Платня за це - інженерні витрати: у headless-фронтенді треба явно реалізувати те, що зв'язана вітрина (Shopify Liquid, теми Magento) дає за замовчуванням.

Усередині headless-екосистеми Shopify склалися дві школи. Hydrogen ставить на те, що глибока нативна інтеграція з API, аналітикою і B2B-примітивами Shopify дає кращу довгу продуктивність, якщо ви остаточно обрали Shopify. Next.js Commerce ставить на те, що незалежність від бекенду і переносимість дають кращу довгу гнучкість, якщо ваша комерційна стратегія ще може змінитися.

Головне, що треба розуміти одразу: обидва фреймворки за коректної реалізації вкладаються в пороги «Good» за Core Web Vitals. Розрив у продуктивності реальний, але вирішальним фактором не є. Це стратегічний архітектурний вибір про зв'язаність, топологію деплою і володіння платформою вдовгу, а не про оптимізацію швидкості.

Частина II - Архітектура Shopify Hydrogen

Технічна архітектура Hydrogen стоїть на трьох спроєктованих разом опорах: прикладний фреймворк Remix (React Router v7), edge-рантайм Oxygen і набір першосторонніх клієнтів до API Shopify.

2.1 - Основа Remix: модель loader/action

Hydrogen 2.0 (загальна доступність - січень 2024) замінив власний React-фреймворк Hydrogen 1.x на Remix як основу. Це рішення об'єднало Hydrogen із ширшою екосистемою Remix і прибрало саморобні стрімінгові примітиви на користь обкатаної моделі loader/action. Remix (з лютого 2025 - React Router v7) реалізує серверо-центричний цикл запит-відповідь на двох основних конструкціях.

• Функції loader виконуються на сервері до рендеру компонента маршруту. Вони отримують HTTP-запит (включно з параметрами URL, куками й заголовками) і повертають типізовані дані через відповідь json() або defer(). Примітив defer() вмикає стрімінг на Suspense: критичні дані резолвляться синхронно, а відкладені приходять паралельно і підставляються в межі Suspense у міру готовності промісів.
• Функції action обробляють запити не-GET: відправки форм і мутації. Вони виконуються на сервері, змінюють стан (додати в кошик, змінити кількість) і повертають редирект або дані. Для більшості комерційних взаємодій це прибирає клієнтський патерн fetch плюс синхронізація стану.
• Вкладена маршрутизація дозволяє вантажити дані на рівні кожного маршруту: /products/:handle вантажить дані товару незалежно від даних колекції батьківського /products, і кожна межа показує свій скелетон.

Модель Remix архітектурно найближча до класичного серверного вебу з циклом запит-відповідь. Суттєво, що в Hydrogen немає аналога статичної генерації: кожен маршрут або рендериться динамічно на Oxygen, або віддається з CDN-кешу Cloudflare. Аналогів ISR (інкрементальної статичної регенерації) і PPR (часткового пререндерингу) немає, і це помітно впливає на TTFB некешованих запитів.

2.2 - Oxygen: рантайм V8-ізолятів на Cloudflare Workers

Oxygen - власна edge-платформа Shopify, яка йде без доплати для всіх розгортань Hydrogen. Вона побудована на архітектурі V8-ізолятів Cloudflare Workers, а це принципово інша модель виконання, ніж у звичайних serverless-функцій.

• Холодний старт менший за мілісекунду: V8-ізоляти ділять процес рушія V8 із рантаймом Workers. Підняти новий ізолят коштує менш ніж 1 мс проти 100–800 мс у холодного старту Node.js-лямбди. Це знімає штраф холодного старту, через який звичайний serverless погано підходить для чутливої до затримок комерції.
• Виконання на глобальному краю мережі: Oxygen автоматично розгортається на всі 300+ точок присутності Cloudflare. Запит сторінки товару з Токіо виконується в Токіо, а виклик Storefront API іде на найближчий вузол Shopify, часто розміщений у тому самому дата-центрі Cloudflare.
• Обмеження рантайму: V8-ізоляти працюють лише в межах Web API. Вбудовані модулі Node.js (fs, path, crypto зі стандартної бібліотеки), нативні аддони й породження дочірніх процесів недоступні. Це найчастіша точка тертя при перенесенні на Hydrogen утилітарних бібліотек, написаних під Node.js.

2.3 - Набір нативних API-клієнтів Shopify

Hydrogen постачає типізовані клієнти першого класу до всієї поверхні API Shopify, і це помітна ергономічна перевага перед ручним написанням GraphQL-запитів до Storefront API.

• Клієнт Storefront API (createStorefrontClient): типізований GraphQL-клієнт із вбудованою колокацією фрагментів, керуванням кеш-тегами й автоматичними persisted queries (APQ). APQ перетворює повні рядки GraphQL-запитів на хеші SHA-256, скорочуючи корисне навантаження запиту більш ніж на 90% і відкриваючи кешування в CDN за стабільним URL.
• Клієнт Customer Account API (createCustomerAccountClient): потік OAuth 2.0 PKCE для headless-автентифікації покупців. Замінює застарілий підхід із токенами Multipass, даючи обмежений за правами доступ до замовлень, адрес, B2B-акаунтів компаній і програм лояльності.
• Cart API: серверне керування кошиком з оптимістичними мутаціями. Компонент <CartForm> надсилає дані через action Remix, що дає робочий кошик узагалі без JavaScript як базовий рівень прогресивного покращення.
• Аналітика (usePageAnalytics, useCartAnalytics): структуровані емітери подій, сумісні з Shopify Analytics, Google Analytics 4 і Meta Pixel, - без сторонніх тег-менеджерів і без надсилання клієнту SDK аналітики.

Частина III - Архітектура Next.js Commerce

Next.js Commerce (референсна реалізація vercel/commerce) побудована на Next.js 15 App Router з React Server Components як основним архітектурним патерном. Її базова теза: шар даних, тобто інтеграція з API Shopify, має бути замінним адаптером, а не несучою конструкцією.

3.1 - React Server Components як шар даних із нульовою ціною

У Next.js Commerce кожна сторінка товару, сторінка колекції та сторінка результатів пошуку - це дерево серверних компонентів. Дані запитуються на сервері через GraphQL Storefront API типізованою обгорткою над fetch. Жодних useEffect, жодних клієнтських викликів API й жодного керування станом завантаження для первинних даних: дерево компонентів рендериться, коли дані вже отримані.

• Ціна в бандлі - нуль. Серверні компоненти не потрапляють у клієнтський JavaScript. Компонент ProductPage, який отримує дані товару, малює картинки, проходить селекторами варіантів і форматує ціни, надсилає у браузер рівно 0 байт.
• Композиція замість домовленостей. Запит даних живе поруч із компонентом, який їх споживає: async function ProductDetails({ handle }) сам отримує свої дані, а не приймає їх від loader рівня маршруту. Це прибирає прокидання пропсів і дозволяє ставити межі Suspense на компонент, а не на маршрут.
• Паралельні запити. Кілька піддерев RSC отримують дані одночасно без жодної координації. Promise.all у моделі рендерингу RSC мається на увазі сам собою: <ProductImages>, <PriceBlock> та <InventoryStatus> надсилають свої GraphQL-запити паралельно.

3.2 - Архітектура кешування Next.js 15

Модель кешування Next.js 15 вводить три окремі шари кешу, які в комерційних сценаріях складаються один з одним.

• Full Route Cache (шар CDN): готова HTML-відповідь сторінки товару кешується на Edge Network Vercel. При влучанні в кеш TTFB становить 15–40 мс незалежно від складності серверного рендеру. Інвалідація йде через revalidateTag('product-${handle}'), зазвичай за вебхуком Shopify при оновленні товару, який спрацьовує за секунди після правки в адмінці.
• Data Cache (шар окремих запитів): кожен виклик fetch() кешується за ключем URL плюс опції запиту. fetch(endpoint, { next: { tags: ['shopify'], revalidate: 3600 } }) тримає відповідь Storefront API годину і ділить її між усіма паралельними серверними рендерами, прибираючи дублювальні виклики API на сплесках трафіку.
• Partial Prerendering (PPR): статична оболонка сторінки товару - лейаут, навігація, hero-картинка, назва - пререндериться на збірці й кешується в CDN з нескінченним TTL. Динамічні частини - залишки в реальному часі, персональні ціни, рекомендації - стримляться із сервера в міру резолву меж Suspense. Браузер отримує статичну оболонку з TTFB менш як 50 мс із CDN, а динаміка приходить за 200–400 мс. Це ключова перевага Next.js Commerce над Hydrogen на великих каталогах.

3.3 - Незалежність від бекенду: патерн адаптера

Найсильніше Next.js Commerce відрізняє від Hydrogen явна ізоляція комерційного шару даних за типізованим інтерфейсом адаптера. Усі виклики API Shopify інкапсульовані в lib/shopify/ - модулі, який експортує типізовані функції (getProduct, getCollection, createCart, addToCart), і жоден специфічний для Shopify тип не протікає в дерево компонентів.

Заміна Shopify на Medusa (open source), BigCommerce або власний API зводиться до реалізації того самого інтерфейсу в lib/medusa/ і правки одного імпорту: дерево React-компонентів лишається недоторканим. Це не теоретична можливість - у репозиторії vercel/commerce живуть пакети провайдерів для Shopify, BigCommerce і Saleor, і кожен реалізує той самий інтерфейс.

Частина IV - Розбір бенчмарків продуктивності

Емпіричне порівняння вимагає розрізняти лабораторні метрики (Lighthouse, WebPageTest) і польові (CrUX, 75-й перцентиль реальних користувачів). Лабораторія міряє одне ідеальне завантаження; поле міряє розподіл справжнього досвіду за пристроями, мережами й географією. Для вітрини робоча метрика - p75 LCP із CrUX: саме вона визначає проходження Core Web Vitals у пошуку Google.

• TTFB (p75, глобально): Hydrogen на Oxygen: 45–90 мс (edge-рендер у V8-ізоляті, Storefront API поруч). Next.js Commerce на Vercel з PPR: 20–50 мс на кешовану статичну оболонку плюс 180–350 мс до першого динамічного шматка. Без PPR: 80–160 мс.
• LCP (p75, сторінка товару): Hydrogen: 1,2–1,9 с (hero-картинка передзавантажена через <link rel=preload> у loader маршруту, edge-рендер на Oxygen). Next.js Commerce з PPR: 0,8–1,4 с (HTML статичної оболонки закешований у CDN, hero-картинка передзавантажена в статичному <head>). Перевага PPR найпомітніша на мобільних у регіонах із високою затримкою.
• INP (p75): Hydrogen: 100–160 мс (база прогресивного покращення Remix, мінімум клієнтського JS на основні взаємодії). Next.js Commerce: 80–140 мс (RSC знімає гідратацію неінтерактивних компонентів, зменшуючи конкуренцію за головний потік під час обробки взаємодії).
• CLS: В обох фреймворків нижче 0,05, якщо в картинок явно проставлені width і height, а шрифти вантажаться з font-display: swap. Автоматичного захисту від зсувів не дає жоден: потрібні коректні розміри зображень.
• Первинний JS-бандл (gzip): Hydrogen: приблизно 180–210 КБ (рантайм Remix плюс утиліти Hydrogen плюс React). Next.js Commerce: приблизно 110–145 КБ (рантайм Next.js, React і лише інтерактивні клієнтські компоненти, без коду завантаження даних).

Розрив у продуктивності між фреймворками реальний, але для вітрин із грамотно зібраною інфраструктурою не вирішує. Обидва за правильного налаштування проходять пороги «Good» за Core Web Vitals (LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1) на польових даних p75. Перевага Next.js Commerce з PPR у 300–500 мс за LCP стає комерційно значущою і помітно впливає на конверсію лише на мобільних у Південно-Східній Азії, Африці на південь від Сахари й Латинській Америці, де медіанна мережева затримка перевищує 150 мс.

Частина V - Досвід розробника та екосистема

Досвід розробника тут важить багато: він прямо визначає, як швидко команда викочує і скільки розумових сил з'їдає підтримка.

• Hydrogen: Інтеграція з Shopify CLI (shopify hydrogen dev) піднімає локальне середовище з живим доступом до Storefront API з тестового магазину. Вбудований режим мок-даних дозволяє верстати інтерфейс узагалі без магазину. Можливості B2B Commerce - акаунти компаній, об'ємні ціни, відтермінування платежу - тут примітиви першого класу, а не саморобні рішення. Shopify Functions (серверна бізнес-логіка для знижок і налаштування платежів) нативно стикується з API-маршрутами Hydrogen.
• Next.js Commerce: Уся екосистема плагінів Next.js під'єднується без тертя: next-auth для автентифікації покупців, next-intl для локалізації, Contentlayer для блогу, Algolia для пошуку. Vercel AI SDK 4.0 відкриває AI-функції першого класу: чат-боти рекомендацій, семантичний пошук і персоналізовані лендінги як композовні RSC-компоненти. Переносимість деплою означає, що та сама кодова база працює на Vercel, AWS App Runner, Google Cloud Run або на власному Node.js-сервері.
• Ширина екосистеми: У Next.js екосистема значно більша за будь-якою метрикою - завантаження npm, зірки на GitHub, пакети спільноти, сторонні інтеграції. Екосистема Hydrogen вужча, зате зібрана під комерцію: кожен пакет спроєктований під Shopify, і всередині цієї області тертя від інтеграцій майже немає.

Частина VI - Повна вартість володіння і ризик локіну

Далі за вартість хостингу справжнє питання TCO - це втрачена вигода: ризик міграції, стеля швидкості додавання функцій і доступність людей на ринку.

• Поверхня локіну Hydrogen - рантайм Oxygen: Застосунки Hydrogen розраховані на середовище V8-ізолятів Cloudflare Workers. Запуск Hydrogen на Node.js-сервері (AWS Lambda, Cloud Run) вимагає адаптера, який жертвує холодним стартом менше мілісекунди й може потребувати поліфілів поверхні Web API. Шлях задокументований, але простим його не назвати.
• Поверхня локіну Hydrogen - роутер Remix: Ментальна модель loader/action специфічна для Remix. Переїзд на інший фреймворк (Next.js App Router, Astro) вимагає переписати все завантаження даних, обробку форм і логіку навігації. Це не зміна конфігурації, а суттєвий інженерний проєкт.
• Поверхня локіну Hydrogen - клієнти API Shopify: createStorefrontClient, createCustomerAccountClient і CartForm - специфічні для Hydrogen абстракції над API Shopify. Якщо комерційний бекенд змінюється - переїзд на BigCommerce, власний хостинг Medusa, - ці клієнти викидаються цілком, а вкладення в нативні примітиви Shopify перетворюються на технічний борг.
• Поверхня локіну Next.js Commerce: Основний локін - адаптер lib/shopify, але він ізольований явно і замінний. Вторинний - PPR та інвалідація кешу за тегами у Vercel: точного еквівалента на самостійно розгорнутому Next.js немає (хоча revalidateTag працює будь-де, а от PPR специфічний для Vercel). React і Next.js - стандартні галузеві залежності, а не прив'язка до пропрієтарної платформи.

• Вартість хостингу: Hydrogen на Oxygen: 0 додатково, входить в усі тарифи Shopify. Next.js Commerce на Vercel: Vercel Pro 20 доларів на місяць за проєкт плюс трафік на масштабі.
• Переїзд на бекенд не-Shopify: Hydrogen: дуже високий ризик, переписування фреймворку цілком. Next.js Commerce: низький ризик, заміна адаптера за 2–5 інженерних днів.
• B2B Commerce з коробки: Hydrogen: є, нативний Customer Account API з примітивами компаній і B2B. Next.js Commerce: потребує власної реалізації B2B-цін і керування акаунтами.
• Контроль мультирегіонального деплою: Hydrogen: мережа Cloudflare, 300+ точок присутності, автоматично. Next.js Commerce: Edge Network у Vercel (100+ точок на Pro, налаштовується) або власне керування.
• Доступність людей: Інженерів із Next.js на ринку найму помітно більше, ніж із Hydrogen і Remix. Для команд, що ростуть, це нетривіальний фактор TCO.

Частина VII - Продакшен-свідчення і кейси

Лабораторні бенчмарки показують лише частину картини. Ось що насправді видно на продакшен-розгортаннях під навантаженням.

• Gymshark (Hydrogen): Переїзд Gymshark на Hydrogen (за опублікованими даними, третій квартал 2024) дав медіанний TTFB 50 мс на сторінках товарів по всьому світу - у 2,1 раза краще за їхню попередню саморобну реалізацію на Next.js. Ключовим фактором стало те, що edge-обчислення Oxygen опинилися поруч зі Storefront API всередині інфраструктури Cloudflare, і міжцентрова затримка попередньої архітектури зникла.
• Allbirds (Hydrogen): Allbirds обрали Hydrogen заради глибокої інтеграції з Shopify Analytics, що дозволило відмовитися від саморобного тег-менеджера. Вихід тег-менеджера з критичного шляху дав покращення LCP на 340 мс на мобільних.
• Patagonia (Next.js + Shopify): Реалізація Patagonia показує перевагу зв'язки контенту і комерції: на сторінках товарів у них редакційні дані про екологічний слід із Contentful, зібрані разом із даними Shopify в одному дереві RSC. Повторити це на Hydrogen можна через композицію loader'ів Remix, але вийде багатослівніше, ніж неявна серверна вибірка в RSC.
• Демо Vercel Commerce (Next.js PPR): Власне референсне розгортання Vercel показує LCP 0,7 с на Edge Network із PPR. Статична оболонка сторінки товару віддається з CDN за 28 мс TTFB, а динамічні залишки й ціни дострімлюються за 220 мс. Це стеля продуктивності патерну Next.js Commerce.

Частина VIII - Фреймворк ухвалення рішення

Ось як співвіднести вашу ситуацію з правильним вибором.

• Беріть Shopify Hydrogen, коли: (1) Ваш комерційний бекенд - Shopify і лишиться Shopify на горизонті від трьох років, без вимог до мультиплатформності. (2) Потрібні нативні можливості B2B Commerce: акаунти компаній, об'ємні ціни, відтермінування платежу, B2B-кабінет. (3) У команди є експертиза в Remix або готовність у неї вкластися. (4) Потрібна глибока інтеграція з Shopify Analytics без тег-менеджера. (5) Edge-топологія Cloudflare - жорстка вимога, географічна чи договірна.
• Беріть Next.js Commerce, коли: (1) Гнучкість бекенду стратегічно важлива: мультивендорність, можливий переїзд платформи або власний комерційний бекенд. (2) У команди вже є експертиза в Next.js і RSC. (3) Потрібна зв'язка контенту і комерції: блог, редакційні та локалізовані матеріали з CMS поруч із даними товарів. (4) Ви будуєте не лише комерцію: закриті SaaS-функції, AI-персоналізацію, інструменти спільноти. (5) Потрібна переносимість деплою: власний хостинг, мультихмара або незалежність від конкретного edge.

Евристика, яка спрощує весь цей фреймворк: якщо ваша п'ятирічна дорожня карта - лише Shopify, беріть Hydrogen; якщо в ній є хоч скільки-небудь помітна ймовірність зміни бекенду, беріть Next.js Commerce. Різниця в продуктивності зворотного вибору не виправдовує: за належних інженерних вкладень обидва фреймворки вкладаються в ті самі пороги Core Web Vitals.

Висновок

Hydrogen і Next.js Commerce - не просто дві реалізації однієї ідеї, а різні архітектурні ставки. Спільне проєктування Hydrogen з інфраструктурою Shopify - рантайм V8-ізолятів Oxygen, нативні клієнти API, B2B і аналітика першого класу - робить його справді сильним для тих, хто остаточно обрав Shopify: холодний старт менше мілісекунди, виклики API поруч, аналітика без налаштування. Але за цю глибину платять реальною зв'язаністю: з курсом платформи Shopify, з ментальною моделлю Remix і з обмеженнями рантайму Oxygen.

Ключове рішення Next.js Commerce - ізолювати комерційний бекенд за типізованим адаптером - коштує вам частини ергономіки: взаємодію з Shopify доводиться розписувати явніше, ніж через нативні клієнти Hydrogen. Натомість ви отримуєте архітектурну свободу: переносимість бекенду, гнучкість деплою і всю екосистему Next.js разом із PPR, AI SDK і RSC. Якщо ви будуєте платформу, яка може обслуговувати кілька брендів, змінити бекенд або вирости за межі чистої комерції, ця свобода варта зайвого налаштування.

Архітектурний консалтинг, скоупінг міграції на headless Shopify або впровадження Next.js Commerce - послуга фронтенд-архітектури | кейси | обговорити проєкт.

Часті питання

• Чи можна розгорнути Hydrogen поза Oxygen? Так, із застереженнями. Hydrogen дає адаптер для Oxygen і адаптер для Node.js. Другий втрачає холодний старт V8-ізолята менше мілісекунди й потребує поліфілів Web API. Hydrogen на власному Node.js-сервері працює коректно, але характеристик Oxygen не повторює.
• Чи працює Next.js Commerce із Shopify Checkout? Так. Shopify Checkout лишається сторінкою на боці Shopify в обох фреймворках: ані Hydrogen, ані Next.js Commerce за замовчуванням не роблять власного інтерфейсу чекауту. Обидва ведуть на myshop.myshopify.com/checkout для оплати. Кастомний чекаут через Checkout Extensibility однаково працює з обома.
• У якого фреймворку SEO з коробки краще? Обидва віддають кравлеру повний HTML на першому запиті: Hydrogen через edge-рендер Remix, Next.js Commerce через SSR або PPR. Жодному для індексації не потрібен JavaScript. У Next.js Commerce є невелика перевага в автоматизації метатегів через generateMetadata() і у впровадженні розмітки через JSON-LD-компоненти.
• Чи можна використовувати Server Actions у Hydrogen? Ні. Server Actions - фіча Next.js (і рекомендований командою React примітив мутацій). Hydrogen використовує функції action із Remix: семантично це еквівалент - надсилання форми запускає серверну мутацію без клієнтського fetch, - але реалізовано інакше. Директива 'use server' у Hydrogen недоступна.
• Як бути з Shopify Markets для багатомовності? У Hydrogen підтримка Shopify Markets першого класу через getStorefrontHeaders() і запити до Storefront API з урахуванням локалі. Next.js Commerce вимагає реалізувати виклики з урахуванням Markets вручну. Для вітрин саме на Shopify Markets, а не на власній стратегії локалізації, Hydrogen з коробки дає помітно кращу мультирегіональність.

Джерела

• Shopify. «Hydrogen Documentation» (2026)
• Shopify Engineering. «Hydrogen 2.0: Built on Remix» (2024)
• Shopify Engineering. «Gymshark Hydrogen Case Study» (2024)
• Vercel. «Next.js Commerce Reference Implementation»
• Remix / React Router. «React Router v7 Documentation» (2025)
• Cloudflare. «How Workers Works - V8 Isolate Architecture»
• Vercel. «Partial Prerendering in Next.js 15» (2025)
• Shopify. «Storefront API Reference» (2024-01)
• Shopify. «Customer Account API Documentation»
• Google. «Core Web Vitals - Understanding the Metrics»

Hydrogen проти Next.js Commerce проти production-темплейта

Якщо коротко: Hydrogen дає нативну глибину Shopify, але прив'язує до Oxygen і до Shopify; Next.js Commerce дає композовну переносимість, але приїжджає як відправна точка, а не готовий магазин; production-темплейт дає протестовану вітрину під будь-який із цих бекендів, живу за тижні.

Що швидше, Shopify Hydrogen чи Next.js Commerce?

На польових даних обидва проходять пороги «Good» за Core Web Vitals, якщо зібрані правильно, тож розрив невеликий і вирішальним не є. У Hydrogen невелика перевага на першому завантаженні завдяки edge-рантайму Oxygen; Next.js Commerce наздоганяє його через React Server Components і грамотне кешування. Обирайте за локіном і гнучкістю, а не за чистою швидкістю.

Чи є готове рішення, щоб не будувати з нуля?

Так. Якщо вам близький підхід Next.js Commerce, але збирати вітрину з нуля не хочеться, Headless Commerce Template - це продакшен-вітрина композовної архітектури, яка працює на Shopify або Magento, приїжджає з контентом, пошуком, лояльністю і подарунковими картками й проходить гейти доступності та продуктивності в CI. Ви підключаєте свій бекенд і виходите в прод за тижні, а код лишається вашим.