1. 异步加载的本质为什么它是性能优化的第一课先别急着看代码。搞懂异步加载这件事得从浏览器怎么“干活”说起。标题里“02-08-原理篇”这个编号一看就是系统课程里的章节但放到实际工作中异步加载和性能优化从来不是两个孤立的关键词——它们是一件事的两面你异步加载做得怎么样直接决定了性能指标的上限而性能优化的所有手段本质上都是在跟浏览器的同步阻塞机制较劲。我见过太多项目功能没问题但首屏白屏时间能到三秒以上用户早就划走了。查下来十有八九是同步脚本一堆、图片全部直接加载、路由页面打包成一个巨大的 bundle。这些问题的根源就是没有把“异步加载”这四个字刻进开发习惯里。这篇文章会从浏览器渲染的底层原理讲起把 async、defer、动态导入、懒加载这些方案的适用场景捋清楚再落到具体的量化指标和排查方法上。内容不挑框架React、Vue、原生 JS 都适用做移动端 H5、小程序、甚至是混合 App 的同学同样能直接套用里面的思路。2. 核心机制拆解浏览器渲染管线与脚本加载模型2.1 渲染管线从 HTML 字节流到像素要理解为什么同步加载会卡你得先知道浏览器拿到 HTML 后做了什么。整个过程大致是网络线程收到 HTML 字节流 → 交给主线程的 HTML 解析器逐行解析 → 解析过程中遇到link就去下载并构建 CSSOM遇到script就暂停 DOM 构建、下载并执行脚本 → 等 DOM 和 CSSOM 都就绪才进入布局Layout、绘制Paint、合成Composite阶段。这里最关键的瓶颈是脚本执行会阻塞 DOM 构建。浏览器在解析 HTML 时遇到普通script会停下来等脚本下载完成、执行完毕再继续往下解析。有人统计过一个位于head里的 100KB 同步脚本在低速网络下能把首屏渲染推迟整整一两秒。这不是夸张是浏览器规范里白纸黑字的行为——普通脚本的下载和执行都会阻塞解析器。那 CSS 呢CSS 不会阻塞 DOM 构建但会阻塞渲染。因为浏览器必须等 CSSOM 完整才能算出元素的最终样式并绘制。所以业界有个经典说法CSS 尽量放头部JS 尽量异步放底部。前者是为了提前构建 CSSOM 避免白屏后者是为了减少脚本对 DOM 解析的干扰。2.2 三种脚本加载姿势默认、async、defer这是异步加载最基础、也最容易被用错的点。先记住一个结论能 defer 就别 async能异步就别同步。加载方式下载时机执行时机DOM 构建是否被阻塞典型适用场景默认同步遇到即下载下载完立即执行是首屏必须依赖的极小体积脚本async遇到即下载与 HTML 解析并行下载完立即执行时机不确定否但执行时可能打断解析独立无依赖的统计、埋点脚本defer遇到即下载与 HTML 解析并行HTML 解析完成后、DOMContentLoaded 前执行否大多数业务脚本、有依赖关系的脚本举两个实际例子。页面里要接入一个第三方埋点 SDK它不依赖任何业务代码业务代码也不依赖它那就用async放head里谁先下载完谁先执行互不干扰。但如果你的业务脚本依赖 jQuery、或者依赖某个 polyfill就必须用defer——defer 脚本按文档顺序执行能保证依赖关系。这里有个坑必须提醒async 脚本的执行时机不可预测。它在下载完成后立刻执行而此时解析器可能正解析到页面中间位置脚本一旦执行照样会打断解析。换句话说async 只是把“下载”异步化了执行仍然是抢占式的。所以 async 只适合完全自治的脚本。我接手过一个项目把首屏一个初始化 SDK 的脚本标成了 async结果它比业务脚本先执行依赖的全局变量没准备好线上直接报错。排查半天改成 defer 之后问题消失。2.3 看得见的异步动态 import 与代码分割站在打包工具的角度import()语法是前端异步加载的主战场。Webpack、Vite、Rollup 都把它当作代码分割的分界点遇到动态 import就会单独打出一个 chunk只有运行时真正执行到这一行才会去下载。// 路由级懒加载Vue 3 配合 Vite 的常见写法 const routes [ { path: /dashboard, component: () import(/views/Dashboard.vue) } ] // React 18 里更推荐的配合方式 const Dashboard lazy(() import(/views/Dashboard)) function App() { return ( Suspense fallback{PageLoading /} Dashboard / /Suspense ) }动态 import 背后其实是一个典型的 Promise 加载流程Webpack 会把动态模块单独打包运行时生成一个 script 标签去请求这个 chunk加载完成后再 resolve 模块。这个机制性能优化的意义在于首屏只需下载首屏用的代码。一个中型后台系统按路由拆完之后首屏 JS 能从 800KB 降到 200KB压缩后 gzip 可能只剩 60KB加载速度是完全不同的量级。除了按路由拆还有一个容易被忽略的拆法按“交互时机”拆。比如富文本编辑器、图表库、PDF 预览这种体积大、又不是一进页面就用的组件完全可以等用户真正点开时再去 import。我做过一个数据大屏项目ECharts 一开始是整个引进去的首屏资源多了快 1MB。改成点击图表按钮后才import(echarts)并把 ECharts 的模块按图表类型再做二次拆分首屏加载直接快了 40%。这就是“用到才下载”的威力。3. 实操落地主流异步加载方案与参数调优3.1 图片懒加载IntersectionObserver 的正确用法图片是网页里体量最大的资源类型尤其是电商、资讯、图片社区这类页面。以前流行用滚动监听 距离判断实现懒加载但那个方案有两个问题一是主线程上绑 scroll 事件滚动时频繁计算性能开销大二是判断逻辑要自己写容易出边界 bug。现在浏览器原生提供了 IntersectionObserver它用独立的合成器线程来检测元素与视口的交叉状态不占用主线程。这段代码可以直接抄const observer new IntersectionObserver((entries) { for (const entry of entries) { if (entry.isIntersecting) { const img entry.target img.src img.dataset.src img.onload () img.classList.add(loaded) observer.unobserve(img) // 加载完就停止观察别浪费性能 } } }, { rootMargin: 200px }) // 提前 200px 开始加载体感更顺滑 document.querySelectorAll(img[data-src]).forEach(img observer.observe(img))rootMargin值得多说几句。很多人习惯设 0那要等图片真正滑进视口才开始加载网络慢的时候会看到明显的“先空白后出图”。我实测下来移动端设 100~300px 的提前量比较合适既能提前加载又不会往下滑动很多屏时把底部图片全部提前请求。另外懒加载图片一定要在img上写固定宽高或者给最外层容器一个宽高比比如 CSS 的aspect-ratio否则图片加载完会撑开布局页面元素发生跳动直接踩到 CLS 指标的红线。3.2 资源预加载Preload、Prefetch 的取舍懒加载是“用到才下”预加载则是“提前下”。Preload 和 Prefetch 很多人混着用其实是两码事。Preload 告诉浏览器这个资源当前页面马上就要用到请以最高优先级下载Prefetch 则说这个资源将来可能用你空闲的时候下载缓存起来。它们的优先级、触发时机都不同。!-- 当前页面马上要用最高优先级 -- link relpreload href/fonts/Inter.woff2 asfont typefont/woff2 crossorigin !-- 下一个路由可能用空闲时下载 -- link relprefetch href/chunks/detail.a1b2c3.js字体是做 Preload 最常见的场景。如果你用了font-display: swap浏览器默认要等 CSS 解析完、发现需要这个字体后才开始下载字体文件首屏文字就会出现一段“字体闪变”。加了 Preload 后字体下载和 HTML 解析并行通常能在第一次绘制前完成。这里有个最容易踩的坑字体文件在跨域加载时必须加crossorigin属性哪怕你的字体和页面同源。这个属性对很多开发者来说是玄学我刚开始也踩过——不加这个属性字体 Preload 会被浏览器直接忽略虽然不报错但没有效果检查半天才发现是少了一个属性。Preload 和 Prefetch 的优先级差异用 WebPageTest 的瀑布图能看得很清楚。Preload 的请求几乎紧跟在 HTML 请求之后Prefetch 则要等主资源加载完、浏览器空闲了才发起。所以首屏关键资源用 Preload下一屏可能用到的资源用 Prefetch。反过来用就出问题——把首屏关键 JS 标成 Prefetch等它下完再执行首屏反而更慢。3.3 动态导入的工程化配套命名 chunk 与预加载联动光是把代码拆了还不够工程化上要处理好 chunk 命名的稳定性和预加载的联动。Webpack 和 Vite 都支持在动态 import 时加魔法注释const Chart () import(/* webpackChunkName: chart, webpackPrefetch: true */ ./Chart)webpackChunkName的作用不只是给分片起个可读名字它还决定了 chunk 名的稳定格式。稳定的 chunk 名对 HTTP 缓存很有意义——文件名里带 contenthash内容没变就不会重新下载。而webpackPrefetch会在浏览器空闲时自动下载这个 chunk比如用户停留在列表页时提前把详情页的 chunk 拉到本地点击跳转时几乎秒开。这里我特别想强调一个团队协作层面的点代码分割的粒度要跟团队约定俗成。有些团队为了“极致首屏”一个按钮就一个 chunk结果 chunk 数量几百个HTTP 请求太多反而拖慢页面。现代浏览器支持 HTTP/2 多路复用但过多的请求和 DNS 查询依然有开销。我自己的实践标准是三个层级路由级必拆、大体积第三方库单独拆、交互级组件在体积超过 50KB 或使用率低时才拆。粒度太细维护成本和请求成本都会上升性能优化也要讲性价比。4. 性能优化全景从加载到渲染的量化指标与工具链4.1 Core Web Vitals把优化目标数字化没有指标的性能优化都是耍流氓。Google 提出的 Core Web Vitals 是业内事实标准也是搜索引擎排名考量因素。用它可以把你“页面有点慢”这种感觉变成可量化的数字。指标全称度量内容合格线满分线LCPLargest Contentful Paint最大内容元素渲染时间 2.5s 1.2sINPInteraction to Next Paint交互到下一次绘制的延迟 200ms 100msCLSCumulative Layout Shift页面累积布局偏移 0.1 0.05LCP 是加载性能最直观的镜子它衡量的是最大图片、标题块这类元素的渲染时间。异步加载的优化效果会直接反映在 LCP 的曲线上。我习惯把 LCP 拆成四个阶段去看TTFB网络与服务器时间、资源加载时间、元素渲染时间、以及三者之间的空闲等待。很多时候 LCP 慢并不是下载慢而是某个同步脚本把渲染主线程占用太久——这时候你去压缩图片、优化带宽都没用正确的解法是把脚本改异步让出渲染时机。INP 是新版 Web Vitals 里替换 FID 的指标它评估的是用户从点击到界面响应的整段延迟。异步加载如果做得不好比如懒加载的组件点击后才开始下载用户会有明显的“卡一下”体验INP 就会飙升。所以交互组件的懒加载不是无脑用关键交互路径上的组件要预加载非关键路径的才懒加载。4.2 性能观测方法Lighthouse 与 WebPageTest 的组合拳实际工作中我很少只依赖一个工具。Lighthouse 适合日常快速体检它给出的评分和 Opportunities 列表能帮你快速定位最大的性能缺口。但 Lighthouse 跑的是本地模拟环境网络是限速过的它反映的是“接近真实的性能底线”不是线上真实体验。要拿到线上真实数据我推荐两条路并行。第一条是浏览器内置的 Performance 面板录制页面加载过程瀑布图里能看到每个请求的耗时、阻塞情况和优先级。第二条是 RUMReal User Monitoring数据国内常用的是自己埋点上报把performance.getEntriesByType(navigation)里的 TTFB、DOMContentLoaded、LCP 数值上报到日志系统看真实用户分布。我自己在团队里推的最小方案是Performance API 采数据 上报到已有日志平台一天时间就能搭完却能提供持续的性能回归监控。性能监控最忌讳“看单点”。单看某个 case 的 LCP 涨了没有意义要结合网络环境、设备档位、页面版本一起看。App 端用户、4G 网络用户、千元机用户的性能数据跟公司 WiFi 下的开发机完全是两个世界。这也是为什么我一直强调移动端性能优化的思路跟桌面端不一样。4.3 工具链之外的思维优先级与取舍做性能优化本质是资源调度。浏览器里每个资源都有优先级从 Highest 到 Lowest关键资源、脚本、图片、字体分布在不同的优先级层级。Preload 能拔高优先级异步加载能降低紧急度——优化的核心思路就是让每类资源都待在合适的优先级上。举个很典型的例子。首屏背景图是一张 2MB 的大图LCP 一直上不去。你以为是图的体积问题实际上可能是这个背景图被浏览器判断为非首屏关键资源优先级排到了很低的位置下载顺序被延后。解决办法不是压缩图而是用fetchpriorityhigh把它的优先级提上来甚至拆成首屏可见部分的局部图低清占位图。优先级调对了加载速度快 50% 都不夸张。5. 常见问题与排查技巧实录5.1 异步顺序引发的“幽灵 Bug”Async 脚本执行顺序不确定这是异步加载最典型的坑。具体现象是页面偶尔正常偶尔报“某某 is not defined”而且只在弱网或缓存的情况下出现。排查思路不要从代码逻辑找要先看资源加载顺序。打开 DevTools 的 Network 面板把“Priority”列显示出来对比几次加载的瀑布图看脚本执行的先后顺序是否一致。如果出现顺序漂移检查这个脚本是不是被标成了 async——如果是要么改成 defer要么把它合并到业务主脚本里。经验法则同一份代码里有依赖关系的脚本永远不要用 async。5.2 懒加载引发的 CLS 布局跳动很多团队上了图片懒加载之后CLS 指标突然变红原因就是没预留图片占位空间。浏览器首次绘制时懒加载的图片还没有高度等它加载完成后高度撑开下面的所有内容都被挤下去布局偏移就产生了。解法我有三个推荐一是给img设置固定宽高二是用 CSSaspect-ratio锁宽高比配合宽度自适应三是最稳妥的让后端在下发图片 URL 时同时下发宽高数值或者图片接口返回头里带宽高信息。我见过一个内容瀑布流项目用第三种方案把 CLS 从 0.32 降到了 0.02效果立竿见影。5.3 动态 import 的路由懒加载白屏闪烁Vue 路由懒加载后切换路由时经常有一个短暂的白屏过程因为 chunk 下载需要时间。很多人会加一个全屏 loading但全屏 loading 反而会造成布局跳动和闪烁感。我推荐的做法是给路由组件套一个 Suspense配合一个跟页面骨架一致的占位符或者只在高频路由上做 Preload。前置的预防更重要在用户进入列表页时就 Prefetch 详情路由的 chunk。Vue Router 里可以监听路由变化下一跳的路由提前加载Vite 下直接用import(/* vite-ignore */ url)结合预取接口。React 生态里loadable/component也提供了preload方法。别再让用户点了按钮才去下代码这才是异步加载的正确姿势。5.4 常见问题速查表现象可能原因优先排查方向脚本偶尔报未定义async 脚本顺序漂移Network 面板看执行顺序改 defer首屏图片出现慢图片未被识别为 LCP 元素加fetchpriorityhigh检查是否懒加载误伤字体闪烁字体文件加载晚link relpreload配crossorigin路由切换白屏chunk 未预加载加 Prefetch 或预取接口页面滚动卡顿懒加载监听频繁触发检查是否还在用 scroll 事件换 IntersectionObserverCLS 指标超标图片/广告位无占位固定宽高或aspect-ratio6. 移动端与更多场景的扩展思考6.1 移动端性能优化更严格的带宽与设备约束近年热搜里手游性能优化、移动端性能优化、优化 Android 启动性能这些词频繁出现说明性能优化的语境早已超出 Web 页面。移动端的物理环境决定了它跟桌面端思路不同CPU 主频低、内存小、网络抖同样是异步加载移动端要额外考虑省电和省流量。在移动端做异步加载我最常用的三条原则一是首屏资源控制在 100KB 以内gzip 后二是所有图片走 CDN 且开启 WebP/AVIF 自适应三是把第三方 SDK 全部异步化且延迟到页面空闲时再初始化。Android 启动性能优化有专门的方法论启动阶段的应用 onCreate、首帧绘制、线程调度都会影响冷启动速度。本质上跟 Web 首屏优化是同一个逻辑把必须在关键路径上的工作最小化把非关键路径的工作往后推。6.2 从 Web 到跨端异步加载的通用心智模型React Native、Flutter 这些跨端框架里照样有包体积优化、路由懒加载、图片缓存这些概念。Julia 这类高性能计算场景聊性能优化与内存管理又是另一套体系——它更关心编译与运行时的 JIT 开销和 GC 停顿看起来跟前端不搭边但底层的调度思想是相通的把贵的操作推迟到必须执行时把高频操作优化到零成本。我做性能优化这几年最大的体悟是不要被“某项技术”框住。异步加载只是手段性能优化是个持续逼近的系统工程。一次优化做完不是终点线上数据会告诉你哪里还有缺口用户行为会告诉你资源优先级排错没有。我现在的做法是每次版本迭代都跑一遍 Lighthouse并盯住 RUM 数据里的 P75 分位数——这个习惯比任何性能方案都管用。最后再分享一个小技巧做异步加载改造时不要一次性全量上。先挑一个最痛的页面改完对比前后的性能数据把收益量化出来再横向复制到其他页面。用数据说话比跟团队讲任何大道理都有效。性能优化这条路每个项目都值得走一遍而且越早走收益越大。