После 2024 года архитектурные решения в проектах Shopify больше не упираются в вопрос «современно или нет». Вопрос конкретнее: какие цифры обосновывают выбор. React Server Components архитектуры Hydrogen против монолитного подхода Liquid — правильное решение основано на данных, а не на трендах. Мы делимся результатами, собранными на 6 проектах: TTFB, время сборки, developer velocity и стоимость миграции. Здесь нет теоретических сравнений фреймворков — только метрики, цифры и анализ компромиссов на основе реальных проектов.

TTFB: Edge SSR против Server-Side Render

Первая метрика — Time to First Byte. На проектах Hydrogen мы тестировали Oxygen (edge runtime Shopify) и Cloudflare Workers. Темы на Liquid используют стандартный pipeline рендеринга Shopify.

Условия тестирования:

  • Hydrogen: Remix 2.x + Oxygen, 8 маршрутов, средний bundle 120 КБ
  • Liquid: Dawn 15.0, стандартные настройки кеша
  • Инструмент: WebPageTest, локация Virginia, соединение 3G Fast, 9 прогонов в среднем

Результаты:

АрхитектураTTFB (p50)TTFB (p95)LCP
Liquid (Dawn)420 мс680 мс2,1 с
Hydrogen (Oxygen)180 мс310 мс1,4 с
Hydrogen (CF Workers)140 мс240 мс1,2 с

При правильно настроенной стратегии кеша SSR на edge TTFB падает на 58 %. Но это работает только для статических маршрутов — на персонализированных страницах (корзина, чекаут) разница сокращается до 30 %, так как кеш обходится.

Компромисс персонализации

На Hydrogen персонализированные маршруты работают так: для каждого пользователя запрос корзины идёт в Storefront API, этот roundtrip добавляет 80–120 мс даже на edge. На Liquid такой запрос разрешается серверной шаблонизацией без дополнительного roundtrip. Если у вас много персонализированных страниц (например, PDP'и с множеством вариантов), выигрыш TTFB сокращается.

На проекте косметики — 240 SKU на одной странице товара — TTFB Hydrogen 290 мс, Liquid 380 мс. Разница только 23 %, а не обещанные 58 %.

Время сборки: Скорость dev iteration

Вторая метрика — время локальной разработки и production сборки. На Hydrogen используем Vite, на Liquid — Theme Kit или Shopify CLI.

Запуск dev сервера:

  • Liquid (Theme Kit): ~4 с
  • Hydrogen (Vite dev): ~1,8 с

Production сборка:

  • Liquid: 0 с (нет сборки, Shopify рендерит напрямую)
  • Hydrogen: 12–18 с (бандлинг + генерация SSR output)

На Liquid нет этапа сборки — это упрощает CI/CD. На Hydrogen npm run build добавляет 12 секунд даже для маленьких изменений. Зато hot module replacement в Hydrogen намного быстрее — изменение .liquid файла на Theme Kit синхронизируется 2–3 секунды, на Hydrogen HMR работает мгновенно (<200 мс).

Для команд с 50+ изменениями в день это напрямую влияет на velocity. На проекте модного бренда sprint velocity вырос на 18 % после миграции на Hydrogen — разработчики остаются в потоке, не дергаясь на ожидание сборки.

Developer velocity: TypeScript + инструменты

Третья метрика — coverage TypeScript, linting, тестирование. Liquid управляется JavaScript (теги <script> в шаблонах), Hydrogen — это полностью типизированный TypeScript.

Процент перехвата ошибок:

ИнструментLiquidHydrogen
Ошибка TypeScript compile-time0124/sprint
ESLint runtime warning8/sprint0
Unit test coverage12 %68 %

На Hydrogen Storefront API возвращает ответы с TypeScript типами. Если контракт API изменится, build упадёт с ошибкой — не runtime, а compile-time. На Liquid такие изменения видны только в production.

Конкретный пример: Storefront API изменил структуру ответа product.metafields (2025 Q2). На Hydrogen проектах TypeScript выдал ошибку, deployment заблокировался, ошибка исправлена ещё до боя. На Liquid проектах это проявилось как console error в production, обнаружено через 3 дня. На крупных e-commerce это критичный риск.

Стоимость миграции: Effort переноса

Четвёртая метрика — затраты на перенос существующей Liquid темы в Hydrogen. Данные effort'а с трёх проектов:

Проект A (мода, 80 SKU):

  • Liquid LOC: ~4200
  • Миграция Hydrogen: 18 дней разработки
  • React компонентов: 32

Проект B (электроника, 1200 SKU):

  • Liquid LOC: ~9800
  • Миграция Hydrogen: 42 дня разработки
  • React компонентов: 78

Проект C (косметика, 240 SKU):

  • Liquid LOC: ~6100
  • Миграция Hydrogen: 28 дней разработки
  • React компонентов: 51

Среднее соотношение: 1 строка Liquid = 0,004 дня разработки. То есть 5000 строк Liquid темы = ~20 дней разработки на Hydrogen. Без учёта тестирования и QA.

Самая затратная часть миграции — flow корзины и чекаута (на Liquid встроенные Shopify компоненты, на Hydrogen нужна кастомная реализация). На проекте B на checkout пришло потратить дополнительно 12 дней, потому что динамическая логика скидок переносилась с Liquid в React и требовала полного переалибра тестов.

Анализ компромисса

Миграция окупается в сценарии: высокий трафик + требования персонализации. На проекте travel e-commerce (120k session/день) переход на Hydrogen привёл к росту conversion rate %2,1 → %2,6. Причина: LCP упал с 2,8 с до 1,4 с, bounce rate снизился. 20 дней миграции окупились за 4 месяца.

Миграция не окупается: низкий трафик + редкие обновления каталога. B2B сайт промышленных деталей (800 session/день) не смог амортизировать затраты на миграцию за 14 месяцев — трафик не рос, изменился только dev stack.

Runtime cost: Хостинг + API квота

Пятая метрика — инфраструктура и расход API. Hydrogen работает на Oxygen или self-hosted edge runtime, Liquid работает на серверах Shopify.

Pricing Oxygen (Shopify Plus):

  • Включено: 1M запросов/месяц
  • Сверх: $0,50 / 10k запросов

Квота Storefront API:

  • Hydrogen: всё через Storefront API (cost запросов растёт)
  • Liquid: серверная шаблонизация, меньше API запросов

На сайте моды (200k session/месяц):

  • Liquid: $0 дополнительно (включено в Shopify)
  • Hydrogen: $120/месяц (2,4M запросов, 1,4M сверх лимита)

Квота API требует внимания на Hydrogen. Каждый SSR маршрут бьёт в Storefront API. Без агрессивной стратегии кеша можно выбежать из квоты. Мы используем pattern stale-while-revalidate:

// Пример loader маршрута Hydrogen
export async function loader({context}: LoaderFunctionArgs) {
  const {storefront} = context;
  
  return defer({
    products: storefront.query(PRODUCTS_QUERY, {
      cache: storefront.CacheCustom({
        mode: 'public',
        maxAge: 3600,
        staleWhileRevalidate: 86400, // 24 часа старого контента
      }),
    }),
  });
}

Этот pattern снизил API запросы на 40 %. Но есть риск: старый контент может показаться 1 час — цены, стоки обновляются с задержкой. Компромисс: стоимость vs свежесть данных.

На основе каких факторов принимали решение

Шестая метрика — не метрика, это матрица решения. Hydrogen мы выбирали для проектов:

  1. 50k+ session/день — улучшение LCP напрямую влияет на conversion
  2. Высокие требования персонализации — edge SSR обслуживает динамический контент быстро
  3. Team знает React — миграция гладкая, velocity растёт
  4. Shopify Plus — Oxygen в плане, нет лишней стоимости runtime

Liquid оставляем в проектах:

  1. <5k session/день — стоимость миграции не окупается
  2. Статический каталог — обновления редкие, Liquid template достаточен
  3. Маленькая team — React не знают, обучение дорого стоит
  4. Бюджет ограничен — миграция + hosting cost не дополучаются

Конкретный пример: цепь супермаркетов (80k session/день, 4000 SKU) — мигрировали на Hydrogen. TTFB упал 480 мс → 190 мс, LCP 3,2 с → 1,6 с. Conversion rate вырос %1,8 → %2,3 (+27 %). Миграция заняла 35 дней разработки, окупилась за 6 месяцев. Параллельно проект бутик-отеля (1200 session/день) остался на Liquid — трафик низкий, LCP уже 2,1 с (приемлем), миграция не обоснована.

Следующий шаг: гибридный подход

Выбор Hydrogen/Liquid — не бинарный. На архитектуре Headless Commerce можно SSR критические маршруты на Hydrogen (PDP, PLP) и оставить некритичные на Liquid (блог, справочные страницы). Гибридный setup снижает риск миграции, расходы остаются под контролем.

Наши критерии выбора: цифры говорят — TTFB, conversion rate, developer velocity. Высокий volume session и критичные Core Web Vitals — Hydrogen даст чистый выигрыш. Низкий трафик и team не знает React — Liquid прагматичный выбор. Решение принимайте в месте, где живут ваши метрики — на dashboard.