О системе
B2C платформа онлайн-бронирования, через которую пользователь может:
- найти туры и отели
- выбрать и настроить поездку
- подобрать перелеты
- оформить и оплатить бронирование
- добавить дополнительные услуги
Система состоит из нескольких связанных подпроектов с общими бизнес-сценариями и единой кодовой базой.
Проблема
Фронтенд платформы развивался неравномерно: одинаковые элементы реализовывались по-разному в разных частях системы, изменения приходилось вносить вручную в нескольких проектах, часть функциональности оставалась на legacy-стеке. Это усложняло поддержку, замедляло развитие и приводило к разному поведению интерфейсов в похожих сценариях.
Наши фронтенд-разработчики подключились к проекту по развитию B2C платформы путешествий. Задача — дорабатывать платформу без перерывов в работе и влияния на продажи.
Решение
Привели интерфейс к единой системе
В разных частях платформы одни и те же элементы (например, шапка, поиск, кнопки, карточки) выглядели и работали по-разному. Это создавало разный пользовательский опыт даже в похожих сценариях.
Интерфейс привели к единой системе: собрали UI-kit и внедрили design tokens — общие правила для цветов, отступов, шрифтов и состояний элементов.
После этого переработали ключевые пользовательские сценарии. Главную страницу собрали заново на базе UI-kit, обновили поисковую строку и карту отелей: добавили фильтры, просмотр карточек и работу с избранным. Типовые элементы верстки в разных разделах привели к единому виду.
Дополнительно внедрили корректную SEO-разметку страниц, что важно для стабильной работы платформы в поиске.
В результате интерфейс стал единообразным, а пользовательский путь — предсказуемым и удобным.
Переход от монолита к модульной архитектуре
Параллельно изменили внутреннюю логику работы фронтенда. Изначально система была реализована как монолит: функциональность была тесно связана, а изменения в одной части могли затрагивать другие.
Фронтенд начали разделять на независимые модули с понятными зонами ответственности. Общие части логики и функциональности вынесли отдельно.
Переход на новый стек без остановки системы
Часть платформы работала на Vue 2. По мере развития системы этот стек стал ограничением: сложнее было внедрять новые функции, поддерживать производительность и использовать современные инструменты.
Полный переход на новый стек был невозможен, потому что платформа уже использовалась клиентами: любое масштабное изменение могло повлиять на работу сайта и процесс бронирования.
Переход выстроили поэтапно: новые части разрабатывались на Vue 3 и Nuxt 3, существующие продолжали работать на Vue 2. Архитектуру фронтенда адаптировали так, чтобы обе версии могли работать вместе.
Повышение производительности
За счет перехода на новый стек и переработки архитектуры удалось ускорить работу платформы:
- время загрузки страниц сократилось в среднем на 20–30%,
- показатели производительности (Lighthouse) выросли на 15–25 пунктов,
- скорость работы поисковой выдачи увеличилась примерно на 20–30%.
Результат
- Конверсия ключевых сценариев выросла на 50% — с 0,2% до 0,3% за счет переработки поиска, корзины и главной страницы.
- Снизилась нагрузка на поддержку: единый UI-kit и общие компоненты позволили отказаться от параллельной доработки одинаковых элементов в разных проектах.
- Ускорили работу платформы: загрузка страниц — быстрее на 20–30%, рост Lighthouse — на 15–25 пунктов, поисковая выдача — быстрее на 20–30%.