做性能优化这几年我最大的一个体会是大部分页面卡顿和启动慢根子往往不在代码执行效率而在于资源是怎么被加载的。异步加载这四个字看起来基础到不能再基础但它恰恰是整个性能体系里最容易被轻视、也最容易翻车的环节。今天这篇就来把异步加载与性能优化这件事讲透——从浏览器底层的事件循环机制到移动端启动链路的异步改造再到性能指标的量化归因一套走完。无论是写 Web 前端、小程序还是做移动端容器化这篇都能给你一套能直接拿去用的思路。看之前已经有经验的可以直接跳到第 3、5 部分基础偏弱的建议从头顺着读我把原理和实操串在一起讲。1. 为什么说异步加载是性能优化的命门1.1 同步执行的阻塞本质一条车道的收费站先建立一个最朴素的认知HTTP 请求本质上是一个异步过程。你的代码发出一条网络请求数据包要经过 DNS 解析、TCP 建连、TLS 握手、服务端处理、响应传输这一整趟下来少说几十毫秒、多则几秒。如果程序是一个严格执行做完这件事再做下一件事的暴君那么在请求返回之前后面所有的代码都只能干等着——这就是同步阻塞。放到浏览器的场景里会更具象。当 HTML 解析器读到script src...这种普通标签时会立刻暂停 DOM 解析先把这个脚本下载下来、执行完再继续往下解析。此时整个页面渲染就像一条原本双向八车道的高速路在收费口被收窄成了一根独木桥所有经过的车都得排队交费而开源脚本的下载速度、目标服务器的响应速度决定了过收费站的排队时长。我见过不少线上事故的根因就是这里首屏 HTML 里埋了一个外部统计脚本源站一抖动整站白屏好几秒。所以异步加载之所以能成为性能优化的基石本质上是在对抗串行等待这个天然敌人。你不需要提高某个环节的速度只要让多个环节同时进行整体的体感耗时就会肉眼可见地缩短就像收费站开了 ETC 专用通道正常车辆减速通过不再被迫停车排队。这也是后面所有优化策略的逻辑起点。1.2 事件循环与异步调度理解谁在背后干活要把异步加载做对光知道异步好是不够的你得知道异步代码到底是怎么被调度执行的。JavaScript 是单线程语言同一时间只能干一件事但浏览器这个宿主环境并不是单线程的。它就像一个餐厅前台点单的服务员只有一个主线程但后厨可以同时开好几个灶网络线程、定时器线程、渲染线程。服务员把一张菜单递进后厨并不会站在窗口等到菜出锅才接待下一位客人而是在菜单上夹个夹子注册回调然后继续接待别的客人。菜做好了后厨按顺序把菜放到出餐口服务员只有忙完手头的事才会来取。放在浏览器里这套机制就是事件循环主线程把任务列表里的任务按顺序取出来执行执行完毕后再取下一个而异步操作网络请求、定时器、事件回调完成后会把对应的回调塞进任务队列排着队等主线程来取。这里有一个经常被忽略的细节任务队列其实分为**宏任务macrotask和微任务microtask**两类。微任务比如 Promise.then 里的回调会在当前宏任务结束之后、下一个宏任务开始之前把队列里所有微任务一把清空而宏任务一次只取一个。这个差异直接决定了异步代码的执行顺序。举个例子console.log(1); Promise.resolve().then(() console.log(2)); setTimeout(() console.log(3), 0); console.log(4); // 输出顺序1、4、2、3如果不理解微任务机制你可能以为输出是 1、2、3、4但实际上Promise的回调是微任务会抢在setTimeout这个宏任务之前执行。做异步加载时这种顺序感知异常重要你可能靠Promise管理加载流程也可能用setTimeout做延迟加载如果没想清楚优先级轻则顺序错乱重则出现白屏、重复初始化、资源加载竞态等诡异问题。这块的坑我在第 5 部分会专门展开。2. 浏览器端异步加载的完整武器库2.1 四种异步加载手段到底该选哪个浏览器原生给前端工程师提供了不止一种异步手段但很多人把它们混为一谈其实每一种的语义和适用场景都不一样。我先把它们拉出来做个硬核对比加载方式下载时机执行时机执行顺序适用场景普通script解析到即下载下载完成后立即执行阻塞后续解析几乎没有应当避免async解析到即下载下载完成后立即执行乱序先下载完先执行独立无依赖的脚本埋点、统计、AB 实验defer解析到即下载DOM 解析完成后执行按文档顺序执行需要操作 DOM 的业务脚本、依赖关系明确的脚本typemodule解析到即下载DOM 解析完成后执行按依赖图顺序执行现代打包产物的标准加载方式async和defer长得很像但差别非常微妙。async脚本下载时不阻塞解析可一旦下载完成它会立刻执行——这个执行动作本身仍然会阻塞 DOM 解析和渲染。而defer脚本不仅下载不阻塞执行也被推迟到了文档解析完成之后并且多个defer脚本依然保持它们在 HTML 里的相对顺序。提示如果脚本之间有依赖关系绝对不要用async。它讲究谁先回来谁先执行两个async脚本一个引用了另一个的全局变量很可能第二个先执行直接报undefined。反过来defer能保证顺序适合所有需要按部就班的场景。另一个容易踩的坑是defer只对外部脚本有效内联脚本加了defer属性会被无视。所以如果你想把一段依赖外部库的内联初始化代码延迟执行正确做法是把初始化逻辑写进一个函数在目标脚本的onload回调里调用它或者干脆把整段逻辑也抽成独立文件用defer加载。2.2 preload/prefetch/preconnect让加载提前发生异步加载的另一种思路是在不阻塞的前提下把加载时机提前。这就是link relpreload、link relprefetch和link relpreconnect存在的意义。它们看着像同一家人的三兄弟但目标完全不同preload提前加载当前页面马上要用、但浏览器还没意识到要下载的关键资源比如首屏 CSS 里引用的字体、背景图、或者通过 JS 动态插入的大图。它告诉浏览器这个资源优先级很高请尽快下载别等用到的时候才去下。但这属于提前下注如果预加载了却没用到等于白白占用带宽。prefetch提前下载下一页面/后续交互才会用到的资源优先级比 preload 低。浏览器会在空闲时间下载下载完成后放进缓存等用户真的跳到下一页直接零延迟读取。preconnect在当前页面提前完成与目标域名的 DNS 解析、TCP 握手和 TLS 协商节省掉后续请求最关键的前置耗时。对第三方 CDN、接口域名尤其有效。dns-prefetchpreconnect 的轻量版只做 DNS 解析支持的浏览器更多但效率也相对低一些。用起来非常简单放在 HTML 的head里即可link relpreload href/static/fonts/main.woff2 asfont typefont/woff2 crossorigin link relpreconnect hrefhttps://api.example.com link reldns-prefetch hrefhttps://cdn.example.com link relprefetch href/static/js/chunk-report.a1b2c3.js asscript这里有两个高频翻车点。第一preload字体或图片时必须带上crossorigin属性别问为什么不带就是加载不到第二preload和prefetch是竞争关系一个抢带宽一个让带宽不能同时对一个资源使用。我见过有人把同一个首屏图片同时写了 preload 和 prefetch浏览器一脸懵行为降级为普通请求。2.3 一套可直接复用的异步资源加载方案看完原理我们落地一套可用、可复制的资源异步加载方案。基本原则是核心渲染链路上的脚本用 module/defer 同步进首屏非关键的脚本用动态 import 按需加载再配合 preload 把最最关键的一两个资源往前提。现代打包工具已经把动态 import 封装得极其顺手了。以 Vite/Webpack 项目为例// 需要用户滚动到评论区才加载的讨论组件 const CommentArea () import(./components/CommentArea.vue); // 点击导出按钮时才加载的导出逻辑 exportButton.onclick async () { const { exportTable } await import(./utils/exporter); exportTable(data); };打包后这些组件会自然被拆成独立 chunk在需要的时候才发起请求。这是懒加载的标准姿势。但如果业务场景不是打包工具管理的前端工程而是原生 HTML 第三方 SDK 的传统页面呢那就需要自己封装一个加载器。我这些年一直在用一个极简版本核心逻辑就是缓存 Promise保证同一个脚本无论被多少个地方请求最终只加载一次const scriptCache new Map(); function loadScript(src) { if (scriptCache.has(src)) return scriptCache.get(src); const promise new Promise((resolve, reject) { const script document.createElement(script); script.src src; script.async true; script.onload resolve; script.onerror () reject(new Error(Script load failed: ${src})); document.head.appendChild(script); }); scriptCache.set(src, promise); return promise; } // 使用 async function initDashboard() { await loadScript(/sdk/chart-lib.js); await loadScript(/sdk/chart-plugin.js); drawChart(); }这比直接document.write插脚本或者字符串拼接脚本标签靠谱得多既有错误处理又有 Promise 缓存加载失败重试、多模块依赖加载这些问题都能在这个基础上扩展出来。懒加载不是目的让加载过程可控、可预期才是目的。3. 移动端异步加载与启动性能优化实战3.1 启动链路拆解每一跳都有异步改造点聊完浏览器我们把目光转到移动端。随着混合开发和小程序生态的成熟很多团队的页面早就不只是纯 WebView 了——Native 壳里嵌着多个 WebView、小程序分包、React Native 桥接这些场景下异步加载与性能优化的重要性甚至比纯浏览器端更高。原因很简单移动端网络更差、设备性能更弱、用户耐心更少。先拆解一次典型的移动端冷启动链路Native 壳启动 → 创建 WebView → HTML 下载 → 首屏渲染 → 资源就绪。这个链路里每一跳都有异步改造的空间。我拿优化 Android 启动性能的实战经验来说很多应用启动慢最大的元凶之一是Application.onCreate里同步初始化了海量 SDK——地图、推送、埋点、热修复一个比一个重全部堆在主线程上执行导致首帧迟迟画不出来。优化思路并不复杂把那些不与首屏直接相关的初始化全部挪到子线程或者延迟到首帧之后。比如地图 SDK 这种重量级选手用户进入首页地图页才需要完全没有理由在冷启动阶段抢占主线程。但这里有个前提能异步化不等于一定能异步化。有些 SDK 内部会默认把回调抛回主线程如果连它自身的初始化都是分线程完成的回调时序就会变得很微妙容易出现我们在子线程初始化完成了但访问它的时候内部状态还没就绪的诡异问题。注意做启动异步改造时先画清楚主线程依赖关系图。凡是首屏 UI 直接依赖的初始化必须留在主线程凡是不依赖 UI、UI 也不依赖它的大胆丢到后台凡是UI 不依赖它但它内部偷偷依赖主线程的这种最阴间需要通过插桩先查出它的真实行为再决定归类。3.2 线程模型与异步调度别把异步做成晚点做移动端做异步加载绕不开线程调度这道坎。一个常见的误解是异步加载 把任务往后排。但真正的异步优化是在正确的线程、正确的时机做正确的事。它解决的是时机错配导致主线程空转或阻塞的问题而不只是时间平移。以 Android 为例主线程负责 UI 渲染和输入响应IO 线程负责网络和磁盘读写但最终 UI 更新必须回到主线程。如果异步加载完资源后直接在主线程执行重活比如把一个几 MB 的 JSON 解析放在回调里首帧是提前了但紧接着会来一个长任务把页面卡住。正确姿势是回调里继续分线程做解析解析出纯数据后再把更新 UI这一小段提交回主线程// Android 侧常见写法 loadDataAsync(new CallbackData() { Override public void onSuccess(Data raw) { executor.execute(() - { // 分线程解析、裁剪、处理数据 Data parsed parseData(raw); runOnUiThread(() - renderUI(parsed)); }); } });iOS 侧的思路完全一致DispatchQueue.global().async做耗时任务DispatchQueue.main.async更新 UI。这里头的性能细节在于线程池的复用频繁创建和销毁线程的开销并不小正确做法是使用线程池或系统提供的并发队列控制并发数避免几十个任务同时涌入把系统资源打满。这个道理放到游戏和重度交互应用里体会更深。手游场景下模型、贴图、音频动辄几百 MB如果全部同步加载进战斗场景直接卡到幻灯片。所以主流的做法是异步资源加载 优先级队列 预加载进入战斗前先预加载核心资源战斗中按需动态加载次要资源并且把加载任务按当前位置是否可见排优先级镜