WebSocket优化重点是帧结构控制、数据序列化和连接复用：控制负载＜126字节以节省长度编码，用原生Ping/Pong替代文本心跳，优先二进制帧及Protocol Buffers/MessagePack序列化，缓冲合并高频小包，按需启用permessage-deflate压缩。

WebSocket本身已大幅压缩了头部开销，相比HTTP轮询每次携带完整请求头（通常数百字节），其帧头最小仅2字节（无掩码、负载＜126字节时）。真正影响效率的往往不是协议设计，而是使用方式。优化重点应放在帧结构控制、数据序列化和连接复用上。

精简帧头：合理控制掩码与负载长度编码

客户端发送帧必须启用掩码（Mask=1），这会固定增加4字节；服务端发给客户端可不掩码，但浏览器强制要求客户端掩码，无法绕过。关键在Payload Length字段：

• 负载长度＜126字节时，长度字段占1字节；126–65535字节占2字节；更大则占8字节——应尽量将单条消息控制在126字节内，例如拆分日志或状态更新为小包
• 避免频繁发送＜10字节的“心跳”字符串（如"ping"），改用WebSocket原生Ping/Pong控制帧（Opcode=0x9/0xA），它们由协议栈自动处理，不经过应用层，无自定义载荷，头部更轻

减少冗余序列化：优先用二进制而非JSON文本

文本帧（Opcode=0x1）需UTF-8编码，且JSON包含大量引号、逗号、字段名等重复字符；二进制帧（Opcode=0x2）可直接传输紧凑结构：

• 用TypedArray（如Uint8Array）构造二进制消息，例如将{type: 3, id: 12345, value: 0.87}编码为[3, 0, 0, 48, 57, 139, 102]（按约定字节序），体积比JSON字符串节省50%以上
• 若必须传结构化数据，选用Protocol Buffers或MessagePack替代JSON，二者序列化后无字段名、支持二进制，且有成熟JS库（protobufjs、msgpack-lite）

复用连接与批量合并：避免高频小包

WebSocket是全双工长连接，但频繁调用send()仍会产生多个独立帧，每个帧都有FIN+Opcode+Length等基础开销：

立即学习“前端免费学习笔记（深入）”；

• 对高频触发的数据（如传感器采样、鼠标轨迹），在客户端做简单缓冲（如100ms窗口或16条阈值），合并为单帧发送
• 服务端推送时，避免为每个用户单独发一条通知；可将同类型事件（如“订单状态更新”）批量打包成一个数组消息，由前端统一解析分发
• 禁用不必要的子协议协商（Sec-WebSocket-Protocol头），除非业务强依赖特定协议语义，否则省去该字段可减少握手开销

启用扩展与压缩（需服务端协同）

WebSocket标准支持扩展（extensions），其中permessage-deflate可在帧级启用zlib压缩：

• 需客户端在握手请求中声明：Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
• 服务端响应确认后，双方自动对每帧负载压缩；对含重复字段的JSON或文本日志效果显著，但会增加CPU开销，适合带宽敏感而算力充足的场景
• 注意：二进制数据（如图片Base64）本身已压缩，再套一层deflate可能增大数据量，应按消息类型动态开关