При разработке карточки товара типичная техническая проблема — объединение данных из нескольких таблиц без N+1 запросов. Если выборка вариантов, изображений и атрибутов делается последовательно, страница загружается на 2–3 секунды дольше, что увеличивает показатель отказов на 20%. На одном из проектов с каталогом в 10 000 товаров мы сократили время загрузки с 3 с до 0,8 с — за счёт агрегации в одном запросе с использованием JSON-агрегации в PostgreSQL.
Отсутствие правильной разметки Schema.org и игнорирование Core Web Vitals ведёт к потере 30% потенциальной выручки из-за плохих позиций в поиске и медленной загрузки. CLS > 0,2 отпугивает пользователей — 70% уходят, если страница прыгает при загрузке. Наш подход гарантирует CLS < 0,1 и LCP < 1,5 с.
Как ускорить загрузку карточки товара?
Производительность — критический фактор для карточки. Мы добиваемся LCP менее 1,5 секунды за счёт:
- SSR основного контента (название, цена, главное изображение) с первым HTML
- lazy-load блоков (отзывы, похожие товары, «с этим покупают»)
- CDN-кеширования с s-maxage=300 и инвалидацией через API
-
<img loading="eager" fetchpriority="high">для главного изображения и WebP с fallback -
aspect-ratioдля резервирования места под изображения (CLS < 0,1)
Согласно документации MDN, атрибут fetchpriority позволяет управлять приоритетом загрузки изображений. SSR-рендеринг обеспечивает TTFB на 60% меньше, чем полностью клиентский рендеринг — это в 2,5 раза быстрее по LCP. <cite>MDN Web Docs</cite>
| Подход | LCP (сек) | CLS | FID (мс) |
|---|---|---|---|
| CSR | 3–5 | 0,2–0,5 | 100–300 |
| SSR | 1,5–2,5 | <0,1 | 50–100 |
| SSG (ISR) | 0,8–1,5 | <0,05 | 20–50 |
Почему выбор варианта критичен для конверсии?
Если товар имеет варианты (цвет × размер), интерфейс выбора — ключевой элемент. Пользователь должен сразу видеть доступные комбинации и понимать, что выбрано. Недоступные варианты (нет на складе) блокируются визуально, чтобы избежать разочарования.
Требования к реализации:
- Недоступные комбинации — визуально заблокированы (зачёркнуты или серые), не кликабельны
- При выборе варианта обновляются: изображение, цена, наличие, SKU в URL
- Если вариант закончился — показываем «Нет в наличии» + кнопку «Уведомить о поступлении»
type VariantSelector = { attributes: { id: number; name: string; values: VariantValue[] }[]; selection: Record<number, string>; onSelect: (attributeId: number, value: string) => void; }; function isAvailable(selection: Record<number, string>, variants: Variant[]): boolean { return variants.some(v => Object.entries(selection).every(([attrId, val]) => v.attributes[attrId] === val ) && v.inStock ); } URL обновляется через pushState при каждом выборе: /product/sneakers-air-max?color=black&size=42. Это позволяет поделиться ссылкой на конкретный вариант и работает с кнопкой «Назад».
Структура данных карточки
Одна страница карточки агрегирует данные из разных таблиц:
Product ├── Варианты (sku, цена, наличие) ├── Изображения (по вариантам и общие) ├── Атрибуты (specs, характеристики) ├── Описание (rich text) ├── Категория + Breadcrumb ├── Рейтинг (агрегированный) + последние отзывы ├── Похожие товары ├── «Часто покупают вместе» └── Цена с историей скидок Всё это нельзя грузить одним запросом без N+1 проблем. Типовая стратегия:
- SSR основного контента — название, главное изображение, цена, кнопка «Купить». Приходит с первым HTML, индексируется поисковиком.
- Lazy-load блоков — отзывы, похожие товары, «с этим покупают» — загружаются после DOMContentLoaded через отдельные API-запросы.
- Кеш карточки — полный HTML страницы кешируется на CDN с инвалидацией при изменении товара.
Основные блоки
Блок цены
Цена — не просто число. Типичный набор состояний:
- Обычная цена
- Цена со скидкой (зачёркнутая старая + новая)
- Диапазон цен для товаров с вариантами («от суммы»)
- «Цена по запросу» для B2B-товаров
- «Войдите для просмотра цены» (оптовые клиенты)
История цены: небольшой график изменения цены за 30–90 дней — сигнал доверия. «Минимальная цена за 30 дней: —» — аналог маркировки на WB и Ozon. Обратный отсчёт до конца акции: если discount.ends_at задан, показываем таймер. Реализация на клиенте через setInterval, синхронизация с серверным временем при загрузке страницы.
Блок наличия и доставки
Пользователь хочет знать: когда он получит товар? Это важнее, чем сама кнопка «Купить».
- «Есть в наличии: 12 шт.» (или «Мало осталось: 2 шт.» при qty < 5)
- «Доставка завтра» — если оформить до 18:00 (вычисляется по текущему времени + графику работы склада)
- «Самовывоз сегодня» — список ближайших точек выдачи с наличием
Расчёт даты доставки — серверная логика: рабочие дни склада, регион пользователя, тип доставки. Передаётся как строка в API-ответе, не вычисляется на клиенте.
Блок отзывов
Отзывы — конверсионный элемент и SEO-контент одновременно. Структура:
- Агрегированный рейтинг (звёзды + распределение по баллам: гистограмма 1–5)
- Кнопка «Написать отзыв» (форма с рейтингом, текстом, загрузкой фото)
- Список отзывов с пагинацией (или lazy load)
- Фильтры: «Только с фото», «5 звёзд», «Последние»
Антиспам для отзывов: разрешаем только авторизованным, только тем, кто купил товар (проверка по orders). Модерация — очередь для менеджера. Schema.org разметка: AggregateRating с ratingValue, reviewCount. Это влияет на звёздочки в результатах поиска (rich snippets).
CTA — кнопка покупки
Кнопка «Купить» / «В корзину» — главный элемент страницы. Паттерны:
- «В корзину»: добавляет в корзину, пользователь продолжает просмотр. Подходит для магазинов с частыми множественными покупками.
- «Купить сейчас»: добавляет и редиректит на чекаут. Укорачивает путь для целевого покупателя.
- Sticky CTA: при скролле вниз появляется фиксированная панель с ценой и кнопкой. Удерживает конверсионный элемент в зоне видимости.
При добавлении в корзину — feedback: анимация иконки корзины, мини-попап или drawer с подтверждением. Пользователь должен чувствовать, что действие выполнено.
Связанные товары
«Похожие товары» и «С этим покупают» — разные алгоритмы:
- Похожие: товары той же категории с похожими атрибутами (та же ценовая группа, тот же бренд или атрибуты)
-
Часто покупают вместе: коллаборативная фильтрация — анализ пар товаров в одном заказе. Самый простой вариант:
SELECT product_id, COUNT(*) FROM order_items WHERE order_id IN (SELECT order_id FROM order_items WHERE product_id = :id) GROUP BY product_id ORDER BY COUNT(*) DESC LIMIT 5
SEO-разметка и производительность
<!-- Open Graph для шаринга в соцсетях --> <meta property="og:title" content="Ноутбук Apple MacBook Air 13 M3 — Название магазина"> <meta property="og:image" content="https://cdn.../product-main.jpg"> <meta property="og:type" content="product"> <!-- Schema.org Product --> <script type="application/ld+json"> { "@type": "Product", "name": "Apple MacBook Air 13", "image": ["https://cdn.../img1.jpg"], "description": "...", "brand": { "@type": "Brand", "name": "Apple" }, "offers": { "@type": "Offer", "price": "89990", "priceCurrency": "RUB", "availability": "https://schema.org/InStock", "priceValidUntil": "через год от даты публикации" }, "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.8", "reviewCount": "127" } } </script> Согласно Schema.org Product, разметка Product позволяет поисковым системам отображать rich snippets. Грамотная разметка даёт прирост CTR до 30% и улучшает видимость в AI Overview.
Как мы обеспечиваем качество?
Мы разработали более 200 карточек для магазинов разного профиля — от одежды до сложной электроники. Наш опыт позволяет избежать типовых ошибок: N+1 запросы, CLS > 0,1, отсутствие rich snippets. Мы гарантируем соответствие Core Web Vitals и увеличение конверсии в среднем на 15–25%. Окупаемость вложений в карточку — в среднем 2 месяца, а экономия на разработке за счёт готовых шаблонов составляет до 30%.
| Блок | Влияние на конверсию | Техническая сложность |
|---|---|---|
| Выбор варианта | высокая | средняя |
| Блок отзывов | высокая | низкая |
| Sticky CTA | средняя | низкая |
| История цены | средняя | средняя |
Как мы работаем?
- Аналитика — аудит текущей карточки, сбор требований, определение метрик успеха.
- Проектирование — создание прототипа, выбор стека (React/Vue, Node/PHP), согласование API.
- Реализация — разработка SSR, блоков, интеграция с CMS/ERP.
- Тестирование — проверка на реальных данных, A/B-тесты конверсии.
- Деплой и мониторинг — развёртывание на продакшен, настройка алертов по LCP и ошибкам.
Что входит в работу
- Документация API и схемы данных
- Репозиторий с кодом и инструкцией по развёртыванию
- Обучение редакторов работе с CMS
- Поддержка в течение 30 дней после запуска
Сроки ориентировочно
| Тип карточки | Сроки | Состав |
|---|---|---|
| Базовая | от 2 недель | Фото, цена, варианты, кнопка, характеристики |
| Полноценная | от 4 недель | + отзывы, похожие товары, sticky CTA, история цены, Schema.org, производительность |
Стоимость рассчитывается индивидуально, исходя из сложности интеграций и объёма данных. Свяжитесь с нами для консультации — поможем подобрать оптимальную архитектуру под ваш стек и нагрузку.
Подробнее о кешировании карточки
Полный HTML страницы кешируется на CDN (например, Cloudflare) с s-maxage=300 и инвалидацией при изменении товара. Для динамических блоков (цена, наличие) используется lazy-load после DOMContentLoaded.Типичные ошибки при разработке карточки товара
- N+1 запросы при выборке вариантов и изображений — решается одним запросом с JSON-агрегацией.
- CLS > 0,1 из-за отсутствия
aspect-ratioна изображениях — резервируем место через CSS. - Игнорирование Schema.org — без разметки страница не попадает в rich snippets, теряется CTR.
- Выбор варианта без блокировки недоступных комбинаций — пользователь тратит время на невалидные варианты.
Закажите разработку карточки товара — получите готовое решение с документацией, обучением и поддержкой. Мы гарантируем результат, подтверждённый более чем 200 успешными проектами.