减少请求次数，合并资源
很多人在开发网页或App时容易忽略一点：频繁的小请求比一次大请求更伤性能。比如一个页面加载时发起十几个API调用，每个都等几百毫秒，累积起来卡得不行。解决办法很简单——把能合并的数据接口整合成一个。比如用户信息、权限、通知数量这些通常一起用的字段，完全可以从三个接口变成一个返回包。
前端也可以把多个小图片合成雪碧图，CSS和JS文件压缩合并，减少HTTP请求数。这就像去超市买东西，一次性拎走所有物品，总比一趟趟跑省时间。
启用压缩传输
服务器返回数据前开启Gzip压缩，文本类响应体积通常能缩小70%以上。特别是JSON这种重复结构多的数据格式，压缩效果非常明显。Nginx配置里加一句gzip on;就能生效，代价是轻微CPU开销，但对现代服务器来说几乎可以忽略。
gzip on;
gzip_types text/plain application/json text/css application/javascript;合理使用缓存机制
静态资源设置长缓存有效期，配合文件名哈希更新。比如style.a1b2c3.css这种命名方式，浏览器会自动缓存，下次访问直接读本地。接口层面也能做缓存，像用户头像、商品详情这类变动不频繁的数据，Redis存个几分钟，既能减轻数据库压力，又能加快响应速度。
注意控制Cache-Control头，避免不该缓存的内容被误存。比如登录状态相关的接口，必须设置no-cache或private。
选择合适的通信协议
传统REST API虽然通用，但在实时性要求高的场景就显得笨重。WebSocket适合聊天、股票行情这类需要持续推送的业务。而gRPC在内部微服务之间调用效率更高，序列化体积小，延迟低，尤其适合移动端弱网环境。
举个例子，外卖App骑手位置更新如果用HTTP轮询，每5秒发一次请求，不仅耗电还占带宽。换成WebSocket主动推，服务器有新坐标才发，省资源还更及时。
优化数据序列化格式
默认用JSON没问题，但如果数据量特别大，考虑用二进制格式如Protocol Buffers。同样的结构化数据，Protobuf编码后体积可能只有JSON的一半，解析速度也更快。尤其在移动设备上，电量和CPU都很宝贵。
message User {
int32 id = 1;
string name = 2;
bool active = 3;
}做好错误处理和降级策略
网络不可能永远稳定。客户端要设置合理的超时时间，比如普通请求8秒超时，图片加载15秒断掉。失败后尝试次数别太多，两三次就够了，否则只会让用户更焦虑。关键功能可以预加载备用数据，比如新闻列表打不开网络时，显示上次缓存的内容，至少界面不空白。
服务器端也要限制单个用户的请求频率，防刷防爬的同时，避免异常流量拖垮整个系统。