benchmark: optimize dashboard bundle and collapsed chart-data DOM

[TheHiddenObserver]

Context

PR #76 is merged and post-merge green on master commit 553f6b722a03b6d6870f8e2fe29b50bc11d38bfa. The release gates established correctness, provenance, production-path behavior, cross-browser coverage, and accessibility, but did not include an independent performance/polish pass.

A measurement-first audit on GitHub ubuntu-latest with headless Chromium against the exact committed deployment under /docs/assets/benchmarks/ produced the following five-run baseline:

cold dashboard ready: median 381 ms, p95 463 ms
Full matrix toggle: median 195 ms, p95 226 ms
return to Focused: median 160 ms, p95 173 ms
complete CV cascade (multiple UI actions): median 548 ms

Payload baseline:

JS:               1,088,385 B raw / 358,159 B gzip-9
CSS:                  9,933 B raw /   2,786 B gzip-9
benchmark_data:    2,841,303 B raw /  83,333 B gzip-9
parse_report:          5,570 B raw /     480 B gzip-9
source_inventory:     65,271 B raw /   3,305 B gzip-9
TOTAL:             4,010,462 B raw / 448,063 B gzip-9

DOM/runtime baseline:

Focused default:
  DOM nodes: 6,934
  hidden/collapsed chart-table rows: 189 timing + 315 speedup
  overview rows: 200
  JS heap used: ~9.6–11.0 MB

Full matrix:
  DOM nodes: 17,608
  collapsed chart-table rows: 438 timing + 1,252 speedup
  timing chart groups: 146
  speedup chart rows: 1,252
  JS heap used: ~10.7–10.9 MB

These results do not establish a need for table virtualization or benchmark-data partitioning at the current 1,796-run scale. Full-matrix interaction remains below ~226 ms p95 on the hosted runner.

Optimization scope

P1 — reduce shipped JavaScript

The JS bundle is about 80% of the gzip-compressed deployment payload. The frontend currently imports the full ECharts namespace from echarts in multiple modules. Replace this with the official echarts/core tree-shakeable registration surface and register only the Bar chart, title, tooltip, grid, legend, data-zoom, mark-line, and Canvas renderer capabilities used by the dashboard.

Acceptance:

• preserve Timing and Speedup behavior and existing E2E contracts;
• record before/after raw and gzip bundle size;
• no new chart dependency or feature regression.

P1 — avoid building collapsed chart tables eagerly

The accessible timing/speedup alternatives are semantically valuable, but closed <details> currently contain hundreds to more than one thousand fully materialized rows. Build each table on first expansion instead, while keeping the summary/row count and aria-describedby target present from initial render.

Acceptance:

• existing production accessibility flow still exposes the exact table after expansion;
• initial and full-matrix DOM node counts fall materially;
• filter changes preserve exact chart/table identity.

P2 — remove metadata request waterfall

Start benchmark data, parse report, and source inventory requests concurrently during initialization instead of starting metadata only after the main data response has parsed. The dashboard may still wait for the three current assets before its first complete render; this change removes an avoidable network RTT without changing generation-ID validation.

Explicit non-goals for this pass

• no table virtualization without a measured interaction problem;
• no benchmark-data partitioning/lazy source loading at 1,796 runs;
• no URL-persisted state;
• no frontend framework migration;
• no ECharts lifecycle rewrite unless post-optimization measurements show the current dispose/recreate strategy is still a P1 bottleneck;
• no schema or benchmark statistical-contract changes.

Validation

After implementation rerun the same five-round production audit and compare:

• raw/gzip payload sizes;
• cold ready time;
• Focused ↔ Full matrix latency;
• CV cascade latency;
• DOM node count and fallback-row materialization;
• JS heap/runtime metrics;
• existing TypeScript/build/staleness/Chromium E2E;
• production Chromium/Firefox/WebKit suite.

[TheHiddenObserver]

Optimization implementation and validation are complete in PR #115, which is now Ready for review but intentionally not merged.

Final clean head:

d10d49a51bd70b3f524e78ad74fac3d14885d1c2

Measured deterministic improvements relative to master@553f6b722a03b6d6870f8e2fe29b50bc11d38bfa:

JavaScript raw/gzip: -46.8%
total gzip deployment payload: -37.4%
Focused pre-expansion DOM: 6,934 -> 2,370 (-65.8%)
Full-matrix pre-expansion DOM: 17,608 -> 2,370 (-86.5%)

Final latency evidence uses a same-runner paired A/B design: one ubuntu-latest runner, one Chromium process, fresh contexts, 10 baseline/optimized pairs with alternating order.

cold-ready paired improvement median: 17.7% (10/10 pairs faster)
Full-matrix paired improvement median: 16.7% (10/10 pairs faster)
Focused-return paired median: 11.3% but mixed per-pair; not treated as guaranteed
CV-cascade paired median: 3.1% but mixed per-pair; treated as effectively unchanged / no regression

The earlier larger latency percentages from separate hosted-runner measurements are deliberately not used as causal claims because cross-runner wall-clock variance was material.

Final permanent gates on the exact clean head:

Tests #1424 — success
Maintenance compatibility #437 — success
Benchmark Frontend CI #495 — success
  python-data 3.9 — success
  python-data 3.11 — success
  frontend typecheck/build — success
  deterministic staleness — success
  Chromium regression E2E — success
  committed-deployment production QA (Chromium/Firefox/WebKit) — success

The production suite explicitly verifies that accessible chart tables are not eagerly materialized while collapsed and become exact, non-empty tables after disclosure expansion.

No temporary measurement workflow remains in the final nine-file diff. Final review ID: 4882801092; no unresolved review threads remain.

The measurements do not justify virtualization, benchmark-data partitioning, or an ECharts lifecycle rewrite at the current 1,796-run scale. #114 should remain open until the maintainer decides whether to merge PR #115.