企业官网建设流程全解析

1. 从一次深夜优化事故说起：为什么异步加载能救命

三个星期前的凌晨一点，我盯着性能分析面板上那个刺眼的红色FCP值，第一次认真思考要不要把项目里那个塞满首屏的图片轮播组件拆出去。那是一个非常典型的移动端活动页——顶部轮播、中部商品列表、底部新人专享券，逻辑不复杂，但首屏 JavaScript 体积超过了 680KB。这个数字意味着什么？按常规 4G 网络下 1.2MB/s 的下载速度计算，光下载脚本就要花近 0.55 秒，再加上解析、编译、执行的时间，用户真正看到可交互页面之前，至少要经历 3 秒以上的空白期。在转化率以毫秒计的电商场景里，每延迟 100ms，流失率就上升 1.5%，这种代价没人扛得住。

那次事故之后，我花了整整两个晚上复盘整个加载链路，最后的优化清单里，八成改动用的是异步加载。所以这篇博文我不想聊虚的，直接把我理解的异步加载原理、实战中用过的代码分割方案、以及移动端场景下那些踩过坑才能总结出来的性能优化细节一次讲透。适合谁看？如果你正被首屏加载速度困扰、想做性能优化却不知道从哪里下手、或者看过不少教程但依然搞不懂 async/defer/dynamic import 实际该怎么选，这篇内容应该能帮你省下一大段摸索时间。

2. 异步加载的技术拆解：从浏览器底层机制到代码层面的三种执行方式

2.1 浏览器渲染链路里的同步阻塞问题

要理解异步加载为什么能优化性能，先得搞清楚浏览器在做什么。当你输入一个 URL 并按下回车，浏览器拿到 HTML 后开始从上往下解析，构建 DOM 树。HTML 里如果出现一个<script src="index.js">，浏览器会立刻停下 DOM 解析，去下载这个脚本，下载完再执行，执行完才继续解析后续的 HTML。这个过程叫同步阻塞。

阻塞的时间由两部分组成：下载时间加执行时间。下载时间取决于网络速度和服务端响应，这个你没法在客户端代码里彻底规避；但执行时间纯粹由脚本体积和代码复杂度决定。这就是为什么同样的页面，有人用 4G 网络首屏秒开，你上班用办公 WiFi 也依然卡顿——当脚本体积足够大时，即使带宽再充裕，主线程解析和执行 JavaScript 的时间也会成为瓶颈。

更糟糕的是，同步阻塞会连带阻塞渲染。假设你的首屏背景图和某个交互脚本绑定在一起，那个脚本下载得越慢，整张页面出现得就越晚。异步加载的本质，就是把“下载解析执行”和“DOM 渲染”这两件事解耦，让脚本不再成为渲染链路上的单点故障。核心手段包括给 script 标签加 async/defer 属性，以及在代码运行层面使用动态 import。

2.2 async 与 defer：两个属性背后的执行时机差异

经常有人问我，async 和 defer 到底有什么区别？先记住一个简单的使用原则：如果你的脚本之间没有依赖关系，用 async；如果脚本依赖 DOM 就绪，或者多个脚本之间有先后执行顺序要求，用 defer。原因要从它们的加载和执行时机说。

普通脚本：HTML 解析遇到就开始下载，下载完立即执行，执行期间阻塞解析。

defer 脚本：HTML 解析过程中遇到就开始下载（异步下载），下载完成后不执行，等 HTML 全部解析完成、DOMContentLoaded 触发之前，按顺序执行所有 defer 脚本。

async 脚本：HTML 解析过程中遇到就开始下载（异步下载），下载完成后立即执行，执行时如果文档还没解析完就停一下，先执行脚本，再继续解析。多个 async 脚本之间不保证顺序。

用一个时间线对比来说明：

2.3 代码运行时层面的异步：Promise、async/await 与微任务队列

上面说的是浏览器在解析 HTML 阶段对脚本加载方式的控制，但异步加载在代码运行层面还有另一层含义——不阻塞主线程的异步操作。这就得说到事件循环机制。

JavaScript 是单线程语言，同一时间只能执行一个任务。浏览器内部维护着调用栈、任务队列和微任务队列。宏任务包括 script 整体代码、setTimeout、setInterval、I/O 事件中的回调；微任务包括 Promise.then/catch/finally、MutationObserver 回调等。事件循环的规则是：每次调用栈清空后，优先把微任务队列里的任务全部执行完，再取一个宏任务执行。

这个机制对你做性能优化有什么用？实际场景非常典型：你向服务器请求了一份用户数据，需要 300ms 才能返回，如果这 300ms 内主线程闲等，用户点击按钮就没有任何响应。用 Promise 包裹请求后，主线程可以继续执行其他渲染任务、处理用户交互，等数据返回后再通过微任务队列把回调塞回主线程。这就是“异步加载”在运行时线程层面的核心意义：把 IO 等待时间从主线程的执行时间里剥离出去。async/await 本质上仍是 Promise 的语法糖，只不过写法更贴近同步逻辑，读起来更舒服，但记住它不会让执行速度变快，只是把异步流程的代码组织方式变得更可控。

3. 方向判断：异步加载如何同性能优化指标挂钩

3.1 性能指标里哪些最依赖异步化改造

做性能优化不能凭感觉，先盯指标。目前业界主流的 Web 性能指标有三类——加载类、交互类和视觉稳定性类。异步加载主要影响的是加载类和交互类指标。

• FCP（First Contentful Paint，首次内容绘制）：指页面上第一次出现文字、图片等内容的时刻。资源加载顺序和是否阻塞对 FCP 影响巨大，首屏关键 CSS 和少量内联脚本应同步，其余资源全部改为异步加载。
• LCP（Largest Contentful Paint，最大内容绘制）：指页面主体内容加载完成的时刻，通常对应首屏最大图片或大标题块的渲染完成时间。LCP 优化核心是让首屏资源尽快拿到，非首屏组件必须延迟加载。
• TTI（Time to Interactive，可交互时间）：指页面从加载完成到用户可以顺畅交互的时间。长任务（Long Task）是拉高 TTI 的元凶，而长任务中相当一部分来自同步执行的大体积脚本。把非关键逻辑拆成异步加载后，主线程才能尽早把控制权交还给渲染和交互。
• TBT（Total Blocking Time，总阻塞时间）：主线程被长任务占用、无法响应用户输入的总时长。异步加载对它的优化作用立竿见影。

如果你公司有内部性能平台，建议先拉四个指标，再看具体优化动作的优先级。一般而言，FCP 靠资源加载顺序优化，LCP 靠首屏资源直出和非首屏延后，TTI 和 TBT 靠脚本拆分和主线程降载。

3.2 拆包粒度怎么定：从体积守恒到体验守恒

异步加载的本质是做延迟，不是做删除。代码总量没变，只是把一段集中执行的体积，按时间轴切成了多段。所以拆包粒度特别关键——拆得太碎，每个分包都有额外 HTTP 请求开销，移动端环境下握手和首字节时间反而拖慢速度；拆得太粗，体积损耗又体现不出来。

一个既能落地又不太费劲的拆包原则：按路由拆，再按重要度排序。

路由级别的拆是最自然的拆。用户从首页跳转到详情页，详情页的脚本可以等跳转时再加载，没必要放进首屏包里。Vue Router 的懒加载和 React Router 配合 React.lazy 都是这个思路。路由拆完之后，如果某个页面内部还有体积特别大的独立组件，再按组件拆。举个例子：活动页首屏只要一个 banner 和一个商品卡片列表，那这个页面包应该只包含渲染这两块所需的代码。点击“查看用户评价”时才弹出来的低概率使用组件，丢进动态 import 里。

3.3 体积阈值参考：用数据驱动你的判断

我整理了一份自己常用的体积参考区间，不一定适用所有项目，但可以帮你建立一个大致的感觉。

这里的核心逻辑是：把用户“几乎一定会看到”的代码放进首屏包，把“可能看到但概率不高”的代码交给异步加载时机控制。虽然拆包写起来就是一个 import 的事情，但选择在哪个位置插入动态 import，才真正考验对业务的理解程度。

4. 实操演示：从 680KB 到 198KB 的异步加载改造过程

4.1 改造前的数据采集与问题定位

我先交代一下项目背景：这是一个面向移动端的促销活动页，技术栈是 Vue 3 + Vite，用的是组合式 API。首屏包含顶部轮播、8 个商品卡片、新人弹窗，以及一个非常大的新人礼包接口。

改造前我先用 Lighthouse 跑了一轮移动端模拟测试，核心数据如下：

从 performance 面板的 Main 火焰图里，我看到首屏阶段有一串连续的长任务，每段都超过 100ms，最长的能到 230ms。点击率最高的耗时堆栈指向三个模块，分别是轮播组件（Swiper.js）、图片懒加载工具（内含 polyfill）、以及新人弹窗的校验逻辑（需要引入一个加密签名计算的库）。三个模块里，轮播和新人弹窗虽然体积大，但用户首屏不一定马上能看到——轮播如果预先请求了图片资源，但用户还没滑动到轮播图，这笔开销就成了浪费；新人弹窗则通常要等接口数据返回后才决定是否弹出，提前执行校验逻辑同样没意义。于是这三个模块就成了异步化改造的首批目标。

4.2 改造步骤实录：构建配置与代码写法

在 Vite 工程里做异步加载改造，不需要额外装插件，核心就是动态 import。我先说结论：Vite 会把动态 import 的部分自动拆成独立 chunk，并在真正执行到那行代码时才发起网络请求。

轮播组件的改造前写法是：

// 改造前 import Swiper from 'swiper/vue';

改造后：

// 改造后 import { ref, onMounted } from 'vue'; const SwiperComponent = ref(null); onMounted(async () => { const module = await import('swiper/vue'); SwiperComponent.value = module.default; });

看起来很简单，但有个坑必须提前说清楚：如果你直接把 Swiper 放到模板里，然后又依赖v-if来控制它的渲染，组件会有一个短暂的空隙时间——接口数据还没回来，组件还没挂载，页面看起来像少了块内容。正确做法是先渲染一个占位容器，异步模块加载完并完成状态赋值之后，再让 Swiper 真正渲染。占位容器我给了一个高度为 300px 的灰色块，轮播一旦挂载就会把占位块替换掉，用户体验上不会感知到额外等待。

新人弹窗的改造路径也类似。新人礼包有单独的接口/api/benefit/check，这个接口会返回用户是否满足领券条件，满足条件才展示弹窗。弹窗内部又引用了券码加密签名库crypto-js，这个库压缩后依然有 88KB 左右，首屏完全没必要加载。我的改造思路是：先调普通页面接口，等页面主体渲染完成后，再异步调 check 接口，根据返回值动态 import 弹窗组件和加密库。

async function loadBenefitModal() { const [modalModule, cryptoModule] = await Promise.all([ import('@/components/BenefitModal.vue'), import('crypto-js') ]); // cryptoModule 传给 modal 内部使用 modals.value = modalModule.default; }

这样改动之后，首屏代码体积直接少了 280KB，因为这些逻辑被拆到独立 chunk 里，浏览器只在真正需要的时机才发起请求。页面主体渲染完成后，主线程从长任务的总时间里释放出至少 300ms 的空闲，TTI 和 TBT 都得到明显改善。

4.3 参数选型背后的逻辑：为什么我不把所有代码都异步化

你可能会问，既然异步加载这么好，为什么不把首屏所有代码都改成动态 import？原因很简单——过度异步化会导致 FOUC（无样式内容闪烁）和交互延迟。比如说按钮的点击事件绑定，如果绑定逻辑也是异步加载，用户看到按钮后立即点击，事件还没注册上，点击行为就丢失了。异步改造的目标是把“用户大概率用不上的逻辑”延后，而不是把“用户一定会用上的逻辑”也延后。

首屏的基础布局、核心交互逻辑、以及视口内的静态资源必须保证同步或接近同步加载完成。具体判断标准是：任何一个用户进入页面后一定会触发的逻辑，必须留在首屏包；用户不一定触发、或者触发时间点大概率在首屏完成之后的逻辑，逐项异步化。

这里我还顺带解决了一个请求优先级的问题。浏览器对资源加载有个默认优先级策略，一般是 CSS 和字体最高，其次是首屏图片和脚本，但某些场景下浏览器定的优先级不符合你的期望。比如轮播图里的三张 banner 图片，虽然本身是异步加载，但图片资源较大，优先级不够高时可能被排在后面。我的做法是用<link rel="preload">声明首图的地址，设置fetchpriority="high"，让性能面板里的资源加载顺序更符合业务权重。这个技巧对 LCP 指标优化非常有帮助，实测能让 LCP 从 4.1s 降到 2.8s。

4.4 改造后的数据对比：异步加载的量化收益

改造整个过程大概用了两天，第一天拆分包调整顺序，第二天做数据回归和兼容性测试。最终数据如下：

这个结果再次验证了异步加载对性能收益的直接贡献，尤其 TBT 的降幅非常明显，几乎等于把主线程的“拥堵路段”全部拆走了。后续我还把同一个优化方案沉淀成了团队的脚手架模板，新页面启动时自动生成懒加载配置和分包预设。

5. 移动端场景下的异步加载与性能优化补充

5.1 网络与设备约束下的移动端专项优化

同样的优化在 PC 端和移动端是完全不同的效果。移动端用户通常使用蜂窝网络，带宽不稳定，DNS 解析和 TCP 连接的时间占整个请求耗时的比重更高。这意味着移动端不能激进地拆出太多小体积分包——每个分包都意味着一次新的连接、TLS 握手和请求往返。我见过一个改造过度的案例，分包数量从 3 个变成 41 个，结果页面加载总量反而增加了 12%，因为 HTTP 请求本身的握手时间开销远远大于省下来的解析时间。连接成本 > 体积成本，这在移动端网络下尤为明显。

所以移动端的策略通常比 PC 端更保守：公共依赖尽量合并，优先保证关键资源尽快到达。另外，有条件的情况下尽量利用服务端 HTTP/2 的多路复用能力，它能减少连接建立次数带来的损耗，但前提是你得先控制分包数量。

5.2 IntersectionObserver 实现图片与组件懒加载

除了 JavaScript 分包，移动端另一个性能大头是图片。首屏区域内的图片要尽量提前加载，首屏以下的图片必须延迟到接近视口时才加载。最早的做法是监听 scroll 事件，计算图片距视口顶部的 offsetTop，这套方法有一个问题——滚动事件本身很频繁，如果不做节流，会在主线程上产生大量计算，反倒是另一种性能负担。现在推荐统一用 IntersectionObserver 实现懒加载。

function lazyLoadImages() { const imageList = document.querySelectorAll('img[data-src]'); const observer = new IntersectionObserver((entries) => { entries.forEach((entry) => { if (entry.isIntersecting) { const img = entry.target; img.src = img.dataset.src; img.removeAttribute('data-src'); observer.unobserve(img); } }); }); imageList.forEach((img) => observer.observe(img)); }

IntersectionObserver 的回调是异步触发的，不会阻塞主线程渲染，而且浏览器内部对观察对象做了优化，回调频率远低于 scroll 事件触发的频率。实测效果是：一个包含 30 张商品图的列表页，首屏图片请求数从 30 个降到 5 个，LCP 维持不变，总流量消耗下降 70% 左右。

除了图片，我还会用 IntersectionObserver 来触发底部组件的异步加载。比如列表滚动到接近底部时，动态 import 底部推荐模块的脚本，这样用户快速滑动时体验不会中断，同时可以把这部分资源的加载延后到真正需要的时刻。

5.3 requestIdleCallback 与空闲时间窗口利用

另一个我在移动端经常用到的 API 是requestIdleCallback。它的机制是在主线程空闲时安排执行低优先级任务，不会抢占用户交互的关键时间窗。我一般用它来加载统计脚本、上报日志、初始化不紧急的埋点逻辑。

if ('requestIdleCallback' in window) { requestIdleCallback(() => { import('@/utils/reporter').then((module) => { module.default.init(); }); }, { timeout: 2000 }); }

这个写法有一个很实用的场景：统计分析脚本一般体积不小又不直接作用于用户体验，放在同步加载里会拉长主线程占用时间。扔进 requestIdleCallback 后，它会在浏览器空闲时（例如用户浏览首屏内容、阅读文案的时候）悄悄加载。但注意timeout参数必须设置，否则在长期不空闲的页面里（比如一直有动画在跑），这个任务可能永远不会执行，统计数据就丢了。

还有一个容易踩坑的地方：低端安卓机（比如运行内存只有 2GB 的千元机）对多个并发异步请求的处理能力有限，浏览器同时发起的请求数会被限制在 6 个左右。如果异步加载的模块之间没有主次之分，建议用一个队列控制最大并发量，避免排队等待时间过长。我一般控制移动端首屏阶段的并发请求数不超过 4 个，页面主体渲染后再放开并发限制。

6. 常见问题与排查技巧：我踩过的那些坑

6.1 首屏白屏和 FOUC 问题

异步加载改造最常见的直接结果，就是首屏内容出现短暂空白或闪烁。这通常不是异步加载本身的问题，而是控制渲染时机的逻辑没有处理好。比如你用 v-if 控制异步组件渲染，模块加载完成前组件压根不渲染，于是渲染结果为空。我的排查思路是：先看 performance 面板的 Network 时间线，确认动态 import 的模块请求是什么时候发出的。如果请求发出到模块执行之间有明显空隙，说明动态 import 的时机过早或过晚，需要调整触发节点，或者像我之前那样增加一个占位结构，让页面在等待期间依然有内容可看。

6.2 组件加载顺序与接口数据的竞争问题

还有一类问题出在组件加载和数据请求的并行竞争上。假设一个弹窗组件需要等接口 A 返回数据后再渲染，但接口 A 的耗时比组件加载更长，这时候你把组件设为异步加载反而会浪费主线程的等待时间。我的做法是并行发起组件加载和数据请求，用Promise.all等待两者都完成后统一渲染。这样做的额外收益是：接口数据请求和脚本加载可以同时进行，总耗时只取决于较慢的一方，而不是两个任务串行相加。实测这个改动让新人弹窗的展示时间从 1.2s 降到了 700ms。

6.3 缓存策略与版本号混乱

频繁改动异步分包后，浏览器缓存策略可能导致线上旧版本资源和新版本逻辑混用。如果你用 Vite 默认的 hash 命名，这个风险比较小；但如果你们项目是接的自定义构建流程，一定确认每个分包文件名的 hash 会随内容变化。我见过一个项目，chunk 文件名固定为vendor.js，异步加载的组件代码更新后没能及时替换缓存，线上出现了“点击后模块执行报错”的怪异现象。排查了整整一个下午，最后发现是服务端缓存头没有设置正确的 ETag。解决方案是规范构建产物的文件名命名规则，并且给 HTML 入口文件设置no-cache。

6.4 核心的排查工具使用顺序

最后总结一下我排查异步加载问题时的工具使用顺序。第一步看 DevTools 的 Network 面板，确认资源加载的顺序和耗时，判断是否该加载的没加载、不该加载的提前加载了；第二步看 Performance 面板的火焰图，识别长任务和主线程的空闲段，确认异步加载是否真正释放了主线程；第三步看 Lighthouse 的 Performance 报告，量化优化前后的指标变化，判断是否还需要继续调整；第四步，用真实移动设备在弱网环境（DevTools 里的 Network Throttling，连接改为 Slow 4G）重复测试，确保加速方案不会在真实网络环境下打折扣。这个流程基本能覆盖九成以上的异步加载性能问题。