Розробка картки товару для інтернет-магазину

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

Чому вибір варіанту критичний для конверсії?

Якщо товар має варіанти (колір × розмір), інтерфейс вибору — ключовий елемент. Користувач повинен одразу бачити доступні комбінації та розуміти, що вибрано. Недоступні варіанти (нема на складі) блокуються візуально, щоб уникнути розчарування.

Вимоги до реалізації:

• Недоступні комбінації — візуально заблоковані (закреслені або сірі), не клікабельні
• При виборі варіанту оновлюються: зображення, ціна, наявність, 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 проблем. Типова стратегія:

1. SSR основного контенту — назва, головне зображення, ціна, кнопка «Купити». Приходить з першим HTML, індексується пошуковиком.
2. Lazy-load блоків — відгуки, схожі товари, «з цим купують» — завантажуються після DOMContentLoaded через окремі API-запити.
3. Кеш картки — повний 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%.

Як ми працюємо?

1. Аналітика — аудит поточної картки, збір вимог, визначення метрик успіху.
2. Проектування — створення прототипу, вибір стеку (React/Vue, Node/PHP), узгодження API.
3. Реалізація — розробка SSR, блоків, інтеграція з CMS/ERP.
4. Тестування — перевірка на реальних даних, A/B-тести конверсії.
5. Деплой та моніторинг — розгортання на продакшен, налаштування алертів по LCP та помилках.

Що входить у роботу

• Документація API та схеми даних
• Репозиторій з кодом та інструкцією з розгортання
• Навчання редакторів роботі з CMS
• Підтримка протягом 30 днів після запуску

Строки орієнтовно

Вартість розраховується індивідуально, виходячи зі складності інтеграцій та обсягу даних. Зв'яжіться з нами для консультації — допоможемо підібрати оптимальну архітектуру під ваш стек і навантаження.

Типові помилки при розробці картки товару

• N+1 запити при вибірці варіантів та зображень — вирішується одним запитом з JSON-агрегацією.
• CLS > 0,1 через відсутність aspect-ratio на зображеннях — резервуємо місце через CSS.
• Ігнорування Schema.org — без розмітки сторінка не потрапляє в rich snippets, втрачається CTR.
• Вибір варіанту без блокування недоступних комбінацій — користувач витрачає час на невалідні варіанти.

Замовте розробку картки товару — отримайте готове рішення з документацією, навчанням та підтримкою. Ми гарантуємо результат, підтверджений більш ніж 200 успішними проектами.

Розробка інтернет-магазинів

Ми знаємо: інтернет-магазин — це не просто «сайт з кошиком». Це розподілена система управління товарами, інвентарем, замовленнями, платежами, доставкою, поверненнями та комунікацією з клієнтами. Кожен блок має нетривіальну реалізацію, і більшість проблем в 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 з проміжним збереженням. Ми гарантуємо, що кожне замовлення проходить аудит на ідемпотентність та блокування — це входить у стандартний чек-лист тестування.

Як інтегрувати 1С з інтернет-магазином?

1С — окрема глава. Три поширених способи інтеграції:

1. CommerceML через HTTP — 1С вивантажує XML за розкладом, сайт імпортує. Працює для невеликих каталогів, є затримка синхронізації.
2. REST API / OData від 1С — двостороння синхронізація в реальному часі. Вимагає налаштування на стороні 1С, примхлива до версій конфігурацій.
3. Проміжна шина (RabbitMQ / Kafka) — 1С публікує події, сайт підписується. Найнадійніший підхід для високонавантажених систем, але найдорожчий у розробці.

Служби доставки — СДЕК, Boxberry, Пошта Росії, DHL: всі надають REST API для розрахунку вартості та створення накладних. Агрегатори (Shiptor, Shipnow) дозволяють працювати з кількома службами через єдиний API.

Платіжні шлюзи

Для кожного шлюзу обов'язкова перевірка підпису вебхука — без цього будь-хто може відправити фейковий payment.succeeded.

CMS vs власна розробка

WooCommerce — виправданий для магазинів до ~5 000 SKU з типовою бізнес-логікою. Швидкий старт, величезна екосистема плагінів. Проблеми починаються при нестандартних цінових правилах, складних варіантах товарів або навантаженні від 10 000+ замовлень на місяць. Економія на ліцензії WooCommerce (безкоштовно) обертається витратами на плагіни та хостинг; для каталогу 50 000 SKU місячна вартість підтримки може перевищити 100 000 ₽.

OpenCart, Prestashop — аналогічна історія. Хороші для старту, обмежені при зростанні.

Власна розробка на Laravel — для:

• Нестандартної бізнес-логіки (підписки, оренда, b2b-прайси, конфігуратор);
• Високих вимог до продуктивності;
• Складних інтеграцій (кілька складів, ERP, маркетплейси);
• Унікального UX checkout.

Як ми розробляємо інтернет-магазин: покроковий процес

1. Аналітика та проектування. Збираємо вимоги, уточнюємо бізнес-процеси, моделюємо доменну логіку. На виході — технічне завдання та архітектурна схема.
2. Backend та API. Реалізуємо ядро (товари, кошик, замовлення), інтеграції з 1С/складами/платіжками. Використовуємо Laravel 11 з Repository pattern, чергами для асинхронних операцій.
3. Frontend та checkout. Налаштовуємо React 18 / Next.js 14 з оптимізованим рендерингом (SSR/SSG для каталогу), єдиний single-page checkout.
4. Тестування. Перевіряємо race condition, ідемпотентність вебхуків, навантажувальне тестування (k6), security-аудит.
5. Деплой та моніторинг. Розгортаємо на 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 місяці (виправлення помилок, консультації);
• Детальний звіт по навантажувальному тестуванню та оптимізації.

Орієнтири за термінами

Вартість розраховується після аналізу вимог: кількість інтеграцій, складність ціноутворення, обсяг каталогу та унікальність UX — основні фактори. Оцінимо ваш проект безкоштовно — замовте консультацію.

Чек-лист перед запуском

• Race condition при оплаті останнього товару — покритий тестом
• Ідемпотентність вебхуків платіжного шлюзу
• Rate limiting на ендпоїнтах кошика та checkout
• Canonical на фільтрованих сторінках каталогу
• Фіскалізація чеків (ФЗ-54 для РФ або аналог)
• Стрес-тест checkout під навантаженням (k6 або Locust)
• Моніторинг помилок (Sentry) та алерти на payment errors
• Backup бази даних з перевіреним restore-процесом

Гарантуємо — кожен проект проходить цей чек-лист перед релізом. Зв'яжіться з нами — підберемо оптимальну архітектуру під ваш бюджет та терміни.