This isn’t a benchmark or a product. I mostly built it to sanity-check my own understanding of a common problem: is this slowdown coming from the network or from the UI thread?
What the demo does:
Uses real SSE streaming (no simulated network behavior)
Relies on real browser throttling (DevTools → Network → 3G)
Intentionally blocks the main thread to create real UI stalls
Exports a plain JSON trace with strict event ordering
How to try it:
Open the site
Set DevTools → Network → 3G
Click Run All (Standard Test)
Download the trace
Run it again and compare
What surprised me is that with the same test and seed, the structure of the trace stays the same, even though timing shifts. That made it much easier (for me) to reason about what actually happened without squinting at timelines.
The page is instrumented with a small deterministic event kernel so the exported trace preserves order and structure across runs. This is meant as a reference artifact, not a claim that this is the “right” way to do things.
Demo: https://deterministic-stream-demo1.pages.dev/
Happy to answer questions or hear where this breaks down.
Slaine•1h ago
I’ve been running the same test multiple times with the same seed and network profile and diffing the JSON. The timings move, but the event structure doesn’t, which helped me reason about cause vs effect more clearly.
If there are existing tools or workflows that already give you this kind of repeatable structure, I’d genuinely love pointers.