Discord Reduced WebSocket Traffic by 40%

Original Article ↗ Hacker News Discussion ↗

Discord’s claim of cutting WebSocket traffic by 40% through better compression and protocol tweaks prompts debate over whether the gains mainly reduce hosting and bandwidth costs or meaningfully improve end‑user performance. Commenters scrutinize the switch from zlib to Zstandard, the absence of client‑side decompression metrics, and the continued reliance on JSON instead of a binary schema, weighing trade‑offs between efficiency, simplicity, and ecosystem compatibility. Many also highlight how the Electron-based desktop client feels heavy and slow to launch, contrasting network‑level optimizations with persistent UX and resource‑usage complaints.

Compression trade-offs and wins

  • Many focus on Discord’s strong emphasis on bandwidth reduction; some argue end-user latency is often dominated by CPU and RTT, not bandwidth, especially for small packets.
  • Others note going from 2+ MB to ~300 KB for READY and similar payloads is a big win for both cost and perceived speed, especially on mobile and slow links.
  • Several comments point out that large payloads (READY, MESSAGE_CREATE) are not “just a few KB,” so compression materially matters.
  • There’s speculation that egress/hosting costs are a major driver, with user-visible gains more secondary.

CPU cost, benchmarks, and confusion

  • Some critics complain the blog largely reports compression time but omits decompression benchmarks, which matter for clients on weaker devices.
  • Others respond that zstd is generally understood to decompress faster than zlib and that the article shows zstd is also faster to compress.
  • The reported “microseconds per byte” numbers appear absurdly slow if taken literally; several commenters suspect they are actually per kilobyte or include heavy fixed overheads. This remains unclear in the thread.

Protocol and serialization choices

  • Several participants question using JSON over WebSockets instead of a binary schema (Protobuf, Cap’n Proto, custom binary).
  • Arguments for JSON: easier debugging with browser devtools; many bots and third-party devs would struggle with binary; existing APIs and tooling assume JSON.
  • Arguments for binary: better baseline efficiency, especially for large-scale traffic; could still expose JSON as an optional content type for bots.
  • Erlang Term Format/External Term Format is discussed; it’s not clearly better than compressed JSON due to verbose structures and similar semantics.

User experience and client performance

  • Multiple users report Discord’s desktop app is slow to launch and resource-heavy, even on high-end PCs; others say it runs fine even on low-end hardware.
  • Some blame Electron; others counter that many Electron apps (e.g., code editors) feel snappier, so app design and bundling matter more than the framework.
  • Comparisons to IRC and older software highlight frustration that modern hardware still struggles with large chat workloads.

Update distribution and packaging

  • Complaints about frequent, slow updates during launch and needing to download new .deb packages, in addition to in-app patching.
  • Some recommend Flatpak or configuration flags to avoid host updates, while others dislike extra packaging layers and prefer system package managers.
  • Sandboxing benefits of Flatpak (limited filesystem and process access) are emphasized for untrusted apps like Discord.

Design / bug and security concerns

  • PASSIVE_UPDATE_V1 initially resent full state instead of deltas; this is clarified as a bug rather than an intentional design.
  • One commenter raises concerns about compression oracle attacks (e.g., BREACH) and wishes Discord had documented their security analysis; the thread offers no answer.
  • Another appreciates the blog for including failed approaches and trade-offs, which are considered rare but valuable.