聊性能优化绕不开异步加载。不管你做的是移动端H5、中后台管理系统还是面向C端的营销活动页只要涉及Web前端“异步加载”这四个字早晚会找上你。我在几次性能专项优化里反复用过这套思路也踩了不少坑。这篇“原理篇”就把异步加载这件事从底层原理到实际操作完整拆一遍讲清楚它到底解决什么问题适合谁看——前端开发、架构师、以及所有被页面卡顿和白屏折磨过的人。很多人一谈异步加载就只会挂一个defer或者async但真正问他“为什么这么做能优化性能”往往答不上来。如果底层逻辑不清楚一旦遇到诡异的线上问题排查就会变成瞎猜。这篇文章我会从JavaScript的运行机制讲起再聊资源层面的加载方式最后落到渲染、指标和真实排障场景。不整虚的直接上结论和过程。1. 为什么必须先搞懂异步加载1.1 事件循环与任务队列异步的地基浏览器里的JavaScript是单线程的这个结论所有前端都知道但它究竟意味着什么很多人没有仔细想过。单线程意味着所有代码都在同一条流水线上执行。如果这条流水线上某一个环节特别耗时后面的活儿全部要等。这就好比只有一个窗口的食堂前面有个人对着菜单纠结了十分钟后面排队的每一个人都得陪着他干瞪眼。那异步是怎么回事JavaScript用了一个叫“事件循环”的机制来处理耗时操作。遇到网络请求、定时器这类任务时不会傻傻地在原地等结果而是先把一个回调函数扔进任务队列等主线程空闲了再把它捞出来执行。这个设计让你可以“先往后走回头再处理结果”页面就不会因为等一个接口而整个卡死。事件循环里还分宏任务和微任务。setTimeout的回调是宏任务Promise.then的回调是微任务。微任务会在当前宏任务结束之前、渲染发生之前被清空所以它的优先级比宏任务高。这个区别在面试里经常被问但实际项目里更有价值的地方在于理解微任务的执行时机能帮你判断一段异步代码到底是什么时候跑完的调BUG的时候不会瞎等。1.2 长任务与主线程阻塞卡顿的真凶明白了事件循环你就能理解页面卡顿的根源在哪里。主线程要干的活太多了执行JavaScript、解析样式、计算布局、绘制页面全挤在这一个线程上。主线程一旦被一个超过50毫秒的“长任务”占住用户点击按钮、滚动页面这些交互就得不到及时响应表现出来就是卡一下、顿一下甚至在性能差的手机上直接白屏几秒。异步加载的核心目的之一就是不让主线程在一个时间点背上太多活。资源的异步加载让浏览器可以在等待下载的同时继续处理其他事代码的异步执行让大计算量任务可以拆散到多个事件循环里跑。理解了这一点你就知道为什么那么多优化手段最终都指向同一个方向减少主线程的瞬时工作量把大的任务切成小的切片。我自己的体会是在性能优化的语境里“异步”不是一个简单的开关而是一套围绕事件循环使用策略。手动拆分长任务可以用requestIdleCallback在浏览器空闲时处理低优先级任务需要动画跟随帧走的时候用requestAnimationFrame保证每次执行都在浏览器准备渲染新一帧之前。用对了工具页面流畅度会有肉眼可见的提升。2. 资源层面的异步加载实战2.1 script标签的三种加载方式同步、defer与async聊完底层原理说点能直接上手的东西。script标签是前端加载脚本最基础的方式但加载策略选错了首屏性能就会被拖垮。默认情况下的script是同步加载浏览器遇到这个标签会停下来先下载脚本再执行脚本下载和执行期间页面渲染完全被阻塞。脚本放在head里时子资源请求还没开始页面就卡在这里了白屏时间直接被拉长。江湖上流传最广的方案是defer和async两个属性。这两个属性都让脚本的下载过程异步化不会阻塞HTML解析但执行时机不同网上很多文章把它们搞混。defer会在整个HTML解析完成后、DOMContentLoaded事件触发之前按顺序执行async则是一旦下载完成就立即执行完全不管HTML解析到哪了执行顺序也不保证。为了看清楚我做了一个对比表可以存下来加载方式下载时机执行时机执行顺序适用场景普通script遇到即阻塞解析并下载下载后立即执行按文档顺序侵入式同步逻辑少用defer解析时并行下载HTML解析完成后按文档顺序普通业务脚本、依赖DOM的脚本async解析时并行下载下载完成后立即执行不保证顺序独立无依赖的脚本、统计代码实际项目里我的做法是所有非关键的业务脚本都尽量用defer因为它不阻塞解析、顺序又可控。async只留给埋点、监控这类独立脚本——它们不依赖其他模块也没人依赖它们什么时候执行完都无所谓。2.2 动态脚本加载与按需注入除了defer和async正式项目里更常用的是动态加载——在需要的时机用JavaScript创建script标签插入到页面里才开始下载。这本质上是把“下载”动作从页面加载阶段推迟到了某个事件发生之后。比如用户点击“高级搜索”按钮时才去加载那个功能对应的代码块页面初始加载的脚本体积就能小不少。动态加载的写法不复杂我一般封装成一个工具函数function loadScript(src) { return new Promise((resolve, reject) { const script document.createElement(script); script.src src; script.onload () resolve(script); script.onerror () reject(new Error(脚本加载失败: src)); document.head.appendChild(script); }); }这个函数返回一个Promise调用方就能用async/await精确控制加载时机。比如在路由切换时按需加载对应路由的JS或者在弹窗打开前加载富文本编辑器资源。打包工具的“代码分割”能力也是基于这个原理实现的import()语法会让构建工具把对应模块单独打成一个chunk只在运行时被需要时才发起请求。这一块要注意的是动态加载如果控制不好很容易出现“动画加载一层层蹦出来”的体验问题。我给几个经验值——首屏不需要的组件延迟到浏览器空闲或交互触发前再加载但弹窗这类用户可能马上要用到的组件最好在页面空闲时就预加载别等到用户点了才让TA盯着转圈圈。2.3 预加载、预连接与关键资源提示异步加载不只是“晚点加载”还包括“提前准备”。浏览器提供了一组资源提示指令能让关键资源的请求在网络层面更早发起。最常用的四个preload、prefetch、preconnect和dns-prefetch。preload用于提前加载当前页面即将用到的关键资源并明确告知浏览器这些资源的高优先级。用link relpreload会抢在普通资源前面下载适合首屏字体、首屏大图、核心脚本。prefetch则是加载下一个页面可能用到的资源优先级最低利用空闲带宽提前把未来要用的东西缓存下来。preconnect和dns-prefetch解决的问题是连接建立耗时的优化。dns-prefetch会提前做DNS解析preconnect则在DNS解析之外把TCP连接甚至TLS握手都提前完成。如果你的页面要请求某个跨域的CDN域名加上preconnect可以省掉几十到几百毫秒的连接时间。这里一定要提醒一句preload是有限资源别滥用。把七八个资源全部preload等于告诉浏览器“全都重要”结果是全都抢带宽反而拖慢真正的首屏关键资源。我一般只对首屏LCP相关的资源做preload比如Hero图或者最大文本块的字体文件。3. 渲染层与交互层的性能优化要点3.1 关键渲染路径与长任务拆分异步加载可以优化资源到达页面的速度但资源到了以后主线程“干活”的方式对性能的影响同样关键。浏览器把HTML、CSS和JavaScript渲染成屏幕上的像素这个过程叫关键渲染路径。从构建DOM、构建CSSOM到生成渲染树再到布局和绘制任何一步在主线程上耗时过长用户都会直接感受到卡顿。项目里最常见的性能杀手是“强制同步布局”。你在读取offsetWidth、offsetHeight、getBoundingClientRect这些几何属性时浏览器为了保证拿到的是最新值会强制把待执行的样式变更提前应用到页面上这个过程会触发一次额外的布局计算。如果在循环里既改样式又读几何属性浏览器就被迫在每一轮都重新布局性能雪崩。一个很典型的反面示例是// 不要这样写循环里读写交错触发强制同步布局 for (let i 0; i list.length; i) { const width list[i].offsetWidth; // 读 list[i].style.width width * 2 px; // 写导致下一次读时重新布局 }正确做法是先统一读再统一写把读写操作分离成两个阶段。这样浏览器可以在“写”的阶段批量处理样式变化把布局次数从N次降到1次。另外批量插入DOM时用DocumentFragment或先拼接字符串再一次性插入也是同样的思路——减少主线程的布局和绘制次数。长任务拆分也是一个实操价值极高的手段。如果一个函数需要做大量计算且没法避免建议用切片方式把它降级成多个短任务。比如处理一万条数据直接循环计算会让主线程阻塞几百毫秒改成用setTimeout或requestIdleCallback分批处理每批只占用一小段时间页面就不会有“冻结感”。3.2 防抖与节流别让事件拖垮页面事件处理器是主线程任务的主要来源之一。用户滚轮一滚scroll事件一秒钟可能触发几十次如果每触发一次就执行一次重操作主线程被塞满页面就开始掉帧。这个场景下防抖和节流就是两个最顺手也最常用的工具。防抖的核心思想事件被连续触发时只在最后一次触发后的等待时间内执行。适合输入框搜索建议这种场景——用户还在打字没必要每次按键都发请求等用户停下来再查询。节流的核心思想事件被连续触发时固定时间间隔内只执行一次。适合滚动事件、窗口resize这种高频率事件——保证每隔一段时间至少处理一次同时又不至于每次触发都处理。这里给一个节流的简单实现按固定间隔执行且保留最后一次触发防止丢事件function throttle(fn, interval) { let last 0; let timer null; return function (...args) { const now Date.now(); const remaining interval - (now - last); if (remaining 0) { if (timer) { clearTimeout(timer); timer null; } last now; fn.apply(this, args); } else if (!timer) { timer setTimeout(() { last Date.now(); timer null; fn.apply(this, args); }, remaining); } }; }这个版本比简单的时间戳版本好一点它在时间间隔到期之前如果又来了一次触发不会直接丢弃而是会安排一个定时器把最后这次触发补上。在高频滚动里保证首尾事件都不丢交互体感会舒服很多。防抖的代码网上有很多版本大家抄作业的时候注意确认是否支持立即执行一次的需求不同业务场景要求不一样。3.3 移动端与弱网下的异步策略移动端性能和桌面端完全是两个世界。桌面端几十毫秒的延迟用户几乎无感手机端网络稍差一点白屏就是一两秒起步。所以移动端的异步加载策略会更激进需要配合弱网环境做更多预案。首先要做的是图片懒加载。首屏之外的图片不要急着加载等滚到可视区域附近再加载。最现代的方案是给img标签加loadinglazy属性和decodingasync属性前者让浏览器原生懒加载后者让图片解码不阻塞渲染。如果还需要兼容更老的浏览器可以用IntersectionObserver去监听元素进入视口再动态设置src。其次是骨架屏。移动端H5页面如果首屏数据依赖接口返回异步加载的代价是短暂的空白区。骨架屏就是在接口返回前先用灰色占位块模拟页面结构用户会感知到“页面马上就出来了”而不是对着白屏等。骨架屏用CSS实现就行配合异步接口的状态切换体验提升很明显。弱网环境还有一个容易被忽略的点资源的体积控制。同样是3G网络一个200KB的脚本和一个2MB的脚本加载时间可以相差7到10倍。移动端项目里我会对首屏脚本体积设硬性预算比如初始传输量不超过300KB超了就考虑路由级拆分、按需引入第三方库或者把大依赖改成动态加载。这个策略在4G、5G时代依然重要因为弱网和拥塞场景永远存在。4. 用数据说话性能指标与测量方法4.1 核心Web指标与性能预算优化做得怎么样最终要落到数字上。业内目前公认的量化标准是Google提出的Core Web Vitals其中三个指标最值得关注LCPLargest Contentful Paint最大内容绘制、INPInteraction to Next Paint交互到下一次绘制的延迟、CLSCumulative Layout Shift累计布局偏移。LCP衡量的是首屏最大元素的加载时间能反映页面“视觉上打开”的快慢。异步加载做得好不好最直接的表现就在LCP上——把首屏最大图片或标题的加载路径优化了LCP立刻降下来。INP反映的是交互响应速度动画卡顿、按钮点击延迟都会体现在这个指标上。CLS则是衡量页面稳定性页面元素在加载过程中突然位移、用户手指差点点错按钮就是CLS在捣乱。我会在项目里设置性能预算比如移动端LCP小于2.5秒、INP小于200毫秒、CLS小于0.1这是业内公认的“良好”阈值。每次发布前跑一次性能审计超了就阻断发布。有了这个硬性门槛性能优化才不会沦为空谈。4.2 可视化测量与代码里的性能观测测量工具方面Chrome DevTools的Performance面板是最直接的。它能录制一段页面运行过程给出主线程时间轴、每项任务的耗时和调用栈一眼就能看出哪项任务占了主线程的“大头”。Lighthouse则是一次性的自动审计给出LCP、CLS、FCP等各项分数和建议适合在开发阶段快速体检。除了工具层面的测量代码里也应该埋上性能观测点。用PerformanceObserver可以直接在浏览器运行时收集指标const observer new PerformanceObserver((list) { for (const entry of list.getEntries()) { // 把 LCP、CLS、INP 数据上报到监控平台 console.log(entry.name, entry.value); } }); observer.observe({ type: [largest-contentful-paint, layout-shift, event], buffered: true });这样页面就具备了“自我感知”能力不用人工打开DevTools就能收集真实用户的性能数据。这些数据上报到监控平台后你可以看到异步加载策略在不同网络环境下的真实表现再针对瓶颈做下一轮优化。5. 常见问题与排查技巧实录5.1 白屏时间怎么排查白屏是性能优化里最常见的抱怨。遇到白屏要先分清是哪种白屏等待脚本加载的白屏还是脚本执行报错导致的空白还是资源加载太慢造成的视觉空白。排查第一步是开DevTools切到Network面板看瀑布图里到底卡在哪个阶段。如果某条请求长时间处于Pending状态多半是服务器响应太慢如果脚本文件加载很快但页面还是一直白着问题大概率出在脚本执行或者DOM渲染上。异步加载场景多了一个坑有些脚本虽然是异步的但它们之间隐含着依赖关系。比如defer保证了脚本按顺序执行但如果你中间漏了一个defer属性或者把一个脚本改成了async它就可能提前执行并因为找不到依赖对象而报错页面直接白掉。排查的时候控制台报错信息是最直接的线索别光看网络面板。5.2 懒加载导致页面跳动怎么办用懒加载的页面经常出现一个问题用户正在往下滑动图片加载完成后突然把下面的内容顶下去导致原有的阅读位置错位。这个问题本质上是CLS指标超标——图片没有预先占位加载完成后撑高了容器。解决办法是给图片容器设置固定的宽高比。前端常用的做法就是CSS的aspect-ratio属性或者老套的padding-top百分比技巧。在图片还没加载完的时候占位元素就已经撑起了正确的高度图片加载完只是替换内容不会改变布局。实测下来这个改动能把CLS从0.3级别降到0问题也不大。5.3 异步加载与SEO的矛盾怎么解异步加载虽然提升了用户体验但搜索引擎的爬虫不一定执行JavaScript。如果首屏关键内容全部靠异步渲染爬虫可能只看到空白页面对SEO极不友好。这是很多技术团队做性能优化时烧脑的地方极致的异步加载方案和搜索引擎抓取内容之间存在冲突。解决方案有三条路。一是用SSR服务端渲染让首屏HTML里直接包含最终内容同时用hydration在浏览器端激活交互能力。二是用SSG静态站点生成构建时输出完整HTML性能比SSR更好但要求内容基本不变化。三是折中方案——首屏做服务端渲染次屏继续用异步加载兼顾首屏速度和后续交互体验。这套思路同样适用于上架要求高的应用尤其是内容型产品。写在最后的优化体会这个“原理篇”讲到的异步加载核心是围绕事件循环、资源加载策略、渲染链路和量化指标这四件事。无论你是在做桌面端站点还是移动端H5把这套思路用到自己的项目里都会获得正向反馈。我之前接过一个移动端活动页面首屏有一个大图和三个业务模块最初实现是进入页面就一次性请求所有接口、同步加载所有脚本。第一次性能审计出来LCP接近4秒首屏完全不可用。后来做的事情也很基础脚本统一加defer、大图加fetchpriorityhigh、首屏数据的接口改成并行请求、非首屏的模块改成IntersectionObserver触发动态渲染。改完再看LCP降到了1.8秒左右INP也从两百多毫秒降到了一百以内。整个过程没有用任何黑科技全是这篇文章里提到的这些“基础操作”。性能优化最大的一个坑不是技术不会而是没有形成“先量化、再优化、再验证”的工作习惯。我建议你手头有项目的时候先把性能指标跑一遍找到最大的瓶颈再动手。很多时候你以为的瓶颈在图片结果实际耗时在脚本执行。数据会告诉你答案。再分享一个小技巧异步加载和性能优化的成果最好沉淀成团队的性能预算和检查清单。比如“新页面必须做路由级代码分割”、“首屏图片必须指定尺寸”、“非关键脚本一律defer”。把这些规范固化下来后面来的同事不容易把性能挖回去团队的整体性能水位也能稳定住。
前端异步加载原理与性能优化实战：从事件循环到LCP
聊性能优化绕不开异步加载。不管你做的是移动端H5、中后台管理系统还是面向C端的营销活动页只要涉及Web前端“异步加载”这四个字早晚会找上你。我在几次性能专项优化里反复用过这套思路也踩了不少坑。这篇“原理篇”就把异步加载这件事从底层原理到实际操作完整拆一遍讲清楚它到底解决什么问题适合谁看——前端开发、架构师、以及所有被页面卡顿和白屏折磨过的人。很多人一谈异步加载就只会挂一个defer或者async但真正问他“为什么这么做能优化性能”往往答不上来。如果底层逻辑不清楚一旦遇到诡异的线上问题排查就会变成瞎猜。这篇文章我会从JavaScript的运行机制讲起再聊资源层面的加载方式最后落到渲染、指标和真实排障场景。不整虚的直接上结论和过程。1. 为什么必须先搞懂异步加载1.1 事件循环与任务队列异步的地基浏览器里的JavaScript是单线程的这个结论所有前端都知道但它究竟意味着什么很多人没有仔细想过。单线程意味着所有代码都在同一条流水线上执行。如果这条流水线上某一个环节特别耗时后面的活儿全部要等。这就好比只有一个窗口的食堂前面有个人对着菜单纠结了十分钟后面排队的每一个人都得陪着他干瞪眼。那异步是怎么回事JavaScript用了一个叫“事件循环”的机制来处理耗时操作。遇到网络请求、定时器这类任务时不会傻傻地在原地等结果而是先把一个回调函数扔进任务队列等主线程空闲了再把它捞出来执行。这个设计让你可以“先往后走回头再处理结果”页面就不会因为等一个接口而整个卡死。事件循环里还分宏任务和微任务。setTimeout的回调是宏任务Promise.then的回调是微任务。微任务会在当前宏任务结束之前、渲染发生之前被清空所以它的优先级比宏任务高。这个区别在面试里经常被问但实际项目里更有价值的地方在于理解微任务的执行时机能帮你判断一段异步代码到底是什么时候跑完的调BUG的时候不会瞎等。1.2 长任务与主线程阻塞卡顿的真凶明白了事件循环你就能理解页面卡顿的根源在哪里。主线程要干的活太多了执行JavaScript、解析样式、计算布局、绘制页面全挤在这一个线程上。主线程一旦被一个超过50毫秒的“长任务”占住用户点击按钮、滚动页面这些交互就得不到及时响应表现出来就是卡一下、顿一下甚至在性能差的手机上直接白屏几秒。异步加载的核心目的之一就是不让主线程在一个时间点背上太多活。资源的异步加载让浏览器可以在等待下载的同时继续处理其他事代码的异步执行让大计算量任务可以拆散到多个事件循环里跑。理解了这一点你就知道为什么那么多优化手段最终都指向同一个方向减少主线程的瞬时工作量把大的任务切成小的切片。我自己的体会是在性能优化的语境里“异步”不是一个简单的开关而是一套围绕事件循环使用策略。手动拆分长任务可以用requestIdleCallback在浏览器空闲时处理低优先级任务需要动画跟随帧走的时候用requestAnimationFrame保证每次执行都在浏览器准备渲染新一帧之前。用对了工具页面流畅度会有肉眼可见的提升。2. 资源层面的异步加载实战2.1 script标签的三种加载方式同步、defer与async聊完底层原理说点能直接上手的东西。script标签是前端加载脚本最基础的方式但加载策略选错了首屏性能就会被拖垮。默认情况下的script是同步加载浏览器遇到这个标签会停下来先下载脚本再执行脚本下载和执行期间页面渲染完全被阻塞。脚本放在head里时子资源请求还没开始页面就卡在这里了白屏时间直接被拉长。江湖上流传最广的方案是defer和async两个属性。这两个属性都让脚本的下载过程异步化不会阻塞HTML解析但执行时机不同网上很多文章把它们搞混。defer会在整个HTML解析完成后、DOMContentLoaded事件触发之前按顺序执行async则是一旦下载完成就立即执行完全不管HTML解析到哪了执行顺序也不保证。为了看清楚我做了一个对比表可以存下来加载方式下载时机执行时机执行顺序适用场景普通script遇到即阻塞解析并下载下载后立即执行按文档顺序侵入式同步逻辑少用defer解析时并行下载HTML解析完成后按文档顺序普通业务脚本、依赖DOM的脚本async解析时并行下载下载完成后立即执行不保证顺序独立无依赖的脚本、统计代码实际项目里我的做法是所有非关键的业务脚本都尽量用defer因为它不阻塞解析、顺序又可控。async只留给埋点、监控这类独立脚本——它们不依赖其他模块也没人依赖它们什么时候执行完都无所谓。2.2 动态脚本加载与按需注入除了defer和async正式项目里更常用的是动态加载——在需要的时机用JavaScript创建script标签插入到页面里才开始下载。这本质上是把“下载”动作从页面加载阶段推迟到了某个事件发生之后。比如用户点击“高级搜索”按钮时才去加载那个功能对应的代码块页面初始加载的脚本体积就能小不少。动态加载的写法不复杂我一般封装成一个工具函数function loadScript(src) { return new Promise((resolve, reject) { const script document.createElement(script); script.src src; script.onload () resolve(script); script.onerror () reject(new Error(脚本加载失败: src)); document.head.appendChild(script); }); }这个函数返回一个Promise调用方就能用async/await精确控制加载时机。比如在路由切换时按需加载对应路由的JS或者在弹窗打开前加载富文本编辑器资源。打包工具的“代码分割”能力也是基于这个原理实现的import()语法会让构建工具把对应模块单独打成一个chunk只在运行时被需要时才发起请求。这一块要注意的是动态加载如果控制不好很容易出现“动画加载一层层蹦出来”的体验问题。我给几个经验值——首屏不需要的组件延迟到浏览器空闲或交互触发前再加载但弹窗这类用户可能马上要用到的组件最好在页面空闲时就预加载别等到用户点了才让TA盯着转圈圈。2.3 预加载、预连接与关键资源提示异步加载不只是“晚点加载”还包括“提前准备”。浏览器提供了一组资源提示指令能让关键资源的请求在网络层面更早发起。最常用的四个preload、prefetch、preconnect和dns-prefetch。preload用于提前加载当前页面即将用到的关键资源并明确告知浏览器这些资源的高优先级。用link relpreload会抢在普通资源前面下载适合首屏字体、首屏大图、核心脚本。prefetch则是加载下一个页面可能用到的资源优先级最低利用空闲带宽提前把未来要用的东西缓存下来。preconnect和dns-prefetch解决的问题是连接建立耗时的优化。dns-prefetch会提前做DNS解析preconnect则在DNS解析之外把TCP连接甚至TLS握手都提前完成。如果你的页面要请求某个跨域的CDN域名加上preconnect可以省掉几十到几百毫秒的连接时间。这里一定要提醒一句preload是有限资源别滥用。把七八个资源全部preload等于告诉浏览器“全都重要”结果是全都抢带宽反而拖慢真正的首屏关键资源。我一般只对首屏LCP相关的资源做preload比如Hero图或者最大文本块的字体文件。3. 渲染层与交互层的性能优化要点3.1 关键渲染路径与长任务拆分异步加载可以优化资源到达页面的速度但资源到了以后主线程“干活”的方式对性能的影响同样关键。浏览器把HTML、CSS和JavaScript渲染成屏幕上的像素这个过程叫关键渲染路径。从构建DOM、构建CSSOM到生成渲染树再到布局和绘制任何一步在主线程上耗时过长用户都会直接感受到卡顿。项目里最常见的性能杀手是“强制同步布局”。你在读取offsetWidth、offsetHeight、getBoundingClientRect这些几何属性时浏览器为了保证拿到的是最新值会强制把待执行的样式变更提前应用到页面上这个过程会触发一次额外的布局计算。如果在循环里既改样式又读几何属性浏览器就被迫在每一轮都重新布局性能雪崩。一个很典型的反面示例是// 不要这样写循环里读写交错触发强制同步布局 for (let i 0; i list.length; i) { const width list[i].offsetWidth; // 读 list[i].style.width width * 2 px; // 写导致下一次读时重新布局 }正确做法是先统一读再统一写把读写操作分离成两个阶段。这样浏览器可以在“写”的阶段批量处理样式变化把布局次数从N次降到1次。另外批量插入DOM时用DocumentFragment或先拼接字符串再一次性插入也是同样的思路——减少主线程的布局和绘制次数。长任务拆分也是一个实操价值极高的手段。如果一个函数需要做大量计算且没法避免建议用切片方式把它降级成多个短任务。比如处理一万条数据直接循环计算会让主线程阻塞几百毫秒改成用setTimeout或requestIdleCallback分批处理每批只占用一小段时间页面就不会有“冻结感”。3.2 防抖与节流别让事件拖垮页面事件处理器是主线程任务的主要来源之一。用户滚轮一滚scroll事件一秒钟可能触发几十次如果每触发一次就执行一次重操作主线程被塞满页面就开始掉帧。这个场景下防抖和节流就是两个最顺手也最常用的工具。防抖的核心思想事件被连续触发时只在最后一次触发后的等待时间内执行。适合输入框搜索建议这种场景——用户还在打字没必要每次按键都发请求等用户停下来再查询。节流的核心思想事件被连续触发时固定时间间隔内只执行一次。适合滚动事件、窗口resize这种高频率事件——保证每隔一段时间至少处理一次同时又不至于每次触发都处理。这里给一个节流的简单实现按固定间隔执行且保留最后一次触发防止丢事件function throttle(fn, interval) { let last 0; let timer null; return function (...args) { const now Date.now(); const remaining interval - (now - last); if (remaining 0) { if (timer) { clearTimeout(timer); timer null; } last now; fn.apply(this, args); } else if (!timer) { timer setTimeout(() { last Date.now(); timer null; fn.apply(this, args); }, remaining); } }; }这个版本比简单的时间戳版本好一点它在时间间隔到期之前如果又来了一次触发不会直接丢弃而是会安排一个定时器把最后这次触发补上。在高频滚动里保证首尾事件都不丢交互体感会舒服很多。防抖的代码网上有很多版本大家抄作业的时候注意确认是否支持立即执行一次的需求不同业务场景要求不一样。3.3 移动端与弱网下的异步策略移动端性能和桌面端完全是两个世界。桌面端几十毫秒的延迟用户几乎无感手机端网络稍差一点白屏就是一两秒起步。所以移动端的异步加载策略会更激进需要配合弱网环境做更多预案。首先要做的是图片懒加载。首屏之外的图片不要急着加载等滚到可视区域附近再加载。最现代的方案是给img标签加loadinglazy属性和decodingasync属性前者让浏览器原生懒加载后者让图片解码不阻塞渲染。如果还需要兼容更老的浏览器可以用IntersectionObserver去监听元素进入视口再动态设置src。其次是骨架屏。移动端H5页面如果首屏数据依赖接口返回异步加载的代价是短暂的空白区。骨架屏就是在接口返回前先用灰色占位块模拟页面结构用户会感知到“页面马上就出来了”而不是对着白屏等。骨架屏用CSS实现就行配合异步接口的状态切换体验提升很明显。弱网环境还有一个容易被忽略的点资源的体积控制。同样是3G网络一个200KB的脚本和一个2MB的脚本加载时间可以相差7到10倍。移动端项目里我会对首屏脚本体积设硬性预算比如初始传输量不超过300KB超了就考虑路由级拆分、按需引入第三方库或者把大依赖改成动态加载。这个策略在4G、5G时代依然重要因为弱网和拥塞场景永远存在。4. 用数据说话性能指标与测量方法4.1 核心Web指标与性能预算优化做得怎么样最终要落到数字上。业内目前公认的量化标准是Google提出的Core Web Vitals其中三个指标最值得关注LCPLargest Contentful Paint最大内容绘制、INPInteraction to Next Paint交互到下一次绘制的延迟、CLSCumulative Layout Shift累计布局偏移。LCP衡量的是首屏最大元素的加载时间能反映页面“视觉上打开”的快慢。异步加载做得好不好最直接的表现就在LCP上——把首屏最大图片或标题的加载路径优化了LCP立刻降下来。INP反映的是交互响应速度动画卡顿、按钮点击延迟都会体现在这个指标上。CLS则是衡量页面稳定性页面元素在加载过程中突然位移、用户手指差点点错按钮就是CLS在捣乱。我会在项目里设置性能预算比如移动端LCP小于2.5秒、INP小于200毫秒、CLS小于0.1这是业内公认的“良好”阈值。每次发布前跑一次性能审计超了就阻断发布。有了这个硬性门槛性能优化才不会沦为空谈。4.2 可视化测量与代码里的性能观测测量工具方面Chrome DevTools的Performance面板是最直接的。它能录制一段页面运行过程给出主线程时间轴、每项任务的耗时和调用栈一眼就能看出哪项任务占了主线程的“大头”。Lighthouse则是一次性的自动审计给出LCP、CLS、FCP等各项分数和建议适合在开发阶段快速体检。除了工具层面的测量代码里也应该埋上性能观测点。用PerformanceObserver可以直接在浏览器运行时收集指标const observer new PerformanceObserver((list) { for (const entry of list.getEntries()) { // 把 LCP、CLS、INP 数据上报到监控平台 console.log(entry.name, entry.value); } }); observer.observe({ type: [largest-contentful-paint, layout-shift, event], buffered: true });这样页面就具备了“自我感知”能力不用人工打开DevTools就能收集真实用户的性能数据。这些数据上报到监控平台后你可以看到异步加载策略在不同网络环境下的真实表现再针对瓶颈做下一轮优化。5. 常见问题与排查技巧实录5.1 白屏时间怎么排查白屏是性能优化里最常见的抱怨。遇到白屏要先分清是哪种白屏等待脚本加载的白屏还是脚本执行报错导致的空白还是资源加载太慢造成的视觉空白。排查第一步是开DevTools切到Network面板看瀑布图里到底卡在哪个阶段。如果某条请求长时间处于Pending状态多半是服务器响应太慢如果脚本文件加载很快但页面还是一直白着问题大概率出在脚本执行或者DOM渲染上。异步加载场景多了一个坑有些脚本虽然是异步的但它们之间隐含着依赖关系。比如defer保证了脚本按顺序执行但如果你中间漏了一个defer属性或者把一个脚本改成了async它就可能提前执行并因为找不到依赖对象而报错页面直接白掉。排查的时候控制台报错信息是最直接的线索别光看网络面板。5.2 懒加载导致页面跳动怎么办用懒加载的页面经常出现一个问题用户正在往下滑动图片加载完成后突然把下面的内容顶下去导致原有的阅读位置错位。这个问题本质上是CLS指标超标——图片没有预先占位加载完成后撑高了容器。解决办法是给图片容器设置固定的宽高比。前端常用的做法就是CSS的aspect-ratio属性或者老套的padding-top百分比技巧。在图片还没加载完的时候占位元素就已经撑起了正确的高度图片加载完只是替换内容不会改变布局。实测下来这个改动能把CLS从0.3级别降到0问题也不大。5.3 异步加载与SEO的矛盾怎么解异步加载虽然提升了用户体验但搜索引擎的爬虫不一定执行JavaScript。如果首屏关键内容全部靠异步渲染爬虫可能只看到空白页面对SEO极不友好。这是很多技术团队做性能优化时烧脑的地方极致的异步加载方案和搜索引擎抓取内容之间存在冲突。解决方案有三条路。一是用SSR服务端渲染让首屏HTML里直接包含最终内容同时用hydration在浏览器端激活交互能力。二是用SSG静态站点生成构建时输出完整HTML性能比SSR更好但要求内容基本不变化。三是折中方案——首屏做服务端渲染次屏继续用异步加载兼顾首屏速度和后续交互体验。这套思路同样适用于上架要求高的应用尤其是内容型产品。写在最后的优化体会这个“原理篇”讲到的异步加载核心是围绕事件循环、资源加载策略、渲染链路和量化指标这四件事。无论你是在做桌面端站点还是移动端H5把这套思路用到自己的项目里都会获得正向反馈。我之前接过一个移动端活动页面首屏有一个大图和三个业务模块最初实现是进入页面就一次性请求所有接口、同步加载所有脚本。第一次性能审计出来LCP接近4秒首屏完全不可用。后来做的事情也很基础脚本统一加defer、大图加fetchpriorityhigh、首屏数据的接口改成并行请求、非首屏的模块改成IntersectionObserver触发动态渲染。改完再看LCP降到了1.8秒左右INP也从两百多毫秒降到了一百以内。整个过程没有用任何黑科技全是这篇文章里提到的这些“基础操作”。性能优化最大的一个坑不是技术不会而是没有形成“先量化、再优化、再验证”的工作习惯。我建议你手头有项目的时候先把性能指标跑一遍找到最大的瓶颈再动手。很多时候你以为的瓶颈在图片结果实际耗时在脚本执行。数据会告诉你答案。再分享一个小技巧异步加载和性能优化的成果最好沉淀成团队的性能预算和检查清单。比如“新页面必须做路由级代码分割”、“首屏图片必须指定尺寸”、“非关键脚本一律defer”。把这些规范固化下来后面来的同事不容易把性能挖回去团队的整体性能水位也能稳定住。
