Superpowers技能体系：让AI编程助手从泛泛而谈到照着做就行
2026/9/29 19:31:05
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 rel="preload" href="/fonts/Inter.woff2" as="font" type="font/woff2" crossorigin> <!-- 下一个路由可能用，空闲时下载 --> <link rel="prefetch" 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 是业内事实标准，也是搜索引擎排名考量因素。用它可以把你“页面有点慢”这种感觉，变成可量化的数字。
| 指标 | 全称 | 度量内容 | 合格线 | 满分线 |
|---|---|---|---|---|
| LCP | Largest Contentful Paint | 最大内容元素渲染时间 | < 2.5s | < 1.2s |
| INP | Interaction to Next Paint | 交互到下一次绘制的延迟 | < 200ms | < 100ms |
| CLS | Cumulative Layout Shift | 页面累积布局偏移 | < 0.1 | < 0.05 |
LCP 是加载性能最直观的镜子，它衡量的是最大图片、标题块这类元素的渲染时间。异步加载的优化效果，会直接反映在 LCP 的曲线上。我习惯把 LCP 拆成四个阶段去看：TTFB（网络与服务器时间）、资源加载时间、元素渲染时间、以及三者之间的空闲等待。很多时候 LCP 慢，并不是下载慢，而是某个同步脚本把渲染主线程占用太久——这时候你去压缩图片、优化带宽都没用，正确的解法是把脚本改异步，让出渲染时机。
INP 是新版 Web Vitals 里替换 FID 的指标，它评估的是用户从点击到界面响应的整段延迟。异步加载如果做得不好，比如懒加载的组件点击后才开始下载，用户会有明显的“卡一下”体验，INP 就会飙升。所以交互组件的懒加载不是无脑用，关键交互路径上的组件要预加载，非关键路径的才懒加载。
4.2 性能观测方法：Lighthouse 与 WebPageTest 的组合拳
实际工作中我很少只依赖一个工具。Lighthouse 适合日常快速体检，它给出的评分和 Opportunities 列表能帮你快速定位最大的性能缺口。但 Lighthouse 跑的是本地模拟环境，网络是限速过的，它反映的是“接近真实的性能底线”，不是线上真实体验。
要拿到线上真实数据，我推荐两条路并行。第一条是浏览器内置的 Performance 面板，录制页面加载过程，瀑布图里能看到每个请求的耗时、阻塞情况和优先级。第二条是 RUM（Real User Monitoring）数据，国内常用的是自己埋点上报，把performance.getEntriesByType('navigation')里的 TTFB、DOMContentLoaded、LCP 数值上报到日志系统，看真实用户分布。我自己在团队里推的最小方案是：Performance API 采数据 + 上报到已有日志平台，一天时间就能搭完，却能提供持续的性能回归监控。
性能监控最忌讳“看单点”。单看某个 case 的 LCP 涨了没有意义，要结合网络环境、设备档位、页面版本一起看。App 端用户、4G 网络用户、千元机用户的性能数据，跟公司 WiFi 下的开发机完全是两个世界。这也是为什么我一直强调移动端性能优化的思路跟桌面端不一样。
4.3 工具链之外的思维：优先级与取舍
做性能优化，本质是资源调度。浏览器里每个资源都有优先级，从 Highest 到 Lowest，关键资源、脚本、图片、字体分布在不同的优先级层级。Preload 能拔高优先级，异步加载能降低紧急度——优化的核心思路就是让每类资源都待在合适的优先级上。
举个很典型的例子。首屏背景图是一张 2MB 的大图，LCP 一直上不去。你以为是图的体积问题，实际上可能是这个背景图被浏览器判断为非首屏关键资源，优先级排到了很低的位置，下载顺序被延后。解决办法不是压缩图，而是用fetchpriority="high"把它的优先级提上来，甚至拆成首屏可见部分的局部图+低清占位图。优先级调对了，加载速度快 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 元素 | 加fetchpriority="high"，检查是否懒加载误伤 |
| 字体闪烁 | 字体文件加载晚 | <link rel="preload">配crossorigin |
| 路由切换白屏 | chunk 未预加载 | 加 Prefetch 或预取接口 |
| 页面滚动卡顿 | 懒加载监听频繁触发 | 检查是否还在用 scroll 事件，换 IntersectionObserver |
| CLS 指标超标 | 图片/广告位无占位 | 固定宽高或aspect-ratio |
6. 移动端与更多场景的扩展思考
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 分位数——这个习惯比任何性能方案都管用。
最后再分享一个小技巧：做异步加载改造时，不要一次性全量上。先挑一个最痛的页面，改完对比前后的性能数据，把收益量化出来，再横向复制到其他页面。用数据说话，比跟团队讲任何大道理都有效。性能优化这条路，每个项目都值得走一遍，而且越早走，收益越大。