Как мы помогли переработать сайт федеральному гипермаркету матрасов

2026-04-17 15:36:05 Время чтения 6 мин 180

Со временем даже сильные продуктовые команды сталкиваются с перегрузкой: задачи копятся, релизы замедляются, а архитектура перестает выдерживать рост проекта. В такой ситуации любое серьезное обновление превращается в риск — остановка сайта даже на короткое время напрямую влияет на выручку.

В какой-то момент команда Матрас.ру оказалась именно в такой ситуации. При растущей нагрузке сайт начал тормозить развитие бизнеса: новые функции внедрялись медленно, а часть идей вообще невозможно было реализовать.

При этом «переписать все» — означало бы на время заморозить продукт. Для e-commerce это прямые потери.

Лишь неполный список производителей матрасов, которые представлены на сайте-агрегаторе

Что было на старте

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

К моменту подключения нашей команды сайт существовал более 10 лет. За это время накопились следующие проблемы:

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

Внутренняя разработка уже не справлялась с объемом задач — проект решили передать на аутсорс.

Почему сайт работал медленно

Аудит показал, что проблема не в отдельных участках, а в самой структуре системы.

Фактически сайт был собран из нескольких независимых частей:

одна отвечала за часть интерфейса;
другая — за серверный рендеринг;
третья — за генерацию страниц на стороне backend.

Это означало, что любое изменение приходилось дублировать в нескольких местах. Даже простые задачи превращались в цепочку правок и деплоев.

Дополнительно страдала инфраструктура:

база данных разрослась до десятков гигабайт;
данные дублировались;
для поддержания скорости приходилось использовать дорогие серверы.

Первый этап: не переписывать, а стабилизировать

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

За несколько месяцев:

автоматизировали отправку платежных ссылок и внедрили оплату частями;
настроили обмен данными с 1С без ручного участия;
перенесли видеоконтент с YouTube на VK Видео из-за нестабильности первого.

Эти изменения снизили нагрузку на процессы, но не решили фундаментальных проблем архитектуры.

Когда стало ясно: без переписывания не обойтись

Критической точкой стал запрос на развитие SEO-раздела со статьями. Выяснилось, что из-за особенностей URL и логики рендеринга внедрить нужные изменения практически невозможно.

Это был сигнал: дальнейшие доработки в текущей системе будут только усложнять ситуацию.

Мы предложили перейти к полной переработке:

объединить фронтенд в единое SSR-приложение на Nuxt.js;
привести backend к единому стеку на Go;
отказаться от разрозненной логики и выстроить единую архитектуру.

Как не остановить продукт: два контура разработки

Главное ограничение со стороны бизнеса — сайт должен продолжать работать и развиваться.

Поэтому мы выстроили параллельный процесс:

текущая версия продолжала поддерживаться;
новая система разрабатывалась отдельно;
ключевой функционал дублировался в обеих версиях.

Такой подход позволил не замораживать развитие и одновременно готовить новую архитектуру.

За следующие шесть месяцев в таком режиме работы удалось внедрить сразу несколько нововведений:

автоматизировали загрузку данных с собственных производств;
внедрили систему отзывов с рейтингами и пользовательским контентом;
добавили удобную работу с поставщиками через админ-панель;
переработали фильтрацию каталога;
автоматизировали расчет скидок и акций.

Эти изменения напрямую повлияли на удобство пользователей и внутренние процессы.

Запуск новой версии

Релиз планировали как поэтапный, чтобы пользователи не заметили перехода. В целом это удалось, но не обошлось без технических сложностей:

отсутствие отдельного QA-специалиста (заказчик решил не привлекать отдельного специалиста, чтобы уложиться в общий бюджет проекта) привело к багам после запуска;
сторонний сервис защиты от ботов вызвал конфликт с сайтом;
временно возникли проблемы с отображением страниц и индексацией.

Все критичные моменты были нами оперативно устранены.