你有没有过这种体验本地开发的时候页面秒开一放到真机上先是白屏然后图片一张一张蹦出来点击还时不时卡一下。项目上线后老板拿着用户反馈截图问你为什么竞品首屏 1 秒不到我们这要 3 秒。这种问题大概率绕不开两个词异步加载、性能优化。这个标题看起来像培训课程的目录页但里面每一个字都是前端、移动端、游戏客户端甚至服务端渲染的人每天都在面对的事。这篇文章不打算兜圈子。我会先讲清楚异步加载到底解决了什么问题然后给出一套从指标到落地的完整优化思路事件循环和渲染阻塞的底层逻辑、性能指标怎么定、代码分割和懒加载的具体方案、网络层渲染层内存层的配套优化最后再用一个典型的移动端 H5 首屏优化案例做复盘。适合做 Web 前端、移动端 H5、小程序以及游戏客户端和服务端渲染的同学参考。原理不看懂的优化都是碰运气指标不建立的优化都是自我安慰——这两句话算是这篇文章的骨架。1. 先弄懂一件事页面为什么慢慢在“阻塞”1.1 同步脚本是首屏性能的头号杀手很多同学一谈性能优化就想着压缩图片、加 CDN、上缓存但真正把首屏拖垮的往往是 JavaScript。原因要回到浏览器解析 HTML 的过程用户输入 URL 后浏览器拿到 HTML 就开始从上往下解析一边解析一边构建 DOM 树。这个过程里只要碰到一个普通的script src...解析工作就得停下来先去下载这个脚本下载完还要编译、执行全部搞定后才能继续解析后面的 HTML。这就是常说的解析器阻塞。CSS 也有类似问题不过方向不太一样CSS 不阻塞 HTML 解析但会阻塞渲染。浏览器要等 CSSOM 构建完成才能把 DOM 和 CSSOM 合并成渲染树。也就是说白屏时间 关键资源下载时间 关键资源执行时间 渲染准备时间任何一个环节卡住用户看到的就是空白页面。这里有个容易误解的点现代浏览器其实没那么傻解析 HTML 的同时会用预加载扫描器去提前发现后面的资源并开始下载。所以很多场景下脚本是真的“下载完了”但执行脚本依然会抢占主线程把后续的 DOM 构建和渲染活活卡住。换句话说阻塞的瓶颈往往不是网络而是脚本执行占用的那段时间。拿日常场景打个比方一个 HTML 文件就像一份装修流程单浏览器是施工队。遇到同步脚本等于施工队看到单子上写着“等一批定制材料到场并安装完”整队人只能站在那等着后面的工序全部排队。你材料运得再快只要安装这一步必须停下来做工期就不可能短。1.2 异步加载的两层含义网络不阻塞与执行不阻塞很多人把“异步”理解成“同时跑几件事”这是最常见的第一层误解。浏览器的主线程只有一个JavaScript 跑起来的时候别的事都得靠边站。所谓异步本质上是把任务挂起等当前任务执行完再通过事件循环挑个时机把回调捡起来执行。事件循环的工作方式说白了就是排队执行栈跑完当前任务先清空微任务队列再取一个宏任务来执行两个宏任务之间留出渲染的机会帧空闲的时候还能跑一下requestIdleCallback。setTimeout、Promise、requestAnimationFrame、requestIdleCallback这些 API 对应的就是不同的排队位置和优先级。所以异步加载真正解决的是两件事第一让主线程不用为了一个长任务卡住其他所有任务第二把非关键资源的下载和执行挪出首屏关键路径。另一方面网络请求本身其实是系统级异步的浏览器发起一个 fetch 并不会冻结页面。真正影响性能的是请求完成后回调里的处理逻辑——如果回调里做的是大量同步计算或者事件循环正被别的长任务占着那用户还是该卡就卡。理解了这两层就不难明白为什么说异步加载不等于性能优化它只是给优化提供了空间具体省不省时间得看主线程的负担有没有真的降下来。1.3 移动端为什么对异步加载更敏感同样一段脚本在桌面浏览器跑 100ms到了低端安卓机上可能飙到 600ms这种差距来自 CPU 性能、内存带宽、GPU 调度等多个方面。移动端网络环境也更差弱网下任何一个串行请求都可能让白屏时间翻倍。所以移动端性能优化的核心思路往往是“调度”哪些任务必须在启动阶段同步完成哪些可以排到首帧绘制之后哪些可以等用户真正用到时再加载。这一点在 Android 启动优化里特别明显Application 的onCreate里如果堆了一堆初始化逻辑冷启动时间直接失控正确做法是把任务拆成有依赖关系的多个小任务用类似拓扑排序的思路编排执行顺序不依赖 UI 的任务尽量往后放。手游场景也一样场景资源和贴图不可能一股脑全加载进内存必须做异步加载和分包加载。说白了移动端优化的本质不是消灭耗时而是让耗时发生在用户感知不到的时间缝隙里。2. 量化先行用指标找到优化靶点2.1 前端性能指标里最值得盯的六个数不量化就谈优化等于闭着眼睛开车。先看指标才知道问题在哪也才知道改完到底有没有效果。现在前端常用的指标有六个指标含义关注点参考值FP首次绘制白屏结束的标记有没有画面越快越好FCP首次内容绘制出现文字或图片用户能看到内容2.5s 以内LCP最大内容绘制核心内容完全可见用户觉得页面“好了”2.5s 以内TTI可交互时间用户能点击、输入不卡顿越快越好TBT长任务阻塞总时间主线程被长任务占用的程度越低越好CLS累计布局偏移页面元素跳来跳去的程度0.1 以内这里特别提醒一句以前经常听人提 FMP首次有意义绘制但现在业界已经普遍不推荐了因为它的算法不够稳定不同页面算出来的结果波动很大参考价值有限。与其纠结一个不稳定的指标不如把 LCP 和 TBT 盯住。指标的存在不是为了给 KPI 打工而是为了当诊断线索。比如 TBT 高说明主线程上长任务太多这时候你该去查脚本执行CLS 高说明图片没有预留宽高或动态插入内容没占位TTI 靠后往往意味着某段代码在首屏阶段抢了太久主线程。2.2 从 LCP 分解看优化优先级LCP 是个很适合用来定位瓶颈的指标它可以拆成三段LCP TTFB 关键资源加载时间 元素渲染时间。TTFB 高说明网络链路或服务端响应有问题得查 CDN、后端接口、缓存策略关键资源加载时间长八成是脚本阻塞了解析或者图片资源太大元素渲染时间晚通常是主线程被其他任务占满渲染任务排不上队。拿到一条 LCP 数据先拆再定优先级这会比盲目地“哪里慢改哪里”靠谱得多。比如 TTFB 占了 1.5s那你去折腾图片懒加载一点用都没有先把服务端响应速度搞定再说。测量手段也要分场景开发环境的本地调试打开 DevTools 的 Performance 面板和 Network 面板就能录到详细火焰图和瀑布图要算标准化的 Web Vitals 指标可以用 Lighthouse 做实验室测试线上则需要接真实用户监控也就是 RUM用web-vitals这种库采集用户的真实体验数据看中位数和 p75 分位。不同数据各有局限实验室测的是“理想网络环境下这台设备的表现”线上数据反映的是“真实用户五花八门的设备表现”。两个都不能丢我的习惯是开发阶段用 Lighthouse 抓问题上线阶段看 RUM 数据验证效果两边对不上就说明还有缓存或者设备差异没考虑到。3. 异步加载工程化从 script 标签到动态 import3.1 三种加载指令async、defer、动态 scriptHTML 里加载脚本的方式有好几种很多项目用了好几年都还是默认的同步加载这是最可惜的浪费。先把几种方式的区别弄清楚加载方式行为特点适用场景默认同步下载并立即执行阻塞 HTML 解析首屏关键脚本但位置要尽量靠后async下载不阻塞下载完立即执行会抢主线程统计脚本、独立无依赖的脚本defer下载不阻塞HTML 解析完按顺序执行需要操作 DOM 的业务脚本动态 script用 JS 创建标签按需加载用户触发才需要的功能模块代码上差别就是这么简单script srcapp.js defer/script script srcanalytics.js async/script但选型有门道。async和defer都是异步下载区别在执行时机async是下载完立刻执行执行时照样卡主线程而且多个async脚本的执行顺序不保证defer则要等 HTML 解析完再执行并且保持文档顺序。所以项目里依赖 DOM 结构、有先后依赖关系的脚本用defer更稳独立埋点、数据上报这种脚本用async就够。至于动态 script常用于真正意义上的按需加载。注意动态创建的 script 默认是异步的加载第三方 SDK 时经常会用到。但动态脚本的执行时机比较不可控如果后续还有依赖它的代码需要手动做就绪判断。3.2 代码分割与组件懒加载的落地姿势现在工程化项目里最常见的异步加载姿势是动态import()。打包器遇到动态import()会把它单独拆成一个 chunk用户真正走到某个路由时才去请求。// 路由级懒加载示例用的是 VueReact 的 React.lazy 同理 const UserProfile () import(./views/UserProfile.vue)这里的核心原则是先做路由级懒加载再做组件级懒加载。路由是用户访问路径上的天然分界线把每个路由页面拆成独立 chunk首屏只加载当前页需要的代码收益最明显。组件级的懒加载则更适合体积大、不在首屏出现的模块比如富文本编辑器、图表库、地图组件这些动辄几百 KB如果一股脑打进主包首屏直接报废。图片懒加载也一样能原生解决就不要自己造轮子img srcphoto.jpg loadinglazy width800 height600 alt示例图loadinglazy是现代浏览器的原生懒加载能力不用监听滚动事件浏览器自己决定何时加载。但有个细节很多人忽略图片必须写width和height或者用 CSS 的aspect-ratio锁定宽高比。否则图片从高度 0 变成实际高度的过程中页面内容会被挤下去这就是 CLS 飙升的来源。懒加载组件还牵涉到一个体验问题用户点进一个路由如果页面要等代码块下载完才能显示会出现短暂白屏。所以路由懒加载一定要配 loading 状态高级一点的方案配合 Suspense 或者骨架屏。更讲究的做法是提前预判用户长时间停在当前页浏览器空闲时就用prefetch把下一个可能的页面资源先拉下来真到跳转时基本秒开。这个后面网络层还会细说。3.3 移动端、Android 启动与游戏场景的异步调度移动端的资源调度比 Web 更讲究因为设备差异大、网络波动大、内存更紧张。移动端 H5 做大图时我通常会做分级加载先显示一张低清模糊的占位图等高清单下载完再替换视觉上感觉“秒开”实际传输成本还没降。弱网环境更要限制预取不能把所有资源一股脑往后预加载那会让当前页面的关键请求排队排到天荒地老。Android 启动优化是另一个高频场景。冷启动过程里如果有大量 SDK 的初始化任务最直接的做法是全部挪到子线程但这里有个坑有些任务之间是隐式依赖的比如某个 SDK 要在另一个初始化完成后才能调用。简单粗暴地用Thread包一层表面上异步了结果运行的时候各种空指针。一次比较规范的做法是做一个启动任务调度器先把任务之间的关系理成一张有向无环图再按拓扑序并发执行必须依赖 UI 的初始化放到第一帧绘制完成之后用一个IdleHandler或者消息队列的延时去做。有的人还会专门写注解处理器把启动任务自动编排原理都一样。游戏场景的思路也类似Unity 这类引擎里的场景加载、资源包加载基本都是异步接口。手游之所以越来越强调分包下载是因为首包体积直接影响渠道转化率和低端机安装体验玩家进入游戏后再在后台把后续资源包下载完本质上就是把启动阶段的高耗时挪到用户已经沉浸在游戏里的低感知时间窗口。Julia 社区聊性能优化时有个习惯特别重视减少内存分配和避免 GC 停顿因为一次不必要的分配可能导致一整片计算停下来等回收。这个思路放到前端一样适用——异步加载把大任务拆开但每次回调里如果还在创建大量临时对象GC 压力上来了照样会造成间歇性的卡顿。性能问题从来不是一个手段能全部解决的一定要多个层面配合着看。4. 性能优化是一整套链路网络、渲染、内存一个都不能少4.1 网络层让连接和缓存先跑起来异步加载解决的是“什么时候去取”的问题网络层解决的是“怎么取更快”的问题两者必须配合。浏览器提供了一套资源提示语法成本极低但经常被忽略link relpreconnect hrefhttps://api.example.com link reldns-prefetch hrefhttps://cdn.example.com link relpreload hrefcritical.css asstyle link relprefetch hrefnext-page.js这四个指令的区别要搞清楚preconnect是提前建立与目标域的连接省掉 DNS 查询和 TCP/TLS 握手dns-prefetch只提前做 DNS 解析范围更小preload是明确告诉浏览器“这个资源当前页面立刻要用”优先级高prefetch是空闲时去取“未来可能用”的资源优先级低。preload是这里面最容易被玩坏的。有些同学给所有资源都加上 preload结果浏览器把带宽都给了这些资源真正关键的首屏脚本反而被饿死。记住一句话preload 是给当前关键资源用的不是给所有资源用的不确定是不是关键就别 preload。缓存策略也是网络层优化的重头。强缓存Cache-Control让浏览器不再发请求协商缓存ETag让浏览器发请求但命中 304两者结合能保证二次访问时静态资源基本零延迟。再往上就是 Service Worker可以做离线缓存和更精细的缓存策略PWA 应用里经常配合异步加载做“秒开”效果。没有缓存的异步加载只是在第一次访问时感觉还行第二次访问反而可能更慢。4.2 渲染层把主线程时间还给用户主线程是浏览器里最珍贵的资源。按浏览器的标准单个任务执行超过 50ms 就会被标记为 Long Task用户会感觉到卡顿。异步加载的意义之一就是把原来一个 500ms 的大任务拆成一堆 50ms 以内的小任务让中间能插入渲染和响应输入。拆任务的思路有好几种。长列表可以分段渲染一帧只插入一定数量的 DOM 节点剩下的用requestIdleCallback或者定时器分批补上数据密集的渲染逻辑配合 Web Worker 把计算放到后台线程主线程只负责最终绘制页面底部离视口较远的模块可以用 CSS 的content-visibility: auto让浏览器跳过渲染滚动到可见区域再画。还有一个特别常见的坑叫强制同步布局。代码里先读offsetWidth后改style浏览器没法批量处理只能被迫立刻重新布局一读一写之间就已经埋下了性能隐患。正确做法是先把所有要读的值读好再一次性地改样式。这个细节在异步加载后的渲染流程里更容易被放大因为数据到了、页面要插入新内容处理不好就会连续触发多次重排。4.3 内存层异步加载最容易留下的坑这一条平时很少有人讲但线上问题十有八九出在这里。异步加载意味着代码的执行时机往后推迟如果回调、监听器、定时器没有被正确清理它们就会一直留在内存里该执行的时候执行不该执行的时候也在跑。最常见的翻车现场是这三个setInterval里引用了组件状态组件卸载了定时器还在跑给全局对象绑定了事件监听器离开页面时忘了removeEventListenerIntersectionObserver观察了一堆懒加载图片组件卸载后没有disconnect观察器。解决思路其实很朴素所有异步任务都要考虑“用户离开时应该怎么办”。现代浏览器给 fetch 提供了AbortController可以用来取消进行中的网络请求以前根本做不到const controller new AbortController(); fetch(url, { signal: controller.signal }) .then(res res.json()) .then(data render(data)); // 组件卸载或路由切换时 controller.abort();这个能力在异步加载场景里价值巨大用户点进路由 A立刻又切到路由 BA 的请求如果不取消不仅浪费带宽数据回来后还可能覆盖当前页面内容。这类问题就是典型的竞态条件。内存优化跟异步加载是闭环只把加载做完、不做善后清理等于只挖坑不填坑迟早要出事。5. 一次移动端 H5 首屏优化的实战复盘5.1 症状与诊断白屏 3 秒问题出在哪拿一个很典型的项目举例一个移动端 H5 商城首页监控后台显示首屏加载时间平均 3.2 秒用户流失率高。接到这个项目我先不是动手改而是先做诊断跑一遍 Performance 和 Network 面板问题立刻浮出水面整个应用只有一个大 bundleJavaScript 主包 1.2MBgzip 后还有 400 多 KB全部同步加载页面总共触发了 50 多个网络请求大量图片请求集中在首屏带宽争抢严重第三方统计脚本和业务脚本互相挤占主线程Long Task 一只接一只首屏大图没有预连接API 接口的 TTFB 又被排队请求拖慢。把问题归纳成一句话关键路径太长非关键资源又全都堵在关键路径上。这种情况不管做多少异步优化只要第三方脚本和首屏大请求卡在前面后面所有努力都会被抵消。5.2 组合拳改造每一项优化动作对应哪个指标诊断做完改造方案就很清晰了。核心思路是分层处理首屏关键资源保证优先、其他资源能延则延。第一件事还是代码拆分。路由级懒加载直接做首页只加载首屏必要的组件弹窗、详情弹层、用户中心全部拆出去。第三方 SDK 全部改成async或动态注入等页面关键内容稳定后再执行。这一步对 FCP 和 TBT 的改善立竿见影——首屏要执行的 JS 少了主线程空出来了。第二件事是图片策略。首屏大图改用 WebP 格式并给preconnect指定图片 CDN 域名提前建立连接非首屏图片统一加loadinglazy和width/height占位。这样 LCP 元素能更快拿到资源CLS 也压住了页面上不再出现突然挤开内容的现象。第三件事是补充资源提示和缓存。API 域加preconnect接口请求提前关键 CSS 内联进 HTML非关键 CSS 不再阻塞渲染静态资源全部加上强缓存头二次访问基本秒开。这些动作看着零散其实每条都对着指标走懒加载和拆包对应 FCP 和 TTI图片宽高占位对应 CLSpreconnect 和 WebP 对应 LCP。5.3 回归验证优化效果如何量化呈现改造完不能只看“感觉快了”要拿数据说话。同样在低端设备上重新跑一遍性能录制几个核心指标的变化是这样的指标优化前优化后FCP3.2s1.4sLCP4.5s2.1sTTI5.8s2.6sCLS0.240.05实验室数据达标只是第一步。上线之后还要接 RUM持续观察真实用户的 LCP、CLS 和 TBT 分位数。这里我想多说一句性能优化不是做完就完了它需要持续守护。我们团队后来把性能预算写进了 CILighthouse 分数低于阈值就不允许合并代码从根本上防止“一边优化一边回退”。6. 异步加载的典型翻车现场与避坑指南6.1 高频翻车问题与排查方法异步加载用不好反而会带来一堆新问题。我把这些年见过的高频翻车现场整理成一张速查表问题典型症状排查思路解决方案竞态条件快速切换路由后返回的数据覆盖前一个页面看 Network 面板请求顺序和回调时间点AbortController取消过期请求或用递增序号判断响应是否最新懒加载图片导致布局跳动图片加载完成后页面内容突然下移检查 img 是否有明确的宽高设置width/height或aspect-ratio锁定占位异步脚本执行顺序错乱依赖库还没加载完业务代码就执行报错DevTools 里看脚本加载完成时间改用defer保持顺序或动态加载时手动做就绪判断动态 import 失败白屏弱网下路由跳转后页面空白看 Network 是不是 chunk 加载失败给懒加载组件加错误边界和重试按钮定时器或监听器泄漏页面越来越卡切几个页面后内存暴增Performance Monitor 看 JS 内存曲线组件卸载时清理setInterval、addEventListener、IntersectionObserver竞态条件是想重点说的一个。之前有个项目列表页快速切换筛选条件时旧请求的结果总是把新结果覆盖掉用户看到的是“筛选没生效”。原因很简单异步请求的返回顺序不可控后发出去的请求可能先回来先发出去的反而后回来。解决思路就是给每次请求带上一个递增的序列号只有序列号最新的一次响应才允许更新页面。6.2 什么时候不该用异步加载异步加载不是银弹有几种场景我甚至不建议强行用。首屏关键脚本尽量不要追加动态加载这一层。一个脚本是你页面渲染的核心依赖一进来就要执行完才能画内容那defer基本就够没必要再包一层动态加载和 loading 态可能反而多一次请求和不可控的执行时机。体积小、数量大的资源比如几十个 50KB 的小文件强行拆成几百个 chunk 会导致请求数爆炸。HTTP 请求的握手开销和排队时间在这些小文件身上会被无限放大。拆包之前先看 chunk 的实际体积个人习惯是小于 50KB 的模块除非确认用户大概率不会马上用到否则不要拆。还有些资源用户几乎是必点的。比如电商详情页里用户从列表页进详情页的概率极高那详情页的核心图片和关键脚本就值得做prefetch预取而不是等用户点击后才开始异步加载。核心数据也谨慎走异步。如果页面首屏内容完全依赖一个接口接口慢一点骨架屏就挂半天这时候首先要考虑的不是怎么异步加载而是怎么让服务端直出或做 SSR把关键数据在 HTML 里直接带过来。异步加载是手段不是目的目的是让用户感知到的等待时间最短。7. 写在最后把性能优化当成一场长期记账做性能优化这些年我最大的体会是异步加载本身不会让系统变快它只是把一部分开销从“现在”挪到了“未来”。你借出去的时间未来总要有人还——可能是用户的主线程时间可能是设备的内存也可能是团队的维护成本。所以每次做技术方案我都会在脑子里过一遍这笔账最终由谁来付真正靠谱的优化离不开三样东西可量化的指标、可持续的监控以及一个“不自我感动”的态度。回头看看我经手的项目凡是长期稳定的都不是靠那些花哨的框架或黑科技堆出来的反而就是把同步改异步、把大图换格式、把连接提前、把缓存建好这些基本功扎实做了。能做到这三点哪怕你只用了defer和懒加载也能稳稳超过大多数靠堆工具的项目。最后分享一个小习惯每次改完性能相关代码我会拿一台低端机、开一次弱网模拟再重新录一遍 Performance。因为优化是否真的有效最终要看它跑在真实用户设备上是什么样子而不是看它在我的开发机上多流畅。这个习惯帮我避开了无数次“看起来优化了线上毫无变化”的尴尬。