13 KiB
Локальная проверка производительности UX/UI
Состояние на2026-10-04; этап12.3 продолжается. Эти измерения относятся к Playwright/Edge/Next dev без CPU throttling и реальной сети. readyMs — wall clock от page.goto до готовой строки, включая компиляцию/подставной API; разные прогоны имеют разную прогретость. Это не production SLA и не p95. Fixtures проверяют UI на реальном формате DTO, но не ёмкость PostgreSQL/RouterOS.
| Сценарий | Размер fixture | Строк в DOM до → после | DOM nodes до → после | Наблюдаемый dev ready до → после |
|---|---|---|---|---|
| Серверы | 1000 ServerRead,501462 JSON bytes | 1000 →50 | 41569 →2644 | 3345 →1058/1543ms |
| Статистика/CompactDataGrid | 1000 users,88894 JSON bytes массива | 1000 →50 | 12585 →1210 | 5195 →2928/1195ms |
| BGP | 1000 полных сессий | 1000 →50 | 25657 →1932 | 2990 →898ms |
| Speed-пробы | 1000 probes/1001 devices | 1000 →50 | 23590 →11265 (секция739) | 3741 →2310ms |
| Ресурсы uptime | 1000 resources/CPU10% | 1000 →50 | 38655 →2580 | 4328 →1578ms |
| Очередь проблем | 1000 offline servers | 5 начальных,55 после раскрытия,105 после кнопки | 831 начальный dashboard | 1081ms; baseline до не замерялся |
Профили: large-servers.spec.ts, large-statistics.spec.ts, large-bgp.spec.ts, dashboard-data.spec.ts. Измерения приложены к Playwright test results как JSON. Полные массивы всё ещё загружаются/валидируются/фильтруются на клиенте. Pagination ограничивает строки DOM, но не число pivot колонок; широкая pivot требует отдельной проверки. Порционное раскрытие очереди допускает постепенный полный список по запросу пользователя.
Оставшиеся специализированные grids
Ниже точный поиск manualPagination:true, а не заключение о дефекте: часть экранов может уже ограничивать данные API. Перед сменой режима нужно проверить читателя, общий recordCount, порядок/drag и выбор из URL. Требуемые сценарии:1000 строк, последняя страница, поиск/сортировка всего среза, обновление на второй странице, уменьшение набора, детали/URL/права,320px. Firewall нельзя слепо разбивать с потерей порядка правил; traffic требует согласовать page/limit с backend.
| Файл | Следующая проверка |
|---|---|
| backups-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| certificates-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| communities-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| data-collection-scheduler-data-grid.tsx | UI строится из11 SCHEDULER_JOB_KEYS; fixture1000 не соответствует источнику |
| filters-data-grid.tsx | Порядок/drag и операции до ограничения DOM |
| firewall-rules-data-grid.tsx | Порядок/drag и операции до ограничения DOM |
| firewall-scenario-rules-data-grid.tsx | Порядок/drag и операции до ограничения DOM |
| gre-pools-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| gre-tunnels-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| ospf-bfd-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| ospf-neighbors-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| ospf-routes-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| probes-schedule-data-grid.tsx | Только demo ScheduleTab/INIT_RULES3; live использует ProbesSpeedProbesDataGrid, проверить его consumer1000 |
| recursive-routes-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| route-optimizer-comm-recs-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| route-optimizer-full-routes-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| route-optimizer-ospf-preview-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| route-optimizer-wan-matrix-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| subusers-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| traffic-flows-data-grid.tsx | FlowAnalyticsPanel получает conversationsList с backend cap50; API page/limit здесь нет |
| users-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| vxlan-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| wireguard-data-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
| wireguard-peers-grid.tsx | Потребитель API, контекст/детали и fixture1000 |
Осталось24 специализированных grids; ни один из оставшегося перечня не принят этим документом на больших данных. CompactDataGrid дополнительно проверен на повторном получении100 active probes: страница сохраняется; сокращение100→1 ограничивает индекс. Speed probes и uptime resources приняты в блоках12.3.7–12.3.9 и исключены из оставшегося перечня. Следующие большие профили: probes-schedule, затем сетевые/admin grids с учётом границ API. Общий журнал: ux-ui-progress.md.
12.3.6:1000 speed probes baseline —1000 rendered rows/23590 DOM nodes/3741ms dev ready; профиль collector-probes4 cases и ESLint прошли. Далее12.3.7 ограничение DOM speed grid; этот baseline не означает принятую производительность.
12.3.7: speed grid принят на1000 строках в описанных локальных границах.50 строк/739 nodes секции; вся страница11265 nodes из-за полного каталога устройств. ServerTileRail требует отдельного ограничения DOM с проверкой поиска, выбора и клавиатуры. Следующий блок12.3.8 — uptime resources.
12.3.8: ресурсы приняты на1000 CPU10% строках; глобальный поиск/URL/сортировка/страница20/refresh/1000→1/320px. Большой список1000 предупреждений ресурсов требует отдельной проверки12.3.9.
12.3.9:1000 предупреждений CPU90% — warning nodes2009→21, страница4739→2751 при закрытом списке.5→55→105→5→55 карточек по явному раскрытию; полный счётчик сохранён.9 browser и tagged axe прошли. Полное постепенное раскрытие допускает весь список, это не виртуализация.
12.3.11: ServerTileRail1001 устройств —50 options на странице (All отдельный aggregate), mobile Sheet тоже50. Speed probes + каталог:11265→1778 DOM nodes,739 nodes speed секции/50 строк. Поиск/URL/граница площадок/клавиатура/refresh/320px/axe обе темы проверены;47 browser и production build прошли. Полные DTO остаются в памяти.
Уточнение ограниченных источников перед общей регрессией
Статический аудит исходников на c4110fa: schedulerGridRows строится из SCHEDULER_JOB_KEYS (11), поэтому отсутствие client pagination не означает1000 строк. TrafficFlowsDataGrid получает analytics.conversationsList, а buildFlowAnalyticsUncached задаёт top=min(50,max(10,settings.topN)) и slice(0,top); page/limit в этом пути нет. Старый /traffic/flows listFlowTalkers — другой источник с settings.topN, его нельзя смешивать с текущей таблицей analytics. Uptime speed history GET /uptime/speed-test/runs использует DB limit200; frontend локальный run список ограничен20. Эти ограничения установлены чтением кода, не нагрузочным испытанием PG. Остальные строки карты требуют проверки по своим потребителям;После history-профиля осталось24 manualPagination:true файла; они не означают24 одинаковых дефекта.
Statistics pivot в backend/src/services/statistics-aggregate.ts ограничен PIVOT_ROW_CAP=50 и PIVOT_COL_CAP=15; при превышении добавляются агрегаты other. Проверять фактическую границу51×16, прокрутку и переходы к срезам, а не произвольную матрицу1000×1000. Это статический аудит источника; browser evidence широкой pivot ещё требуется.
12.3.13: pivot51×16/17311 JSON bytes принята в описанных локальных границах.50 rows/2574 nodes desktop и2313 mobile; крайние колонки доступны через штатный DataGridScrollArea, агрегаты Other без ложных действий. Sort/page2/два измерения/Back/reload/320px/axe проверены. Фактический cap backend исключает потребность в произвольной матрице1000×1000; реальная скорость PG не измерялась.
12.3.14: history200/73075 JSON bytes —200→50 rows,7583→2361 DOM nodes; final dev ready1271ms. Global TX sort/page4/refresh page2/200→1/320px/ScrollArea/axe проверены. Это DOM приёмка, не принятие legacy null→0 rates и общей очистки двух GET при ошибке reloadSpeedData.
12.3.15: live расписание на1000 rows дополнительно проверено при503 на page20, freshness/cache/recovery1/no POST;50 rows/739 section nodes/1778 page nodes. Demo ProbesScheduleDataGrid не использует API и начинается с3 INIT_RULES; исключать его из live migration, но не считать произвольный большой demo-list проверенным.