πŸ“Š

Worker HTTP β€” Benchmark Suite

Reproducible measurements: main thread vs worker transports

Long TasksDropped FramesWall Clock

How this works: each scenario simulates identical "server" work (CPU burn + delay + payload generation). The only difference between modes is where the work runs.

Long Tasks are PerformanceObserver longtask entries (Chromium-only). Dropped frames are requestAnimationFrame gaps > 25ms β€” works in every browser.

Long Task API unsupported in this browser β€” using dropped frames only

100 small requests (sequential)

Pure transport overhead: tiny payload, no server work, fired one after another.

ModeTotal timeLong tasksLong task timeDropped framesOK / Fail
Main thread not run yet
Worker (pool=1) not run yet
Worker (pool=4) not run yet

1 large response (10MB JSON)

Serialization cost: a single response with a 10MB string payload.

ModeTotal timeLong tasksLong task timeDropped framesOK / Fail
Main thread not run yet
Worker (pool=1) not run yet
Worker (pool=4) not run yet

50 requests in parallel burst

Pool benefit: 50 requests fired at once, each with 50ms simulated server delay.

ModeTotal timeLong tasksLong task timeDropped framesOK / Fail
Main thread not run yet
Worker (pool=1) not run yet
Worker (pool=4) not run yet

20 requests + 500ms main-thread CPU burn

Real-world jank case: the UI is busy (heavy CPU) while requests run. Workers should keep frames smooth; main-thread cannot.

ModeTotal timeLong tasksLong task timeDropped framesOK / Fail
Main thread not run yet
Worker (pool=1) not run yet
Worker (pool=4) not run yet

Large Dataset Streaming (10MB)

Zero memory block: progressively streams a 10MB dataset in chunks with simulated latency.

ModeTotal timeLong tasksLong task timeDropped framesOK / Fail
Main thread not run yet
Worker (pool=1) not run yet
Worker (pool=4) not run yet
Numbers vary by hardware, browser and current system load. Run a scenario multiple times and watch the trend, not a single value.