1. 为什么现在的页面性能问题几乎都出在加载这一环

做了这么多年前端，我越来越觉得一个现象很有意思：绝大多数用户眼中的"卡"，其实根本不是页面跑起来之后的计算卡顿，而是内容半天出不来、点了按钮没反应、滚动的时候图片一张张蹦出来这种"加载型卡顿"。尤其是移动端，网络环境波动大、设备性能参差不齐，加载环节稍微处理不好，用户两秒内就关页面走人了。我自己的实测数据是，一个页面从3秒优化到1.5秒，跳出率能降差不多20个百分点，这个收益任何业务场景都值得认真对待。

异步加载这个概念，核心要解决的其实就是三件事：减少首屏必须等待的资源、把非关键资源的加载时间挪到空闲时段、避免单个资源的失败拖垮整条链路。听起来不复杂，但真正落地的时候很多人会踩坑，比如代码分割之后导致重复请求、懒加载触发时机不对导致首屏反而变慢、预加载用过头导致带宽被占满。这些问题的根源，往往不是某一个工具用得不对，而是对整个加载过程缺少清晰的心理模型。

这篇内容我打算从一个真实的优化框架来讲：先理清浏览器的加载机制和异步原理，再讲具体落地手段（defer、async、代码分割、懒加载、预加载），然后配合一套可量化的测量方法，最后把移动端和App启动优化的思路一并带上。适合的人群是：有一定前端基础、想把性能优化从"玄学"变成"工程方法"的开发者。不管你是写业务页面还是做基建框架，这套思路都通用。

在展开细节之前，先提供一个核心认知：异步加载不是"把代码写异步"这么简单，而是要从资源调度层面重新思考整个页面加载的时间线。浏览器从拿到HTML到页面可交互，中间每一毫秒都有优化的空间，只是大多数人只盯着接口耗时，忽略了自己能掌控的一部分。

2. 异步加载的底层运行逻辑

2.1 浏览器加载页面的完整时间线

先把时间线拉出来看一遍。用户在地址栏输入网址按下回车之后，浏览器大致经历这几个阶段：DNS解析、TCP连接、TLS握手、发送HTTP请求、收到HTML、解析HTML、构建DOM树、解析CSS构建CSSOM、执行JavaScript、合成布局、绘制。

这里大多数开发者对"解析HTML"的理解过于简化了。实际上，浏览器解析HTML是一个边下载边解析的流式过程。遇到<script>标签时，默认行为是立即下载并执行，这会阻塞解析器——也就是说后面的HTML即便已经下载到本地，也不能继续生成DOM。这就是最原始的同步加载模型，在十年前页面普遍简单的时候问题不大，但今天的页面动辄几十个脚本，同步加载直接导致首屏被无限拉长。

基于这个机制，性能优化的核心思路就变成了：减少阻塞解析器的时间。而实现手段，就是异步加载。具体来说有两种常见方式，一是把脚本标记为defer或async，二是把资源放到页面底部或通过动态注入的方式加载。两者背后的逻辑都是"不让我等你，你下载好了再说"。

2.2 事件循环、宏任务与微任务：异步的底层心法

很多初学者以为"异步"就是"代码同时执行"，这个理解需要修正。JavaScript是单线程语言，异步的本质是先把任务挂起，等满足条件后回到主线程执行。浏览器有一套事件循环机制在调度这一切：主线程执行完当前宏任务之后，会清空微任务队列（Promise的回调就在这里执行），然后才从宏任务队列里取下一个任务（setTimeout、事件回调、IO回调等都属于宏任务）。

这套机制和性能优化有什么关系？关系太大了。如果一段异步回调里做了大量同步计算，它依然会阻塞主线程，因为异步不等于轻量。我见过不少团队把重计算塞进Promise里就以为是"异步优化"了，结果页面依然卡，原因就是异步只改变了执行时机，没有改变执行代价。

在资源加载层面，浏览器的网络进程是多线程的，同一域名下一般允许6个左右的并发连接。这意味着资源请求是真正"并行"的，但这个并行度有限。如果你首屏同时发起30个资源请求，它们会在队列里排队，关键资源反而不一定最先到达。异步加载策略必须考虑这种并发限制，合理规划哪些资源优先、哪些延后。

2.3 渲染进程与网络进程的分工

现代浏览器普遍采用多进程架构：网络进程负责下载资源，渲染进程负责解析、布局、绘制和JavaScript执行。这两个进程之间通过IPC通信。理解这个分工对异步加载很有帮助——资源下载可以完全独立于渲染进行，所以你完全可以在渲染空闲时提前把后面可能用到的资源下载好，这就是预加载和预获取的理论基础。

不过有一个很容易被忽视的细节：虽然下载不阻塞渲染，但资源到达渲染进程后，解析和执行依然会阻塞主线程。所以异步加载策略要分两层考虑：第一层是网络层面让资源"早点到"或"晚点到"，第二层是执行层面让脚本"晚点跑"或"分片跑"。两者配合才是完整的优化方案。

3. 四类常用的异步加载落地手段

3.1 defer与async：脚本加载的首选方案

在HTML中给<script>加上defer或async属性，是最基础的异步加载手段。两者区别经常有人混淆，我用一句话总结：async是下载完就执行，defer是下载完等DOM解析完再执行。

<!-- 立即下载，不阻塞解析，下载完立即执行（会中断解析） --> <script async src="analytics.js"></script> <!-- 立即下载，不阻塞解析，下载完等待DOM解析完成后执行 --> <script defer src="app.js"></script>

具体选哪个要看场景。第三方统计脚本、广告脚本，互相没有依赖关系，适合用async，它不保证执行顺序，谁先下载完谁先执行，但也无所谓。业务代码之间有依赖关系，必须保持执行顺序，或者要等DOM就绪之后操作，就用defer。defer还有一个好处：执行时机在DOMContentLoaded事件之前，这意味着你可以在脚本里安全地操作完整DOM。

我自己的实践习惯是：凡是业务相关脚本一律defer，凡是第三方独立脚本一律async，能放底部的同时加上async也完全没问题。不过defer有一个兼容性细节：defer对src外链脚本有效，对内联脚本无效——内联脚本没有下载过程，它的执行还是同步的。如果遇到必须内联又不想阻塞的情况，就需要用动态创建script标签的方式了。

3.2 动态import与代码分割：按需加载的工程化实践

现代前端工程化的主流做法是使用import()语法实现动态加载。注意，这里的动态import和ES模块的静态import是完全不同的概念。静态import在编译期就把模块关系确定了，打包工具会把代码打进同一个chunk；动态import()是运行时执行的，返回一个Promise，Webpack、Vite等工具会将对应的代码单独打成chunk，触发加载时才去请求。

// 静态导入：打包时合并到当前chunk import { initReport } from './modules/report'; // 动态导入：打包时单独分包，点击/路由切换时才加载 button.addEventListener('click', async () => { const { initReport } = await import('./modules/report'); initReport(); });

这个机制的价值在于：首屏只加载当前路由或首屏真正需要执行的代码，其余代码推迟到实际需要时再拉取。比如一个管理后台，用户可能永远不打开"报表"选项卡，那报表相关的代码干嘛要在首屏加载呢？动态导入就是解决这个问题的标准答案。

使用动态导入有一个工程上的坑——模块体积过小会导致分包碎片化。如果你把每个工具函数都动态导入，会产生大量几十KB甚至几KB的chunk，HTTP请求数量暴涨，反而拖累性能。Webpack有optimization.splitChunks配置可以合并小模块，Vite底层也有类似机制。我一般建议按路由或按业务模块动态导入，粒度控制在100KB以上才值得单独分包，太小的合并到公共chunk更划算。

3.3 懒加载与占位策略：图片和组件的延迟渲染

懒加载是异步加载的另一大主战场，最常见的场景就是图片。一个电商列表页可能有上百张商品图，如果全部在首屏加载，带宽瞬间被占满，LCP（Largest Contentful Paint，最大内容绘制）会差得离谱。图片懒加载的标准做法是先用占位符占据空间，等图片即将进入视口时再加载真实地址。

现代浏览器原生支持loading="lazy"属性，这是最轻量的方案：

<img src="placeholder.jpg">const observer = new IntersectionObserver((entries) => { entries.forEach((entry) => { if (entry.isIntersecting) { const img = entry.target; img.src = img.dataset.src; observer.unobserve(img); } }); }, { rootMargin: '200px 0px' }); // 提前200px开始加载 document.querySelectorAll('img[data-src]').forEach(img => observer.observe(img));

rootMargin: '200px 0px'的作用是预加载提前量：用户还没看到图片，但图片距视口只有200px时就开始加载，体感上无缝衔接。这个值不要设得太大，否则就失去了懒加载的意义；也不要设太小，否则用户滚动到图片位置时还是能看到"白框闪一下"的过程。200px左右是经验值，在主流浏览器上表现都不错。

组件懒加载的原理也类似，在React中常用React.lazy配合Suspense，在Vue中可以使用异步组件defineAsyncComponent。核心都是基于动态import()，只是封装成了框架层API。

3.4 预加载与预连接：空闲时段的主动出击

异步加载不只是"晚点加载"，还包含"提前加载"。浏览器提供了一组资源提示，其中最常用的是preload、preconnect和prefetch。

preload告诉浏览器："这个资源当前页面立刻需要，请优先下载"。适合首屏关键但发现得晚的资源，比如字体文件：

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

preconnect提前建立与第三方域的连接（DNS解析+TCP+TLS），适合已知要请求外部API或第三方CDN的场景：

<link rel="preconnect" href="https://cdn.example.com">

prefetch则是"空闲时下载下一个页面/功能可能用到的资源"，比如用户停留在登录页时，提前下载主页的核心JS：

<link rel="prefetch" href="/home/index.js">

这里有一个很重要的忠告：预加载不是越多越好。preload用多了会变成"把未来的问题提前到现在"，在低端设备或弱网环境下反而拉低首屏速度。我一般制定这样的策略：首屏关键字体和CSS用preload，已知第三方请求域名用preconnect，下一个交互场景的资源用prefetch，未来页面用prefetch（Vanilla式），其余一律不额外预取。资源提示和普通加载的区别在于，它不阻塞当前渲染，只是提前占用网络，所以需要你站在用户角度想清楚"什么值得提前"。

4. 性能优化的测量闭环与优化前后对比

4.1 指标先行：从FCP到LCP的性能标尺

聊优化之前得先说清楚怎么衡量优化效果。性能优化领域有几个全球通行的核心指标，我画了张快速对照表：

异步加载主要影响的就是FCP和LCP，而脚本执行优化则决定TTI和TBT。如果你的页面LCP在2.5秒以上（移动端参考值），优先看是不是首屏关键资源被过多的非关键脚本拖累了，这就是异步加载发挥价值的地方。

4.2 用Performance API做现场测量

浏览器Performance API可以直接在页面里拿到各类时间点，这对做自动化性能监控特别有用：

// 拿到关键时间点 const nav = performance.getEntriesByType('navigation')[0]; console.log('TTFB:', nav.responseStart - nav.requestStart); console.log('DOMContentLoaded:', nav.domContentLoadedEventEnd - nav.requestStart); console.log('Load:', nav.loadEventEnd - nav.requestStart); // 监听性能时间线 const paint = performance.getEntriesByType('paint'); paint.forEach(p => console.log(p.name, p.startTime));

LCP在PerformanceObserver里可以动态监听：

new PerformanceObserver((list) => { const entries = list.getEntries(); const lastEntry = entries[entries.length - 1]; console.log('LCP:', lastEntry.startTime); }).observe({ type: 'largest-contentful-paint', buffered: true });

实测中我习惯在开发环境用Chrome DevTools的Performance面板录一段加载过程，重点看主线程的长任务（Long Task）。任何超过50ms的任务都会导致用户可感知的延迟，而这些长任务绝大部分来自于同步脚本执行。这就把优化目标变得很明确：把超过50ms的任务拆碎，或者推迟到空闲时间执行。

4.3 一个实际案例的优化前后对比

拿我之前遇到的一个项目举例，是一个内容型站点，首屏包含大约3MB的JavaScript打包文件。优化前的LCP在移动端（中档Android机、4G网络）测试是4.8秒，TTI是7.2秒，用户基本要等六七秒才能正常操作。

做了三件事：第一，用路由级代码分割，首屏只加载核心bundle，从3MB减到1.1MB；第二，所有图片开启懒加载，首屏只加载视口内的5张；第三，把第三方统计脚本加上async并移除它在首屏的render-blocking标记。优化后同一设备同一网络环境下，LCP降到2.3秒，TTI降到3.9秒，FCP从2.1秒降到1.2秒。没有改任何业务逻辑，纯粹是资源调度策略的调整。

这个案例最大的启发是：首屏JS体积减少不意味着"总代码量减少"，而是"该等的资源不用等了"。总代码量可能没变，但用户感知发生了质变。

5. 场景延伸：移动端与App启动优化

5.1 移动端性能优化的特殊约束

移动端和桌面端的性能优化有本质差异。桌面端有稳定的网络和充足的内存，移动端则面临两个核心瓶颈：网络延迟更高、CPU/内存更有限。根据实际统计，中低端Android设备的CPU性能可能只有旗舰机的三分之一，而JavaScript引擎的即时编译能力差别更大。同一个异步加载方案在旗舰机上看不出差别，在低端机上可能仍然明显卡顿。

移动端还要考虑耗电和流量。一个后台无限重试的网络请求，可能让用户在不知情的情况下消耗大量流量。异步加载方案在移动端要额外关注：减少不必要的网络请求数、合并小请求、合理利用缓存。Service Worker配合Cache API可以做离线缓存，这是移动端性能优化的重要武器——第一次访问后，静态资源都能从本地缓存加载，二次访问速度会惊人地快。

5.2 Android启动优化的思路迁移

Android应用启动过程和Web页面加载本质上遵循同一个逻辑：启动时间 = 必须要做的同步工作 + 可以推迟的异步工作。Android开发中常说的启动优化手段，跟Web的异步加载思路惊人地相似。

第一类是懒初始化：Application的onCreate里只初始化真正必要的SDK，其他SDK放到后台线程或者等用到时再初始化。这对应Web里把非关键脚本从首屏移除。第二类是启动时分线程：用ExecutorService把IO操作、数据库预加载、图片预解码放到后台线程，主线程只做UI准备。第三类是启动后延迟加载：通过postOnIdle()或IdleHandler把任务推迟到主线程空闲时执行，对应Web的requestIdleCallback。

// Android：主线程空闲时再执行非关键初始化 Looper.myLooper()?.queue?.addIdleHandler { initUnimportantSDKs() false // false表示执行完移除，不重复执行 }

这种"主线程优先做关键事，非关键任务塞进空闲时间"的哲学，横跨Web和App开发完全通用。我做App性能优化时，经常先把Web前端那套资源调度模型在脑子里过一遍，在移动端场景直接套用，只是API不同、网络情况更复杂一点。

5.3 如何应对移动端弱网环境

弱网是移动端异步加载最大的变数。一个经验：不要假设用户的网络质量和你办公网络一样。我见过用WiFi测试一切正常、用户用2G网络打开白屏十秒的项目。弱网环境下的异步加载策略要注意几个细节：超时时间要合理设置，不能无限等待；加载失败要有重试机制，重试要有退避策略；关键资源要有兜底方案，比如图片加载失败显示占位图而不是烂图；考虑数据压缩和接口合并，减少网络往返。

还有一个容易被忽视的点——连接复用。HTTP/2和HTTP/3的多路复用能力能大幅减少握手开销，在移动端尤其明显。如果你的服务端还停留在HTTP/1.1，很多异步加载的优化效果会大打折扣。我建议在条件允许时优先升级到HTTP/2或HTTP/3，这本身就是一种"看不见的"性能优化。

6. 常见问题与排查经验实录

6.1 异步加载后首屏反而变慢的怪现象

这是最常见也是最诡异的问题：明明做了懒加载和代码分割，首屏怎么还变慢了？我排查过几次之后发现，多半是懒加载时机和资源提示打架。比如某张首屏大图使用懒加载，但另一处代码里又preload了同一张图，结果浏览器按"高优先级"把它提前拉取了，懒加载白做了。或者动态import触发的chunk体积过大，首屏核心逻辑本身就包含了亟待加载的模块，一旦延迟反而让关键路径变长。

解决方法是分清主次，先建立资源优先级清单。首屏必须渲染的内容，果断用preload或高优先级加载，不要懒加载；首屏不需要的内容，统一用懒加载或异步加载，不要画蛇添足。尽可能避免对同一资源既懒加载又预取。

6.2 预加载失效：字体文件与crossorigin属性

我在预加载字体时踩过一个隐蔽的坑：preload字体文件必须加crossorigin属性，否则字体无法生效。具体原因是浏览器对字体请求默认发起跨域请求，而preload请求本身默认是同源的，两者请求方式不一致导致缓存命中失败。正确写法：

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

这个细节如果不注意，会出现"明明preload了但字体还是文字闪一下变字体"的FOUT现象。我在团队内部checklist里专门加了一条"preload字体必须带crossorigin"。

6.3 动态import的循环依赖与执行顺序

动态import在复杂业务中容易引发循环依赖问题——A模块动态导入B，B又动态导入A。由于动态导入是运行时才执行，循环依赖不会被像静态导入那样在构建期直接报错，而是运行时会拿到undefined，然后报错。排查思路是看网络面板中这两个chunk是否出现互相请求、循环等待的现象。解决办法通常是提取公共部分为一个独立模块，切断循环链。

另一个相关问题是执行顺序。defer保证执行顺序，但动态import不保证。如果两个chunk之间有依赖关系，正确的做法是在同一个import()的Promise内部顺序引入，而不是分别动态导入。

// 错误：两个动态导入的执行顺序无保证 const modB = await import('./b.js'); const modA = await import('./a.js'); // 正确：在同一个模块内通过静态import再导出 const { b } = await import('./b.js'); const { a } = await import('./a.js');

6.4 常见问题速查表

6.5 我踩过的最有价值的一次坑

最后分享一个印象最深的排查经历。有一次优化一个后台管理系统，首屏脚本从3.2MB降到了800KB，但用户反馈"打开速度没感觉变快"。我带着疑问去看了监控数据，发现FCP确实降低了不少，但TTI几乎没变。原因是虽然代码分割让首屏脚本变小了，但登录页里有一个递归组件被错误地放入了核心chunk，这个组件第一次渲染时要执行大量递归计算，把主线程长时间占住，导致页面虽然"画出来了"但其实不可交互。

这次经历给我留下的教训很深：性能优化不要只盯着"资源加载"，还要盯着"主线程任务"。资源加载决定了内容出现的速度，但主线程是否空闲决定了用户是否能操作。两者缺一不可。后面我做性能方案都养成了一个习惯：用Performance面板录一段完整加载过程，专门看有没有超过50ms的长任务，逐个处理，收益非常直接。