При розробці картки товару типова технічна проблема — об'єднання даних з кількох таблиць без 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 успішними проектами.