Skip to content

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

Shopify Hydrogen и Next.js Commerce конкурируют не на уровне функций - они конкурируют на уровне архитектурной философии. Hydrogen оптимизирует нативную глубину интеграции с Shopify ценой портируемости. Next.js Commerce оптимизирует компонуемую гибкость ценой Shopify-эргономики. Выбор определяет скорость разработки и стратегический потолок платформы на следующие три-пять лет.

Архитектурная сравнительная диаграмма Shopify Hydrogen и Next.js Commerce
Автор:Опубликовано:Обновлено:Время чтения:16 мин

Senior Frontend Architect, 10+ лет опыта построения production-проектов на Next.js. Contentful Certified Professional (2024). Специализация: React Server Components, headless eCommerce, инженерия Core Web Vitals.

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

В статье сравниваю их по шести измерениям: runtime и модель деплоя, слой данных, стратегия кэширования, производительность по полевым данным CrUX, Developer Experience и TCO с учётом риска вендор-локина. В конце - практический фреймворк принятия решений под реальные ситуации команд.

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

Headless-парадигма отделяет frontend-слой представления от commerce-бэкенда: каталога, корзины, оформления заказа, инвентаря и данных о покупателях. Frontend потребляет commerce-примитивы через API, а не рендерит шаблоны платформы. Это разделение даёт два стратегических преимущества: полный инженерный контроль над производительностью и UX - и свободу компоновать best-of-breed сервисы независимо от нативных возможностей платформы.

В экосистеме Shopify сформировались две школы мысли. Первая - Shopify Hydrogen - основана на тезисе: глубокая нативная интеграция с API, аналитикой и B2B-примитивами Shopify даёт наилучшую долгосрочную продуктивность для committed Shopify-мёрчантов. Вторая - Next.js Commerce - основана на тезисе: backend-агностичная компонуемость и архитектурная портируемость дают наилучшую долгосрочную гибкость для команд, чья commerce-стратегия может эволюционировать.

Принципиально важно: производительность обоих фреймворков при корректной реализации находится в одном порядке величин по всем Core Web Vitals. Выбор между ними - не оптимизационное решение, а стратегическое архитектурное решение об организационной связанности, топологии деплоя и долгосрочном владении платформой.

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

Техническая архитектура Hydrogen опирается на три совместно спроектированных столпа: фреймворк приложения Remix (React Router v7), edge compute runtime Oxygen и suite первопартийных API-клиентов Shopify.

Модель loader/action. Remix реализует server-centric цикл запрос/ответ. Функции loader выполняются на сервере до рендеринга компонента, получают данные и возвращают типизированные ответы. Примитив defer() позволяет стримить некритичные данные через Suspense-границы. Функции action обрабатывают мутации (добавление в корзину, обновление количества) без клиентских fetch-вызовов. Вложенная маршрутизация позволяет управлять состоянием загрузки на уровне отдельного маршрута. Аналога ISR/PPR в Hydrogen нет - каждый маршрут либо динамически рендерится на edge, либо отдаётся из CDN-кэша.

Oxygen: V8 isolate runtime. Oxygen предоставляется бесплатно для всех Hydrogen-деплоев. Основан на Cloudflare Workers: <1ms cold start (V8 isolates не требуют запуска отдельного процесса), глобальное исполнение на 300+ PoP Cloudflare, доступ к Cloudflare KV для хранения сессий и корзины. Ограничение: только Web API-поверхность, Node.js built-ins недоступны - наиболее частый источник friction при миграции.

Нативные API-клиенты Shopify. Hydrogen поставляет типизированные клиенты для всего API Shopify: createStorefrontClient с APQ (Automatic Persisted Queries, сжатие GraphQL-запросов до SHA-256 хэша), createCustomerAccountClient (OAuth 2.0 PKCE для headless-аутентификации), Cart API с оптимистичными мутациями, и хуки аналитики (usePageAnalytics, useCartAnalytics) - совместимые с Shopify Analytics, GA4 и Meta Pixel без tag manager.

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

Next.js Commerce использует Next.js 15 App Router с React Server Components. Фундаментальный тезис: слой данных (интеграция с Shopify API) должен быть заменяемым адаптером, а не несущим конструктивным элементом.

RSC как zero-cost слой данных. Каждая страница продукта, коллекции и поиска - это RSC-дерево. Загрузка данных происходит на сервере; компонентное дерево рендерится с уже разрешёнными данными. Серверные компоненты не вносят ни байта в клиентский бандл. Параллельная загрузка данных имплицитна: <ProductImages>, <PriceBlock> и <InventoryStatus> отправляют GraphQL-запросы одновременно без явной координации.

Трёхуровневый кэш Next.js 15. Full Route Cache кэширует полный HTML-ответ на CDN-слое - TTFB при попадании в кэш 15–40ms. Data Cache кэширует отдельные fetch()-вызовы с тегами (next: { tags: ['shopify'] }) - весь слой данных Shopify инвалидируется одним вызовом revalidateTag('shopify') из webhook. Partial Prerendering (PPR): статичная оболочка страницы (layout, hero-изображение, заголовок продукта) кэшируется на CDN с бесконечным TTL - TTFB <50ms; динамические секции (инвентарь, цены) стримятся с origin в пределах 200–400ms.

Backend-агностицизм: паттерн адаптера. Все Shopify API-вызовы инкапсулированы в lib/shopify/ - модуле, экспортирующем типизированные функции (getProduct, createCart, addToCart). Смена Shopify на Medusa или BigCommerce требует реализации того же интерфейса в lib/medusa/ с обновлением одного импорта. Компонентное дерево не изменяется. Это не теоретическая возможность: репозиторий vercel/commerce поддерживает провайдеры для Shopify, BigCommerce и Saleor.

Часть IV - Бенчмарки производительности

  • TTFB (p75, глобально): Hydrogen на Oxygen: 45–90ms (edge-рендеринг V8 isolate, Shopify API co-located). Next.js Commerce на Vercel с PPR: 20–50ms (CDN-кэшированная статичная оболочка) + 180–350ms для первого динамического чанка.
  • LCP (p75, страница продукта): Hydrogen: 1.2–1.9s. Next.js Commerce с PPR: 0.8–1.4s. Преимущество PPR наиболее значимо на мобильных в регионах с высокой латентностью.
  • INP (p75): Hydrogen: 100–160ms. Next.js Commerce: 80–140ms (RSC исключает гидратацию неинтерактивных компонентов, снижая конкуренцию на main thread).
  • Начальный JS-бандл (gzip): Hydrogen: ~185–210 KB. Next.js Commerce: ~110–145 KB (только интерактивные компоненты).
  • Вывод: Оба фреймворка при корректной реализации проходят пороги Core Web Vitals 'Good' по p75 CrUX. Разрыв в 300–500ms LCP в пользу Next.js Commerce с PPR коммерчески значим только на мобильных в регионах с латентностью >150ms.

Часть V - TCO и риск вендор-локина

  • Локин Hydrogen: (1) Oxygen runtime - адаптация к Node.js теряет гарантии производительности V8 isolate. (2) Remix-роутер - миграция на другой фреймворк требует переписывания всей загрузки данных и форм. (3) Нативные клиенты Shopify - createStorefrontClient бесполезен за пределами Shopify. (4) Хостинг Oxygen: $0.
  • Локин Next.js Commerce: (1) Адаптер lib/shopify - изолирован, заменяем за 2–5 инженерных дней. (2) PPR и tag-based инвалидация кэша - оптимальны на Vercel, работают и на self-hosted. (3) Хостинг Vercel Pro: $20/мес.
  • Таланты: Next.js-инженеров значительно больше на рынке найма, чем Remix/Hydrogen. При масштабировании команды - нетривиальный TCO-фактор.
  • B2B из коробки: Hydrogen - нативно. Next.js Commerce - кастомная реализация.
  • Миграция с Shopify: Hydrogen - очень высокий риск (полный переписывание). Next.js Commerce - низкий риск (замена адаптера).

Фреймворк принятия решений

Выбирайте Hydrogen: бэкенд Shopify на горизонте 3+ лет без планов смены; нативные B2B-возможности; экспертиза команды в Remix; глубокая интеграция с Shopify Analytics без tag manager; жёсткое требование edge Cloudflare.

Выбирайте Next.js Commerce: требуется или возможна гибкость бэкенда; команда на Next.js/RSC; интеграция контент-коммерция (блог, CMS, локализация); фичи за пределами e-commerce (AI, SaaS-функции); портируемость деплоя.

Эвристика: если пятилетний roadmap - только Shopify, выбирайте Hydrogen; если есть значимая вероятность эволюции бэкенда - выбирайте Next.js Commerce. Разница в производительности не оправдывает обратного выбора.

Для архитектурного консалтинга, оценки headless-миграции или реализации Next.js Commerce - сервис архитектуры фронтенда | кейсы | обсудить задачу.

Источники

Похожие статьи

Headless Shopify на Next.js: полный гайд по архитектуре (2026)

Практический гайд по построению продакшн headless Shopify-стора на Next.js App Router. Три API-уровня Shopify, типизированный GraphQL data layer, генерация каталога через generateStaticParams + ISR, механика Cart API с cookies, OAuth PKCE для Customer Account API, SEO для вариантов продуктов и производительность - с референсами из реальных продакшн-реализаций.

ShopifyNext.jsHeadless
Читать статью

React 19: useOptimistic, use(), Server Actions - механизм и архитектура (2026)

Детальный разбор пяти новых примитивов React 19: useOptimistic (конкурентная composition оптимистичного состояния с автоматическим rollback), use() (условное чтение Promise и Context), Server Actions (RPC-over-HTTP контракт и Progressive Enhancement), useActionState (стейт-threading паттерн), useFormStatus. Action-based mutation архитектура, которая заменяет Redux/Zustand для серверных мутаций.

React 19ArchitectureNext.js
Читать статью

Partial Prerendering (PPR) в продакшне: архитектурные паттерны (2026)

Детальный разбор Next.js Partial Prerendering в продакшне. Механизм двухфазного ответа (статический shell с CDN + стриминговые dynamic holes), правила размещения Suspense-границ, взаимодействие с Full Route Cache, дизайн fallback для нулевого CLS, измеренные TTFB/LCP, сравнение с ISR+CSR и full SSR, известные ограничения и фреймворк принятия решений.

Next.jsPerformancePPR
Читать статью