一、能合并的请求，绝不分两次发
移动端建立一次HTTP连接的成本比PC端高得多，DNS解析、TCP握手、TLS加密（如果是HTTPS），这一套流程下来，几百毫秒就没了。所以，第一个优化思路就是减少请求次数。
别为了所谓的"模块化"就把数据拆得稀碎。比如，一个页面需要用户信息、商品列表、 Banner图三个数据，如果后端兄弟好说话，尽量磨着他提供一个聚合接口，一次请求全部返回。如果后端实在不方便，或者数据来源不同，那在前端也可以考虑在代码层面进行一定程度的合并，避免在极短的时间内连续发起多个请求。
对于图片，经典的雪碧图（CSS Sprite）技术在移动端依然有它的用武之地，特别是对于数量多、体积小的图标类图片。或者，现在更流行的方式是用图标字体（Icon Font）或者SVG Sprite来替代部分图片，它们体积更小，且是矢量图，缩放不失真。
二、减少不必要的数据传输，能省一点是一点
移动网络环境复杂，流量也是用户真金白银买来的。传输的数据量越小，加载速度自然越快。
开启Gzip压缩： 这是服务器端最基础的优化手段。文本类资源（JS、CSS、HTML）经过Gzip压缩，体积通常能减少60%-70%。这个需要后端配合，在服务器（如Nginx）上配置一下即可。
图片优化是重中之重： 移动端页面，图片往往是流量大头。
精简JSON数据： 和后端沟通，返回的JSON字段名能不能短一点？没用的字段能不能别返回？有时候后端图省事，把一个对象的所有字段都塞给你，前端要学会"按需取用"。
三、利用缓存，让重复访问"秒开"
缓存是利用本地存储来避免重复请求的终极武器。
强缓存（Cache-Control, Expires）： 对于长期不会变的静态资源（如打包后的JS/CSS、库文件），可以让浏览器直接缓存起来，下次访问同地址时直接使用本地副本，连HTTP请求都不发。设置 （一年）是个常见的做法。
协商缓存（Last-Modified / ETag）： 对于可能变化的接口数据或资源，可以使用协商缓存。浏览器会询问服务器资源是否过期，如果没变，服务器返回304，浏览器就用本地缓存。这虽然有一次请求，但省去了传输数据体的时间。
本地存储（LocalStorage/SessionStorage）： 对于一些非实时性要求的数据，比如城市列表、配置信息等，可以第一次请求后存到本地，下次直接读取。并设置一个合理的过期时间，定期更新。
四、针对弱网和不稳定网络的策略
移动端网络环境瞬息万变，必须有容错机制。
设置合理的超时时间： 全局或为重要请求设置请求超时时间。比如，普通请求设5秒，关键请求设10秒。超时后要及时给用户反馈，而不是让页面一直卡死。
重试机制： 对于因网络抖动导致的失败请求，可以实现一个带指数退避的重试机制。比如，第一次失败后等1秒重试，再失败等2秒，再失败等4秒......避免在网络恢复瞬间同时发起大量重试请求，压垮服务器。
请求优先级与取消： 页面同时有多个请求时，要区分优先级。首屏关键数据优先加载，非关键请求可以延后。同时，对于已经发出但不再需要的请求（比如用户快速跳转了页面），要能够手动取消（Abort），释放连接和资源。
Service Worker 的离线缓存： 这是高阶玩法。通过Service Worker，你可以拦截网络请求，并返回预先缓存好的资源，从而实现离线访问或极速的二次访问。这对于PWA应用来说是核心能力。
五、其他零碎但实用的技巧
HTTP/2： 如果条件允许，一定要上HTTP/2。它支持多路复用，一个连接可以并行处理多个请求，彻底解决了HTTP/1.1的队头阻塞问题，头部压缩还能进一步减小数据量。
域名分片（HTTP/1.1下）： 在还没用上HTTP/2的情况下，对于HTTP/1.1，浏览器对同一域名有并发请求限制（一般是6个）。可以通过将静态资源分布在多个不同域名下，来突破这个限制，提升并发加载速度。
预连接（Preconnect/DNS-Prefetch）： 在页面头部使用 ，提前与即将要用到的重要第三方域名建立连接或进行DNS解析，减少实际请求时的延迟。
总结一下
移动端网络优化是个系统工程，从前端的代码构建、资源管理，到后端的接口设计、服务器配置，再到网络协议本身，每个环节都有挖掘的空间。咱们前端能做的，就是从用户实际体验出发，建立"减少请求数、减小数据量、善用缓存、增强鲁棒性"的核心思想，把每一个细节做到位。多测试，尤其是在真实弱网环境下测试，才能发现真正的问题。希望上面这些唠叨能对大家有点启发，欢迎在评论区一起交流踩坑经验！