Перевели WP+Woocommerce на собственное frontend-приложение

Кратко

FLUIDE — российский бренд женской одежды для спорта и повседневной жизни. Интернет-магазин развивался на WordPress и WooCommerce: в этой системе команда управляла товарами, ценами, остатками, вариациями, заказами и интеграцией с учетным контуром.

Со временем публичная часть сайта стала заметно тяжелее. Каталог зависел от стандартного Woo loop, старого бесконечного скролла, Elementor-шаблонов и нескольких вендорных frontend-плагинов. Каждый из них решал отдельную задачу, но вместе они создавали большой DOM, загружали лишние стили и скрипты, задерживали появление карточек и давали нестабильное поведение на мобильных устройствах.

Обычная оптимизация уже не решала архитектурную проблему. При этом полный перенос магазина на другую платформу означал бы заново собирать админку, товарную модель, интеграции, заказы и привычные процессы команды.

Мы выбрали другой путь: оставили WordPress и WooCommerce в роли CMS и коммерческого backend, но заменили тяжелый публичный frontend собственным headless/light-app слоем. Каталог, архивы категорий, карточки товаров, избранное и ключевые блоки главной стали управляемыми приложениями, которые получают подготовленные данные через собственный API.

Почему сайт нельзя было ускорить одним плагином кеша

На старой витрине задержка возникала не в одной точке. Страница собиралась из WooCommerce-разметки, Elementor-шаблонов и поведения нескольких плагинов. После загрузки браузер продолжал перестраивать интерфейс: инициализировал карточки, изображения, фильтры, бесконечный скролл, избранное и другие элементы.

Это приводило к системным проблемам:

• каталог создавал тяжелое DOM-дерево еще до того, как пользователь видел товары;
• карточки и изображения появлялись с задержкой или миганием;
• старый infinite scroll усложнял возврат на прежнюю позицию;
• мобильная галерея и desktop-поведение зависели от разных плагинов;
• обновление одного компонента могло ломать стили или события другого;
• в браузер попадали ассеты, которые не требовались для текущего сценария;
• команда была ограничена возможностями и жизненным циклом вендорных решений.

Кеш мог быстрее отдать исходный HTML, но не устранял объем разметки, конкурирующие скрипты и позднюю инициализацию интерфейса. Поэтому мы оптимизировали не отдельные симптомы, а сам способ построения витрины.

Что было важно сохранить

У клиента уже существовал рабочий e-commerce-контур. WordPress и WooCommerce хранили не только карточки товаров, но и вариации по цветам и размерам, цены, остатки, статусы, заказы и данные для интеграций.

Новая архитектура не должна была заставлять контент-команду переучиваться или вести два каталога. Мы зафиксировали несколько принципов:

• WordPress остается привычной административной системой;
• WooCommerce остается источником товарных и коммерческих данных;
• существующие URL каталога и категорий сохраняются;
• корзина, оформление заказа, личный кабинет и интеграции продолжают работать;
• frontend можно развивать независимо от Woo-шаблонов и Elementor;
• миграция выполняется поэтапно без остановки продаж.

Такой подход позволил обновить именно ту часть системы, которая ограничивала скорость и UX, не переписывая работающий бизнес-контур с нуля.

Как построили новую витрину

Оставили WordPress и WooCommerce управляющим слоем

Менеджеры по-прежнему создают товары, редактируют описания, загружают фотографии, настраивают категории, цены, размеры и цвета в знакомой админке. WooCommerce продолжает отвечать за товарную модель, остатки, корзину и заказы.

Публичная страница больше не обязана выводить стандартный Woo loop. WordPress формирует легкую оболочку страницы и конфигурацию приложения, а сами товарные данные приходят через отдельные endpoint-ы.

Создали собственный API и индекс карточек

Для каталога разработали endpoint local-products, который возвращает подготовленные данные карточек: изображения, цены, наличие, цвета, бейджи, ссылки и служебные признаки. Для одиночной страницы используется отдельный local-single-product.

Чтобы не собирать тяжелую карточку заново при каждом запросе, добавили индекс каталога. Он хранит подготовленный payload товара и инвалидируется при изменении карточки, изображений или важных метаданных. API поддерживает фильтры, сортировку, курсорную пагинацию и отдельные режимы для специальных сценариев.

Frontend получает ровно тот объем данных, который нужен для текущего экрана, а backend сохраняет единый источник истины.

Заменили Woo loop собственным приложением

Новый каталог сначала строит тонкие оболочки карточек, а медиа гидратирует только возле области просмотра. Пользователь быстрее видит структуру страницы, при этом браузер не тратит ресурсы на полную галерею каждого товара далеко за пределами экрана.

В приложении реализовали:

• единый каталог для магазина, категорий и товарных меток;
• cursor-based подгрузку и предварительную загрузку следующих данных;
• восстановление позиции после возврата из карточки товара;
• отдельное поведение фильтров и сортировки на desktop и mobile;
• галерею из нескольких фотографий с hover на desktop и swipe на mobile;
• ленивую гидрацию и освобождение тяжелых медиа вне viewport;
• собственное избранное без вендорного frontend-плагина;
• skeleton-состояния без скачков товарной сетки.

В результате каталог перестал зависеть от стандартного Woo infinite scroll. При отключенном JavaScript сохраняется fallback-разметка, поэтому отказ одного frontend-сценария не превращает страницу в пустой экран.

Пересобрали карточку товара

Следующим этапом мы отказались от Elementor single-product template и собрали нативную карточку в теме. Она использует собственную галерею, выбор цвета и размера, AJAX-добавление в корзину, избранное, лист ожидания и блок связанных товаров.

При этом коммерческая логика остается на сервере. Frontend не подменяет проверку вариаций и остатков: перед добавлением WooCommerce подтверждает конкретный товар, размер и доступность. Это особенно важно для магазина с большим количеством вариативных позиций и обменом данными с учетной системой.

Добавили выборочный кеш

Полное кеширование всего WooCommerce-магазина рискованно: карточка товара, корзина, checkout и личный кабинет зависят от сессии и актуального состояния пользователя.

Мы сделали selective full-page cache только для главной и архивов каталога. Мобильная и desktop-версии используют разные ключи. Динамические Woo-сценарии, REST, AJAX, авторизованные пользователи и предпросмотр из кеша исключены.

Так публичные страницы открываются быстро, но кеш не вмешивается в корзину, оформление заказа и персональные данные.

PageSpeed: с 40 до 96

До переработки Google PageSpeed оценивал производительность витрины в 40 баллов. Сохранившийся отчет также показывает 81 балл за специальные возможности, 77 за рекомендации и 92 за поисковую оптимизацию.

После перехода на новый витринный слой контрольный отчет показал 96 баллов производительности. В сохраненном отчете также зафиксированы 79 баллов за специальные возможности, 96 за рекомендации и 92 за поисковую оптимизацию.

PageSpeed зависит от устройства, сети, состояния кеша и момента измерения, поэтому отдельный запуск нельзя трактовать как неизменную скорость для каждого посетителя. Для проекта этот отчет важен как контрольный результат архитектурной переработки: производительность выросла на 56 пунктов относительно исходного значения.

Что изменилось для бизнеса и команды

Проект не ограничился заменой шаблона каталога. У интернет-магазина появился собственный управляемый frontend-контур, который можно развивать без постоянной борьбы с Woo-разметкой и конфликтами вендорных плагинов.

После перехода:

• PageSpeed Performance вырос с 40 до 96 в контрольном замере;
• WordPress и WooCommerce сохранили роль единой административной системы;
• контент-команда продолжила работать с товарами в привычной среде;
• каталог и карточка товара перестали зависеть от Elementor frontend;
• изображения и товарные данные загружаются по мере необходимости;
• поведение галереи, фильтров, сортировки и избранного стало единым;
• мобильные сценарии получили отдельную продуманную логику;
• frontend стало возможно развивать независимо от стандартных Woo-шаблонов;
• перенос на другую CMS и повторная сборка всех интеграций не потребовались.

Почему это не просто «ускорение WordPress»

Проблема зрелого WooCommerce-магазина часто состоит не в самом WordPress, а в том, что публичная витрина годами собирается из шаблонов и плагинов с разными моделями загрузки. В какой-то момент очередная оптимизация изображений или кеш-плагин дают слишком небольшой эффект, потому что архитектура frontend остается прежней.

Headless-подход не обязательно означает полный отказ от WordPress или отдельный сайт на новом домене. В этом проекте мы провели границу внутри существующей системы: сохранили зрелый backend и заменили ту часть, которую непосредственно ощущает покупатель.

Для FLUIDE это оказалось рациональнее полного переезда. Бизнес сохранил товары, заказы, интеграции и привычную админку, а покупатели получили более быстрый и предсказуемый каталог.