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

Question

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?

Tasadduq Burney · Answer

The Direct Answer
For 50+ concurrent clients, server.hmr.interval is the intended mechanism to tune the trade-off between perceived latency and network overhead. There is no separate "batch size" limit that acts as a bottleneck; the interval simply defines the debounce window before the server flushes the current queue of updates to all connected WebSockets.
Recommendation: If latency is the primary complaint, lower the interval. If the browser UI freezes or network congestion occurs, raise it. Do not set it to 0 or near-zero, as this can flood the browser's main thread with individual update events, causing the very lag you are trying to avoid.

Analysis of HMR Bottlenecks
In a high-concurrency scenario, the delay you perceive is usually a result of one of three stages. It is important to distinguish between them before adjusting the server configuration:

Server-side Batching: The time between a file change and the WebSocket broadcast. This is directly controlled by server.hmr.interval.
Network Transport: The time it takes for the WebSocket frame to reach 50+ clients. This is a function of bandwidth and the number of open connections.
Client-side Execution: The time the browser spends receiving the update, requesting the changed modules, and applying the HMR patch.

Measuring the Source of Latency
To determine if the bottleneck is the server batching or the client transformation, use the following verification method:

Open the Browser DevTools > Network tab and filter by WS (WebSockets).
Trigger a file change and note the exact timestamp of the update frame arriving in the WebSocket stream.
Compare this to the timestamp of the file save on the server.

If there is a significant gap between the save and the WebSocket frame, server.hmr.interval is the culprit. If the frame arrives instantly but the page takes seconds to update, the bottleneck is client-side module transformation or network congestion during the subsequent HTTP requests for the new modules.

Version Differences and Constraints
There is no fundamental change in the HMR batching logic between Vite 4 and Vite 5 that would alter this recommendation. While Vite 5 includes general performance improvements in the build engine, the WebSocket broadcast mechanism remains consistent.
Caution: When scaling to 50+ concurrent users on a single dev server, ensure your environment's open file descriptor limit (ulimit -n) is sufficiently high, as each WebSocket connection and file watch consumes resources that can cause the server to hang regardless of the HMR interval.

Diagnostic Request
To refine this recommendation: Are the 50+ clients connected to a single shared remote dev server, or are they local instances running in a containerized environment (e.g., via a proxy)? Network latency in remote shared environments often outweighs the impact of the HMR interval.

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

1 answer

The Direct Answer

Analysis of HMR Bottlenecks

Measuring the Source of Latency

Version Differences and Constraints

Diagnostic Request

Your perspective belongs here.

0 question comments