В июле 2026 года на Habr появилась статья от команды X5 Tech, которая вызвала бурное обсуждение в профессиональном сообществе. Разработчики из крупной розничной сети поделились опытом миграции внутреннего инструмента для управления продажами. Главный вывод, который они сделали: фронтенд потребовал в три раза больше трудозатрат, чем бэкенд. Это не единичный случай — многие команды сталкиваются с тем, что визуальная часть проекта оказывается «узким горлом». Разберёмся, почему так происходит и какие выводы можно сделать.
Что показало исследование X5 Tech
В материале Источник описывается процесс переписывания системы для планирования ассортимента. Изначально планировалось, что фронтенд займёт около 40% общего времени, но на практике эта доля выросла до 70%. Бэкенд, напротив, был реализован быстрее ожиданий — сказалось использование готовых модулей и типовых решений.
Авторы выделяют несколько причин такого перекоса:
- Сложность пользовательских сценариев. Интерфейс должен был поддерживать десятки фильтров, drag-and-drop, live-обновление данных и работу с большими таблицами. Каждый такой элемент требовал отдельной проработки.
- Необходимость адаптации под разные устройства. Внутренний инструмент используют как с ПК, так и с планшетов, а иногда и со смартфонов. Это добавляет слои медиазапросов и тестирования.
- Интеграция с legacy-системами. Фронтенд должен был корректно отображать данные, которые приходят из старых баз, с нестандартными форматами и задержками.
Факторы, которые систематически замедляют фронтенд
Хотя кейс X5 Tech относится к корпоративной разработке, его выводы универсальны. Вот ключевые причины, по которым фронтенд часто «съедает» больше времени:
1. Интерфейс — это лицо продукта
Любые ошибки в UI сразу видны пользователю. Бэкенд может работать с задержками или выдавать некорректные данные, но если кнопка не нажимается или анимация тормозит — продукт воспринимается как сломанный. Поэтому QA-цикл для фронтенда обычно длиннее: проверяются не только логика, но и визуальные состояния (загрузка, пустой список, ошибка), адаптивность, доступность.
2. Многообразие состояний и краевых случаев
Любой интерфейс — это конечный автомат с множеством состояний. Например, форма заказа может находиться в режиме редактирования, отправки, ошибки валидации, успешного завершения и т.д. Разработчику нужно предусмотреть и отрисовать каждое из них. В бэкенде многие состояния обрабатываются автоматически (например, HTTP-статусы), а фронтендер должен вручную описать каждый сценарий.
3. Зависимость от браузеров и устройств
Кроссбраузерность и адаптация под разные разрешения экранов — это часы дополнительной работы. В отличие от серверного кода, который выполняется в контролируемой среде, фронтенд работает на сотнях комбинаций браузеров и ОС. Даже с современными инструментами (например, Playwright или Cypress) покрыть все варианты сложно.
4. Работа с дизайнерами и заказчиками
Фронтенд — это точка соприкосновения с заказчиком. Часто именно на этапе демонстрации интерфейса возникают новые требования: «сделайте кнопку чуть левее», «добавьте анимацию при наведении», «измените шрифт». Каждое такое изменение — это правка CSS, HTML и часто логики. Бэкенд обычно защищён от подобных «косметических» правок.
Практический пример: таблица с данными
Рассмотрим типовую задачу — отображение таблицы с заказами. На бэкенде это один SQL-запрос с JOIN и пагинацией. На фронтенде:
- Компонент таблицы с сортировкой по столбцам.
- Фильтры (по дате, статусу, сумме).
- Пагинация или бесконечная прокрутка.
- Адаптивное отображение (на мобильных — карточки вместо строк).
- Обработка состояний: загрузка, пустой результат, ошибка сети.
- Анимация появления строк.
Каждый из этих пунктов — отдельная задача, которая может занять от нескольких часов до пары дней. И таких компонентов в большом проекте десятки.
Как сократить время на фронтенд
Команда X5 Tech применила несколько подходов, которые помогли снизить нагрузку:
- Использование UI-кита. Вместо того чтобы писать компоненты с нуля, они взяли готовую библиотеку (например, Material UI или Ant Design) и кастомизировали её под корпоративный стиль. Это сократило время разработки типовых элементов (кнопки, поля ввода, таблицы).
- Создание дизайн-системы. Заранее описанные компоненты с чёткими пропсами и состояниями позволили избежать дублирования кода и упростили ревью.
- Автоматизация тестирования. Вместо ручной проверки всех состояний интерфейса команда написала скрипты на Playwright, которые имитируют действия пользователя.
Заключение
Фронтенд действительно «съедает» больше времени, чем бэкенд, и это не аномалия, а следствие сложности современного UI. Пользователи ожидают мгновенной реакции, красивой анимации и безупречной работы на любом устройстве. Однако грамотное проектирование — использование готовых библиотек, дизайн-систем и автоматизация тестов — позволяет сократить разрыв. Кейс X5 Tech — хорошее напоминание о том, что фронтенд требует не меньше архитектурных усилий, чем серверная часть, и закладывать на него время нужно с запасом.
Комментарии