（二）图片加载这块必须放在首位说。现在很多团队还在用JPG/PNG全家桶，2倍图3倍图直接往页面上怼，3秒白屏不找你找谁？成熟点的方案应该这么玩：WebP格式兼容性现在都90%+了，安卓全线支持，iOS从11开始也跟进了，用<picture>标签做优雅降级不香吗？再说个骚操作，用CSS渐变色模拟图片占位，等真实图片加载完毕再渐变替换，这体验直接提升一个level。
（三）JS脚本的加载时机得讲究策略。见过不少项目把几十KB的库文件全塞在head里，这不是拦着用户不让吃饭吗？推荐两种姿势：对于非关键依赖库，用defer异步加载；对于首屏用不着的组件，动态import()它不香吗？特别是那个IntersectionObserver API，元素进入视口再加载资源，懒加载做到极致。记得去年做电商项目，商品详情页的评论组件就用这招，首屏加载时间直接干下去40%。
（四）CSS渲染阻塞这个老生常谈的问题，很多人还是没搞明白。移动端尤其要警惕伪全屏loading动画，某些团队为了炫技搞个3MB的Lottie动画，用户流量烧了1/10还没看到正文。正确的打开方式应该是：关键CSS内联到head，非关键CSS异步加载。实测过把首屏CSS控制在14KB以内，4G网络下基本能实现秒开。要是搞不定，试试critical这个webpack插件，自动提取关键CSS。
（五）网络请求优化这块水特别深。先说个反常识的------HTTP/2服务器推送在移动端可能适得其反，因为蜂窝网络波动太大。更实在的做法是：静态资源走CDN+强缓存，接口数据上防抖节流。本地存储策略也要设计好，localStorage存非敏感配置数据，IndexedDB存结构化数据。特别提醒：缓存更新机制要做好，别让用户永远看不到新版本。
（六）运行时性能才是重头戏。避免强制同步布局这个坑我见一个踩一个，比如在循环里连续读取offsetTop又修改样式，浏览器不得不在每次循环都重新计算布局。正确的姿势是用FastDom这样的工具做读写批处理。还有内存泄漏问题，SPA项目里事件监听器忘了移除的，setInterval不清除的，都是性能炸弹。推荐用Chrome DevTools的Memory面板定期体检。
（七）最后说几个立竿见影的骚操作：
用will-change属性提前告诉浏览器哪些元素要变化，但别滥用否则加重内存负担
滚动事件用passive: true提升流畅度，特别是处理touchmove的时候
图片解码用decode()方法避免渲染卡顿，这个API现在兼容性很可以了
Service Worker做缓存拦截，实测能把二次打开速度提到0.5秒内
（八）性能优化不是玄学，关键要建立数据驱动的意识。别光靠感觉，老老实实在Chrome DevTools里跑Lighthouse，用Performance面板记录交互过程。真机测试更不能少，建议搞个性能监控SDK收集真实用户数据。记住一个真理：用户觉得快才是真的快，那些测试工具的高分都是虚的。