Разработка 360°-просмотра товара для интернет-магазина

Разработка 360°-просмотра товара для интернет-магазина

На одном из недавних проектов мы столкнулись с типичной проблемой: 72 кадра по 500 КБ каждый загружались асинхронно, но страница всё равно весила 36 МБ, LCP достигал 12 секунд, а пользователи покидали страницу, не дождавшись загрузки. После замены формата на WebP с прогрессивной загрузкой и внедрения приоритизации нечётных кадров LCP упал до 1.8 секунды, а конверсия выросла на 15%. Такой результат — прямое следствие грамотной стратегии загрузки, а не сложности кода.

360°-просмотр — это последовательность фотографий объекта (см. Продуктовая фотография), сделанных с равномерным шагом по кругу. Пользователь перетаскивает изображение влево-вправо и видит товар со всех сторон. Технически это не видео и не 3D — просто анимация через массив статических кадров, но эффект создаёт иллюзию интерактивного вращения. Ключевая задача — обеспечить плавное вращение без потери производительности.

Такой формат особенно эффективен для товаров, где важен внешний вид: одежда, обувь, электроника, ювелирные изделия. Однако реализация требует внимания к деталям: от съёмки до формата хранения и стратегии загрузки. Без этого пользовательский опыт ухудшается, а не улучшается. Получите консультацию по реализации 360°-просмотра в вашем магазине — мы поможем избежать типовых ошибок.

Технические требования к съёмке

Какой формат хранения кадров выбрать?

Три основных подхода — их сравнение в таблице:

Видео (MP4) в 3–5 раз компактнее, чем отдельные WebP-файлы, но требует более сложного управления воспроизведением. Если гибкость важнее минимального веса, выбирайте отдельные файлы.

Как реализовать 360-просмотр на отдельных кадрах?

Наиболее распространённый подход — массив изображений с отрисовкой на Canvas. Код компонента:

class Product360Viewer {
  private frames: HTMLImageElement[] = [];
  private currentFrame = 0;
  private isDragging = false;
  private startX = 0;
  private startFrame = 0;

  constructor(
    private container: HTMLElement,
    private canvas: HTMLCanvasElement,
    private frameUrls: string[]
  ) {
    this.preloadFrames();
    this.bindEvents();
  }

  private preloadFrames() {
    // Загружаем первый кадр сразу, остальные в фоне
    const loadFrame = (index: number) => {
      const img = new Image();
      img.src = this.frameUrls[index];
      img.onload = () => {
        this.frames[index] = img;
        if (index === 0) this.render(0);
        if (index < this.frameUrls.length - 1) loadFrame(index + 1);
      };
    };
    loadFrame(0);
  }

  private render(frameIndex: number) {
    const ctx = this.canvas.getContext('2d')!;
    const img = this.frames[frameIndex];
    if (!img) return;
    ctx.clearRect(0, 0, this.canvas.width, this.canvas.height);
    ctx.drawImage(img, 0, 0, this.canvas.width, this.canvas.height);
  }

  private handleDrag(deltaX: number) {
    const sensitivity = 3; // пикселей на кадр
    const frameDelta = Math.round((this.startX - deltaX) / sensitivity);
    const totalFrames = this.frameUrls.length;
    this.currentFrame = ((this.startFrame + frameDelta) % totalFrames + totalFrames) % totalFrames;
    this.render(this.currentFrame);
  }
}

Почему прогрессивная загрузка критична для крупных каталогов?

7MB сразу при открытии страницы — неприемлемо. В одном проекте с каталогом на 500 товаров мы внедрили следующую стратегию:

1. Отображаем статичное изображение (первый кадр) — он уже в галерее товара
2. При наведении / при попадании в viewport (IntersectionObserver) — начинаем загрузку кадров
3. Показываем индикатор загрузки «Загрузка 360°: 45%»
4. При загрузке >50% кадров — активируем интерактивность
5. Продолжаем загружать остальные в фоне

Приоритет загрузки: нечётные кадры (0, 2, 4, 8, 16, 32...) — сначала грубая интерактивность, потом заполнение пропусков. Такой подход снижает объём начальной загрузки на 70% по сравнению с полной загрузкой всех кадров.

Как обрабатывать touch-события на мобильных устройствах?

private bindEvents() {
  // Mouse
  this.canvas.addEventListener('mousedown', e => this.startDrag(e.clientX));
  window.addEventListener('mousemove', e => { if (this.isDragging) this.handleDrag(e.clientX); });
  window.addEventListener('mouseup', () => this.isDragging = false);

  // Touch
  this.canvas.addEventListener('touchstart', e => {
    e.preventDefault(); // предотвращаем scroll страницы
    this.startDrag(e.touches[0].clientX);
  }, { passive: false });

  this.canvas.addEventListener('touchmove', e => {
    e.preventDefault();
    if (this.isDragging) this.handleDrag(e.touches[0].clientX);
  }, { passive: false });

  this.canvas.addEventListener('touchend', () => this.isDragging = false);
}

Важно: passive: false и e.preventDefault() на touchmove — иначе браузер будет скроллить страницу вместо вращения товара.

Готовые библиотеки vs кастомная разработка

Если задача разовая и нет специфических требований, можно использовать готовые библиотеки: 360-image-viewer (vanilla JS, поддерживает touch), Pannellum (для панорам), Three.js (для сферических панорам). Для React есть react-360-image-viewer, но кастомизация ограничена.

Сравнение подходов:

Стоимость кастомной реализации варьируется от 150 000 до 500 000 ₽ в зависимости от объёма каталога и требований к производительности.

Автозапуск вращения

При первом попадании в viewport — автоматически прокрутить один оборот, потом остановиться. Это демонстрирует возможность и подсказывает пользователю, что изображение интерактивное.

autoSpin(rotations = 1, fps = 30) {
  const totalFrames = this.frameUrls.length * rotations;
  let frame = 0;
  const interval = setInterval(() => {
    this.currentFrame = (this.currentFrame + 1) % this.frameUrls.length;
    this.render(this.currentFrame);
    if (++frame >= totalFrames) clearInterval(interval);
  }, 1000 / fps);
}

Подсказки для пользователя

Интерактивность должна быть очевидна. Стандартные решения:

• Иконка «360°» поверх изображения в галерее (на тумбнейле)
• Overlay с подсказкой «Перетащите для вращения» — исчезает при первом взаимодействии
• Стрелочки влево-вправо по бокам (альтернативное управление для кнопочной навигации)
• Кнопки «Пауза/Воспроизвести» для автовращения

Интеграция с галереей

360°-просмотр — один из слотов галереи товара. Тумбнейл — специальная иконка, не фото. При выборе этого слота — запускается 360°-виджет вместо обычного изображения. При переходе на другой слот — виджет размонтируется и освобождает память (отменяем все незавершённые загрузки через AbortController).

Что входит в работу

• Интеграция готовой библиотеки: 3–5 рабочих дней. Включает настройку и встраивание в галерею.
• Кастомная реализация (Canvas API, прогрессивная загрузка, touch): 1.5–2.5 недели. Пишется полностью под ваш проект.
• Сопровождение: документация по съёмке, скрипты конвертации кадров в WebP, оптимизация.
• Гарантия: поддерживаем работоспособность на всех современных браузерах и устройствах.

Если вы планируете внедрить 360°-просмотр — свяжитесь с нами для оценки вашего каталога и подбора оптимального решения. Мы уже реализовали такие проекты для каталогов от 100 до 5000 товаров и знаем, как избежать типовых проблем. Получите консультацию по реализации 360°-просмотра в вашем магазине.

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

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

Гарантируем — каждый проект проходит этот чек-лист перед релизом. Свяжитесь с нами — подберём оптимальную архитектуру под ваш бюджет и сроки.