刚开始做前端性能优化的时候我踩过不少坑其中最典型的一个就是代码写完了、功能没问题但页面首屏就是慢白屏时间长用户一进来就想关掉。后来把网络面板打开一看好家伙一堆同步脚本堵在HTML解析的路上一个卡一个整个页面加载过程像早高峰的地铁。从那时候起我意识到一个问题异步加载不是“优化技巧”而是性能优化的地基。你后面做的所有缓存、压缩、拆包如果异步加载这层没做好效果都会打折扣。这篇文章我想把“异步加载与性能优化”这件事拆开讲透包括它背后的原理、常用实现方式、框架里的落地姿势以及我实际排查过的那些问题。内容会偏Web前端但涉及的思路同样适用于移动端、桌面端的资源加载优化。如果你是刚接触性能优化的新手或者正在优化现有项目但总感觉不得要领这篇应该能帮你梳理出一条清晰的路线。我会尽量讲明白“为什么这么做”而不是只告诉你“这么做”。1. 异步加载到底在解决什么问题1.1 同步加载带来的阻塞代价先回到最基础的问题为什么需要异步加载答案只有一个字堵。浏览器解析HTML时遇到普通的script标签会暂停HTML解析立刻去下载并执行这个脚本。下载要花时间执行要花时间期间页面渲染完全停摆。这个过程叫“解析阻塞”。你可能想一个脚本能有多大问题在于一个页面通常不止一个脚本而且这些脚本往往还得按顺序执行。假设你有5个脚本每个1MB带宽只有5Mbps单是下载这5个脚本就要8秒这8秒里用户看到的只有白屏体验能好就有鬼了。同步加载的本质是把“必须做的事”和“阻塞页面”绑在了一起。可是仔细想想很多脚本真的必须在首屏执行吗统计代码为什么不能让页面先出来再慢慢跑埋点上报为什么要等所有DOM解析完才发送功能按钮绑定事件为什么必须先等业务脚本跑完这些问题的答案都是一样的没必要。所以异步加载要解决的就是把“加载和执行”从关键渲染路径里剥离出去让浏览器先干完正事渲染首屏再抽空处理其他杂事。一旦你理解了这层逻辑你会发现自己对页面性能的判断力会明显上升——看到一段代码你会本能地问它真的需要在首屏执行吗它能不能延迟加载1.2 浏览器的“任务调度机制”是异步的地基异步加载能实现靠的是浏览器的事件循环模型。JavaScript是单线程的但浏览器不是单线程的。浏览器有专门的网络线程去下载资源有独立的渲染线程处理解析和绘制在开启多进程架构后这些隔离做得更彻底。JavaScript线程执行逻辑浏览器通过事件循环机制把网络请求、定时器、用户交互这些任务排成队列依次交付给JavaScript线程处理。这样模型就清楚了下载资源这件事根本不需要占用JavaScript线程。你发一个fetch请求浏览器在网络线程里默默下载下载完把结果存到缓冲区等JavaScript线程空闲了再把数据交给它。这个过程里页面该解析解析该渲染渲染两不耽误。异步加载要做的就是充分利用这个能力尽早发起请求、但尽量推迟执行。这里有个重点需要澄清async和defer属性都能实现“不阻塞解析”但它们的行为不一样。defer是下载完也不执行等整个HTML解析完成后按顺序执行所有defer脚本async是下载完立即执行执行时依然可能阻塞解析而且多个async脚本之间没有执行顺序保证。所以如果脚本之间有依赖关系别用async用defer更像如果脚本相互独立、想尽快执行才用async。这个坑我以前踩过两个脚本都用async结果后加载的依赖还没定义完先执行的脚本直接报错白屏。排查了半天最后发现是async顺序问题。你说冤枉不冤枉。2. 异步加载的核心实现方式2.1 动态脚本注入手动控制加载时机用JavaScript动态创建script标签并插入到文档中这是最老派但依然有效的异步加载方式。原理很简单function loadScript(url) { return new Promise((resolve, reject) { const script document.createElement(script); script.src url; script.onload () resolve(script); script.onerror () reject(new Error(Script load error: ${url})); document.head.appendChild(script); }); }每次调用loadScript(/js/sdk.js)浏览器就会去下载这个脚本下载完成后触发onload你在回调里继续跑后续逻辑。这个方案的好处是灵活可以控制某一个脚本在某个业务场景出现时才加载比如用户点击“登录”按钮才加载登录SDK用户打开视频弹层才加载播放器代码。缺点也很明显如果脚本之间有依赖关系你得自己维护加载顺序嵌套一深就变成回调地狱。所以现实中动态脚本注入通常用于加载第三方SDK——独立、无依赖、按需触发非常契合。2.2 ES Module动态import现代工程的标准解原生import()函数是现代浏览器支持得最好的异步加载方案它返回一个Promise可以在代码里任何位置调用。和动态创建script标签相比它不光是“下载脚本”还天然支持模块化async function openReportModal() { const { default: ReportModal } await import(./report-modal.js); const modal new ReportModal(); modal.show(); }这段代码的意思是只有用户触发openReportModal时浏览器才开始下载report-modal.js。如果用户一直不点这个模块永远不会被加载。配合打包工具Webpack、Vite、Rollup等动态import()导入的模块会自动拆分到独立的chunk文件里从而实现“代码分包”。这是现在前端工程里最主流的异步加载方式后面讲框架时会再展开。2.3 图片与资源的懒加载IntersectionObserver大杀器脚本可以异步图片也一样。传统的做法是监听scroll事件计算元素位置来决定是否加载但scroll事件触发频率太高还得自己写防抖和位置计算的逻辑性能和正确性都很难保证。现在首选方案是IntersectionObserver——浏览器原生提供的交叉观察器专门用来监听元素是否进入视口const observer new IntersectionObserver((entries) { for (const entry of entries) { if (entry.isIntersecting) { const img entry.target; img.src img.dataset.src; observer.unobserve(img); } } }, { rootMargin: 200px }); document.querySelectorAll(img[data-src]).forEach((img) observer.observe(img));把rootMargin设成200px可以提前200像素开始加载图片给用户一种“图加载得很快”的感觉等图片真正进入视口时已经下载得差不多了。这个方案不需要自己处理滚动事件浏览器自动管理回调时机性能比传统做法好得多。懒加载不只是图片甚至可以用于iframe、video、组件、路由核心思路一致等它接近或进入视口再拿着真实资源去替换占位标记。3. 前端框架中的异步组件与分包策略3.1 React.lazy与Vue异步组件框架层面基本上都封装好了异步加载的能力。React写React.lazy加Suspenseimport { lazy, Suspense } from react; const HeavyChart lazy(() import(./components/HeavyChart)); function Dashboard() { return ( Suspense fallback{div图表加载中.../div} HeavyChart / /Suspense ); }Vue则是defineAsyncComponentimport { defineAsyncComponent } from vue; const HeavyChart defineAsyncComponent(() import(./components/HeavyChart.vue));这两种写法做的事情本质相同组件首次渲染时才去请求对应的JS chunk未加载完成前显示fallback内容加载完成后渲染真实组件。请注意这里有个关键点不要把首屏大组件也用异步加载。有些同学一听异步加载好就把路由对应的所有页面组件全改成了动态导入结果首屏关键内容反而被延迟了——明明用户进来就要看到的东西你偏要等它下载完才渲染这和同步加载的性能差异只在网络快慢的区别上。异步加载是用来处理“非必要但可能用到”的资源而不是把首屏自己给搞成异步。3.2 Webpack/Vite分包配置里的门道动态import()只负责“写法”真正把这些模块变成独立文件的是打包工具。以Webpack为例动态导入的模块会默认按规则生成chunk。在实际项目中你还需要关注几点配置output.chunkFilename给异步chunk命名最好带上[name]或[contenthash]方便线上排查是哪个chunk出了问题。optimization.splitChunks让多个异步模块公共依赖提取成共享chunk避免重复打包。比如两个动态import的模块都引用了同一个工具库lodash如果不提取lodash会被打进两个chunk造成重复下载。prefetch和preload魔法注释Webpack支持在动态import时声明资源预加载策略const ReportModal await import(/* webpackPrefetch: true */ ./report-modal.js); const DetailPanel await import(/* webpackPreload: true */ ./detail-panel.js);preload是和高优先级的当前任务并行加载prefetch是等浏览器空闲了再下载以后要用的资源。这里经常有人混用结果preload的资源还没用到就占用了带宽反而拖慢首屏。我的经验是首屏几乎马上会用到比如用户交互后立刻展示的弹层用preload将来才可能用到比如滚到页面底部才出现的模块用prefetch。别把两个都无脑打上。3.3 从Web延伸到移动端和桌面端异步加载的思路放在移动端技术栈里同样成立。Android的启动性能优化经常讨论冷启动时间核心手段之一就是把Application初始化阶段的业务模块延迟到首帧渲染完成后再加载。很多第三方SDK都支持这个模式先占个位置启动完成后再异步初始化。手游性能优化里的资源异步加载更是常态场景地图、角色模型、音频文件如果全部同步加载内存和加载时间都扛不住做法就是分场景按需加载、线程流式读取。虽然生态不同但底层逻辑完全一致识别出真正能推迟的工作让关键路径更短让首屏先跑起来。4. 性能优化落地与数据观测4.1 计算异步加载的收益一个简单的量化模型讨论性能优化最怕“感觉变快了”没有数字就没有说服力。做一个粗略的测算假设你有10个同步脚本每个8KB总共80KB。在4G网络下一个RTT往返时延算30ms下载1MB大约需要160ms那么80KB大约需要13ms看起来很快对不对。但问题是同步脚本必须下载完一个再下载下一个每个脚本还要额外消耗一次连接建立和请求往返HTTP/2下可以多路复用但老项目HTTP/1.1很常见同时还要加上脚本解析执行的时间。如果这10个脚本都在HTML解析的首要路径上实际瓶颈往往是“请求串行”而不是流量大小。把脚本改成异步加载后浏览器可以并行下载多个资源关键路径上只保留内联的、必须的少量CSS和JS。以LCPLargest Contentful Paint最大内容绘制为例很多项目的LCP时间可以从2.5秒降到1.5秒以内核心不是流量变少了而是请求变成了并行、执行推后了。做优化前和优化后用Lighthouse或者Performance面板分别测一遍对比LCP、FIDFirst Input Delay首次输入延迟、CLSCumulative Layout Shift布局偏移这三个核心指标优化的收益就非常直观了。4.2 用Performance API记录异步加载的真实消耗除了看面板还可以在代码里自主埋点。浏览器提供了performance.getEntriesByType(resource)能拿到所有资源加载的时间明细const resources performance.getEntriesByType(resource); for (const resource of resources) { console.log(resource.name, resource.initiatorType, resource.duration); }通过initiatorType可以看到这个资源是谁发起的script代表脚本link代表链接预加载fetch代表fetch请求img代表图片。把耗时特别长、而且initiatorType是script的资源挑出来再结合Network面板确认是否在关键路径上往往就能找到性能瓶颈。异步加载做得好不好看这张表就清楚了如果首屏阶段的script资源特别多你要想想哪些可以延后。4.3 资源优先级preload、preconnect和Critical CSS异步加载的一个作者观点是“异步”并不是说所有加载都越晚越好而是越“该早的早、该晚的晚”。首屏关键CSS就应该早甚至要内联首屏背景图和关键LCP元素对应的图片应该用preload告诉浏览器早点下载第三方接口所在的域名应该用preconnect提前建连。link relpreconnect hrefhttps://api.example.com link relpreload href/styles/critical.css asstyle关键CSS内联是性能优化里成本最低、收益最直接的方案。把首屏必须的样式写死在HTML里非关键CSS文件加mediaprint onloadthis.mediaall做成异步加载等页面核心渲染完成后再加载完整样式。这个做法很多老项目还在用虽然现代打包工具都支持Critical CSS插件自动抽取但原理一直没变。5. 常见问题与排查技巧实录5.1 懒加载图片导致布局抖动CLS上升这是懒加载做得不对的典型后果。图片标签没写宽高或者占位图高度和真实图片不一致当真实图片加载完被替换占位时整个页面高度突然被撑开用户正读着文章突然页面跳了一下浏览体验非常糟糕。解决方案是在图片标签上明确设置width和height属性或者用CSS的aspect-ratio固定比例img srcplaceholder.jpg>async function loadModule(importFn) { try { return await importFn(); } catch (error) { console.warn(Chunk加载失败尝试刷新恢复, error); window.location.reload(); throw error; } }刷新后HTML是新的引用的chunk文件名也会是新的旧chunk失效的问题就绕过去了。这个方法简单但非常实用我接手过的中大型项目基本都遇到过这类问题。5.3 预加载和懒加载打架导致资源重复下载很多时候页面同时用了preload和懒加载某些资源明明已经在preload里声明了懒加载逻辑又在元素进入视口时发起加载两个请求都发出去浪费了带宽。排查方法是打开Network面板尝试搜索同一个资源URL有没有出现两次请求。如果有要么把懒加载逻辑里排除已preload的资源要么统一用preload替代懒加载。我见过一个项目首屏背景图同时被CSS加载和JS懒加载触发同两张图下载了四次首屏性能怎么优化都上不去原因就是这么简单。这类问题数据面板上看不出来必须逐一核查请求列表。5.4 异步模块之间共享依赖被重复请求日常开发里多个异步chunk都可能引用同一个业务模块或工具库。如果不做公共依赖提取Webpack会把同一个库打进多个异步chunk造成重复下载和内存浪费。配置splitChunks时把公共依赖提取成单独chunk// webpack.config.js optimization: { splitChunks: { cacheGroups: { vendor: { test: /[\\/]node_modules[\\/]/, name: vendors, chunks: all, }, }, }, }这不是一个“配置完就完事”的任务而是要定期检查产物里chunk的依赖关系。推荐用webpack-bundle-analyzer看产物构成哪个库被多处引用、哪个chunk体积异常一目了然。6. 我踩过的一些坑和总结的思考做异步加载优化这些年我的最大感受是它不是一个“开关式”的功能而是一整套资源调度策略。你不用在这个页面里把所有内容都变成异步也不用执着于把LCP压到零点几秒而是要想清楚哪些资源是用户每次打开页面立刻需要的哪些是这个功能模块用到时才需要的哪些是用户可能用到的。三条类别对应不同的加载策略临界资源立即加载功能资源按需加载未来资源延迟预取。最后再分享一个我实际改项目时发现的小技巧做性能优化时别一上来就改代码。先用Network面板和Performance面板把现状摸清楚记录下当前的LCP、FID、CLS和关键资源的加载时序画一张“资源加载顺序图”哪里堵、哪里冗余自然就清楚了。改完一处再对照这个基线看数字变化。不要只凭感觉改性能优化的好坏最终要拿数据来说话。异步加载这条路越往后越会觉得它不光是技术更是一种思维方式。看代码时多问一句“它真的需要现在跑吗”你会慢慢发现许多性能问题在写代码的阶段就能避免。希望这篇文章能帮你在性能优化的地图上少走几条弯路。
刚开始做前端性能优化的时候我踩过不少坑其中最典型的一个就是代码写完了、功能没问题但页面首屏就是慢白屏时间长用户一进来就想关掉。后来把网络面板打开一看好家伙一堆同步脚本堵在HTML解析的路上一个卡一个整个页面加载过程像早高峰的地铁。从那时候起我意识到一个问题异步加载不是“优化技巧”而是性能优化的地基。你后面做的所有缓存、压缩、拆包如果异步加载这层没做好效果都会打折扣。这篇文章我想把“异步加载与性能优化”这件事拆开讲透包括它背后的原理、常用实现方式、框架里的落地姿势以及我实际排查过的那些问题。内容会偏Web前端但涉及的思路同样适用于移动端、桌面端的资源加载优化。如果你是刚接触性能优化的新手或者正在优化现有项目但总感觉不得要领这篇应该能帮你梳理出一条清晰的路线。我会尽量讲明白“为什么这么做”而不是只告诉你“这么做”。1. 异步加载到底在解决什么问题1.1 同步加载带来的阻塞代价先回到最基础的问题为什么需要异步加载答案只有一个字堵。浏览器解析HTML时遇到普通的script标签会暂停HTML解析立刻去下载并执行这个脚本。下载要花时间执行要花时间期间页面渲染完全停摆。这个过程叫“解析阻塞”。你可能想一个脚本能有多大问题在于一个页面通常不止一个脚本而且这些脚本往往还得按顺序执行。假设你有5个脚本每个1MB带宽只有5Mbps单是下载这5个脚本就要8秒这8秒里用户看到的只有白屏体验能好就有鬼了。同步加载的本质是把“必须做的事”和“阻塞页面”绑在了一起。可是仔细想想很多脚本真的必须在首屏执行吗统计代码为什么不能让页面先出来再慢慢跑埋点上报为什么要等所有DOM解析完才发送功能按钮绑定事件为什么必须先等业务脚本跑完这些问题的答案都是一样的没必要。所以异步加载要解决的就是把“加载和执行”从关键渲染路径里剥离出去让浏览器先干完正事渲染首屏再抽空处理其他杂事。一旦你理解了这层逻辑你会发现自己对页面性能的判断力会明显上升——看到一段代码你会本能地问它真的需要在首屏执行吗它能不能延迟加载1.2 浏览器的“任务调度机制”是异步的地基异步加载能实现靠的是浏览器的事件循环模型。JavaScript是单线程的但浏览器不是单线程的。浏览器有专门的网络线程去下载资源有独立的渲染线程处理解析和绘制在开启多进程架构后这些隔离做得更彻底。JavaScript线程执行逻辑浏览器通过事件循环机制把网络请求、定时器、用户交互这些任务排成队列依次交付给JavaScript线程处理。这样模型就清楚了下载资源这件事根本不需要占用JavaScript线程。你发一个fetch请求浏览器在网络线程里默默下载下载完把结果存到缓冲区等JavaScript线程空闲了再把数据交给它。这个过程里页面该解析解析该渲染渲染两不耽误。异步加载要做的就是充分利用这个能力尽早发起请求、但尽量推迟执行。这里有个重点需要澄清async和defer属性都能实现“不阻塞解析”但它们的行为不一样。defer是下载完也不执行等整个HTML解析完成后按顺序执行所有defer脚本async是下载完立即执行执行时依然可能阻塞解析而且多个async脚本之间没有执行顺序保证。所以如果脚本之间有依赖关系别用async用defer更像如果脚本相互独立、想尽快执行才用async。这个坑我以前踩过两个脚本都用async结果后加载的依赖还没定义完先执行的脚本直接报错白屏。排查了半天最后发现是async顺序问题。你说冤枉不冤枉。2. 异步加载的核心实现方式2.1 动态脚本注入手动控制加载时机用JavaScript动态创建script标签并插入到文档中这是最老派但依然有效的异步加载方式。原理很简单function loadScript(url) { return new Promise((resolve, reject) { const script document.createElement(script); script.src url; script.onload () resolve(script); script.onerror () reject(new Error(Script load error: ${url})); document.head.appendChild(script); }); }每次调用loadScript(/js/sdk.js)浏览器就会去下载这个脚本下载完成后触发onload你在回调里继续跑后续逻辑。这个方案的好处是灵活可以控制某一个脚本在某个业务场景出现时才加载比如用户点击“登录”按钮才加载登录SDK用户打开视频弹层才加载播放器代码。缺点也很明显如果脚本之间有依赖关系你得自己维护加载顺序嵌套一深就变成回调地狱。所以现实中动态脚本注入通常用于加载第三方SDK——独立、无依赖、按需触发非常契合。2.2 ES Module动态import现代工程的标准解原生import()函数是现代浏览器支持得最好的异步加载方案它返回一个Promise可以在代码里任何位置调用。和动态创建script标签相比它不光是“下载脚本”还天然支持模块化async function openReportModal() { const { default: ReportModal } await import(./report-modal.js); const modal new ReportModal(); modal.show(); }这段代码的意思是只有用户触发openReportModal时浏览器才开始下载report-modal.js。如果用户一直不点这个模块永远不会被加载。配合打包工具Webpack、Vite、Rollup等动态import()导入的模块会自动拆分到独立的chunk文件里从而实现“代码分包”。这是现在前端工程里最主流的异步加载方式后面讲框架时会再展开。2.3 图片与资源的懒加载IntersectionObserver大杀器脚本可以异步图片也一样。传统的做法是监听scroll事件计算元素位置来决定是否加载但scroll事件触发频率太高还得自己写防抖和位置计算的逻辑性能和正确性都很难保证。现在首选方案是IntersectionObserver——浏览器原生提供的交叉观察器专门用来监听元素是否进入视口const observer new IntersectionObserver((entries) { for (const entry of entries) { if (entry.isIntersecting) { const img entry.target; img.src img.dataset.src; observer.unobserve(img); } } }, { rootMargin: 200px }); document.querySelectorAll(img[data-src]).forEach((img) observer.observe(img));把rootMargin设成200px可以提前200像素开始加载图片给用户一种“图加载得很快”的感觉等图片真正进入视口时已经下载得差不多了。这个方案不需要自己处理滚动事件浏览器自动管理回调时机性能比传统做法好得多。懒加载不只是图片甚至可以用于iframe、video、组件、路由核心思路一致等它接近或进入视口再拿着真实资源去替换占位标记。3. 前端框架中的异步组件与分包策略3.1 React.lazy与Vue异步组件框架层面基本上都封装好了异步加载的能力。React写React.lazy加Suspenseimport { lazy, Suspense } from react; const HeavyChart lazy(() import(./components/HeavyChart)); function Dashboard() { return ( Suspense fallback{div图表加载中.../div} HeavyChart / /Suspense ); }Vue则是defineAsyncComponentimport { defineAsyncComponent } from vue; const HeavyChart defineAsyncComponent(() import(./components/HeavyChart.vue));这两种写法做的事情本质相同组件首次渲染时才去请求对应的JS chunk未加载完成前显示fallback内容加载完成后渲染真实组件。请注意这里有个关键点不要把首屏大组件也用异步加载。有些同学一听异步加载好就把路由对应的所有页面组件全改成了动态导入结果首屏关键内容反而被延迟了——明明用户进来就要看到的东西你偏要等它下载完才渲染这和同步加载的性能差异只在网络快慢的区别上。异步加载是用来处理“非必要但可能用到”的资源而不是把首屏自己给搞成异步。3.2 Webpack/Vite分包配置里的门道动态import()只负责“写法”真正把这些模块变成独立文件的是打包工具。以Webpack为例动态导入的模块会默认按规则生成chunk。在实际项目中你还需要关注几点配置output.chunkFilename给异步chunk命名最好带上[name]或[contenthash]方便线上排查是哪个chunk出了问题。optimization.splitChunks让多个异步模块公共依赖提取成共享chunk避免重复打包。比如两个动态import的模块都引用了同一个工具库lodash如果不提取lodash会被打进两个chunk造成重复下载。prefetch和preload魔法注释Webpack支持在动态import时声明资源预加载策略const ReportModal await import(/* webpackPrefetch: true */ ./report-modal.js); const DetailPanel await import(/* webpackPreload: true */ ./detail-panel.js);preload是和高优先级的当前任务并行加载prefetch是等浏览器空闲了再下载以后要用的资源。这里经常有人混用结果preload的资源还没用到就占用了带宽反而拖慢首屏。我的经验是首屏几乎马上会用到比如用户交互后立刻展示的弹层用preload将来才可能用到比如滚到页面底部才出现的模块用prefetch。别把两个都无脑打上。3.3 从Web延伸到移动端和桌面端异步加载的思路放在移动端技术栈里同样成立。Android的启动性能优化经常讨论冷启动时间核心手段之一就是把Application初始化阶段的业务模块延迟到首帧渲染完成后再加载。很多第三方SDK都支持这个模式先占个位置启动完成后再异步初始化。手游性能优化里的资源异步加载更是常态场景地图、角色模型、音频文件如果全部同步加载内存和加载时间都扛不住做法就是分场景按需加载、线程流式读取。虽然生态不同但底层逻辑完全一致识别出真正能推迟的工作让关键路径更短让首屏先跑起来。4. 性能优化落地与数据观测4.1 计算异步加载的收益一个简单的量化模型讨论性能优化最怕“感觉变快了”没有数字就没有说服力。做一个粗略的测算假设你有10个同步脚本每个8KB总共80KB。在4G网络下一个RTT往返时延算30ms下载1MB大约需要160ms那么80KB大约需要13ms看起来很快对不对。但问题是同步脚本必须下载完一个再下载下一个每个脚本还要额外消耗一次连接建立和请求往返HTTP/2下可以多路复用但老项目HTTP/1.1很常见同时还要加上脚本解析执行的时间。如果这10个脚本都在HTML解析的首要路径上实际瓶颈往往是“请求串行”而不是流量大小。把脚本改成异步加载后浏览器可以并行下载多个资源关键路径上只保留内联的、必须的少量CSS和JS。以LCPLargest Contentful Paint最大内容绘制为例很多项目的LCP时间可以从2.5秒降到1.5秒以内核心不是流量变少了而是请求变成了并行、执行推后了。做优化前和优化后用Lighthouse或者Performance面板分别测一遍对比LCP、FIDFirst Input Delay首次输入延迟、CLSCumulative Layout Shift布局偏移这三个核心指标优化的收益就非常直观了。4.2 用Performance API记录异步加载的真实消耗除了看面板还可以在代码里自主埋点。浏览器提供了performance.getEntriesByType(resource)能拿到所有资源加载的时间明细const resources performance.getEntriesByType(resource); for (const resource of resources) { console.log(resource.name, resource.initiatorType, resource.duration); }通过initiatorType可以看到这个资源是谁发起的script代表脚本link代表链接预加载fetch代表fetch请求img代表图片。把耗时特别长、而且initiatorType是script的资源挑出来再结合Network面板确认是否在关键路径上往往就能找到性能瓶颈。异步加载做得好不好看这张表就清楚了如果首屏阶段的script资源特别多你要想想哪些可以延后。4.3 资源优先级preload、preconnect和Critical CSS异步加载的一个作者观点是“异步”并不是说所有加载都越晚越好而是越“该早的早、该晚的晚”。首屏关键CSS就应该早甚至要内联首屏背景图和关键LCP元素对应的图片应该用preload告诉浏览器早点下载第三方接口所在的域名应该用preconnect提前建连。link relpreconnect hrefhttps://api.example.com link relpreload href/styles/critical.css asstyle关键CSS内联是性能优化里成本最低、收益最直接的方案。把首屏必须的样式写死在HTML里非关键CSS文件加mediaprint onloadthis.mediaall做成异步加载等页面核心渲染完成后再加载完整样式。这个做法很多老项目还在用虽然现代打包工具都支持Critical CSS插件自动抽取但原理一直没变。5. 常见问题与排查技巧实录5.1 懒加载图片导致布局抖动CLS上升这是懒加载做得不对的典型后果。图片标签没写宽高或者占位图高度和真实图片不一致当真实图片加载完被替换占位时整个页面高度突然被撑开用户正读着文章突然页面跳了一下浏览体验非常糟糕。解决方案是在图片标签上明确设置width和height属性或者用CSS的aspect-ratio固定比例img srcplaceholder.jpg>async function loadModule(importFn) { try { return await importFn(); } catch (error) { console.warn(Chunk加载失败尝试刷新恢复, error); window.location.reload(); throw error; } }刷新后HTML是新的引用的chunk文件名也会是新的旧chunk失效的问题就绕过去了。这个方法简单但非常实用我接手过的中大型项目基本都遇到过这类问题。5.3 预加载和懒加载打架导致资源重复下载很多时候页面同时用了preload和懒加载某些资源明明已经在preload里声明了懒加载逻辑又在元素进入视口时发起加载两个请求都发出去浪费了带宽。排查方法是打开Network面板尝试搜索同一个资源URL有没有出现两次请求。如果有要么把懒加载逻辑里排除已preload的资源要么统一用preload替代懒加载。我见过一个项目首屏背景图同时被CSS加载和JS懒加载触发同两张图下载了四次首屏性能怎么优化都上不去原因就是这么简单。这类问题数据面板上看不出来必须逐一核查请求列表。5.4 异步模块之间共享依赖被重复请求日常开发里多个异步chunk都可能引用同一个业务模块或工具库。如果不做公共依赖提取Webpack会把同一个库打进多个异步chunk造成重复下载和内存浪费。配置splitChunks时把公共依赖提取成单独chunk// webpack.config.js optimization: { splitChunks: { cacheGroups: { vendor: { test: /[\\/]node_modules[\\/]/, name: vendors, chunks: all, }, }, }, }这不是一个“配置完就完事”的任务而是要定期检查产物里chunk的依赖关系。推荐用webpack-bundle-analyzer看产物构成哪个库被多处引用、哪个chunk体积异常一目了然。6. 我踩过的一些坑和总结的思考做异步加载优化这些年我的最大感受是它不是一个“开关式”的功能而是一整套资源调度策略。你不用在这个页面里把所有内容都变成异步也不用执着于把LCP压到零点几秒而是要想清楚哪些资源是用户每次打开页面立刻需要的哪些是这个功能模块用到时才需要的哪些是用户可能用到的。三条类别对应不同的加载策略临界资源立即加载功能资源按需加载未来资源延迟预取。最后再分享一个我实际改项目时发现的小技巧做性能优化时别一上来就改代码。先用Network面板和Performance面板把现状摸清楚记录下当前的LCP、FID、CLS和关键资源的加载时序画一张“资源加载顺序图”哪里堵、哪里冗余自然就清楚了。改完一处再对照这个基线看数字变化。不要只凭感觉改性能优化的好坏最终要拿数据来说话。异步加载这条路越往后越会觉得它不光是技术更是一种思维方式。看代码时多问一句“它真的需要现在跑吗”你会慢慢发现许多性能问题在写代码的阶段就能避免。希望这篇文章能帮你在性能优化的地图上少走几条弯路。
