Серверные компоненты Next.js для внутренних дашбордов, которые остаются быстрыми

Почему внутренние дашборды со временем становится сложно поддерживать

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

Со временем страница становится и более интерактивной. Команды добавляют поиск, сортировку, диапазоны дат, меню в строках, массовые действия, редактирование прямо в таблице, кнопки согласования и экспорт. Каждое такое улучшение по отдельности выглядит разумно. Но если собрать всё на одной странице, экран превращается в перегруженную панель управления с множеством движущихся частей.

Распространённая ошибка — загружать большую часть этих данных прямо в браузере. Тогда по всей странице расползаются индикаторы загрузки, кнопки повтора, пустые состояния и сообщения об ошибках. Один запрос завершается быстро, другой тянется пять секунд, а третий падает только у части пользователей. В итоге всё ощущается неровно. Люди кликают по экрану, который ещё не готов, а разработчики ищут баги, которые появляются только при одновременной работе нескольких запросов.

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

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

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

Что на самом деле решают серверные компоненты

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

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

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

Хорошее разделение делает код и понятнее. То, что получает и формирует данные, может жить на сервере. То, что реагирует на клики, ввод текста или перетаскивание, может остаться на клиенте. Когда одно дерево компонентов пытается делать и то и другое, за ним труднее следить и его труднее менять.

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

В этом и есть настоящая польза. Серверные компоненты не делают любой дашборд проще, но они убирают из браузера работу, которая не даёт пользы. На экранах с большим объёмом данных эта разница обычно очень заметна.

Где они лучше всего подходят в дашборде

Серверные компоненты лучше всего работают на экранах, где человек сначала читает, сравнивает и принимает решения, а уже потом что-то нажимает. Если страница больше похожа на отчёт, чем на приложение, большую часть её стоит строить на сервере.

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

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

Обычно хороший кандидат выглядит так:

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

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

То же касается очередей согласования. Руководителю могут понадобиться на одном экране ожидающие заявки, сведения о сотруднике, правила политики и статус бюджета. В первую секунду эта страница не слишком интерактивна. Её задача — быстро показать нужный контекст, а потом дать пользователю согласовать или отклонить.

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

Что должно остаться на клиенте

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

Формы — самый понятный пример. Пользователь может изменить десять полей, сделать паузу, сравнить значения, исправить опечатку и сохранить всё в конце. Для такого сценария нужны локальное состояние, черновики, валидация прямо в интерфейсе и быстрая визуальная обратная связь. Если каждый ввод зависит от обращения к серверу, задержка ощущается сразу.

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

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

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

Модальные окна и уведомления работают по тому же принципу. Когда человек нажимает «Архивировать», экран должен отреагировать сразу. Модальное окно подтверждения нужно открыть немедленно. А после успешного действия сразу показать уведомление. Сервер по-прежнему может обрабатывать изменение, но ощущение контроля должно оставаться в браузере.

Клиентские компоненты в Next.js также хорошо подходят для рабочих процессов, где пользователь сначала собирает много изменений, а потом сохраняет их одним действием. Например, на ценовом дашборде менеджер меняет маржу сразу в нескольких строках, проверяет результат и только потом отправляет всё разом. Такой экран требует локальных расчётов, состояния изменённых полей, удобного поведения с отменой и понятных кнопок сохранения или отмены.

Разделение не обязано быть жёстким. Хороший дашборд часто загружает данные с помощью серверных компонентов, а затем передаёт интерактивную часть небольшому клиентскому обёрточному компоненту. Оставляйте тяжёлую работу с данными на сервере, а быстрые действия — на клиенте.

Как разделить один экран шаг за шагом

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

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

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

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

Хорошее разделение специально выглядит скучно. Страница получает данные на сервере, там же рендерит блоки только для чтения и передаёт простые props небольшим интерактивным частям.

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

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

Реалистичный пример

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

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

Середина страницы может работать так же. Первый список тикетов приходит уже отрендеренным — с темой, приоритетом, исполнителем и временем последней активности. Если у команды 2 000 открытых тикетов, браузер всё равно получает более лёгкую страницу, потому что получает HTML для видимой части, а не большой клиентский апп, которому ещё нужно всё загрузить и собрать после открытия.

А потом вступают интерактивные части. Фильтры по статусу, владельцу и диапазону дат лучше оставить на клиенте, потому что сотрудники будут часто их менять. Массовый выбор тоже должен быть там. Люди хотят отметить 15 тикетов, снять выделение, потом выбрать ещё 8 — и всё это без задержек.

Редактор заметок тоже должен остаться на клиенте. Ввод текста, автосохранение, предупреждения о несохранённых изменениях и небольшие сообщения о валидации лучше ощущаются, когда браузер обрабатывает их напрямую. Если агент открывает тикет и пишет: «Клиент подтвердил исправление, закрыть после подтверждения биллинга», действие должно казаться мгновенным.

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

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

Ошибки, которые создают проблемы

Команды часто винят серверные компоненты, хотя настоящая проблема — в том, как они разделили экран. Подход отлично работает для внутренних дашбордов, но у каждой части должна быть одна ясная задача.

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

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

Ещё одна проблема возникает на границе между сервером и клиентом. Сервер загружает огромный объект, а затем передаёт его в клиентский компонент просто потому, что так кажется проще, чем сформировать данные. Это добавляет лишнюю передачу, лишний разбор и лишнюю путаницу. Если таблице нужны шесть колонок и два флага, отправляйте шесть колонок и два флага.

Серверный рендер не спасает и плохой запрос. Если базе нужно четыре секунды, чтобы собрать отчёт, server component лишь спрячeт задержку за экраном загрузки. Медленная часть всё равно остаётся медленной. Нужно чинить запрос, добавлять правильный индекс, кэшировать результат или предварительно считать отчёт до того, как пользователь откроет страницу.

Много грязного кода в дашбордах начинается в одном слишком большом файле. Логика загрузки, layout, состояние формы и код изменения данных оказываются перемешаны. Потом небольшое изменение, например добавление одного массового действия, превращается в рискованную правку, потому что всё связано со всем остальным.

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

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

Если страница кажется медленной или её трудно менять, сначала проверьте, что именно проходит через границу. Чаще всего лишнее начинается именно там.

Быстрые проверки перед релизом

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

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

Откройте страницу и задайте один простой вопрос: показывает ли она что-то полезное до первого клика? Сводка, оболочка таблицы с реальными строками или понятный статус — этого уже достаточно. Пустой экран, который ждёт действия, обычно означает, что разделение выбрано неправильно.

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

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

Прочитайте пустые и ошибочные состояния вслух. «Ни один счёт не подходит под этот фильтр» — понятно. «Что-то пошло не так» — нет. Людям важно знать, что произошло, что ещё работает и что делать дальше.

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

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

Что делать дальше

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

Потом просмотрите страницу блок за блоком. Таблица только для чтения, панель итогов или журнал аудита обычно относятся к серверу. Фильтры с мгновенной реакцией, редактирование прямо в строке, drag and drop и несохранённое состояние формы обычно относятся к клиенту. Такое простое разделение часто помогает быстрее, чем ещё один созвон по планированию.

Полезна и практическая последовательность:

• пометьте каждую область как серверную или клиентскую
• измерьте объём JavaScript в браузере до любых изменений
• сначала исправьте один медленный запрос, а уже потом рефакторите страницу
• перестраивайте сначала только самый медленный участок

Третий шаг экономит много лишней работы. Если один отчёт выполняет плохой запрос, перенос его в серверные компоненты не сделает данные быстрее. Пользователь может скачать меньше JavaScript, но всё равно будет ждать тот же медленный запрос к базе. Сначала почините запрос, уменьшите payload или добавьте недостающий индекс.

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

Запишите, что изменилось после первого экрана. Страница стала загружаться быстрее? Код стало проще читать? Команда тратит меньше времени на поиски багов состояния? Эти заметки облегчат следующий выбор.

Если команде нужно второе мнение, Oleg Sotnikov на oleg.is помогает с архитектурой продукта и настройкой Fractional CTO для стартапов и небольших компаний. Он может помочь выбрать практичное разделение в Next.js, не превращая разумный рефакторинг в полное переписывание.