Headline findings
Summary
Slowest interaction — root cause & contributors
How time grows from 100 → 1000 → 10000
Each panel is one scenario. X-axis is listing size (100, 1000, 10000 files). Solid lines are the median across repeats; faint dots are the individual repeats. The dashed line is what that browser would do if time scaled linearly from its 100-file run (10× rows → 10× time). A solid line that bends above the dash is the scaling problem.
Milliseconds per thousand rows
Duration ÷ (folders + files) × 1000. A flat line is O(n): each extra row costs the same. A line that rises as the listing grows means work per row is getting worse — that is where the implementation degrades.
DOM & listeners at load
One panel per browser. Lines are listing rows, addEventListener calls, and IntersectionObservers as listing size grows 100 → 1000 → 10000.
Baseline comparison
Status uses a ±10% bar: ≥10% worse is a regression, ≥10% better is an improvement. Metrics that were never collected (0→0 FPS on load, Event Timing on programmatic scroll, CDP layout during compositor-only scroll) are omitted instead of looking like a pass. Histogram: green = better, red = worse. Click a bar or chip to filter.
| Status | Scale | Scenario | Metric | Baseline | Current | Δ | Δ% |
|---|
All runs
Click a row for full profiling, contributors, and threshold warnings. Time is the median; Repeats lists every iteration.
| Browser | Scale | Scenario | Median (ms) | Repeats (ms) | Rows | Listeners | IO | Thresholds |
|---|
Analysis table
| Browser | Scale | Scenario | Metric | Value |
|---|