Verification Metadata
- Route:
/transparency/load-testing/ - Last verified:
- Benchmark matrix: 4 scenarios, 10 runs each (40 total page runs).
- Modes compared:
earnings_mode=eagervsearnings_mode=lazy. - Profiles: Real user dataset and synthetic 2025/2026 high-volume profile.
Executive Summary
Lazy loading delivered a major reduction in initial page completion time for real data and a consistent improvement for synthetic high-volume data.
- Real dataset: average
DOMContentLoadedimproved from 8831.64 ms (eager) to 977.43 ms (lazy), an 88.93% reduction. - Synthetic dataset: average
DOMContentLoadedimproved from 629.25 ms (eager) to 500.46 ms (lazy), a 20.47% reduction. - Section-ready timing: lazy reduced YTD / Pay Period / Monthly / Daily section readiness by 28.32% (real) and 18.30% (synthetic).
- Trade-off: lazy mode increased API call count (real: 2.10 to 8.00; synthetic: 5.00 to 8.00 average calls per run).
- FCP observation: first-contentful-paint was slightly slower in lazy mode (+22.56% real, +8.16% synthetic), but total interactive section readiness was faster.
Benchmark Method
Use Case: Detecting Real-World Slowdowns
When users report a slower earnings page after a feature rollout, this benchmark method provides a reproducible way to compare eager and lazy behavior across identical datasets before and after the change.
- Automation used Playwright Chromium in headless mode against
https://dev.paycal.local. - Authentication used local dev bypass login to ensure realistic user/session execution paths.
- Each run captured navigation timing, paint timing, per-section ready timing, and API request count.
- Metrics are averaged over 10 runs per scenario to reduce single-run noise.
Results: Real User Dataset (10 Runs)
| Metric | Eager Avg (ms) | Lazy Avg (ms) | Delta |
|---|---|---|---|
| DOMContentLoaded | 8831.64 | 977.43 | -88.93% |
| Load Event | 8831.94 | 977.83 | -88.93% |
| FCP | 594.00 | 728.00 | +22.56% |
| YTD Ready | 9033.02 | 6475.12 | -28.32% |
| Pay Periods Ready | 9033.02 | 6475.13 | -28.32% |
| Monthly Ready | 9033.05 | 6475.15 | -28.32% |
| Daily Ready | 9033.11 | 6475.29 | -28.32% |
| API Calls (count) | 2.10 | 8.00 | +280.95% |
Results: Synthetic 2025/2026 Dataset (10 Runs)
| Metric | Eager Avg (ms) | Lazy Avg (ms) | Delta |
|---|---|---|---|
| DOMContentLoaded | 629.25 | 500.46 | -20.47% |
| Load Event | 629.54 | 500.69 | -20.47% |
| FCP | 377.60 | 408.40 | +8.16% |
| YTD Ready | 831.05 | 678.95 | -18.30% |
| Pay Periods Ready | 831.05 | 678.97 | -18.30% |
| Monthly Ready | 831.07 | 678.99 | -18.30% |
| Daily Ready | 831.07 | 679.00 | -18.30% |
| API Calls (count) | 5.00 | 8.00 | +60.00% |
Interpretation
- Lazy loading significantly improves initial route completion and section readiness under both tested profiles.
- The largest gain appears when user datasets are heavy enough to make server-side eager rendering expensive.
- The architecture shifts work from one large payload to multiple targeted API calls, improving perceived performance but increasing request count.
- This trade-off is intentional and currently favorable for user-perceived responsiveness on
/earnings/.