1. 异步加载与性能优化：从卡顿到丝滑的实战拆解
前端性能优化这个话题，说大可以大到全链路架构，说小可以小到一行代码的摆放位置。但真正让大多数开发者头疼的，往往不是“不知道要优化”，而是“不知道从哪里下手”。异步加载就是那个最容易被低估、却又能带来立竿见影效果的切入点。我见过太多项目，页面白屏三秒起步，用户还没看到内容就跑了，而罪魁祸首往往就是资源加载策略出了问题。
这篇文章面向的是有一定前端基础、正在被页面加载速度困扰的开发者。不管你是做移动端H5、PC端管理后台，还是混合App里的WebView页面，异步加载的思路都是通用的。我会从核心原理讲起，把方案选型的逻辑掰开揉碎，再给出可以直接抄的代码和配置，最后把我自己踩过的坑和排查技巧一并倒出来。目标只有一个：让你看完就能动手，动手就能见效。
2. 异步加载到底在解决什么问题
2.1 同步加载的代价：浏览器被“堵死”的那些瞬间
要理解异步加载的价值，得先搞清楚浏览器是怎么处理资源的。默认情况下，浏览器解析HTML时遇到<script>标签，会暂停DOM构建，先去下载并执行脚本，执行完了再继续往下解析。这就是所谓的阻塞式加载。一个放在<head>里的同步脚本，如果服务器响应慢或者文件体积大，用户看到的就是一片白屏。
我用一个真实场景来说明。之前接手过一个后台管理系统，首页引了七个JS文件，全部同步加载，加起来大概2.3MB。在办公室的千兆网络下感觉不到问题，但销售同事拿着笔记本在客户现场用4G网络演示时，首屏加载时间直接飙到8秒以上。打开Chrome DevTools的Performance面板一看，主线程被脚本执行占满了，DOMContentLoaded事件在6.7秒才触发。这就是同步加载的典型症状：网络请求串行化、主线程被长时间占用、用户交互完全无响应。
更隐蔽的问题在于，同步脚本的执行顺序是严格保证的。如果A脚本依赖B脚本，那B必须排在A前面。这在大型项目里会导致依赖链越来越长，加载时间呈线性增长。而且一旦某个脚本报错，后面的脚本全部不会执行，整个页面直接瘫痪。
2.2 异步加载的核心思路：让该并行的并行，该延迟的延迟
异步加载的本质就一句话：不阻塞HTML解析的前提下，按需或并行地获取和执行资源。具体拆开来看，有三个维度：
第一个维度是加载时机的异步。脚本的下载不再阻塞DOM构建，浏览器可以一边解析HTML一边在后台下载JS文件。这解决的是网络层面的串行问题。
第二个维度是执行时机的异步。脚本下载完了不一定马上执行，可以等DOM就绪后再执行，或者等某个事件触发后再执行。这解决的是执行顺序和依赖关系的问题。
第三个维度是资源优先级的异步。不是所有资源都一样重要，首屏需要的CSS和关键JS应该优先加载，非关键的图片、统计脚本、第三方组件可以延后。这解决的是带宽分配的问题。
这三个维度对应到具体技术手段，就是async、defer、动态创建script标签、动态import()、以及基于IntersectionObserver的懒加载等等。每种手段适用的场景不同，选错了不仅没效果，还可能引入新的bug。
2.3 性能优化的衡量标尺：别凭感觉，看数据
优化之前得先知道现状。我习惯用三个核心指标来判断一个页面的加载性能：
| 指标 | 含义 | 达标参考值 |
|---|---|---|
| FCP | 首次内容绘制，用户看到第一个内容的时间 | < 1.8s |
| LCP | 最大内容绘制，首屏最大元素渲染完成的时间 | < 2.5s |
| TTI | 可交互时间，页面能响应用户操作的时间 | < 3.8s |
这三个指标在Chrome DevTools的Lighthouse面板里都能直接跑出来。我一般会先在移动端4G网络模拟下跑一遍，因为这才是最接近真实用户的场景。很多人只在本地localhost测，那数据没有任何参考价值。
除了实验室数据，线上真实用户的监控更重要。我通常会在项目里埋一段PerformanceObserver的代码，采集真实用户的LCP和TTI数据上报。具体做法是监听largest-contentful-paint和longtask两个entry type，把数据攒起来在页面卸载时通过navigator.sendBeacon发出去。这样你才能知道优化到底有没有效果，而不是自我感觉良好。
3. 核心方案拆解：async、defer与动态加载怎么选
3.1 async和defer的区别：一张图讲清楚
这两个属性经常被混用，但行为差异很大。我用一个生活化的类比来解释：把HTML解析想象成一条流水线，脚本就是需要装配的零件。
- 普通script：流水线停下来，等零件送到并装好，再继续。
- async script：流水线不停，零件在后台送过来，送到了立刻插进去装配（可能打断当前工序）。
- defer script：流水线不停，零件在后台送过来，等整条流水线走完了再按顺序装配。
具体对比如下：
| 特性 | 普通script | async | defer |
|---|---|---|---|
| 阻塞HTML解析 | 是 | 否 | 否 |
| 执行时机 | 立即 | 下载完立即执行 | DOM解析完成后 |
| 执行顺序 | 按文档顺序 | 不确定 | 按文档顺序 |
| 适用场景 | 极少 | 独立第三方脚本 | 有依赖关系的业务脚本 |
实际项目中，defer是最常用的。比如Vue或React打包出来的vendor.js和app.js，它们之间有依赖关系，必须按顺序执行，同时又不能阻塞HTML解析，defer就是标准答案。而async更适合那些完全独立的脚本，比如百度统计、客服 widget 这类，它们不依赖任何其他脚本，也不被其他脚本依赖。
注意：
async和defer只对外部脚本（有src属性）生效，内联脚本上写这两个属性是无效的。
3.2 动态创建script标签：更细粒度的控制
async和defer虽然好用，但它们是声明式的，你没法在运行时动态决定什么时候加载。这时候就需要用JS动态创建script标签：
function loadScript(url, callback) { const script = document.createElement('script'); script.src = url; script.async = true; script.onload = callback; script.onerror = () => console.error(`加载失败: ${url}`); document.head.appendChild(script); } // 使用示例 loadScript('/js/chart-library.js', () => { // 图表库加载完成后初始化 initChart(); });这种方式的好处是完全可控：你可以根据用户行为决定是否加载某个模块，可以在加载失败时重试，可以设置超时时间。我做过一个数据大屏项目，图表库有800KB，但用户可能只看默认的概览页。我的做法是概览页不加载图表库，等用户点击“详细分析”标签时再动态加载，首屏时间直接从4.2秒降到了1.6秒。
动态加载的另一个典型场景是多语言包。很多项目的做法是把所有语言包打包进主bundle，导致体积膨胀。更好的方式是只加载当前语言，用户切换语言时再动态加载对应的语言包。
3.3 动态import()：模块级的按需加载
ES2020引入的import()语法是异步加载的终极形态。它返回一个Promise，可以在任何地方调用：
button.addEventListener('click', async () => { const { exportReport } = await import('./modules/report.js'); exportReport(); });Webpack和Vite都会自动把import()的模块拆成独立的chunk，运行时按需下载。这比动态创建script标签更优雅的地方在于：它走的是模块系统，有类型提示，有tree-shaking，打包工具会自动处理依赖关系。
我在一个后台项目里用动态import()做了路由级懒加载，配合Vue Router的component: () => import('./views/xxx.vue')，首屏bundle从1.8MB降到了320KB。用户访问不同页面时才加载对应的路由组件，体验提升非常明显。
不过要注意，动态import()的chunk如果太多太碎，会产生大量小文件请求，反而增加HTTP开销。我的经验是：单个chunk不要小于10KB，否则合并到相邻chunk里。Webpack的splitChunks配置里可以设置minSize来控制这个阈值。
3.4 预加载与预获取：提前布局，但别滥用
<link rel="preload">和<link rel="prefetch">是两个容易被误用的指令。简单说：
- preload：告诉浏览器“这个资源我马上要用，请优先下载”。适用于首屏关键资源，比如字体文件、首屏图片、关键CSS。
- prefetch：告诉浏览器“这个资源我以后可能要用，你空闲时下载一下”。适用于下一个页面可能用到的资源。
<!-- 预加载首屏关键字体 --> <link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin> <!-- 预获取下一个页面可能用到的JS --> <link rel="prefetch" href="/js/next-page.js">注意：preload的资源如果3秒内没被使用，浏览器会在控制台发出警告。滥用preload会导致带宽被非关键资源占用，反而拖慢首屏。我的原则是：首屏preload不超过3个资源，prefetch只在用户可能跳转的页面使用。
4. 移动端性能优化的特殊考量
4.1 移动端网络的不确定性：弱网才是常态
PC端优化和移动端优化最大的区别在于网络环境。办公室的WiFi和4G信号满格不代表用户的真实环境。地铁里、电梯里、偏远地区，网络可能只有几十KB/s，延迟可能超过500ms。
我在做移动端项目时，会把Chrome DevTools的网络限速调到Slow 3G（400ms延迟，400kb/s下载速度）来测试。这个标准比大多数用户的真实环境还要苛刻，但能暴露出很多在正常网络下看不到的问题。
针对弱网环境，异步加载的策略要更激进：
- 首屏只加载最核心的CSS和JS，其他全部异步
- 图片使用
loading="lazy"属性，配合IntersectionObserver做更精细的控制 - 接口请求做超时和重试，超时时间不要超过5秒
- 关键数据做本地缓存，弱网时先展示缓存内容
4.2 移动端CPU和内存的限制：别让主线程太累
移动端设备的CPU性能只有PC的几分之一，内存更是捉襟见肘。一个在PC上跑得好好的页面，在千元安卓机上可能卡成幻灯片。
异步加载在移动端要特别注意执行时机的分散。如果你把五个脚本都设成defer，它们会在DOM解析完成后依次执行，主线程连续被占用，用户在这段时间内无法交互。更好的做法是：
// 把非关键脚本分散到不同时机执行 window.addEventListener('load', () => { // 页面完全加载后执行统计脚本 loadAnalytics(); }); // 使用requestIdleCallback在浏览器空闲时执行 requestIdleCallback(() => { // 预加载下一个页面的资源 prefetchNextPage(); }); // 用户交互后再加载非关键模块 document.addEventListener('click', () => { import('./modules/feedback.js').then(mod => mod.init()); }, { once: true });requestIdleCallback是移动端优化的利器，它让浏览器在空闲帧里执行低优先级任务，不阻塞用户交互。不过Safari对它的支持比较晚，需要做降级处理：
const idleCallback = window.requestIdleCallback || function(cb) { return setTimeout(() => cb({ timeRemaining: () => 50 }), 1); };4.3 启动性能优化：从白屏到首帧的极限压缩
移动端App里的WebView页面，启动性能直接影响用户留存。我做过一个混合App的H5页面，从点击入口到页面可交互，最初需要4.5秒。经过一系列异步加载优化后，降到了1.8秒。具体做了这几件事：
第一，内联关键CSS。首屏渲染需要的样式直接写在<style>标签里，避免额外请求。非关键CSS用media属性或动态加载。
第二，骨架屏先行。在JS还没加载完之前，先用纯HTML+CSS渲染一个骨架屏，让用户感知到页面正在加载，而不是一片空白。
第三，接口预请求。在WebView初始化阶段就发起首屏接口请求，不等JS加载完。这需要原生端配合，在WebView创建时注入一个预请求的JS桥接调用。
第四，资源离线包。把JS、CSS、图片等静态资源打包成离线包，随App一起发布或提前下载。WebView加载时直接从本地读取，省去网络请求时间。这是移动端性能优化的大杀器，但需要建立一套离线包的版本管理和更新机制。
5. 实操过程：一个真实项目的优化全记录
5.1 优化前的性能基线采集
去年我接手了一个电商活动页，页面包含商品列表、倒计时、抽奖转盘、评论区四个模块。优化前在Slow 3G下的Lighthouse跑分是28分，FCP 4.2秒，TTI 8.6秒。用户反馈最多的问题就是“打开慢”“点了没反应”。
我先用Chrome DevTools的Coverage面板分析了代码覆盖率，发现首屏只用了打包后JS的23%，其余77%都是当前页面用不到的代码。再用Network面板看请求瀑布图，发现15个JS请求全部是同步加载，而且有一个第三方统计脚本因为服务器响应慢，阻塞了整整3秒。
5.2 分阶段优化：从同步到异步的改造
第一阶段：把同步脚本改成defer。这是改动最小、收益最明显的一步。把<head>里的所有业务脚本加上defer属性，第三方统计脚本改成async。这一步做完，FCP从4.2秒降到了2.8秒。
第二阶段：路由级代码分割。活动页有四个模块，但用户可能只关心商品列表。我把抽奖转盘和评论区改成动态import()，用户滚动到对应区域时才加载。首屏JS体积从1.6MB降到了480KB。
// 滚动到评论区时再加载评论模块 const commentSection = document.querySelector('#comment-section'); const observer = new IntersectionObserver((entries) => { entries.forEach(entry => { if (entry.isIntersecting) { import('./modules/comment.js').then(mod => mod.init()); observer.unobserve(entry.target); } }); }, { rootMargin: '200px' }); observer.observe(commentSection);第三阶段：图片懒加载和响应式图片。商品列表有40张图片，之前全部同步加载。改成loading="lazy"后，只有视口内的图片会加载。同时用srcset根据屏幕宽度加载不同尺寸的图片，移动端加载的图片体积减少了60%。
第四阶段：接口请求优化。首屏接口从3个合并成1个，减少TCP连接建立的开销。接口数据做了本地缓存，二次访问时先展示缓存再后台更新。
5.3 优化后的数据对比与经验总结
最终优化后的数据：Lighthouse跑分从28分提升到86分，FCP从4.2秒降到1.1秒，TTI从8.6秒降到2.3秒。首屏JS体积从1.6MB降到320KB，图片总体积从4.8MB降到1.2MB。
| 指标 | 优化前 | 优化后 | 提升幅度 |
|---|---|---|---|
| Lighthouse跑分 | 28 | 86 | +207% |
| FCP | 4.2s | 1.1s | -74% |
| TTI | 8.6s | 2.3s | -73% |
| 首屏JS体积 | 1.6MB | 320KB | -80% |
| 图片总体积 | 4.8MB | 1.2MB | -75% |
这个项目让我最深的体会是：优化要抓大放小，先解决阻塞性问题，再抠细节。把同步改异步、把大bundle拆小，这两步就能拿到80%的收益。剩下的图片压缩、缓存策略、CDN加速是锦上添花。
6. 常见问题与排查技巧实录
6.1 异步加载后脚本执行顺序错乱怎么办
这是最常见的问题。用了async之后，脚本执行顺序不确定，如果A脚本依赖B脚本，就可能报错。解决方案很简单：有依赖关系的脚本用defer，完全独立的用async。如果必须用动态加载，就通过回调或Promise来保证顺序：
// 串行加载，保证顺序 async function loadSequentially(urls) { for (const url of urls) { await loadScript(url); } } // 并行加载，但按顺序执行 async function loadParallel(urls) { const promises = urls.map(url => loadScript(url)); const scripts = await Promise.all(promises); scripts.forEach(script => script.execute()); }6.2 动态import()的chunk加载失败怎么处理
网络不稳定时，动态import()的chunk可能加载失败，导致页面报错。我一般会加一层重试逻辑：
async function importWithRetry(path, retries = 3) { for (let i = 0; i < retries; i++) { try { return await import(path); } catch (err) { if (i === retries - 1) throw err; await new Promise(r => setTimeout(r, 1000 * (i + 1))); } } }另外，Webpack有一个output.chunkLoadTimeout配置，默认是120秒。在弱网环境下可以适当调大，避免chunk还没下载完就超时。
6.3 预加载资源没被使用导致浪费
preload的资源如果没被使用，浏览器会浪费带宽去下载。我遇到过一个问题：首页preload了一个字体文件，但用户可能根本不滚动到使用该字体的区域。解决方案是只preload首屏确定会用的资源，其他资源用prefetch或者动态加载。
还有一个坑是preload的as属性写错，导致资源被下载了两次。比如字体文件的as必须是font，并且要加crossorigin属性，否则浏览器会认为是不同的资源，重新下载一次。
6.4 移动端WebView的缓存策略怎么配
移动端WebView的缓存行为和浏览器不完全一样，需要和原生端配合。我通常会在服务端设置Cache-Control头，静态资源设置长期缓存（max-age=31536000），HTML设置不缓存或短缓存。同时给静态资源的URL加上hash指纹，内容变了URL就变，避免缓存失效问题。
在WebView层面，Android和iOS的缓存机制不同。Android的WebView默认会缓存资源，但可以通过setCacheMode控制。iOS的WKWebView缓存更激进，有时候需要原生端主动清理缓存。这些细节需要和客户端同学对齐，不能只在前端层面解决。
6.5 性能优化速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 首屏白屏时间长 | 同步脚本阻塞 | Network面板看瀑布图 | 改defer或动态加载 |
| 页面可交互时间晚 | 主线程被长任务占用 | Performance面板看Long Task | 拆分任务，用requestIdleCallback |
| 滚动卡顿 | 图片同步加载 | Coverage面板看代码覆盖率 | 图片懒加载，代码分割 |
| 二次访问没变快 | 缓存策略没生效 | 看Response Headers | 配置Cache-Control和hash指纹 |
| 动态加载报错 | chunk加载失败 | Console看错误信息 | 加重试逻辑，调大chunkLoadTimeout |
实操心得：性能优化不是一次性的工作，而是一个持续的过程。我习惯在每次发版前跑一遍Lighthouse，把性能指标纳入CI流程。一旦指标下降超过10%，就阻断发布，先排查原因。这个习惯帮我们避免了很多次性能回退。
7. 我踩过的坑和最后分享几个小技巧
第一个坑是过度优化。我曾经把一个页面的所有脚本都改成动态加载，结果用户点击按钮后要等1秒才响应，体验反而更差。后来我明白了：首屏关键路径上的脚本不要异步，异步的是非关键路径。判断标准很简单：如果这个脚本不加载，用户能不能看到主要内容？能，就异步；不能，就同步或defer。
第二个坑是忽略第三方脚本的影响。很多项目自己代码优化得很好，但引了一堆第三方统计、客服、广告脚本，把性能拖垮了。我的做法是：所有第三方脚本一律async加载，并且设置加载超时，超时就不等了。同时定期审查第三方脚本的体积和性能影响，能砍的就砍。
第三个技巧是用performance.mark()和performance.measure()做精细化测量。不要只看整体加载时间，要测量每个关键步骤的耗时：
performance.mark('script-start'); // 加载脚本... performance.mark('script-end'); performance.measure('脚本加载', 'script-start', 'script-end'); const measures = performance.getEntriesByType('measure'); measures.forEach(m => console.log(`${m.name}: ${m.duration}ms`));第四个技巧是利用Service Worker做资源缓存。对于重复访问的用户，Service Worker可以从缓存直接返回资源，完全省去网络请求。配合Workbox工具，可以自动生成缓存策略，不用手写复杂的缓存逻辑。
最后一个建议：性能优化要建立监控闭环。优化前采集基线，优化后对比数据，上线后监控真实用户指标。没有数据支撑的优化都是自嗨。我现在的项目里，每个页面都会上报LCP、FID、CLS三个核心指标，每周出一份性能报告，持续跟踪变化趋势。这样才能保证优化效果不反弹，也能及时发现新引入的性能问题。
