Consider disabling WebSocket message splitting when permessage-deflate is off

[pastelsky]

WebSocket message splitting adds significant latency for large files on proxied connections

When serving code-server behind a proxy (which is the common production deployment), the 256KB WebSocket message splitting introduced in microsoft/vscode#174278 multiplies per-message RTT overhead significantly for large file operations like image previews.

Background

VS Code splits large IPC messages into 256KB chunks (MaxWebSocketMessageLength = 256 * 1024 in ipc.net.ts) to avoid blocking the Node.js event loop during zlib compression. Each chunk becomes a separate WebSocket message.

The latency problem in proxied deployments

In a proxied deployment (e.g. a gateway in front of a devbox), each WebSocket message incurs a full round-trip. With 100ms RTT between the proxy and the devbox:

• A 10MB file generates ~40 chunks (10MB ÷ 256KB)
• Each chunk = one WebSocket message = one round-trip
• Total overhead: ~40 × 100ms = ~4 seconds of pure latency

We tested image preview times (time from opening a file in the explorer to the image fully rendering) across different file sizes at 100ms simulated RTT:

File size	Splitting ON	Splitting OFF	Improvement
145 KB	2,212ms	2,251ms	~0%
1 MB	1,988ms	1,707ms	14%
1.5 MB	2,093ms	1,412ms	33%
5.6 MB	4,255ms	2,193ms	48%
10.3 MB	7,262ms	2,888ms	60%

Is disabling splitting safe? (Does zlib actually block?)

A few basic tests didn't seem to indicate this issue in our case, but more investigation may be needed

Question

Would you consider making enableMessageSplitting configurable via a CLI flag, or defaulting it to false for single-user deployments?

Happy to submit a PR if there's agreement on the right approach.

[code-asher]

It does sound reasonable to me. Maybe the setting can take 0 for no splitting or a non-zero positive number for custom chunk sizes.

Or maybe a bigger default size for images?

I do think it would be best to submit such a change upstream since the VS Code maintainers have probably looked into this a lot more than I have and may have some good insight.