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 srcanalytics.js/script !-- 立即下载不阻塞解析下载完等待DOM解析完成后执行 -- script defer srcapp.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()是运行时执行的返回一个PromiseWebpack、Vite等工具会将对应的代码单独打成chunk触发加载时才去请求。// 静态导入打包时合并到当前chunk import { initReport } from ./modules/report; // 动态导入打包时单独分包点击/路由切换时才加载 button.addEventListener(click, async () { const { initReport } await import(./modules/report); initReport(); });这个机制的价值在于首屏只加载当前路由或首屏真正需要执行的代码其余代码推迟到实际需要时再拉取。比如一个管理后台用户可能永远不打开报表选项卡那报表相关的代码干嘛要在首屏加载呢动态导入就是解决这个问题的标准答案。使用动态导入有一个工程上的坑——模块体积过小会导致分包碎片化。如果你把每个工具函数都动态导入会产生大量几十KB甚至几KB的chunkHTTP请求数量暴涨反而拖累性能。Webpack有optimization.splitChunks配置可以合并小模块Vite底层也有类似机制。我一般建议按路由或按业务模块动态导入粒度控制在100KB以上才值得单独分包太小的合并到公共chunk更划算。3.3 懒加载与占位策略图片和组件的延迟渲染懒加载是异步加载的另一大主战场最常见的场景就是图片。一个电商列表页可能有上百张商品图如果全部在首屏加载带宽瞬间被占满LCPLargest Contentful Paint最大内容绘制会差得离谱。图片懒加载的标准做法是先用占位符占据空间等图片即将进入视口时再加载真实地址。现代浏览器原生支持loadinglazy属性这是最轻量的方案img srcplaceholder.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 relpreload hreffont.woff2 asfont typefont/woff2 crossoriginpreconnect提前建立与第三方域的连接DNS解析TCPTLS适合已知要请求外部API或第三方CDN的场景link relpreconnect hrefhttps://cdn.example.comprefetch则是空闲时下载下一个页面/功能可能用到的资源比如用户停留在登录页时提前下载主页的核心JSlink relprefetch href/home/index.js这里有一个很重要的忠告预加载不是越多越好。preload用多了会变成把未来的问题提前到现在在低端设备或弱网环境下反而拉低首屏速度。我一般制定这样的策略首屏关键字体和CSS用preload已知第三方请求域名用preconnect下一个交互场景的资源用prefetch未来页面用prefetchVanilla式其余一律不额外预取。资源提示和普通加载的区别在于它不阻塞当前渲染只是提前占用网络所以需要你站在用户角度想清楚什么值得提前。4. 性能优化的测量闭环与优化前后对比4.1 指标先行从FCP到LCP的性能标尺聊优化之前得先说清楚怎么衡量优化效果。性能优化领域有几个全球通行的核心指标我画了张快速对照表指标全称含义可感知体验FCPFirst Contentful Paint首次内容绘制白屏结束、第一次出现文字或图片LCPLargest Contentful Paint最大内容绘制首屏最大元素通常是图片或标题出现TTITime to Interactive可交互时间页面能可靠响应用户操作TBTTotal Blocking Time总阻塞时间主线程被长任务阻塞的总时长CLSCumulative Layout Shift累计布局偏移页面元素跳动程度异步加载主要影响的就是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 relpreload hreffont.woff2 asfont typefont/woff2 crossorigin这个细节如果不注意会出现明明preload了但字体还是文字闪一下变字体的FOUT现象。我在团队内部checklist里专门加了一条preload字体必须带crossorigin。6.3 动态import的循环依赖与执行顺序动态import在复杂业务中容易引发循环依赖问题——A模块动态导入BB又动态导入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 常见问题速查表现象可能原因解决方案首屏白屏时间变长关键CSS/字体未preload对首屏关键资源加preload懒加载图片闪白框rootMargin太小或占位尺寸不符增大提前量设置明确宽高第三方脚本拖慢加载大量同步脚本阻塞解析加async或defer或改用动态注入JS执行卡顿单次任务超过50ms拆分任务、延迟非关键计算、使用Web Worker弱网下接口超时超时设置过长设置合理超时和重试退避策略预加载不生效请求属性不匹配检查是否缺少crossorigin等属性分包过碎请求暴涨模块拆分粒度太小用splitChunks合并小chunk或提高分包阈值6.5 我踩过的最有价值的一次坑最后分享一个印象最深的排查经历。有一次优化一个后台管理系统首屏脚本从3.2MB降到了800KB但用户反馈打开速度没感觉变快。我带着疑问去看了监控数据发现FCP确实降低了不少但TTI几乎没变。原因是虽然代码分割让首屏脚本变小了但登录页里有一个递归组件被错误地放入了核心chunk这个组件第一次渲染时要执行大量递归计算把主线程长时间占住导致页面虽然画出来了但其实不可交互。这次经历给我留下的教训很深性能优化不要只盯着资源加载还要盯着主线程任务。资源加载决定了内容出现的速度但主线程是否空闲决定了用户是否能操作。两者缺一不可。后面我做性能方案都养成了一个习惯用Performance面板录一段完整加载过程专门看有没有超过50ms的长任务逐个处理收益非常直接。