Привет, Хабр!

Продолжаю писать статьи на тему хорошего кода и архитектуры.

В этой статье разберу сценарий оптимизации работоспособности систем на примере кабинета Дзена с точки зрения UX.

Введение

Все мы любим статистику и аналитику. Сразу после публикации любого поста, статьи, аудио, видео хочется сходить в нужный раздел frontend'а и посмотреть - закрутилось или не закрутилось, есть ли показы, просмотры, лайки, комментарии. Или всё сломано.

Как правило, мы рассматриваем данный функционал, как черный ящик по схеме - "мы авторизовались, кликнули на нужный раздел/кнопку/вкладку/ссылку, они нам показали данные".

Архитектурная схема упрощенно выглядит так:

• Пользователь заходит на фронт через браузер/мобильное приложение

• Авторизуется, если не авторизован. Модули Gateway и Auth

• Запрашивает данные у сервиса Analytics. Как правило, это REST-запросы

• Выбираются данные из БД. Могут присутствовать и другие сервисы, запросы, базы. Как было задумано по архитектуре

• Данные через ответ доходят обратно до фронта. Обрабатываются и рисуется представление в виде верстки соответствующего дизайна.

И мы получаем по адресу https://habr.com/ru/statistics/<id статьи>/funnels/ что-то типа этой картинки

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

Предварительные рассуждения

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

• Пишем в базу всё без разбора

• Смешиваем агрегированные и детальные данные

• Сделаем прототип, а потом будем разбираться

• Сначала функционал, а потом интерфейсы

• Срочно нужна аналитика

За этими паттернами стоит хаотичное применение информации из прошлых проектов, копипаста, скорость разработки (или лень), неверные советы и прочее.

Давайте глубже посмотрим на тему аналитических модулей, таблиц и дашбордов с другой стороны.

Тезис:

В большинстве случаев аналитика и статистика не нужны.

Вернее, не в таких количествах, не такая детальные. И потребности в них преувеличены.

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

Это происходит в течение некоторого не слишком большого интервала времени - 5-15 минут из-за переливки данных и разбора очереди, конечно, если ничего не лагает. Но если начинаются проблемы, как недавние 14 - 15 января 2026, то рука тянется посмотреть в кабинете на цифры, вдруг что-то сломалось или статья не зашла.

А это действительно так.

Наблюдаемый результат: всё как в жизни, ожидаемое поведение систем нас успокаивает, что-то пошло не так - начинаем лезть и разбираться. Таким образом, детализация данных в принципе не особо требуется, лайки и просмотры есть - значит всё стабильно, иначе начинаются раскопки.

На аналогичных рассуждениях можно неплохо сэкономить - уменьшить общее количество Request Per Seconds и оптимизировать расходы на время ответа сервера, да и ресурсы немного освободить.

Кейс Дзена

На платформе есть кабинет. Любой гостевой пользователь может принять решение зарегистрироваться, авторизоваться и сразу начать создавать контент. Например, статьи.

После авторизации нам будет доступна Студия.

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

Чтобы перейти в общий - нужно сделать 2 дополнительных клика: в выпадающий список

И получить:

Казалось бы - ну обычный сервис, функционал доступен, работает. Что может быть с ним не так? Давайте посмотрим детальнее. Будем использовать просто скрины и Инструменты разработчика в Хроме.

Лишний клик = много ненужных запросов на сервер

Смотрим в Network. Вот некоторые из ответов с бэкенда

Далее - чтобы переключиться на целевой аккаунт - мне нужно кликнуть 2 раза: на выпадающий список и на искомый элемент, как я показывал ранее.

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

Здесь время ответа сервера на запросы уже побольше. ~250 ms против ~400 ms.

В итоге получаем из-за простой не слишком удачной реализации:

• Неудобство пользователя в виде дополнительного клика

• Лишние бесполезные запросы на сервер со всеми вытекающими

Как можно поправить: вынести выпадающий список изнутри кабинета в

Мне нравится, как реализовано на YouTube - список аккаунтов ДО захода в Студию.

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

Выводы

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

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

Есть эмпирическое правило 0-1-10 - после загрузки элемента страницы более 1 секунды пользователь начинает нервничать

Также есть правило - меньше лишних кликов - больше отзывчивость. Но разумная.

По данным на 10 января 2025 года, в 2024 году на платформе «Дзен» появилось 1 млн новых авторов. Источник - Алиса

10^6 авторов - нормальная величина. И она растет.

Даже если небольшая часть использует несколько аккаунтов, например, 1% - то это 10 000 лишних кликов. А запросов в несколько раз больше.

Многие скажут - а смысл? И так всё нормально работает без сбоев.

Отчасти с этим соглашусь.

При разработке всегда нужен компромисс между:

• Скоростью разработки и деплоя фич

• Оценкой стоимости затрат на "железо"

• Производительностью.

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

Лучше всегда застраховаться заранее даже в таких маленьких вещах.

Данную статью сознательно решил не перегружать кодом, подсчетами и подробностями.

Около IT сферы всегда существует огромное количество баек, люди рассуждают о высоких материях, таких как Big Data, ИИ, миллионы и миллиарды просмотров.

А с прошлого века ИТ не особо изменилось - отношение к маленьким деталям, реально влияющим на оптимизацию систем осталось таким же.

Доступно - не значит дешево.