Разработка кастомной темы Shopify (Liquid)
Мы разрабатываем кастомные темы Shopify на Liquid, когда ни одна из готовых тем не соответствует вашему дизайну, структуре секций или требованиям производительности. Наша команда имеет 10-летний опыт в веб-разработке и реализовала более 50 проектов на Shopify. Наши инженеры — сертифицированные Shopify Experts, создают уникальную тему с нуля или глубоко кастомизируют существующую, используя Liquid, CSS (Tailwind или BEM) и JavaScript (Vanilla JS, Web Components или Alpine.js). Такой подход даёт полный контроль над интерфейсом, вёрсткой и логикой магазина.
Какие проблемы решает кастомная тема?
Готовые темы часто страдают от неоптимальной архитектуры: избыточный CSS, тяжелые скрипты, отсутствие адаптации под специфику товаров. Кастомная тема устраняет эти проблемы:
-
Производительность. Убираем неиспользуемый код, оптимизируем загрузку шрифтов и изображений. Кастомная тема в среднем загружается на 30–50% быстрее, чем тема из Theme Store.
-
Уникальный дизайн. Любая секция, любой блок — без ограничений Theme Editor. Реализуем макеты любой сложности: параллакс, анимации, нестандартная корзина.
-
Гибкость данных. Используем метаполя Shopify для хранения кастомной информации (дата поставки, артикулы, размеры). Настраиваем фильтрацию и сортировку под каталог.
Как мы разрабатываем кастомную тему?
Каждый проект начинается с аудита текущей темы (если она есть) и согласования архитектуры. Мы используем стандарт Online Store 2.0 — это обязательное требование для всех современных тем. В основе лежат JSON-шаблоны и секции с вложенными блоками.
Пример структуры секции с кастомными настройками:
{%- comment -%} sections/product-hero.liquid {%- endcomment -%}
<div class="product-hero" style="--accent: {{ section.settings.accent_color }}">
{% for block in section.blocks %}
{% case block.type %}
{% when 'title' %}
<h1 class="product-hero__title">{{ product.title }}</h1>
{% when 'price' %}
<div class="product-hero__price">
{{ product.selected_or_first_available_variant.price | money }}
</div>
{% when 'add_to_cart' %}
<button type="submit" form="product-form-{{ section.id }}" class="btn btn--primary"
{% unless product.available %}disabled{% endunless %}>
{{ block.settings.button_text | default: 'В корзину' }}
</button>
{% endcase %}
{% endfor %}
</div>
{% schema %}
{
"name": "Product Hero",
"tag": "section",
"class": "section-product-hero",
"settings": [
{ "type": "color", "id": "accent_color", "label": "Акцентный цвет", "default": "#0066cc" }
],
"blocks": [
{ "type": "title", "name": "Название товара", "limit": 1 },
{ "type": "price", "name": "Цена", "limit": 1 },
{ "type": "add_to_cart", "name": "Кнопка «В корзину»", "limit": 1,
"settings": [
{ "type": "text", "id": "button_text", "label": "Текст кнопки", "default": "В корзину" }
]
}
],
"presets": [
{
"name": "Product Hero",
"blocks": [ { "type": "title" }, { "type": "price" }, { "type": "add_to_cart" } ]
}
]
}
{% endschema %}
Для динамических элементов используем Web Components или Alpine.js — они не требуют сборки и идеально ложатся в экосистему Shopify.
Почему важно оптимизировать производительность темы?
Core Web Vitals — прямые факторы ранжирования в Google, и кастомная тема позволяет управлять каждым байтом. Мы критический CSS инлайним в <head>, некритический загружаем асинхронно. Шрифты подключаем с font-display: swap и preconnect. Изображения обрабатываем через CDN с lazy-loading и адаптивными разрешениями.
{{ product.featured_image
| image_url: width: 800
| image_tag:
loading: 'lazy',
widths: '400, 800, 1200',
sizes: '(max-width: 768px) 100vw, 50vw'
}}
Согласно данным Shopify, улучшение Core Web Vitals напрямую влияет на конверсию. Результаты оптимизации нашей темы:
| Метрика |
До оптимизации |
После |
| LCP |
4.2 с |
1.8 с |
| TBT |
350 мс |
120 мс |
| CLS |
0.15 |
0.02 |
Как кастомная тема влияет на конверсию?
Улучшение LCP на 2.4 секунды и снижение CLS до 0.02 уменьшает показатель отказов и увеличивает время на сайте. По нашим данным, после внедрения кастомной темы конверсия в среднем растёт на 15–20%. Это связано с тем, что пользователи не ждут загрузки и не сталкиваются со смещением контента. Дополнительно мы внедряем микроразметку, которая повышает CTR в выдаче.
Почему стоит инвестировать в кастомную тему?
Готовая тепа стоит дёшево, но её производительность и гибкость ограничены. Кастомная разработка — это инвестиция, которая окупается за счёт роста продаж, снижения нагрузки на сервер и уменьшения затрат на доработки. Вы получаете контроль над каждым элементом, а наша гарантия на код и месячная поддержка обеспечивают спокойствие. Свяжитесь с нами, чтобы обсудить ваш проект и получить предварительную оценку. Закажите консультацию инженера — мы поможем разобраться, нужна ли вам кастомная тема.
Процесс работы и что входит
- Аналитика и аудит — проверяем текущую тему, собираем требования по дизайну и функционалу.
- Проектирование — разрабатываем структуру секций, схему метаполей, маршруты.
- Разработка — пишем код на Liquid, настраиваем бандлер (Vite или Webpack), интегрируем приложения через App Block.
- Тестирование — функциональное (корзина, чекаут), кросс-браузерное, производительность (Lighthouse, WebPageTest).
- Деплой и документация — публикуем тему, передаём доступы, инструкции по редактированию.
Отметим: что входит в результат:
- Полностью кастомная тема с уникальным дизайном.
- Оптимизированные изображения, шрифты, скрипты.
- Документация по секциям и настройкам.
- Обучение редакторов работе в Theme Editor.
- Гарантия поддержки в течение месяца после сдачи.
Сравнение кастомной и готовой темы
| Параметр |
Готовая тема |
Кастомная тема |
| Индивидуальный дизайн |
Ограничен |
Неограничен |
| Производительность |
Средняя (зависит от кода) |
Высокая (оптимизация под проект) |
| Гибкость секций |
Фиксированные |
Любые блоки и настройки |
| Обновляемость |
Автоматические обновления |
Под контролем разработчика |
| Стоимость |
Низкая (single purchase) |
Индивидуальная |
Сроки ориентировочно
- Разработка с нуля по макету (до 15 типов страниц) — 3–6 недель.
- Кастомизация существующей темы под брендбук с сохранением обновляемости — 1–2 недели.
- Рефакторинг legacy-темы в OS 2.0 — 2–3 недели.
Точная стоимость рассчитывается после аудита и утверждения ТЗ. Получите консультацию инженера — напишите нам.
Технические детали архитектуры OS 2.0
Используйте JSON-шаблоны для страниц, секции с поддержкой blocks, app blocks для интеграции приложений. Подробнее в официальной документации Shopify.
Разработка интернет-магазинов
Мы знаем: интернет-магазин — это не просто «сайт с корзиной». Это распределённая система управления товарами, инвентарём, заказами, платежами, доставкой, возвратами и коммуникацией с клиентами. Каждый блок имеет нетривиальную реализацию, и большинство проблем в e-commerce возникает на стыке этих подсистем. Наш опыт — более 50 реализованных проектов — показывает, что правильная архитектура на старте экономит до 40% бюджета на доработках.
Почему производительность каталога деградирует при росте SKU?
Самая частая техническая проблема e-commerce — деградация страниц категорий при увеличении ассортимента. Страница работает хорошо на 500 товарах и начинает тормозить на 10 000. Причины почти всегда одни и те же.
N+1 на атрибутах. Загружаете список товаров — 50 элементов. Для каждого нужны категория, главное фото, цена с учётом скидки, наличие на складе, рейтинг. Без правильного eager loading это 250+ запросов на страницу. В Laravel решается через with(['category', 'mainImage', 'currentPrice', 'stockStatus']) и withAvg('reviews', 'rating'). Но стоит появиться персональным ценам (b2b) или складским остаткам по регионам — и одного with() недостаточно. Нужны Query Object или выделенный ReadModel.
Фасетная фильтрация без индексов. Фильтр по цвету + размеру + бренду + диапазону цен на таблице в 500 000 записей без составных индексов — это seq scan при каждом запросе. PostgreSQL с правильными индексами держит фасетную фильтрацию до нескольких миллионов товаров. Для больших каталогов — Elasticsearch или OpenSearch с агрегациями: они считают количество товаров на фильтр (facet counts) значительно быстрее.
Пагинация через OFFSET. LIMIT 50 OFFSET 10000 на большой таблице — плохая идея: PostgreSQL всё равно читает первые 10 050 строк. Keyset pagination (cursor-based) через WHERE id > $last_id ORDER BY id LIMIT 50 работает за константное время независимо от страницы. Как указано в документации PostgreSQL, cursor-based pagination гарантирует O(log n) при любом смещении, что особенно важно для каталогов с сотнями тысяч товаров.
Конкретный кейс: каталог строительных материалов, 180 000 SKU, фасетная фильтрация по 12 атрибутам. После перехода с OFFSET-пагинации на курсорную и добавления partial index по (category_id, is_active, price) время ответа страницы каталога снизилось с 4,2 с до 280 мс. Экономия на серверных ресурсах составила около 30 000 ₽ в месяц. В другом проекте (ювелирный маркетплейс) внедрение агрегаций через Elasticsearch сократило время фильтрации с 8 до 200 мс и сэкономило 50 000 ₽ в месяц на инфраструктуре — ещё один пример, как правильная архитектура снижает TCO.
Что такое race condition в корзине и как его избежать?
Checkout — место, где деньги либо попадают на счёт, либо нет. Технические проблемы здесь стоят дорого.
Race condition при резервировании товара. Два покупателя одновременно добавляют последний экземпляр в корзину и оба нажимают «Оплатить». Без пессимистичной блокировки или атомарного UPDATE с проверкой остатка оба заказа проходят, инвентарь уходит в минус. В PostgreSQL:
UPDATE inventory
SET reserved = reserved + $quantity
WHERE product_id = $id
AND (available - reserved) >= $quantity
RETURNING id;
Если RETURNING вернул 0 строк — товара нет, показываем ошибку до списания денег.
Идемпотентность платёжных вебхуков. payment.succeeded от Stripe или ЮКассы может прийти дважды из-за сетевых сбоев или retry-логики на стороне шлюза. Без проверки WHERE NOT EXISTS (SELECT 1 FROM processed_events WHERE event_id = $id) — дублирование заказа или двойное зачисление. Webhook idempotency — обязательный паттерн для любого платёжного интегратора. Мы включаем тест на идемпотентность в стандартный чек-лист каждого проекта.
Checkout в несколько шагов. Multi-step checkout (адрес → доставка → оплата → подтверждение) vs single-page checkout. Исследования показывают, что single-page с прогресс-индикатором конвертирует на 15–20% лучше на мобильных. Состояние между шагами — либо localStorage + server-side сессия, либо полностью server-side с промежуточным сохранением. Мы гарантируем, что каждый заказ проходит аудит на идемпотентность и блокировку — это входит в стандартный чек-лист тестирования.
Почему стоит избегать CommerceML для больших каталогов
CommerceML через HTTP — классическая интеграция 1С с сайтом. 1С выгружает XML по расписанию, сайт импортирует. Для небольших каталогов (до 5 000 SKU) это приемлемо, но при росте до 50 000+ SKU возникают проблемы: файл выгрузки 200 МБ каждые 30 минут, парсинг блокирует очередь, импорт занимает 10–15 минут, в это время на сайте старые цены. Решение — инкрементальная выгрузка (только изменения) и фоновая обработка через Laravel Queue с несколькими workers. Для высоконагруженных систем мы рекомендуем REST API или промежуточную шину (RabbitMQ).
Интеграции: 1С, склад, доставка
1С — отдельная глава. Три распространённых способа интеграции:
-
CommerceML через HTTP — 1С выгружает XML по расписанию, сайт импортирует. Работает для небольших каталогов, есть задержка синхронизации.
-
REST API / OData от 1С — двусторонняя синхронизация в реальном времени. Требует настройки на стороне 1С, капризна к версиям конфигураций.
-
Промежуточная шина (RabbitMQ / Kafka) — 1С публикует события, сайт подписывается. Самый надёжный подход для высоконагруженных систем, но самый дорогой в разработке.
Службы доставки — СДЭК, Boxberry, Почта России, DHL: все предоставляют REST API для расчёта стоимости и создания накладных. Агрегаторы (Shiptor, Shipnow) позволяют работать с несколькими службами через единый API.
Платёжные шлюзы
| Шлюз |
Особенности интеграции |
| Stripe |
Webhook-based, отличная документация, Stripe Elements для PCI DSS |
| ЮКасса |
Популярен в РФ, поддержка ФЗ-54 (фискализация) |
| ЕРИП |
Белорусская система, SOAP API, специфическая документация |
| Tinkoff Acquiring |
REST API, 3D Secure 2.0, webhook-уведомления |
Для каждого шлюза обязательна проверка подписи вебхука — без этого любой может отправить фейковое payment.succeeded.
CMS vs собственная разработка
WooCommerce — оправдан для магазинов до ~5 000 SKU с типовой бизнес-логикой. Быстрый старт, огромная экосистема плагинов. Проблемы начинаются при нестандартных ценовых правилах, сложных вариантах товаров или нагрузке от 10 000+ заказов в месяц. Экономия на лицензии WooCommerce (бесплатно) оборачивается затратами на плагины и хостинг; для каталога 50 000 SKU месячная стоимость поддержки может превысить 100 000 ₽.
OpenCart, Prestashop — аналогичная история. Хороши для старта, ограничены при росте.
Собственная разработка на Laravel — для:
- Нестандартной бизнес-логики (подписки, аренда, b2b-прайсы, конфигуратор);
- Высоких требований к производительности;
- Сложных интеграций (несколько складов, ERP, маркетплейсы);
- Уникального UX checkout.
Как мы разрабатываем интернет-магазин: пошаговый процесс
-
Аналитика и проектирование. Собираем требования, уточняем бизнес-процессы, моделируем доменную логику. На выходе — техническое задание и архитектурная схема.
-
Backend и API. Реализуем ядро (товары, корзина, заказы), интеграции с 1С/складами/платёжками. Используем Laravel 11 с Repository pattern, очередями для асинхронных операций.
-
Frontend и checkout. Настраиваем React 18 / Next.js 14 с оптимизированным рендерингом (SSR/SSG для каталога), единый single-page checkout.
-
Тестирование. Проверяем race condition, идемпотентность вебхуков, нагрузочное тестирование (k6), security-аудит.
-
Деплой и мониторинг. Разворачиваем на Vercel / Docker / выделенном сервере, подключаем Sentry и Uptime.
SEO для e-commerce
Canonical и дублирование. Фасетная фильтрация генерирует тысячи URL (?color=red&size=M&sort=price). Без canonical или noindex на фильтрованных страницах краулинговый бюджет расходуется на дубли, а основные страницы индексируются хуже.
Structured data. Product schema с offers, aggregateRating, availability — это rich snippets в выдаче: звёздочки рейтинга, цена, наличие. Влияет на CTR.
Core Web Vitals на страницах товаров. Hero image товара — это LCP element. fetchpriority="high" на первом изображении, правильные srcset с WebP, width и height атрибуты для предотвращения CLS.
Что входит в результат работы
После завершения проекта вы получаете:
- Исходный код и полную документацию (API, архитектура, инфраструктура);
- Доступы к репозиторию, хостингу, мониторингу (Sentry, Uptime);
- Обучение команды работе с админ-панелью и кастомизациями;
- Гарантийную поддержку 3 месяца (исправление ошибок, консультации);
- Подробный отчёт по нагрузочному тестированию и оптимизации.
Ориентиры по срокам
| Тип магазина |
Срок |
| Малый (до 1 000 SKU, типовая логика) |
8–12 недель |
| Средний (до 50 000 SKU, интеграция 1С) |
14–20 недель |
| Крупный (100 000+ SKU, ERP, маркетплейсы) |
24–40 недель |
Стоимость рассчитывается после анализа требований: количество интеграций, сложность ценообразования, объём каталога и уникальность UX — основные факторы. Оценим ваш проект бесплатно — закажите консультацию.
Чек-лист перед запуском
- Race condition при оплате последнего товара — покрыт тестом
- Идемпотентность вебхуков платёжного шлюза
- Rate limiting на эндпоинтах корзины и checkout
- Canonical на фильтрованных страницах каталога
- Фискализация чеков (ФЗ-54 для РФ или аналог)
- Стресс-тест checkout под нагрузкой (k6 или Locust)
- Мониторинг ошибок (Sentry) и алерты на payment errors
- Backup базы данных с проверенным restore-процессом
Гарантируем — каждый проект проходит этот чек-лист перед релизом. Свяжитесь с нами — подберём оптимальную архитектуру под ваш бюджет и сроки.
