服务器响应用了 800ms首屏就是等这个 JS 下载完才开始渲染用户盯着的就是一个白屏。后来我把路由改成动态 import首屏只加载当前页面需要的代码瞬间从 3 秒出页面压到了 1.2 秒。这个改动前后不到 10 行代码但背后涉及的正是“异步加载”这套机制。这篇原理篇我打算把异步加载这件事彻底讲透——它到底解决什么问题、底层是怎么办到的、实际落地时该选哪种方案、优化效果怎么量化以及我在移动端和手性能优化里踩过的那些坑。适合前端开发者、移动端工程师还有对 Web 性能优化感兴趣的技术同学参考。看完之后你能明白的不只是“该用懒加载”而是知道为什么该用、什么时候用、用了之后怎么验证效果。1. 异步加载解决的核心问题渲染进程为什么会被卡死1.1 浏览器解析和渲染的底层流程要理解异步加载的价值先得搞清楚浏览器是怎么把一个 URL 变成用户能看到的页面的。整个过程大致分这几步拿到 HTML 后解析器边读边构建 DOM 树遇到link标签去请求 CSS 构建 CSSOM遇到script标签如果是普通同步脚本立即下载并执行然后才能继续解析后面的 HTML。这里有个容易被忽视的关键点DOM 构建和 CSSOM 构建是两个独立的线程但 JavaScript 的执行必须在主线程上。主线程是个单线程环境同一时间只能干一件事。同步脚本一旦开始执行DOM 解析就得暂停页面渲染也得等它跑完。如果这个脚本体积很大或者执行很慢白屏时间就会直线上升。CSS 也会阻塞渲染。浏览器只有在 CSSOM 构建完成之后才会开始首次渲染因为如果没有样式信息渲染出来的页面是裸的没有布局没有颜色。所以 CSS 资源在关键渲染路径上默认是渲染阻塞资源除非通过媒体类型或media属性告诉浏览器“这不重要别等我”。这就引出了异步加载的第一个核心动机把非关键的资源从关键渲染路径上挪开。所谓关键渲染路径就是从收到 HTML 到完成首次渲染所经历的最短序列。1.2 同步加载的现实代价一个真实场景聊天页首屏需要在 WebView 里加载一个混合应用壳子里面嵌了 React、业务公共代码、图表库、监控 SDK全打在一个 bundle 里压缩后接近 2.8MB。这个 bundle 在下发到低端 Android 手机骁龙 660 级别时的表现是下载慢2MB 以上在弱网环境下可能要 5~10 秒解析慢JS 引擎解析 2MB 的脚本要花几百毫秒到 1 秒执行慢启动时还要跑一堆初始化逻辑。为什么移动端尤其痛因为移动端有两层限制网络带宽不稳定4G 弱信号、地铁、电梯场景很多和 CPU 能力受限中低端机的 JS 引擎性能大概是旗舰机的三分之一甚至更低。同样的 1MB 脚本桌面 Chrome 上解析只要 100ms到了旧安卓机上可能就得 500ms。当时的权衡是聊天页必须快速出消息列表但图表库只用于账单页监控 SDK 不能阻塞 UI 渲染。这三个需求对应三种异步加载手段消息列表的渲染代码必须走关键路径——同步加载但要保证体积瘦身图表库按需加载用户跳到账单页时才动态 import监控 SDK 完全异步执行不阻塞 DOM 解析用 defer 加载。同步加载本身不是性能问题问题在于把不需要首屏的资源也放进了关键路径。异步加载的本质就是给资源分级哪些是真核心、必须立刻执行哪些可以往后放、按需再拉。1.3 事件循环、任务队列与异步执行的微观机制异步加载之所以能实现底层依赖的是浏览器的事件循环机制。JavaScript 是单线程语言但它运行时依托的是浏览器提供的多线程环境网络请求由网络线程负责、定时器由 timer 线程管理、事件监听由事件触发线程分发。主线程维护一个任务队列Task Queue也叫宏任务队列。异步加载到的脚本不是下载完就往主线程塞而是被投递到任务队列等主线程把当前任务处理完调用栈清空后才会从队列中取出执行。这套机制就是“异步”的微观含义任务的加载和调度不阻塞主线程但任务的最终执行还是得回到主线程串行完成。ES6 之后又多了微任务队列Microtask QueuePromise 回调、MutationObserver 回调都走这里。微任务的优先级高于宏任务。所以动态import()加载的模块其后续代码可能在微任务里继续执行这一点在写依赖链时会有所体现。理解了事件循环就能解释一个常见的性能误解异步加载不是“不花时间”而是“把时间藏起来”。下载和执行的总耗时并没有消失只是不再占住关键路径上的这段时间。所以异步加载的真正收益在于让首屏渲染在等待资源的同时继续推进把非关键代码的执行推迟到浏览器空闲时段。2. 异步加载的落地手段从脚本标签到代码分包2.1 defer 与 async两种异步脚本加载方式的对决script标签加载脚本有三种经典模式很多同学分不清defer和async的区别。我直接给出结论性的对比表属性加载方式执行时机DOM 解析阻塞执行顺序无同步遇到即阻塞下载下载完成后立即执行阻塞按文档顺序async下载不阻塞解析下载完成后立即执行执行时阻塞不保证顺序defer下载不阻塞解析DOM 解析完成后执行不阻塞按文档顺序async适合完全独立的脚本比如广告、埋点、数据上报这类代码执行时机无所谓谁先到谁先执行。defer适合依赖 DOM 结构或需要保证顺序的脚本比如页面增强逻辑、需要操作 DOM 的模块。实际开发中最容易踩的坑是给带依赖关系的脚本加了async结果后加载的脚本先执行直接报“xxx is not defined”。我见过团队排查了半天最后发现就是async导致的执行顺序错乱。如果没有强理由优先用defer。这里有个扩展认知移动端 WebView 里的脚本加载defer脚本是在 HTML 解析完成后执行但如果脚本本身很重还是会抢占主线程。所以就算加了defer也要控制脚本体积最好配合分包。2.2 代码分包与动态 import现代前端异步加载的核心工程手段工程化场景下异步加载的主要实现方式有两种一种是构建工具层面的代码分包Code Splitting另一种是运行时层面的动态导入Dynamic Import。webpack 和 Vite 都支持通过动态import()语法实现分包// 原来的写法首屏加载所有依赖 import * as echarts from echarts; // 优化后点击账单页时才加载图表库 const showBillPage () { import(./chart).then(module { module.renderBillChart(); }); };构建工具看到import()语法后会把对应的模块拆成独立的 chunk 文件。浏览器并不会在首屏加载这个 chunk只有当用户触发showBillPage时才会通过网络请求拉取这个文件并执行。分包策略的关键在于怎么切边界。我的经验是三个原则路由级分包每个页面独立的资源打成单独 chunk是最粗粒度也是最有效的分包。第三方库独立分包把体积大、版本稳定的第三方库如 ECharts、Ant Design、Monaco Editor拆成 vendor chunk利用浏览器缓存业务代码更新时不需要重新下载这些大体积库。异步组件粒度的按需加载对于弹窗、折叠面板里才出现的重型组件可以按交互动作来懒加载。分包不是越细越好。如果分包太小会产生大量 HTTP 请求每次请求都有握手开销反而拖慢加载。我在一个项目中把每个组件都拆了结果首页要并发 40 多个请求中低端手机的 TCP 并发连接数有限资源排队严重性能反而下降。合理的做法是把首屏资源控制在 20 个请求以内更小的模块合并到同一个 chunk。2.3 懒加载实操图片、列表与组件三种场景图片懒加载是最常见的异步加载场景因为它直接减少传输字节数。传统做法是监听scroll事件判断图片是否进入视口再替换src。现代浏览器提供了原生能力!-- 原生懒加载无需 JS -- img srcplaceholder.png>const observer new IntersectionObserver((entries) { entries.forEach(entry { if (entry.isIntersecting) { const img entry.target; img.src img.dataset.src; observer.unobserve(img); } }); }, { rootMargin: 0px 0px 200px 0px }); // 提前 200px 预加载 document.querySelectorAll(img[data-src]).forEach(img observer.observe(img));rootMargin这个参数值得注意设为200px可以提前触发加载用户在快速滚动时不容易看到占位图闪一下。但如果设得太大比如1000px等于把整个屏幕往下两屏的资源全部提前加载懒加载就失去意义了。列表组件的懒加载和图片类似核心思路是可视区渲染只渲染用户当前能看到的那部分列表项其余用空白占位。像 react-virtualized、vue-virtual-scroller 这类库就是干这个的。这里有个细节列表项高度必须固定或能预估否则滚动计算会错乱。如果是高度不定的列表如富文本评论就需要测量后缓存每项高度组件内部实现复杂度会高不少。组件的懒加载通常配合动态 import弹窗组件、抽屉组件、详情面板这类不常用但体积不小的 UI都可以在触发时再加载。一个典型场景是富文本编辑器体积往往有 200~400KB如果放在首页包里直接把首屏拖垮。正确做法是用户点击“编辑”按钮时才拉取。2.4 预加载与预取异步加载的进阶玩法异步加载不只是“延迟加载”还包括“提前加载”。preload和prefetch是两个容易混淆的指令preload告诉浏览器这个资源当前页面马上要用提前下载并缓存。prefetch告诉浏览器这个资源是未来可能用到的在浏览器空闲时提前下载。!-- 当前页面需要的关键字体提前加载 -- link relpreload href/fonts/inter.woff2 asfont typefont/woff2 crossorigin !-- 用户下一步跳转可能用到的路由资源预先拉取 -- link relprefetch href/page-bill.chunk.jspreload 适合首屏必须用但发现太晚的资源典型如字体、首屏大图、关键 CSS。prefetch 适合预测用户行为的场景——用户停留在列表页时预取详情页的 JS 分包这样用户点击详情时几乎没有加载等待。但 preload 使用要克制。之前有过一个案例我把页面所有资源都加了 preload浏览器在高优先级下载这些资源导致真正的首屏关键请求反而排队首屏时间变得更差。preload 只加给那些确信要用的关键资源比如字体文件、首屏背景图、核心 CSS。3. 性能优化从指标量化到关键路径的系统工程3.1 性能优化先回答三个问题量什么、怎么量、目标多少很多人做性能优化容易陷入“我感觉快了一点”的误区。性能优化第一原则是先量化再优化。要回答三个问题第一量什么指标推荐从用户体验角度选指标不是去数请求数或者包体积。业界公认的核心指标是 Web Vitals 体系重点关注三个LCPLargest Contentful Paint最大内容绘制用户看到主要内容的时间理想值低于 2.5s。INPInteraction to Next Paint交互到下一次绘制衡量交互响应理想值低于 200ms。CLSCumulative Layout Shift累计布局偏移衡量页面稳定性理想值低于 0.1。第二用什么工具量我在 Chrome DevTools 里最常用的三件套是Performance 面板录制完整的加载过程、Lighthouse 做整体评分和诊断建议、Network 面板看资源瀑布流。移动端我会用 WebPageTest它能模拟真实设备与弱网环境。第三目标是多少性能优化没有绝对的合格线建议按业务场景设定。工具类页面的 LCP 目标定在 2s 以内内容型的资讯页可以放宽到 2.5s游戏类页面则重点看 FPS 和内存占用。有一点很重要只优化不测量就是撞大运。我习惯把 Lighthouse 分数、LCP、CLS 三个指标做成简单的基准报告每次改动前后跑一遍用数据验证优化方向是否正确。3.2 关键渲染路径从请求 HTML 到首次渲染的每一毫秒关键渲染路径优化的对象是浏览器从请求 HTML 到完成首次渲染所走的路径。每一个资源请求都会延长这个路径异步加载的核心价值就在于把非关键资源从这条路径上剥离。优化关键渲染路径有一套标准动作第一压缩和精简关键资源。HTML、CSS、JS 都做压缩移除注释、空格、无用代码。CSS 和 JS 做 Tree Shaking把没用的代码从构建产物中剔除。这一步是纯收益没有副作用优先做。第二内联关键样式。首屏布局和核心视觉相关的最小 CSS 直接内联到 HTML 的style里减少一个 CSS 文件请求。非关键的样式比如某些组件的样式、弹窗样式放到异步加载的 CSS 文件里。注意内联 CSS 增加了 HTML 体积所以只内联真正关键的通常控制在 20~30KB 以内。第三给非关键脚本加 defer 或动态 import。第三方的 SDK、统计代码、客服组件全部延迟加载让主业务脚本在优先路径上执行。第四使用relpreload提前发现关键资源。如果首屏使用了一个重要的图片或字体但 HTML 头部无法直接发现它比如图片在 CSS 背景图中引用浏览器只能等 CSS 下载并解析后才去请求图片这就是“发现延迟”。preload 可以让浏览器提前去请求它。第五优化连接握手。建立 TLS 连接、DNS 解析都需要时间。HSTS 预加载、dns-prefetch、preconnect可以在浏览器空闲时提前完成这些连接步骤link relpreconnect hrefhttps://api.example.com这套流程跑完后我见过不少项目从首屏 4s 降到 2s 以内并不需要复杂的技术栈就是老老实实把每一步的时间压到极限。3.3 移动端性能优化的特殊策略WebView 与低端机适配移动端性能优化和桌面端有个本质区别资源下载速度差不多时移动端主线程的解析和执行速度要慢得多。所以移动端优化策略要额外考虑几个维度。WebView 层面的优化。Android 的 WebView 和 iOS 的 WKWebView 在性能表现上有差异前者更容易出现内存占用高、JS 执行慢的问题。对于套壳 App 内的 H5 页面有几个关键做法首屏只加载必要资源移动端网络质量参差不齐弱网环境下 2MB 的 JS 分包可能要下载好几秒所以首屏 bundle 必须严格瘦身控制在 300KB 以内比较稳妥。开启硬件加速和 GPU 渲染CSS 动画、transform 操作使用 GPU 合成层减少主线程渲染压力。合理使用本地缓存静态资源通过 Service Worker 或 App 端缓存做离线化和本地化重复访问时可以完全跳过网络下载。这里要注意缓存版本管理否则老用户拿到了新页面却用旧资源会出现页面错乱。启动性能优化在 Android 原生场景里另有一层含义。如果标题里的“启动性能”是指 App 冷启动时间那么和异步加载相关的部分是首屏视图的渲染数据、图片资源在冷启动时就预加载但非首屏的 Fragment、页面数据可以通过懒加载延后。我曾经在一个社交 App 里做启动优化把首页的网络请求和数据解析做成异步流水线启动时间从 2.8s 压到 1.5s核心思路就是数据请求和视图渲染的并行化。3.4 手游性能优化视角异步加载的分帧思想说句题外话“手游性能优化”这个热搜词也跟异步加载强相关。游戏引擎如 Unity、UE4里有个概念叫分帧加载Interleaved Loading资源加载不在同一帧内完成而是分成多帧逐步加载避免某一帧因为同步加载大量资源而卡顿卡顿超过 100ms 用户就能感知。这个思路和 Web 端的异步加载殊途同归把耗时任务切碎分散在多个空闲时间片里执行。Web 端的对应实现是requestIdleCallback// 在浏览器空闲时段加载非关键资源 requestIdleCallback(() { loadLowPriorityModule(); }, { timeout: 2000 });游戏场景对 FPS 极其敏感一个同步加载造成的掉帧可能直接导致操作延迟和卡顿感。Web 页面虽然不要求 60FPS 实时渲染但主线程被长时间占用时滚动不流畅、点击响应迟钝这些体验问题同样会发生。所以异步加载不仅是为了“更快”更是为了保证交互的流畅性——即使加载过程中用户也不应该感觉到页面卡住。4. 实战复盘一个资讯页从 4.5 秒到 1.8 秒的优化过程4.1 优化前的性能画像与瓶颈定位分享一个实际项目的优化过程。这是一个资讯详情页功能包括文章正文渲染、评论列表、点赞、图片展示、分享按钮。优化之前用 Lighthouse 跑分Performance Score 只有 55LCP 是 4.5s。用 Performance 面板录了一下加载过程发现三个明显的瓶颈一个 1.2MB 的 vendor.js包含引入的图表库、编辑器依赖在首屏加载而且没有加 defer正文里的 23 张图片全部同步加载没有懒加载总图片体积约 3.8MB首屏 HTML 只有 6KB但要等 1.2MB JS 解析执行完毕后才能渲染内容。这些问题的核心本质就一句话非关键资源占用了关键路径。图表库和编辑器在首屏根本用不到但代码把它们统一打包了进去。图片在用户没有滚动到的时候就应该只加载占位符。优化目标定得很明确LCP 小于 2sLighthouse Performance Score 大于 90首屏请求数减半首屏传输体积减少 60% 以上。4.2 优化方案的分步落地与效果数据方案分四步执行第一步代码分包。把图表库、编辑器这些重型依赖从主 bundle 中拆出去通过动态 import 按需加载。主 bundle 从 1.2MB 减到 180KB。这一步改动最大也是效果最明显的一步。第二步图片懒加载。给正文图片加 Intersection Observer 懒加载首屏只加载首图和前三张可能出现在视口内的图片其余图片全部延迟。第三步关键资源预加载。正文使用了一个自定义字体在 HTML head 里加了 preload避免字体发现太晚导致的文字闪烁FOUT。第四步非关键 JS 加 defer。统计代码、分享 SDK 全部改为defer加载让它们等 DOM 解析完成后排队执行。优化后的数据对比指标优化前优化后变化幅度LCP4.5s1.6s下降 64%首屏传输体积~4.5MB~1.2MB下降 73%首屏请求数41 个18 个减少 56%Lighthouse Performance5593提升 38 分CLS0.320.07达标表格里的数据不是拍脑袋的都是真实跑出来的。LCP 从 4.5s 到 1.6s 过程中最大的功臣是主 bundle 瘦身——首屏不用等 1.2MB JS 解析执行完主要内容可以更快绘制出来。4.3 优化的成本与收益权衡任何优化都不是零成本的。这次优化的隐性成本有两个一是分包后的加载流程变得复杂需要更仔细地处理加载错误和依赖缓存二是图片懒加载引入后对图片的占位方式、宽高设定有了更高要求否则容易 CLS。但收益远大于成本。从业务角度看首屏速度提升直接影响了用户跳出率。从工程角度看以后每次发版本图表库和编辑器版本的更新不再是全量更新的部分缓存命中率提升让老用户回访的加载进一步变快。这让我想到一个性能优化的通用原则优化方案选择的标准不在于技术多炫而在于收益是否可持续成本是否可控。最有效的优化往往是“删掉多余的东西”这种朴素操作而不是引进一套复杂的新架构。5. 常见问题与排查技巧实录5.1 加载顺序错乱与脚本依赖问题现象异步加载的模块偶尔报xxx is not defined特别是刷新页面时概率出现。原因分析脚本加载完成时不保证顺序。用async加载多个有依赖关系的脚本时后加载的脚本可能先执行。这是最容易踩的坑之一。解决方式检查script标签是否误用了async。如果脚本之间有依赖关系改用defer。构建工具层面确保分包模块的加载顺序由代码依赖控制而不是页面标签顺序控制。动态 import 之间有依赖关系时用 Promise 链来保证顺序async function loadModules() { await import(./core.js); await import(./feature.js); }这里多说一句不要试图用loadAsync之类的自定义方案来实现顺序控制直接依赖浏览器的 Promise 机制更可靠。5.2 图片懒加载引发的布局抖动CLS 恶化现象图片懒加载后用户滚动时页面内容上下跳动CLS 指标明显恶化。原因分析懒加载的图片在未加载时没有占位布局图片加载完成后才撑开高度导致后续内容被挤下去。解决方式给图片设置固定宽高比例或使用aspect-ratioCSS 属性预占空间.lazy-image { aspect-ratio: 16 / 9; /* 预占 16:9 比例的空间 */ width: 100%; object-fit: cover; }如果是瀑布流布局给容器设置一个估算最小高度。这个问题的本质是懒加载减少了传输量但如果布局不稳定体验的扣分可能比纯加载慢更严重。懒加载的同时必须配合布局稳定性设计。5.3 分包碎片化导致请求过多现象分包后首屏请求数暴涨弱网环境下加载更慢了。原因分析分包粒度太细每个小组件都被拆成独立 chunk浏览器并发连接数有限大量请求在排队。解决方式合理设置分包粒度。webpack 中可以用splitChunks的minSize参数控制最小 chunk 体积低于该体积的模块合并到大 chunk 中// webpack.config.js optimization: { splitChunks: { chunks: all, minSize: 20000, // 小于 20KB 的模块不打散 } }Vite 也有类似配置还可以配合手动分包策略把常用工具库合入同一个 vendor chunk。我的一个经验是首屏请求数保持在 20 个以内是合理的超过就要考虑合并。5.4 预加载抢占带宽导致首屏更慢现象加了 preload / prefetch 后Lighthouse 评分不升反降。原因分析preload 和 prefetch 的资源下载占用网络带宽导致关键资源下载变慢。尤其是 prefetch 在浏览器空闲时下载但如果页面同时触发了其他请求可能互相竞争。解决方式preload 只给首屏确定会用的资源加。prefetch 资源只放在用户大概率会跳转到的路由上不要全站 prefetch。如果资源是动态接口数据尽量通过浏览器空闲时的requestIdleCallback来触发而不是抢占加载。5.5 异步加载后的错误处理与降级策略现象动态 import 失败如弱网超时、服务器 500用户点击后页面无响应。原因分析动态 import 返回的 Promise 如果 reject而代码没有捕获错误功能就会静默失败。解决方式动态 import 必须带错误处理const loadChart () { return import(./chart.js).catch(() { // 降级方案提示用户稍后重试或使用精简版替代组件 showToast(模块加载失败请检查网络); }); };经验之谈异步加载引入后错误处理从“页面加载时就报错”变成了“用户操作时才报错”后者更难被测试发现。所以异步加载的代码必须显式处理失败场景不能放任 Promise reject。6. 异步加载与性能优化的工具链选择做性能优化离不开工具链。我自己常用的工具分三个层次第一个层次是构建期工具。webpack 的 Bundle Analyzer 做包体积分析vite 的build --report也能输出依赖分析。这类工具能帮你发现哪些模块占了太多体积为分包决策提供依据。我每次做优化前都会先跑一次分析看看最大的几个 chunk 是什么再决定拆哪里。第二个层次是浏览器运行时工具。Chrome DevTools 的 Performance 面板录制加载过程能看到主线程的每个任务耗时、每个资源的加载时段。它最擅长回答“慢在哪里”的问题——是某个 JS 执行太久还是某个请求延迟过高。Network 面板的 Waterfall 视图能清晰展示资源加载的并行和阻塞情况。第三个层次是基于 Lighthouse 的自动化审计。Lighthouse 不只是给个分数它还会给出具体的诊断建议比如“移除未使用的 Javascript”“预连接到所需来源”。这些建议可以直接变成优化待办清单。如果是移动端真机性能我还会在优化周期结束时用 DevTools 远程调试真机跑一遍看实际设备上的 FPS、CPU、内存表现。以我的经验Chrome DevTools 的模拟和真机差距还挺大的尤其是中低端安卓机上一次真机测试能发现很多模拟测不出的问题。可能你会问 Julia 性能优化的事——那是语言实现层面的另一回事讲的是 JIT 编译和类型稳定性对运行时性能的影响跟 Web 页面的异步加载不是一个领域。但两者有共同的底层逻辑性能瓶颈的解决之道都是先找到最耗时的环节再针对性地做工程改造而不是盲目的整体优化。我自己在实践中坚持一个原则异步加载是手段用户体验是目的。技术方案的选择永远服务于业务场景——首屏出速度、交互流畅度、弱网可用性这三件事做扎实了用户就能感知到“这页面真快”。这些经验和坑都是从一个个线上问题里磨出来的希望这篇原理篇能帮你少走几步弯路。