I have been looking into the idea of adding WebSocket support to the DevTools Network panel and wanted to better understand what the traffic actually looks like at the socket level, so I ran a small experiment locally.
To make things concrete, I wrote a simple wrapper around dart:io’s WebSocket that intercepts outgoing and incoming messages. The goal was just to capture a few pieces of metadata for each frame (timestamp, direction, and payload size) and see what that event stream might look like if something similar were surfaced to DevTools.
For example, outgoing frames are intercepted through add() before they are forwarded to the underlying socket:





To try it out, I connected to a public WebSocket echo server and built a small CLI tool that lets me send messages interactively:


Watching the events appear while sending messages made the difference between HTTP and WebSocket traffic clearer to me. HTTP fits naturally into a request/response model, which matches how the Network panel currently displays activity. With WebSockets, though, the connection is long-lived, and the meaningful activity happens at the frame level as messages move in both directions.
That made me think that representing WebSocket activity as a stream of frame events(timestamp, direction, payload size, etc.) might be a natural way to surface it in DevTools.
One thing I’m still trying to understand is where this instrumentation would ideally live. Do you see WebSocket traffic eventually being emitted through dart:developer timeline events (similar to how HTTP profiling works today), or would it make more sense to expose it through a dedicated VM Service stream that DevTools could subscribe to?
If there is a particular part of the DevTools or Dart SDK codebase you would recommend digging into next, I would be happy to experiment further and share what I learn.
Best,
Harshita