Интерфейсы с высокой плотностью данных: как рендерить тысячи строк без просадки FPS

Таблица, которая плавно работает на 50 строках и становится неюзабельной на 5000, — это не проблема данных, а проблема рендеринга. Большинство просадок FPS в интерфейсах с большим объёмом данных вызваны одним и тем же набором ошибок, и их можно исправить без переписывания слоя данных.

Сначала виртуализация — потом всё остальное

Если вы рендерите каждую строку в DOM независимо от того, что видно во вьюпорте, никакая мемоизация не спасёт: вы платите за layout и paint тысяч элементов, которые пользователь никогда не увидит одновременно. Виртуализация списков и таблиц (рендер только видимых или близких к вьюпорту строк, переиспользование DOM-узлов при скролле) — самое эффективное решение, и начинать нужно именно с него, а не оставлять напоследок.

Дешёвые обновления состояния

После виртуализации следующее узкое место — каскады перерендера: обновление одной ячейки триггерит перерисовку всей таблицы, потому что состояние живёт слишком высоко в дереве компонентов. Держите состояние как можно ближе к месту потребления, мемоизируйте компоненты строк, чтобы изменение в строке 4000 не пересчитывало строку 12, и осознанно решайте, что именно триггерит реактивность — наивный глубоко-реактивный объект, оборачивающий весь датасет, будет мешать вам на масштабе.

Кэшируйте то, что не нужно перезапрашивать

Дашборды реального времени склонны перезапрашивать данные "на всякий случай". Нормализуйте входящие данные так, чтобы обновления патчили существующие записи, а не заменяли весь датасет, и используйте паттерн stale-while-revalidate там, где не нужна посекундная свежесть. Дашборд, перерисовывающий всю таблицу на каждый тик WebSocket, начнёт терять кадры задолго до того, как узким местом станет сам объём данных.

Реальное время без рывков

Высокочастотные обновления (тикеры цен, живые метрики, стриминг логов) нужно батчить, а не применять по одному по мере поступления:

• Буферизируйте входящие обновления и сбрасывайте их на следующем animation frame, а не сразу при получении
• Дебаунсите или троттлите обновления для ячеек, на которые пользователь сейчас не смотрит
• Выносите действительно тяжёлые вычисления (сортировку, фильтрацию, агрегацию на больших датасетах) с основного потока в web worker

Вывод

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