Discord Reduced WebSocket Traffic by 40%

Original Article ↗ Hacker News Discussion ↗

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.