网络请求中的不可控因素：弱网与首包延迟

移动端网络的复杂性远超桌面端，用户可能随时从Wi-Fi切换到4G/5G，甚至进入地铁、电梯等信号衰减区域。延迟优化的第一个难点，在于你无法控制网络本身的物理特性：TCP连接的握手时间、DNS解析的递归查询、以及基站切换带来的RTT波动，都会直接拉长“首包到达时间”。很多优化方案假设带宽充足，但实际情况往往是高延迟+低带宽的弱网环境，此时即便一个10KB的请求也可能需要数秒才能完成。更棘手的是，移动端操作系统的网络栈对并发连接数限制更严格，浏览器的预连接和HTTP/2多路复用能力在某些自定义WebView中会被丢弃。开发者必须放弃“一次请求获取全部数据”的思维，转而设计分级的加载策略：首屏关键资源走CDN边缘节点，非关键数据延后拉取，同时利用service worker预取用户最可能点击的内容。但预取时机如何判断？缓存过期后如何避免请求风暴？这些问题没有标准答案，必须根据业务场景反复权衡，这正是移动端延迟优化最“不可控”的难点所在。

渲染路径的阻塞陷阱：从主线程到合成器的每一毫秒

移动端屏幕尺寸小，但像素密度高，渲染压力反而更大。延迟的第二大难点藏在浏览器的渲染管线里：当用户触摸屏幕，事件处理、样式计算、布局、绘制、合成与光栅化，任何一个阶段卡住，都会造成肉眼可感知的“延迟感”。许多开发者只关注JavaScript执行时间，却忽略了主线程上的其他隐形任务——比如一个巨大的CSS选择器匹配、一次强制同步布局（Layout Thrashing），或者频繁触发will-change导致的合成层爆炸。尤其低端安卓设备，GPU显存有限，合成层过多会直接导致掉帧。更隐蔽的是，滚动和动画期间，主线程可能被同步的阻塞JavaScript霸占，而移动设备的CPU频率通常比桌面低30%到50%，同样的逻辑在手机上耗时可能加倍。难点在于：渲染路径的瓶颈往往不是某一个“慢操作”，而是多个微小的性能坑互相叠加。你无法简单通过DevTools的Performance面板一次性发现所有问题，因为真实用户设备的屏幕刷新率、系统阉割策略、内存压力都各不相同。有效的办法是建立以帧预算为中心的监控体系：主线程上任何长于16.7毫秒的任务都需要标记排查，同时谨慎使用transform与opacity触发合成器加速，将动画从主线程剥离，才能真正减少延迟的视觉冲击。

JavaScript执行成本为何常被低估

移动端JavaScript引擎的解析、编译和垃圾回收机制，与桌面端存在显著差异，而多数性能分析工具默认用桌面CPU模拟移动设备，这导致执行成本被严重低估。一个在现代Chrome上只需2毫秒的复杂算法，到了中端移动手机的JIT编译下，可能要花费20毫秒以上。更关键的是，移动设备的功耗约束会让CPU主动降频，当设备发热时，同样的代码执行时间还会成倍增长。很多团队只关注网络与渲染，却忘了业务逻辑中的循环、正则表达式、对象频繁创建和销毁，都会成为延迟的隐性推手。尤其React/Vue这类框架，依赖虚拟DOM的diff运算，每次状态更新都会触发大量JavaScript函数调用，在低端机上的开销不容小觑。还有一个容易被忽视的点：JavaScript垃圾回收（GC）是阶段性的暂停，移动端小内存设备几乎每3到5秒就会触发一次minor GC，若在动画或滚动期间发生，就会直接引起卡顿。难点在于优化执行成本没有银弹——减少代码体积只是第一步，还要警惕框架抽象层产生的额外调用开销，利用性能指标（如Long Task API）主动发现主线程上的长任务，并将高频触发的事件（如touchmove）中的复杂计算移到requestAnimationFrame之外或Worker线程中。只有承认JavaScript在移动端是“昂贵资源”，才能做出正确的延迟取舍。

存储与缓存：看似简单却最容易被忽视的延迟源头

移动端延迟优化越到后期，存储系统反而越容易被忽略。开发者通常认为多读几次缓存或索引数据库是“快操作”，但在低端手机上，顺序读写速度可能比旗舰机慢10倍以上。IndexedDB的事务提交、本地存储的同步读取，甚至是Cache Storage的元数据查询，都可能产生几十毫秒到上百毫秒的阻塞。难点在于，不同移动WebView对存储API的实现存在差异：Safari的IndexedDB在某些版本上性能极差，Android系统WebView的缓存清理策略也可能导致查询命中后还要重新解密和解压缩。更麻烦的是，缓存带来的延迟优化常常被“新鲜度”抵消——为了展示最新数据，开发者设置极短的缓存时间，结果用户每次进入页面都需要等待网络验证；而设置过长缓存又会造成数据过期，进而出现前端展示与后端状态不一致的诡异交互。真正的延迟优化应该将存储视为一个多层系统：内存中的轻量状态缓存（如redux或vuex）负责毫秒级响应，持久化存储负责跨会话恢复，而网络请求只作为最底层的兜底。同时要避免在启动路径上同步读取存储数据，应该把必要数据在首帧前通过预加载埋入HTML或独立脚本中，其余数据异步填充。同时，针对写入场景，使用防抖或批量写入策略降低存储事务频率，并对大对象进行分流压缩——这些细微操作看似微不足道，却能在真实用户的弱设备上累计出明显的延迟差异。