做前端时间长了会发现一个反复出现的规律用户真正感知到的“快”和浏览器实际加载完成的速度并不总是同一件事。异步加载与性能优化说白了就是在用户没反应过来之前把该干的事都干完或者至少让用户觉得“这个页面一下就出来了”。这篇文章我按“从原理到实战、从工具到排查”的顺序展开适合正在做Web开发、想系统梳理前端优化思路的人读。不管你是刚接触性能优化还是已经被Lighthouse分数折磨过几轮这篇里讲到的加载模型、脚本策略、图片懒加载、指标监控和问题排查都是可以直接落到项目里的东西。1. 异步加载的核心逻辑与浏览器加载模型1.1 浏览器解析HTML时的阻塞机制理解异步加载的前提是先搞清楚浏览器在解析一个页面时到底在忙什么。以Chrome为例渲染主线程从上到下处理HTML文档时遇到普通的script src...标签会立即停下手里所有工作——暂停DOM解析去网络请求这个脚本文件拿到以后执行完毕再继续解析后面的HTML。页面里塞了三个普通脚本就得串行地被“卡”三次第一次请求期间后面的DOM根本不会被解析首屏渲染的时间自然被拉长。把这种阻塞机制类比成去商场结账就好理解了同步脚本等于每拿一件商品都要单独排一次队结账你手里那件还没付钱收银台后面的顾客全得等着。异步方案想解决的就是“排队结账”这个过程对后续顾客的阻塞问题——要么让商品在排队的同时先被你装进购物袋并行下载要么延后到结账结束再处理延迟执行要么直接开一个不问顺序的窗口立即执行。这里有个常被忽略的细节script标签不仅阻塞解析还会阻塞渲染。也就是说同步脚本执行期间用户看到的不是“一部分页面已显示”而是白屏。用户在这段时间内盯着空白页任何一点延迟都会被放大。这也是为什么性能优化领域有一条不成文的规矩首要目标是给用户尽快呈现第一批内容而不是等所有资源加载完了再一次性显示。1.2 异步加载的三大分类与适用场景异步加载在实践中基本可以归为三类对应的优化思路完全不同。第一类是脚本加载异步化。核心目标是让JS文件的下载和执行不再阻塞DOM解析。工程上最常见的手段是给script标签加async或defer属性或者运行时动态创建script节点。细化到框架层面Webpack、Vite的代码分割与动态import()本质上也是同一件事——把暂时用不到的模块拆出去等需要时再加载。第二类是资源加载懒化。针对图片、视频、iframe这类体积大、数量多、优先级低的资源用延迟加载策略让它们等“真正需要出现在视口附近”时再去请求。这种策略对于长页面和图片瀑布流尤为有效可以大幅降低首屏网络带宽消耗把宝贵的加载资源让给核心文本和关键样式。第三类是数据请求异步化。接口慢、数据量大、服务端响应时间长这类问题在首屏体验中往往比静态资源更难解决也是移动端性能优化里最让人头疼的一环。思路是把数据请求与页面渲染解耦页面先展示框架数据到了再填充内容也就是常说的骨架屏方案。更进一步还可以做数据预取、接口并发控制、请求缓存等让数据加载的“感知时间”远小于“实际耗时”。这三类之间不是互斥的。生产环境中一个性能合格的页面通常同时用到了它们入口脚本做了拆包与延迟加载首屏图片用了懒加载策略核心接口做了预取和骨架屏兜底。搞清楚每一类的作用边界排优先级的时候才不会眉毛胡子一把抓。2. 脚本异步与模块加载的实战拆解2.1 async和defer到底有什么区别网上讲这两者区别的文章很多但很多人看完概念以后往页面里一用还是会出现诡异问题——比如脚本执行顺序变了。这里直接给你一个结论性的对照表属性下载时机执行时机执行顺序无属性遇到即阻塞边下边阻塞解析下载完成后立即执行按文档顺序defer解析的同时后台并行下载文档解析完毕后执行触发DOMContentLoaded之前按文档顺序可靠async解析的同时后台并行下载下载完成后立即执行随时可能打断解析不保证顺序谁先到谁先执行defer适合那种需要操作DOM、依赖页面结构的业务脚本。因为它在解析结束后才跑此时DOM树已经完整。async适合跟页面结构无关的独立脚本——典型的是统计埋点、数据上报、广告脚本这类“和页面没有依赖关系、也不被页面依赖”的第三方代码。这类脚本的特点是不管它什么时候执行都不影响页面功能哪怕它在下载完成后立刻执行打断了当前解析对用户也没有明显影响。这里有一个实际项目里非常容易踩的坑有些团队把原本依赖顺序的外部库全都加上了async以为异步就是无脑加属性结果库A还没执行完依赖库A的业务代码已经开始跑了控制台一片“undefined is not a function”。所以要记住一条铁律有依赖关系的脚本不要用async多个有依赖关系的脚本又不想被解析阻塞用defer。2.2 动态脚本注入与模块化代码分割静态写在HTML里的script标签改起来不方便运行时机也不够灵活。很多场景下页面需要根据用户交互再去加载某段代码——比如用户点击“高级筛选”按钮时才加载对应的筛选组件逻辑。这时会用到动态创建脚本的方式function loadScript(src, opts {}) { return new Promise((resolve, reject) { const script document.createElement(script); script.src src; // 关键默认不阻塞当前解析等价于defer语义 script.async true; if (opts.crossorigin) script.crossOrigin anonymous; script.onload () resolve(script); script.onerror () reject(new Error(Script load failed: ${src})); document.body.appendChild(script); }); } // 场景示例用户触发某个交互后才加载埋点SDK button.addEventListener(click, () { loadScript(https://example.com/sdk.js, { crossorigin: true }) .then(() sdk.init()) .catch(() console.warn(SDK加载失败降级方案)); });动态注入的脚本异步特性更可控配合Promise还能优雅处理加载失败。而且它天然规避了HTML解析期的阻塞问题——毕竟脚本是在用户交互之后才插入DOM的理论上主线程早就处于空闲状态了。如果在Webpack或者Vite工程里更现代的做法是用动态import()来做模块级拆包。举个Vue或React项目里的直观例子路由懒加载。现在创建路由时几乎没人会直接import HomePage from ./pages/Home而是写成() import(./pages/Home)。这一步操作背后打包工具会把Home模块单独打成独立的chunk用户只在访问对应路由时才去下载它。首屏只加载入口路由相关的代码体积直接缩小一大截。2.3 脚本加载优先级控制与关键路径瘦身异步加载并不是“把脚本都弄成不阻塞就完事”真正要做的其实是优先级管理。浏览器核心渲染路径上其实有几样东西是无论如何都不能省的HTML文档本身、首屏需要的CSS尤其是CSSOM构建需要的样式、以及首屏渲染前必须执行的脚本。这三样之外的东西理论上都是可以延迟、降级或异步化的。工程上有一个很实用的手段给关键资源设置提示属性。比如首屏万一渲染必须要用的某个JS文件可以提前让浏览器知道它的存在link relpreload asscript href/js/critical.jspreload的作用是告诉浏览器这个资源很重要尽早去下载它哪怕它出现在文档底部、还没被解析器碰到。这与defer并不冲突——preload只管下载下载好之后依然遵循defer的执行时机去执行。实践中还有一个颇有争议但确实有效的姿势把只负责修改DOM样式但逻辑不重的脚本直接以内联方式放进head里减少一次网络往返。很多站点首屏核心脚本会选择内联这确实会牺牲一些缓存优势但换来的是首屏关键逻辑零请求延迟。对于非关键脚本另一种思路是主动降低优先级link relpreload asscript href/js/analytics.js fetchprioritylowfetchpriority属性是后来才广泛支持的能力它允许你标注某个资源的网络请求优先级为“低”。对于埋点、统计、客服聊天等不着急的资源主动把请求优先级降下来可以避免它和首屏关键资源抢带宽。项目里做了这个调整以后观测到LCP指标在很多中低端机型上有比较明显的改善原因就是带宽被优先让给了首屏渲染需要的CSS和字体文件。3. 图片与媒体资源懒加载的完整落地方案3.1 一行代码的loadinglazy和它的问题图片通常是页面里体积占比最大的静态资源也是懒加载策略收益最明显的对象。原生懒加载属性loadinglazy简单到极点img srcbanner.jpg alt大图 loadinglazy width1920 height1080浏览器检测到这个属性会推迟图片的网络请求直到图片即将进入视口。开发成本几乎为零兼容性在主流浏览器上也没有问题。但它有一个很难绕开的问题浏览器的懒加载阈值并不是开发者能控制的。Chrome内部算法会根据网络状况和设备性能动态决定“提前多少像素开始加载”这个阈值对开发者是个黑盒。实测下来慢速网络环境下浏览器可能会在图片还离视口很远时就开始加载懒加载该有的网络节省效果不明显。而且原生特性不支持“进入视口后再逐渐加载”“第一屏快速响应、后续屏慢慢来”这类精细控制遇到复杂业务需求还是得动手自己实现。所以我的建议是能用原生属性的场景直接原生比如图库里的大部分非首屏图片。但如果你做的产品对流量和加载成本敏感、或者要精细控制加载时机那就要考虑更可控的IntersectionObserver方案。3.2 IntersectionObserver懒加载的完整实现IntersectionObserver是现代浏览器提供的观察器API核心能力就是异步监听目标元素与视口或指定祖先元素的交叉状态。用它做懒加载比监听scroll事件高效得多因为它不依赖主线程频繁计算滚动位置而是由浏览器底层合成器在交叉状态变化时回调。一个比较完整的实现长这样class LazyLoader { constructor(options {}) { this.options { root: null, // 默认视口 rootMargin: 0px 0px 200px 0px, // 提前200px开始加载 threshold: 0.01, // 露出1%即触发足够及时 ...options }; this.observer new IntersectionObserver( this.onIntersect.bind(this), this.options ); } onIntersect(entries, observer) { for (const entry of entries) { if (entry.isIntersecting) { const img entry.target; this.loadImage(img); observer.unobserve(img); // 加载完就不再观察避免重复触发 } } } loadImage(img) { const dataSrc img.dataset.src; if (!dataSrc) return; img.src dataSrc; img.classList.add(loaded); // 解码完成后再移除占位样式避免闪烁 img.decode?.().catch(() {}).finally(() { img.classList.remove(placeholder-loading); }); } add(img) { this.observer.observe(img); } }实现过程中有几个细节值得注意。第一rootMargin直接决定提前量建议设置成200px左右。设太小会出现用户快速滚动时图片来不及加载、白色区域暴露的情况设太大又会让懒加载退化成提前加载网络节省效果变差一般200~400px是一个实际项目里比较稳的经验值。第二img标签上真正展示的src属性需要保留原始内容还是替换为占位内容取决于你的占位策略。最稳妥的做法是HTML里写一个体积极小的占位图或完全不写src把真实地址放在>img { aspect-ratio: 16 / 9; width: 100%; height: auto; }或者直接在HTML属性里写上width和height这在现代浏览器上会自动推导出宽高比为图片预留正确的空间。这样即便图片还没有加载浏览器也清楚它应该占据多大空间整个布局不会因为图片到达而发生跳动。再一个是图片解码的性能问题。大图加载完成后立即进入解码流程解码也是CPU密集操作。如果页面同一时间有大量图片完成加载主线程会瞬间被解码任务挤满用户交互出现卡顿。比较有效的优化方式是分批触发图片解码利用img.decode()方法做显式解码控制或者通过分批设置src来控制同时进入解码流程的图片数量。实际项目中我处理过类似问题一次性首屏展示12张大图的相册页把所有图片的src同时赋值后在低端安卓机上出现明显的滚动卡顿改成分批渲染、每次只加载3-4张后卡顿问题基本消失。4. 数据异步加载与接口层性能优化4.1 骨架屏与请求异步解耦静态资源只是前端性能的一半另一半卡在数据请求上。一个常见的糟糕体验页面HTML和CSS加载飞快但核心内容依赖一个3秒后才返回的接口用户就盯着一个空白区块等。数据请求是一个典型的“慢路径”优化的核心思路是让页面渲染不依赖数据到达。最直观的做法是交互上先用静态结构占位——骨架屏。它不是优化了接口本身而是优化了用户对等待的感知。骨架屏的渲染要尤其注意位置稳、颜色淡、不卡主线程让用户的视线有一个稳定的等待区域。数据请求层面的异步解耦指的是首屏关键接口发起时不做无谓等待// 典型优化前串行等待 const res1 await fetch(/api/user); const res2 await fetch(/api/cart?uid${res1.data.uid}); // 优化后并行请求用Promise.all const [userRes, cartRes] await Promise.all([ fetch(/api/user), fetch(/api/cart) ]);当然这个示例里两个接口实际可能没有依赖关系才能并行。真实场景中后端不合理的接口设计常常造成“本来可以并行却必须串行”的问题——比如购物车接口需要先拿用户ID而用户ID完全可以从前端Cookie或本地存储取到却非要先请求用户信息。这种接口依赖关系上的优化收益往往比前端调优更大。4.2 接口并发控制与带宽竞争的处理页面同时发起的请求太多会互相抢带宽和连接数。浏览器对同一域名有并发连接数限制HTTP/1.1下常见为6超出限制的请求只能排队等待。请求队列拖得越长后发请求的等待时间就越长这部分等待用户同样感知得到。这正是手游性能优化和移动端性能优化里反复讨论的“网络竞争”问题在Web端的投影。处理思路有两个层面。第一个层面是请求合并与去重。同一个页面里多个相似的接口合并成一个前端能少发好几个请求多个组件各自请求同样数据时做应用层去重只发一次网络请求后续组件拿缓存结果。很多网络请求库比如SWR、TanStack Query默认就有请求去重能力算是工程上比较成熟的方案。第二个层面是请求优先级。浏览器对fetch请求默认不区分优先级但可以显式控制。对核心接口尽早发出对非关键请求如埋点、推荐位放到空闲时间再发// 空闲时执行低优先级数据请求 if (scheduler in window window.scheduler?.postTask) { scheduler.postTask(() fetchLowPriorityData(), { priority: background }); } else { // 低版本浏览器兜底延后100ms再发 setTimeout(() fetchLowPriorityData(), 300); }这个能力在Chrome较新版本里已经可用。没有这个API的老环境退而求其次用requestIdleCallback或者简单加一个延时也能达到“把请求让给关键资源”的目的。4.3 预取策略与缓存治理数据异步加载的终极目标不是“页面能显示”而是“页面秒开”。当用户的操作路径可以预测时提前去拿数据是比任何加载优化都更暴力的解法。常见做法的顺序是静态资源预加载preload、页面预判预取prefetch/ 路由级import()、数据预取在空闲时请求下一个页面接口。预取属于典型的“用带宽换体验”因此务必克制只预取用户大概率会进入的页面和数据否则就是浪费用户的流量。缓存治理在异步数据优化里同样关键。一个反直觉的事实是开发阶段大家都在注意的HTTP缓存头到了生产环境反而经常被忽略。接口返回时如果没有合理的Cache-Control头浏览器每次都会重新请求前端再怎么优化加载策略网络请求一次的耗时也省不掉。前后端联调时应该主动去对齐接口的缓存规则不常变的数据设置较长的max-age频繁变化的只做协商缓存配合ETag。另外也可以考虑前端内存缓存。同一个路由来回切换时接口数据是否还在内存里直接决定了二次打开的速度。很多中后台项目里路由离开时把关键查询结果存进全局Store回来时先渲染旧数据再静默刷新体验上会“顺滑”得多。5. 性能指标度量与调优方向诊断5.1 关键性能指标与它们的意义做性能优化不能凭感觉得先定义什么叫“快”。业界共识的几个核心指标是Google提出的Web Vitals以及配套的一系列扩展指标指标含义理想区间FCP首次内容绘制页面首个元素显示的时间1.8秒内LCP最大内容绘制页面上最大元素渲染完成的时间2.5秒内CLS累积布局偏移页面元素意外移动的严重程度0.1以下TTI可交互时间主线程空闲且事件可以响应的时刻建议监控趋势TBT总阻塞时间主线程被长任务阻塞的时间总和300ms以下这五个指标对应的是不同层面的体验FCP管的是一眼能看到LCP管的是主要内容出来没有TTI和TBT管的是能不能顺畅操作CLS管的是页面有没有乱跳。异步加载和性能优化所做的一切几乎都能映射到这些指标上——脚本延迟执行改善FCP和TTI图片占位和宽高声明改善CLS资源预加载改善LCP骨架屏感知优化间接改善用户体验信心。这里要特别提醒一点不要只盯着LCP单指标优化。实践中有团队把LCP优化到1.5秒以内但TBT依然在600ms以上用户点按钮迟迟没反应照样被吐槽“假快”。性能优化必须全指标一起看才能模拟出真实用户的使用感受。5.2 用Performance API埋点观测异步加载Lighthouse和WebPageTest是项目上线前必跑的体检工具但线上真实用户环境下的性能数据更需要性能埋点。浏览器提供的Performance API可以拿到几乎所有关键事件的精确时间并对资源加载耗时进行统计分析// 收集资源加载耗时数据 const resources performance.getEntriesByType(resource); const slowResources resources .filter(r r.initiatorType img || r.initiatorType script) .map(r ({ name: r.name.slice(0, 80), duration: r.duration, size: r.transferSize, // LCP的时间节点 })) .sort((a, b) b.duration - a.duration) .slice(0, 10); // 上报慢资源用于发现异常请求 slowResources.forEach(item { // 这里交给自己团队的上报通道 });更实用的一个场景是监控异步脚本的加载耗时。动态脚本、懒加载图片、异步接口这三类资源耗时全部可以从performance.getEntriesByType(resource)里捞出来。布置上报以后可以定期发现“某个CDN域名在部分地区慢”“某张图片体积突然暴涨”“某个第三方脚本平均耗时超过阈值”这类线上问题。这些靠人工测试几乎发现不了。5.3 性能诊断的优先级判断方法性能优化最容易踩的坑是方向跑偏——光看技术不看数据流优化了半天发现用户根本没慢在你想的那一层。我习惯的排查路径是先看FCP和LCP——卡在哪是HTML/CSS的问题还是图片/字体的问题再看TTI和TBT——主线程被哪段长任务占用了是同步执行的脚本还是解析巨大的JSON最后看CLS——哪些元素在晚期加入文档导致布局跳动是不是错用了懒加载却忘了给容器定宽高。定位长任务的精确手段是借助PerformanceObserver里的longtask条目new PerformanceObserver((list) { for (const entry of list.getEntries()) { // 长任务超过50ms会阻塞用户交互 if (entry.duration 250) { console.warn(超长任务, entry.duration, entry.startTime); } } }).observe({ entryTypes: [longtask] });一个超过250ms的长任务几乎可以确定会让用户感觉到明显的卡顿和响应延迟定位到它发生在哪个脚本阶段后就可以针对性做拆分或延后。实际业务里最常见的长任务来源集中在大JSON解析、DOM大批量插入、同步执行第三方库初始化。这三类问题通过异步化、分批处理、并发控制都能得到比较显著的改善。6. 常见问题与排查技巧实录6.1 懒加载图片后页面出现大面积空白这个现象多半出现在快速滚动场景。用户手指迅速划过整个页面滚动距离远大于提前加载量图片进入视口的瞬间才开始发请求网络一慢视口区域就空白了。排查思路分三步先确认是否设置了合理的rootMargin再确认图片加载完成之前容器是否有明确的占位尺寸最后检查是否误给首屏图片也加了懒加载。首屏元素绝对不要懒加载这是基本纪律。我遇到过一个比较极端的案例一个资讯页面的首屏大图被加上了懒加载属性结果慢速网络下LCP直逼5秒。排查后发现原因是团队为了统一模板给所有图片统一套用了懒加载代码完全没有区分首屏和非首屏。首屏大图对LCP指标影响极大统一切换为立即加载后LCP直接降到了2秒以内。6.2 异步脚本执行顺序混乱导致报错症状是页面有时正常、有时大量报错刷新一下又好了非常玄学。这种问题基本可以锁定为多个async脚本之间的顺序竞争导致的。async脚本执行顺序由“下载完成的先后”决定网络环境稍有波动顺序就变了。解决方案优先级从高到低排列第一优先去掉不必要的async改用defer第二优先把有依赖关系的代码合并进同一个脚本文件从源头消解顺序问题第三如果依赖关系复杂的第三方脚本无法合并那就保留同步加载——牺牲一点解析阻塞换来确定性的执行顺序对于关键路径上的脚本是值得的。调试这种问题有个小工具技巧Chrome DevTools的Network面板里点击“Priority”排序能看到各脚本的加载优先级和耗时。通过对比多次刷新的Timeline能直观看到执行顺序的随机性。6.3 异步加载后CLS指标不降反升这是一个很反直觉的现象明明做了异步加载布局偏移分数反而更高了。仔细排查后发现问题出在“异步加载的内容占位缺失”上。很多组件在数据没回来时不渲染数据回来后直接往DOM里插入一大块高内容父容器高度瞬间改变底下所有内容被顶下去这就是典型的CLS事件。解决思路比较明确异步内容区域在数据到达之前就用固定高度或骨架屏占住位置。高度不好预估的场景至少也要用min-height兜底把抖动范围控制在尽量小的面积内。类似地底部“加载更多”按钮点击后新内容插入列表之前也要事先考虑列表容器的高度变化策略。6.4 优化后Lighthouse分数高但真实体验差这种“数据与体感背离”的情况并不少见。Lighthouse跑分的时候处于“理想网络高性能设备”环境分数好看不代表中低端设备上的真实用户也一样顺滑。真实用户设备可能只有2G/3G网络CPU性能只有测试机的三分之一主线程的每一个长任务都会被放大。因此我强烈建议建立一套线上性能监控体系用真实用户的Performance Timing数据说话而不是只看上线前的Lab数据。回看之前提到的Performance API埋点这套东西应用在真实环境中能够告诉你哪些页面、哪些地域、哪些网络类型下出现了哪些指标劣化从而针对性地优化。否则团队很可能花了一周时间优化了一个真实用户根本感知不到的环节真正的瓶颈还在那里放着。另外一个实战心得是优化完一项措施后不要只看总分变化。一次性能优化往往是一串连锁反应——资源预加载可能导致网络带宽竞争低优先级请求延后可能在高峰期堆积。把每一项优化都单独上线、单独验证才能准确知道每项手段的真实收益。我个人的习惯是每轮优化只改一个变量然后对比核心指标的变化曲线否则出了问题根本无从定位是策略A还是策略B导致的。实际项目中我的异步加载落地清单最后按照自己的实操经验整理一份可以直接拿去用的异步加载检查清单按照从上到下的顺序逐项核对首屏CSS是否被合理内联或极早加载避免渲染阻塞超过首屏所需。关键脚本是否用了defer独立第三方脚本是否明确标了async。非首屏、非关键功能的路由或组件是否做了代码分割与动态import()。首屏图片不懒加载非首屏图片统一loadinglazy或IntersectionObserver。所有图片容器是否有显式宽高比阻止CLS发生。数据请求是否与渲染解耦骨架屏是否稳定占位。接口是否能并行就并行低优先级请求是否延后或降优先级发出。页面上线前跑一次Lighthouse上线后接好真实用户性能监控。这个清单每次都能帮我快速定位大多数性能问题的方向。优化没有银弹无非是把这些基本功一项项做扎实再根据业务特点去做取舍。前端性能优化的路上最容易忽略的往往不是高深的技巧而是这些基础动作是否真的做到了位。 前端性能优化实战：异步加载、懒加载与浏览器加载模型全解析
做前端时间长了会发现一个反复出现的规律用户真正感知到的“快”和浏览器实际加载完成的速度并不总是同一件事。异步加载与性能优化说白了就是在用户没反应过来之前把该干的事都干完或者至少让用户觉得“这个页面一下就出来了”。这篇文章我按“从原理到实战、从工具到排查”的顺序展开适合正在做Web开发、想系统梳理前端优化思路的人读。不管你是刚接触性能优化还是已经被Lighthouse分数折磨过几轮这篇里讲到的加载模型、脚本策略、图片懒加载、指标监控和问题排查都是可以直接落到项目里的东西。1. 异步加载的核心逻辑与浏览器加载模型1.1 浏览器解析HTML时的阻塞机制理解异步加载的前提是先搞清楚浏览器在解析一个页面时到底在忙什么。以Chrome为例渲染主线程从上到下处理HTML文档时遇到普通的script src...标签会立即停下手里所有工作——暂停DOM解析去网络请求这个脚本文件拿到以后执行完毕再继续解析后面的HTML。页面里塞了三个普通脚本就得串行地被“卡”三次第一次请求期间后面的DOM根本不会被解析首屏渲染的时间自然被拉长。把这种阻塞机制类比成去商场结账就好理解了同步脚本等于每拿一件商品都要单独排一次队结账你手里那件还没付钱收银台后面的顾客全得等着。异步方案想解决的就是“排队结账”这个过程对后续顾客的阻塞问题——要么让商品在排队的同时先被你装进购物袋并行下载要么延后到结账结束再处理延迟执行要么直接开一个不问顺序的窗口立即执行。这里有个常被忽略的细节script标签不仅阻塞解析还会阻塞渲染。也就是说同步脚本执行期间用户看到的不是“一部分页面已显示”而是白屏。用户在这段时间内盯着空白页任何一点延迟都会被放大。这也是为什么性能优化领域有一条不成文的规矩首要目标是给用户尽快呈现第一批内容而不是等所有资源加载完了再一次性显示。1.2 异步加载的三大分类与适用场景异步加载在实践中基本可以归为三类对应的优化思路完全不同。第一类是脚本加载异步化。核心目标是让JS文件的下载和执行不再阻塞DOM解析。工程上最常见的手段是给script标签加async或defer属性或者运行时动态创建script节点。细化到框架层面Webpack、Vite的代码分割与动态import()本质上也是同一件事——把暂时用不到的模块拆出去等需要时再加载。第二类是资源加载懒化。针对图片、视频、iframe这类体积大、数量多、优先级低的资源用延迟加载策略让它们等“真正需要出现在视口附近”时再去请求。这种策略对于长页面和图片瀑布流尤为有效可以大幅降低首屏网络带宽消耗把宝贵的加载资源让给核心文本和关键样式。第三类是数据请求异步化。接口慢、数据量大、服务端响应时间长这类问题在首屏体验中往往比静态资源更难解决也是移动端性能优化里最让人头疼的一环。思路是把数据请求与页面渲染解耦页面先展示框架数据到了再填充内容也就是常说的骨架屏方案。更进一步还可以做数据预取、接口并发控制、请求缓存等让数据加载的“感知时间”远小于“实际耗时”。这三类之间不是互斥的。生产环境中一个性能合格的页面通常同时用到了它们入口脚本做了拆包与延迟加载首屏图片用了懒加载策略核心接口做了预取和骨架屏兜底。搞清楚每一类的作用边界排优先级的时候才不会眉毛胡子一把抓。2. 脚本异步与模块加载的实战拆解2.1 async和defer到底有什么区别网上讲这两者区别的文章很多但很多人看完概念以后往页面里一用还是会出现诡异问题——比如脚本执行顺序变了。这里直接给你一个结论性的对照表属性下载时机执行时机执行顺序无属性遇到即阻塞边下边阻塞解析下载完成后立即执行按文档顺序defer解析的同时后台并行下载文档解析完毕后执行触发DOMContentLoaded之前按文档顺序可靠async解析的同时后台并行下载下载完成后立即执行随时可能打断解析不保证顺序谁先到谁先执行defer适合那种需要操作DOM、依赖页面结构的业务脚本。因为它在解析结束后才跑此时DOM树已经完整。async适合跟页面结构无关的独立脚本——典型的是统计埋点、数据上报、广告脚本这类“和页面没有依赖关系、也不被页面依赖”的第三方代码。这类脚本的特点是不管它什么时候执行都不影响页面功能哪怕它在下载完成后立刻执行打断了当前解析对用户也没有明显影响。这里有一个实际项目里非常容易踩的坑有些团队把原本依赖顺序的外部库全都加上了async以为异步就是无脑加属性结果库A还没执行完依赖库A的业务代码已经开始跑了控制台一片“undefined is not a function”。所以要记住一条铁律有依赖关系的脚本不要用async多个有依赖关系的脚本又不想被解析阻塞用defer。2.2 动态脚本注入与模块化代码分割静态写在HTML里的script标签改起来不方便运行时机也不够灵活。很多场景下页面需要根据用户交互再去加载某段代码——比如用户点击“高级筛选”按钮时才加载对应的筛选组件逻辑。这时会用到动态创建脚本的方式function loadScript(src, opts {}) { return new Promise((resolve, reject) { const script document.createElement(script); script.src src; // 关键默认不阻塞当前解析等价于defer语义 script.async true; if (opts.crossorigin) script.crossOrigin anonymous; script.onload () resolve(script); script.onerror () reject(new Error(Script load failed: ${src})); document.body.appendChild(script); }); } // 场景示例用户触发某个交互后才加载埋点SDK button.addEventListener(click, () { loadScript(https://example.com/sdk.js, { crossorigin: true }) .then(() sdk.init()) .catch(() console.warn(SDK加载失败降级方案)); });动态注入的脚本异步特性更可控配合Promise还能优雅处理加载失败。而且它天然规避了HTML解析期的阻塞问题——毕竟脚本是在用户交互之后才插入DOM的理论上主线程早就处于空闲状态了。如果在Webpack或者Vite工程里更现代的做法是用动态import()来做模块级拆包。举个Vue或React项目里的直观例子路由懒加载。现在创建路由时几乎没人会直接import HomePage from ./pages/Home而是写成() import(./pages/Home)。这一步操作背后打包工具会把Home模块单独打成独立的chunk用户只在访问对应路由时才去下载它。首屏只加载入口路由相关的代码体积直接缩小一大截。2.3 脚本加载优先级控制与关键路径瘦身异步加载并不是“把脚本都弄成不阻塞就完事”真正要做的其实是优先级管理。浏览器核心渲染路径上其实有几样东西是无论如何都不能省的HTML文档本身、首屏需要的CSS尤其是CSSOM构建需要的样式、以及首屏渲染前必须执行的脚本。这三样之外的东西理论上都是可以延迟、降级或异步化的。工程上有一个很实用的手段给关键资源设置提示属性。比如首屏万一渲染必须要用的某个JS文件可以提前让浏览器知道它的存在link relpreload asscript href/js/critical.jspreload的作用是告诉浏览器这个资源很重要尽早去下载它哪怕它出现在文档底部、还没被解析器碰到。这与defer并不冲突——preload只管下载下载好之后依然遵循defer的执行时机去执行。实践中还有一个颇有争议但确实有效的姿势把只负责修改DOM样式但逻辑不重的脚本直接以内联方式放进head里减少一次网络往返。很多站点首屏核心脚本会选择内联这确实会牺牲一些缓存优势但换来的是首屏关键逻辑零请求延迟。对于非关键脚本另一种思路是主动降低优先级link relpreload asscript href/js/analytics.js fetchprioritylowfetchpriority属性是后来才广泛支持的能力它允许你标注某个资源的网络请求优先级为“低”。对于埋点、统计、客服聊天等不着急的资源主动把请求优先级降下来可以避免它和首屏关键资源抢带宽。项目里做了这个调整以后观测到LCP指标在很多中低端机型上有比较明显的改善原因就是带宽被优先让给了首屏渲染需要的CSS和字体文件。3. 图片与媒体资源懒加载的完整落地方案3.1 一行代码的loadinglazy和它的问题图片通常是页面里体积占比最大的静态资源也是懒加载策略收益最明显的对象。原生懒加载属性loadinglazy简单到极点img srcbanner.jpg alt大图 loadinglazy width1920 height1080浏览器检测到这个属性会推迟图片的网络请求直到图片即将进入视口。开发成本几乎为零兼容性在主流浏览器上也没有问题。但它有一个很难绕开的问题浏览器的懒加载阈值并不是开发者能控制的。Chrome内部算法会根据网络状况和设备性能动态决定“提前多少像素开始加载”这个阈值对开发者是个黑盒。实测下来慢速网络环境下浏览器可能会在图片还离视口很远时就开始加载懒加载该有的网络节省效果不明显。而且原生特性不支持“进入视口后再逐渐加载”“第一屏快速响应、后续屏慢慢来”这类精细控制遇到复杂业务需求还是得动手自己实现。所以我的建议是能用原生属性的场景直接原生比如图库里的大部分非首屏图片。但如果你做的产品对流量和加载成本敏感、或者要精细控制加载时机那就要考虑更可控的IntersectionObserver方案。3.2 IntersectionObserver懒加载的完整实现IntersectionObserver是现代浏览器提供的观察器API核心能力就是异步监听目标元素与视口或指定祖先元素的交叉状态。用它做懒加载比监听scroll事件高效得多因为它不依赖主线程频繁计算滚动位置而是由浏览器底层合成器在交叉状态变化时回调。一个比较完整的实现长这样class LazyLoader { constructor(options {}) { this.options { root: null, // 默认视口 rootMargin: 0px 0px 200px 0px, // 提前200px开始加载 threshold: 0.01, // 露出1%即触发足够及时 ...options }; this.observer new IntersectionObserver( this.onIntersect.bind(this), this.options ); } onIntersect(entries, observer) { for (const entry of entries) { if (entry.isIntersecting) { const img entry.target; this.loadImage(img); observer.unobserve(img); // 加载完就不再观察避免重复触发 } } } loadImage(img) { const dataSrc img.dataset.src; if (!dataSrc) return; img.src dataSrc; img.classList.add(loaded); // 解码完成后再移除占位样式避免闪烁 img.decode?.().catch(() {}).finally(() { img.classList.remove(placeholder-loading); }); } add(img) { this.observer.observe(img); } }实现过程中有几个细节值得注意。第一rootMargin直接决定提前量建议设置成200px左右。设太小会出现用户快速滚动时图片来不及加载、白色区域暴露的情况设太大又会让懒加载退化成提前加载网络节省效果变差一般200~400px是一个实际项目里比较稳的经验值。第二img标签上真正展示的src属性需要保留原始内容还是替换为占位内容取决于你的占位策略。最稳妥的做法是HTML里写一个体积极小的占位图或完全不写src把真实地址放在>img { aspect-ratio: 16 / 9; width: 100%; height: auto; }或者直接在HTML属性里写上width和height这在现代浏览器上会自动推导出宽高比为图片预留正确的空间。这样即便图片还没有加载浏览器也清楚它应该占据多大空间整个布局不会因为图片到达而发生跳动。再一个是图片解码的性能问题。大图加载完成后立即进入解码流程解码也是CPU密集操作。如果页面同一时间有大量图片完成加载主线程会瞬间被解码任务挤满用户交互出现卡顿。比较有效的优化方式是分批触发图片解码利用img.decode()方法做显式解码控制或者通过分批设置src来控制同时进入解码流程的图片数量。实际项目中我处理过类似问题一次性首屏展示12张大图的相册页把所有图片的src同时赋值后在低端安卓机上出现明显的滚动卡顿改成分批渲染、每次只加载3-4张后卡顿问题基本消失。4. 数据异步加载与接口层性能优化4.1 骨架屏与请求异步解耦静态资源只是前端性能的一半另一半卡在数据请求上。一个常见的糟糕体验页面HTML和CSS加载飞快但核心内容依赖一个3秒后才返回的接口用户就盯着一个空白区块等。数据请求是一个典型的“慢路径”优化的核心思路是让页面渲染不依赖数据到达。最直观的做法是交互上先用静态结构占位——骨架屏。它不是优化了接口本身而是优化了用户对等待的感知。骨架屏的渲染要尤其注意位置稳、颜色淡、不卡主线程让用户的视线有一个稳定的等待区域。数据请求层面的异步解耦指的是首屏关键接口发起时不做无谓等待// 典型优化前串行等待 const res1 await fetch(/api/user); const res2 await fetch(/api/cart?uid${res1.data.uid}); // 优化后并行请求用Promise.all const [userRes, cartRes] await Promise.all([ fetch(/api/user), fetch(/api/cart) ]);当然这个示例里两个接口实际可能没有依赖关系才能并行。真实场景中后端不合理的接口设计常常造成“本来可以并行却必须串行”的问题——比如购物车接口需要先拿用户ID而用户ID完全可以从前端Cookie或本地存储取到却非要先请求用户信息。这种接口依赖关系上的优化收益往往比前端调优更大。4.2 接口并发控制与带宽竞争的处理页面同时发起的请求太多会互相抢带宽和连接数。浏览器对同一域名有并发连接数限制HTTP/1.1下常见为6超出限制的请求只能排队等待。请求队列拖得越长后发请求的等待时间就越长这部分等待用户同样感知得到。这正是手游性能优化和移动端性能优化里反复讨论的“网络竞争”问题在Web端的投影。处理思路有两个层面。第一个层面是请求合并与去重。同一个页面里多个相似的接口合并成一个前端能少发好几个请求多个组件各自请求同样数据时做应用层去重只发一次网络请求后续组件拿缓存结果。很多网络请求库比如SWR、TanStack Query默认就有请求去重能力算是工程上比较成熟的方案。第二个层面是请求优先级。浏览器对fetch请求默认不区分优先级但可以显式控制。对核心接口尽早发出对非关键请求如埋点、推荐位放到空闲时间再发// 空闲时执行低优先级数据请求 if (scheduler in window window.scheduler?.postTask) { scheduler.postTask(() fetchLowPriorityData(), { priority: background }); } else { // 低版本浏览器兜底延后100ms再发 setTimeout(() fetchLowPriorityData(), 300); }这个能力在Chrome较新版本里已经可用。没有这个API的老环境退而求其次用requestIdleCallback或者简单加一个延时也能达到“把请求让给关键资源”的目的。4.3 预取策略与缓存治理数据异步加载的终极目标不是“页面能显示”而是“页面秒开”。当用户的操作路径可以预测时提前去拿数据是比任何加载优化都更暴力的解法。常见做法的顺序是静态资源预加载preload、页面预判预取prefetch/ 路由级import()、数据预取在空闲时请求下一个页面接口。预取属于典型的“用带宽换体验”因此务必克制只预取用户大概率会进入的页面和数据否则就是浪费用户的流量。缓存治理在异步数据优化里同样关键。一个反直觉的事实是开发阶段大家都在注意的HTTP缓存头到了生产环境反而经常被忽略。接口返回时如果没有合理的Cache-Control头浏览器每次都会重新请求前端再怎么优化加载策略网络请求一次的耗时也省不掉。前后端联调时应该主动去对齐接口的缓存规则不常变的数据设置较长的max-age频繁变化的只做协商缓存配合ETag。另外也可以考虑前端内存缓存。同一个路由来回切换时接口数据是否还在内存里直接决定了二次打开的速度。很多中后台项目里路由离开时把关键查询结果存进全局Store回来时先渲染旧数据再静默刷新体验上会“顺滑”得多。5. 性能指标度量与调优方向诊断5.1 关键性能指标与它们的意义做性能优化不能凭感觉得先定义什么叫“快”。业界共识的几个核心指标是Google提出的Web Vitals以及配套的一系列扩展指标指标含义理想区间FCP首次内容绘制页面首个元素显示的时间1.8秒内LCP最大内容绘制页面上最大元素渲染完成的时间2.5秒内CLS累积布局偏移页面元素意外移动的严重程度0.1以下TTI可交互时间主线程空闲且事件可以响应的时刻建议监控趋势TBT总阻塞时间主线程被长任务阻塞的时间总和300ms以下这五个指标对应的是不同层面的体验FCP管的是一眼能看到LCP管的是主要内容出来没有TTI和TBT管的是能不能顺畅操作CLS管的是页面有没有乱跳。异步加载和性能优化所做的一切几乎都能映射到这些指标上——脚本延迟执行改善FCP和TTI图片占位和宽高声明改善CLS资源预加载改善LCP骨架屏感知优化间接改善用户体验信心。这里要特别提醒一点不要只盯着LCP单指标优化。实践中有团队把LCP优化到1.5秒以内但TBT依然在600ms以上用户点按钮迟迟没反应照样被吐槽“假快”。性能优化必须全指标一起看才能模拟出真实用户的使用感受。5.2 用Performance API埋点观测异步加载Lighthouse和WebPageTest是项目上线前必跑的体检工具但线上真实用户环境下的性能数据更需要性能埋点。浏览器提供的Performance API可以拿到几乎所有关键事件的精确时间并对资源加载耗时进行统计分析// 收集资源加载耗时数据 const resources performance.getEntriesByType(resource); const slowResources resources .filter(r r.initiatorType img || r.initiatorType script) .map(r ({ name: r.name.slice(0, 80), duration: r.duration, size: r.transferSize, // LCP的时间节点 })) .sort((a, b) b.duration - a.duration) .slice(0, 10); // 上报慢资源用于发现异常请求 slowResources.forEach(item { // 这里交给自己团队的上报通道 });更实用的一个场景是监控异步脚本的加载耗时。动态脚本、懒加载图片、异步接口这三类资源耗时全部可以从performance.getEntriesByType(resource)里捞出来。布置上报以后可以定期发现“某个CDN域名在部分地区慢”“某张图片体积突然暴涨”“某个第三方脚本平均耗时超过阈值”这类线上问题。这些靠人工测试几乎发现不了。5.3 性能诊断的优先级判断方法性能优化最容易踩的坑是方向跑偏——光看技术不看数据流优化了半天发现用户根本没慢在你想的那一层。我习惯的排查路径是先看FCP和LCP——卡在哪是HTML/CSS的问题还是图片/字体的问题再看TTI和TBT——主线程被哪段长任务占用了是同步执行的脚本还是解析巨大的JSON最后看CLS——哪些元素在晚期加入文档导致布局跳动是不是错用了懒加载却忘了给容器定宽高。定位长任务的精确手段是借助PerformanceObserver里的longtask条目new PerformanceObserver((list) { for (const entry of list.getEntries()) { // 长任务超过50ms会阻塞用户交互 if (entry.duration 250) { console.warn(超长任务, entry.duration, entry.startTime); } } }).observe({ entryTypes: [longtask] });一个超过250ms的长任务几乎可以确定会让用户感觉到明显的卡顿和响应延迟定位到它发生在哪个脚本阶段后就可以针对性做拆分或延后。实际业务里最常见的长任务来源集中在大JSON解析、DOM大批量插入、同步执行第三方库初始化。这三类问题通过异步化、分批处理、并发控制都能得到比较显著的改善。6. 常见问题与排查技巧实录6.1 懒加载图片后页面出现大面积空白这个现象多半出现在快速滚动场景。用户手指迅速划过整个页面滚动距离远大于提前加载量图片进入视口的瞬间才开始发请求网络一慢视口区域就空白了。排查思路分三步先确认是否设置了合理的rootMargin再确认图片加载完成之前容器是否有明确的占位尺寸最后检查是否误给首屏图片也加了懒加载。首屏元素绝对不要懒加载这是基本纪律。我遇到过一个比较极端的案例一个资讯页面的首屏大图被加上了懒加载属性结果慢速网络下LCP直逼5秒。排查后发现原因是团队为了统一模板给所有图片统一套用了懒加载代码完全没有区分首屏和非首屏。首屏大图对LCP指标影响极大统一切换为立即加载后LCP直接降到了2秒以内。6.2 异步脚本执行顺序混乱导致报错症状是页面有时正常、有时大量报错刷新一下又好了非常玄学。这种问题基本可以锁定为多个async脚本之间的顺序竞争导致的。async脚本执行顺序由“下载完成的先后”决定网络环境稍有波动顺序就变了。解决方案优先级从高到低排列第一优先去掉不必要的async改用defer第二优先把有依赖关系的代码合并进同一个脚本文件从源头消解顺序问题第三如果依赖关系复杂的第三方脚本无法合并那就保留同步加载——牺牲一点解析阻塞换来确定性的执行顺序对于关键路径上的脚本是值得的。调试这种问题有个小工具技巧Chrome DevTools的Network面板里点击“Priority”排序能看到各脚本的加载优先级和耗时。通过对比多次刷新的Timeline能直观看到执行顺序的随机性。6.3 异步加载后CLS指标不降反升这是一个很反直觉的现象明明做了异步加载布局偏移分数反而更高了。仔细排查后发现问题出在“异步加载的内容占位缺失”上。很多组件在数据没回来时不渲染数据回来后直接往DOM里插入一大块高内容父容器高度瞬间改变底下所有内容被顶下去这就是典型的CLS事件。解决思路比较明确异步内容区域在数据到达之前就用固定高度或骨架屏占住位置。高度不好预估的场景至少也要用min-height兜底把抖动范围控制在尽量小的面积内。类似地底部“加载更多”按钮点击后新内容插入列表之前也要事先考虑列表容器的高度变化策略。6.4 优化后Lighthouse分数高但真实体验差这种“数据与体感背离”的情况并不少见。Lighthouse跑分的时候处于“理想网络高性能设备”环境分数好看不代表中低端设备上的真实用户也一样顺滑。真实用户设备可能只有2G/3G网络CPU性能只有测试机的三分之一主线程的每一个长任务都会被放大。因此我强烈建议建立一套线上性能监控体系用真实用户的Performance Timing数据说话而不是只看上线前的Lab数据。回看之前提到的Performance API埋点这套东西应用在真实环境中能够告诉你哪些页面、哪些地域、哪些网络类型下出现了哪些指标劣化从而针对性地优化。否则团队很可能花了一周时间优化了一个真实用户根本感知不到的环节真正的瓶颈还在那里放着。另外一个实战心得是优化完一项措施后不要只看总分变化。一次性能优化往往是一串连锁反应——资源预加载可能导致网络带宽竞争低优先级请求延后可能在高峰期堆积。把每一项优化都单独上线、单独验证才能准确知道每项手段的真实收益。我个人的习惯是每轮优化只改一个变量然后对比核心指标的变化曲线否则出了问题根本无从定位是策略A还是策略B导致的。实际项目中我的异步加载落地清单最后按照自己的实操经验整理一份可以直接拿去用的异步加载检查清单按照从上到下的顺序逐项核对首屏CSS是否被合理内联或极早加载避免渲染阻塞超过首屏所需。关键脚本是否用了defer独立第三方脚本是否明确标了async。非首屏、非关键功能的路由或组件是否做了代码分割与动态import()。首屏图片不懒加载非首屏图片统一loadinglazy或IntersectionObserver。所有图片容器是否有显式宽高比阻止CLS发生。数据请求是否与渲染解耦骨架屏是否稳定占位。接口是否能并行就并行低优先级请求是否延后或降优先级发出。页面上线前跑一次Lighthouse上线后接好真实用户性能监控。这个清单每次都能帮我快速定位大多数性能问题的方向。优化没有银弹无非是把这些基本功一项项做扎实再根据业务特点去做取舍。前端性能优化的路上最容易忽略的往往不是高深的技巧而是这些基础动作是否真的做到了位。