| I built a small reference demo that streams data in the browser, intentionally stalls the UI, and exports a structured trace you can compare across runs. 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. |
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.