Vite HMR under many concurrent clients: tune server.hmr.interval or accept default batching?

In a Vite (v4/v5) dev-server setup where many browser tabs or team members trigger hot-module updates at once, I see HMR latency grow once many updates queue up at the same time. My understanding is that the server batches pending updates before broadcasting them over the WebSocket, and that server.hmr.interval controls how frequently those batches flush.

My goal is to keep update latency low for a large team without inflating WebSocket traffic. As I read it, lowering the interval flushes the pending-update queue more often, cutting perceived latency, but produces more frequent, smaller broadcasts and therefore more network overhead. Raising it does the opposite.

What is unresolved for me is how to choose between these two documented levers for this specific constraint:

• For roughly 50+ concurrent HMR events, is tuning server.hmr.interval the intended mechanism, or is the default batch size itself the real bottleneck?
• Is there a documented way to measure whether latency comes from server-side batching versus client-side module transformation, so the trade-off can be made on evidence rather than guesswork?
• Does this behavior differ between Vite 4 and Vite 5 in a way that would change the recommendation?