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

Таблиця, що плавно працює на 50 рядках і стає непридатною на 5000, — це не проблема даних, а проблема рендерингу. Більшість просадок FPS в інтерфейсах з великим обсягом даних викликані одним і тим самим набором помилок, і їх можна виправити без переписування шару даних.

Спочатку віртуалізація — потім усе інше

Якщо ви рендерите кожен рядок у DOM незалежно від того, що видно у вʼюпорті, жодна мемоізація не врятує: ви платите за layout і paint тисяч елементів, які користувач ніколи не побачить одночасно. Віртуалізація списків і таблиць (рендер лише видимих або близьких до вʼюпорту рядків, повторне використання DOM-вузлів під час скролу) — найефективніше рішення, і починати треба саме з нього, а не залишати наостанок.

Дешеві оновлення стану

Після віртуалізації наступне вузьке місце — каскади перерендеру: оновлення однієї комірки тригерить перемальовування всієї таблиці, бо стан живе занадто високо в дереві компонентів. Тримайте стан якомога ближче до місця споживання, мемоізуйте компоненти рядків, щоб зміна в рядку 4000 не перераховувала рядок 12, і свідомо вирішуйте, що саме тригерить реактивність — наївний глибоко-реактивний обʼєкт, що обгортає весь датасет, заважатиме вам на масштабі.

Кешуйте те, що не потрібно перезапитувати

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

Реальний час без ривків

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

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

Висновок

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