После 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.
Процент перехвата ошибок:
| Инструмент | Liquid | Hydrogen |
|---|---|---|
| Ошибка TypeScript compile-time | 0 | 124/sprint |
| ESLint runtime warning | 8/sprint | 0 |
| Unit test coverage | 12 % | 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 мы выбирали для проектов:
- 50k+ session/день — улучшение LCP напрямую влияет на conversion
- Высокие требования персонализации — edge SSR обслуживает динамический контент быстро
- Team знает React — миграция гладкая, velocity растёт
- Shopify Plus — Oxygen в плане, нет лишней стоимости runtime
Liquid оставляем в проектах:
- <5k session/день — стоимость миграции не окупается
- Статический каталог — обновления редкие, Liquid template достаточен
- Маленькая team — React не знают, обучение дорого стоит
- Бюджет ограничен — миграция + 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.