Аудит рендеринга React для дашбордов с живыми виджетами

Почему живые дашборды начинают тормозить

Живые дашборды ощущаются лёгкими, пока вы просто набрасываете их на бумаге. Добавьте 12 виджетов, автообновление, несколько графиков — и страница начинает бороться с ноутбуком. Проблема редко бывает в одной большой ошибке. Чаще это десятки мелких обновлений, которые приходят одновременно.

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

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

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

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

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

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

Что измерить сначала

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

Запишите короткую сессию в React DevTools Profiler во время обычной работы. Тридцати–шестидесяти секунд достаточно. Поменяйте фильтр, откройте панель, наведите курсор на график и дайте виджетам обновиться несколько раз. Так вы получите трассировку с тем же шумом и пересечениями, которые видят реальные пользователи.

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

Отмечайте четыре вещи:

• какие виджеты перерендериваются при каждом обновлении данных
• время commit у самых медленных взаимодействий
• всплески CPU во время стабильного live-обновления
• рост памяти спустя несколько минут на странице

Commit time показывает, сколько времени React тратит на вывод обновлений на экран. Нагрузка на CPU показывает, не слишком ли тяжело браузеру между обновлениями. Рост памяти часто указывает на графики, обработчики событий или кэш запросов, которые так и не успокаиваются.

Держите рядом с React DevTools диспетчер задач браузера или панель производительности. React сам по себе может выглядеть нормально, а страница при этом всё равно сжигает CPU на коде графиков, работе с layout или тяжёлой обработке данных. Нужны оба взгляда, потому что пользователи чувствуют всю страницу, а не только React.

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

Разберите страницу по шагам

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

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

Если да — проблема в локальном рендеринге. Если страница становится плавной — live-обновления проталкивают слишком много работы через дерево компонентов.

Практический порядок действий выглядит так:

1. Откройте медленный маршрут и попробуйте обычные действия: введите текст в поле поиска, измените диапазон дат, прокрутите виджеты.
2. Отключите live-данные и повторите те же действия. Запишите, что стало лучше, а что осталось плохим.
3. Подключайте по одному источнику данных и проверяйте снова после каждого изменения.
4. Останавливайтесь, как только задержка вернётся. Обычно это указывает на один виджет, один запрос или одно общее обновление состояния.

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

Когда найдёте проблемную область, проследите, что меняется при каждом рендере. Ищите props, которые пересоздаются каждый раз: новые массивы, object literals или inline callback-функции. Проверьте и состояние ближе к верху страницы. Один тикающий timestamp в родительском компоненте может заставить перерендериться половину дашборда.

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

Хорошие аудиты остаются узкими. Меняйте по одной вещи, проверяйте результат и ведите заметки. Так вы находите настоящий узкий участок, а не гоняетесь за десятью мелкими.

Используйте memo там, где это убирает реальную работу

Memo даёт пользу только тогда, когда повторный рендер действительно повторяет полезную работу. Если родительский компонент обновляется каждую секунду, а виджет в 90 процентах случаев получает одни и те же props, React.memo может не дать этому виджету делать одну и ту же работу снова и снова.

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

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

useMemo работает так же. Используйте его для производных значений, которые стоят времени или создают новые ссылки и ломают memoization. Типичные примеры — отсортированные строки таблицы, массивы точек для графика и объекты настроек, собранные из live-данных. Если вычисление почти ничего не стоит, пропустите его.

Один удобный паттерн — разделить тяжёлый контейнер и простой view-компонент. Контейнер получает данные, преобразует поля API и решает, когда обновляться. View-компонент принимает обычные props вроде title, value и series. Такой компонент намного проще обернуть в React.memo, тестировать и держать стабильным.

Короткое правило для аудита рендеринга React:

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

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

Пакетуйте запросы и уменьшайте payload

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

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

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

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

• Используйте один polling hook для похожих карточек
• Храните общие результаты в одной записи кэша
• Пусть каждый виджет читает только нужный ему срез
• Обновляйте группы с разной скоростью, если данные меняются с разной частотой

Размер payload важен не меньше, чем количество запросов. Многие дашборды запрашивают полные записи, когда им нужны только сумма, подпись и timestamp. Если графику нужны последние 30 точек, не запрашивайте 5 000 строк, чтобы потом обрезать их в браузере. Попросите API вернуть 30 строк. Если таблице нужны три столбца, запросите только эти три столбца.

Общий кэш тоже сокращает лишнюю работу. Если двум виджетам нужны одни и те же исходные данные, получите их один раз и дайте обоим читать один и тот же кэшированный результат. React Query, SWR или небольшой собственный store справятся с этим хорошо. Смысл простой: один ответ, много потребителей.

Вынесите повторяющиеся преобразования и из render тоже. Сортировка, группировка, объединение series и форматирование дат могут занимать время, если повторяются на каждом рендере. Делайте эту работу при получении данных или в memoized selector, привязанном к результату запроса.

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

Замедляйте обновления графиков намеренно

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

Начните с того, чтобы задать каждому виджету свой темп обновления. Итоги, бейджи и простые статус-карточки могут обновляться каждую секунду. Тяжёлые графики лучше обновлять реже — например, раз в 3–10 секунд, в зависимости от того, сколько данных они рисуют.

Одно это разделение уже сильно снижает нагрузку. Числовая карточка перерисовывается быстро. График часто пересчитывает шкалы, подсказки, оси и большой SVG- или canvas-слой.

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

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

Простое правило работает хорошо:

• часто обновляйте сводные числа
• обновляйте графики пакетами
• останавливайте работу графиков, когда вкладка скрыта
• останавливайте работу графиков для карточек вне viewport
• отключайте анимации для live-обновлений

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

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

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

Простой пример дашборда

Представьте dashboard продаж с 18 live-виджетами на одной странице: выручка, заказы, возвраты, активные пользователи, таблица последних сделок и несколько графиков. Каждая карточка опрашивает свой endpoint каждые пять секунд. Это звучит скромно, но браузер делает больше, чем просто получает данные. Каждый опрос создаёт новые объекты, запускает обновления состояния и заставляет React снова проверять большое количество интерфейса.

Проблема усугубляется общим объектом фильтра. Страница пересоздаёт этот объект на каждом тике, даже когда выбранные регион, диапазон дат и sales rep остаются прежними. Поскольку identity объекта меняется, многие дочерние компоненты выглядят для React новыми. Даже карточки, обёрнутые в React memo, всё равно перерендериваются, если их props постоянно меняются по ссылке. Через минуту ввод в поле поиска начинает казаться липким. Вы нажимаете несколько клавиш, а потом ждёте, пока ввод догонит вас.

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

Исправление довольно простое:

• Замените 18 polling-таймеров одним пакетным запросом для виджетов, которые видны на экране.
• Мемоизируйте общий объект фильтра, чтобы он менялся только тогда, когда пользователь меняет фильтр.
• Дайте маленьким числовым карточкам обновляться часто, а обновления графиков замедлите до 15 или 30 секунд.

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

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

Ошибки, из-за которых страница остаётся медленной

Аудит рендеринга React обычно вскрывает одни и те же вредные привычки. Самая распространённая — оборачивать половину дерева в React.memo, не исправив props, которые меняются при каждом рендере. Memo пропускает работу только тогда, когда child получает те же значения по ссылке. Если parent продолжает создавать свежие массивы, объекты и callbacks, child всё равно рендерится, а код ещё и становится труднее читать.

На дашбордах с live-виджетами это особенно часто. Родительский компонент пересобирает параметры графика, объекты фильтров, столбцы таблицы и производные массивы каждые несколько секунд. Данные могут быть теми же, но ссылки уже новые. React видит изменение и проталкивает больше работы через страницу, чем вы ожидали.

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

Скрытый интерфейс даёт ещё один медленный расход. Команды часто держат вкладки, боковые панели и detail views смонтированными, потому что так удобнее. Проблема в том, что скрытые части по-прежнему подписываются, сортируют, рендерятся и обновляются, если вы их не остановите. Если пользователь открывает одну панель раз в несколько минут, нет хорошей причины заставлять её постоянно выполнять live-работу.

Графики часто оказываются самой тяжёлой частью экрана, и многие команды полностью перерисовывают график из-за мелких изменений данных. Это дорого. Один новый пункт не должен заставлять заново собирать все series, оси, подсказки и легенду. На обычном ноутбуке два-три загруженных графика с полными перерисовками могут сделать ввод в поле фильтра заметно медленным.

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

Если экран остаётся занятым, даже когда никто ничего не нажимает, одна из этих ошибок, скорее всего, всё ещё есть в коде.

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

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

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

Короткая проверка перед релизом ловит большинство типичных проблем:

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

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

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

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

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

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

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

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

Можно оставить всё практичным:

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

Будьте строгими к области работ. Если одна таблица перерисовывается 40 раз после изменения фильтра, исправьте это прежде, чем трогать более мелкие проблемы. Если один запрос отправляет 2 000 строк, хотя карточке нужно 20, уменьшите payload до того, как добавите ещё больше memo-вызовов. Если одна библиотека графиков полностью перерисовывает canvas на каждом тике, сначала замедлите частоту обновлений, а уже потом меняйте библиотеку.

Если хотите получить вторую пару глаз, внешний разбор может сильно сократить количество проб и ошибок. Oleg Sotnikov делает именно такую работу как fractional CTO, проводя практические аудиты рендеринга React, потока данных и инфраструктуры, которая стоит за live-продуктами. Это особенно важно, когда проблема страницы не ограничивается деревом компонентов, а затрагивает polling, размер payload, caching или то, как backend отправляет обновления.

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