1. 异步加载到底在解决什么问题前端性能优化这个话题说起来人人都懂一点但真到了项目里很多人第一反应还是“压缩图片、开个CDN、上懒加载”然后就没下文了。我做了十多年前端见过太多项目把性能优化做成了“玄学调参”——今天看个文章说预加载好明天看个视频说骨架屏香最后代码里堆了一堆互相打架的策略首屏该慢还是慢。异步加载这件事本质上不是某个API的用法问题而是一个资源调度问题。你可以把浏览器想象成一个只有一条主通道的仓库HTML是进货单JS和CSS是必须优先上架的货物图片、视频、字体这些是“可以晚点摆出来”的展示品。异步加载要做的就是决定哪些货物先上架、哪些可以等顾客走到货架前再拿出来。这个决策做得好不好直接决定了三个核心指标首屏渲染时间FCP、最大内容绘制时间LCP、可交互时间TTI。我见过一个后台管理系统首页加载了2.3MB的JS其中真正首屏用到的不到300KB剩下的全是各种图表库、富文本编辑器、地图组件。这就是典型的“同步加载思维”——反正都要用那就一次性全加载了。结果就是用户盯着白屏转圈圈产品经理天天被老板问“为什么这么慢”。所以异步加载的核心目标很明确让首屏只加载首屏需要的东西其余资源按需、分时、分优先级加载。这不是一个技术炫技而是一个成本收益的权衡——你多花一天时间做代码分割和加载策略换来的是用户留存率提升几个百分点这笔账怎么算都划算。适合谁来参考这篇内容如果你是刚接触性能优化的初中级前端这篇能帮你建立一套完整的异步加载认知框架如果你是有经验的开发者里面关于加载优先级、预加载时机、缓存策略的细节应该能给你一些新的思路。我不打算讲太多教科书式的定义而是把我在实际项目里踩过的坑、验证过的方案原原本本拆开来说。2. 异步加载的核心机制与方案选型2.1 浏览器原生的加载优先级体系很多人做异步加载时忽略了一个前提浏览器本身已经有一套资源优先级机制了。Chrome从很早的版本开始就把网络请求分成了五个优先级Highest、High、Medium、Low、Lowest。HTML文档本身是HighestCSS是Highest同步JS是High而图片、字体这些默认是Low或Medium。这意味着什么意味着你写一个img标签浏览器不会立刻去下载它而是等HTML解析到那个位置、布局计算完成后才开始请求。但如果你用fetch或者XMLHttpRequest手动去拉图片反而可能打乱这个优先级。我见过一个项目为了做图片懒加载用Intersection Observer监听图片进入视口然后手动new Image()去加载结果因为手动创建的Image对象优先级被判定为Low加载速度比原生img loadinglazy还慢。所以第一个原则是能用原生属性解决的不要用JS手动干预。img loadinglazy、script defer、script async、link relpreload这些原生能力浏览器厂商已经帮你把优先级调度做得很好了。你手动用JS去控制反而容易适得其反。但原生能力也有局限。比如script async虽然不阻塞HTML解析但它的执行时机是不确定的——可能在DOMContentLoaded之前也可能之后。如果你的脚本依赖DOM结构用async就是给自己埋雷。这时候就需要更精细的控制手段。2.2 代码分割的粒度怎么定代码分割是异步加载的基础。没有分割就没有异步。但分割粒度是个技术活——切得太粗一个chunk还是几百KB异步加载没意义切得太细HTTP请求数量爆炸反而增加开销。我的经验法则是按路由分割是底线按功能模块分割是进阶按组件分割要谨慎。路由级别的分割是最容易做的Webpack的import()配合React Router或者Vue Router每个路由页面打成一个独立的chunk。这个粒度通常比较合适因为用户访问一个页面时确实只需要那个页面的代码。但路由分割有个问题如果两个路由共享了大量组件Webpack默认会把共享部分提取到公共chunk里。这时候你需要配置splitChunks策略。我一般会设置minSize: 2000020KB小于这个大小的模块不单独分割避免产生大量碎片文件。同时设置maxInitialRequests: 6控制首屏并行请求数量因为浏览器对同一域名的并发请求是有限制的HTTP/1.1下通常是6个。功能模块级别的分割更适合大型应用。比如一个电商后台商品管理、订单管理、数据分析这三个模块每个模块内部又有自己的子路由和组件。这时候可以在路由分割的基础上把每个模块的公共依赖比如该模块专用的图表库、表格组件再单独抽出来。这样用户进入商品管理时不会加载订单管理才用的富文本编辑器。组件级别的分割要特别小心。我见过有人把每个Modal弹窗都做成异步组件结果用户点开一个弹窗要等500ms加载chunk体验极差。只有那些“首屏绝对用不到、且体积较大”的组件才值得单独分割比如代码编辑器、地图组件、PDF预览器。判断标准很简单这个组件如果同步加载会让首屏体积增加超过50KB吗如果会就分割如果不会就别折腾。2.3 预加载与预取的时机选择异步加载解决的是“什么时候加载”预加载解决的是“能不能提前加载”。这两者配合使用才能达到最佳效果。link relpreload是告诉浏览器“这个资源我后面肯定要用你尽快下载但先别执行/渲染。”它适合关键路径上的资源比如首屏渲染必需的字体文件、首屏图片、关键的CSS。但preload有个坑如果你preload了一个资源但实际使用时又用另一个URL去请求比如带了不同的query参数浏览器会认为这是两个不同的资源preload就白做了。所以preload的URL必须和实际请求的URL完全一致。link relprefetch则是告诉浏览器“这个资源可能后面会用到你在空闲时间下载。”它适合下一个页面可能用到的资源比如用户从列表页进入详情页详情页的JS就可以在列表页空闲时prefetch。但prefetch的优先级非常低如果网络繁忙或者用户快速跳转可能根本来不及下载。所以prefetch只能作为锦上添花不能作为核心加载策略。link relpreconnect和link reldns-prefetch是更轻量的优化。preconnect会提前建立TCP连接和TLS握手dns-prefetch只做DNS解析。对于第三方域名比如CDN、字体服务这两个能省下100-300ms的延迟。我一般会在head里对关键的第三方域名加preconnect对次要的加dns-prefetch。实际项目中我通常这样组合首屏关键资源用preload下一个路由的chunk用prefetch第三方域名用preconnect。但要注意preload和prefetch都会占用带宽如果滥用反而会拖慢首屏。我的经验是preload的资源不超过3个prefetch的资源不超过5个超过这个数就要重新审视哪些是真正必要的。2.4 动态导入的运行时行为import()是异步加载的语法基础但它的运行时行为很多人没搞清楚。当你调用import(./module)时Webpack会做几件事首先检查这个模块是否已经被加载过如果加载过就直接返回缓存的Promise如果没有就创建一个script标签插入到DOM中src指向对应的chunk文件等script加载并执行完毕后resolve这个Promise。这里有个关键点动态导入的模块其依赖也会被打包进同一个chunk。比如你import(./Chart)而Chart组件内部又import(echarts)那么echarts也会被放进Chart的chunk里。这通常是好事因为减少了请求数。但如果你有多个异步组件都依赖echartsWebpack会把echarts提取到公共chunk避免重复打包。这个行为由splitChunks配置控制。另一个关键点是加载失败的处理。动态导入返回的是Promise如果网络问题导致chunk加载失败Promise会reject。很多人不处理这个reject结果就是用户看到一个空白页面控制台报个错就完了。我的做法是给每个动态导入加一个重试机制配合错误边界Error Boundary展示友好的提示。重试逻辑很简单捕获reject后等待1秒重新import一次最多重试2次。如果还是失败就展示“网络异常请刷新重试”的提示。function lazyImport(factory, retries 2) { return new Promise((resolve, reject) { const attempt () { factory() .then(resolve) .catch((err) { if (retries 0) { retries--; setTimeout(attempt, 1000); } else { reject(err); } }); }; attempt(); }); }这个简单的封装在实际项目里能减少很多“白屏投诉”。尤其是移动端网络不稳定的场景重试机制的价值非常明显。3. 性能优化的实操落地与关键细节3.1 首屏加载的黄金路径分析做性能优化第一步不是写代码而是搞清楚首屏的黄金路径是什么。黄金路径指的是从HTML请求到首屏内容完全渲染出来浏览器必须完成的一系列关键步骤。这个路径上的每一个资源、每一次网络往返都是优化对象。我通常用Chrome DevTools的Performance面板录制一次首屏加载然后看几个关键时间点HTML下载完成时间、CSS下载完成时间、首屏JS执行完成时间、首次内容绘制FCP时间、最大内容绘制LCP时间。把这几个时间点标出来就能看到瓶颈在哪里。如果HTML下载慢说明服务端响应或者网络有问题这时候优化前端代码没用得看服务端渲染SSR或者CDN配置。如果CSS下载慢说明CSS文件太大或者阻塞了渲染需要做关键CSS内联、非关键CSS异步加载。如果JS执行慢说明首屏JS太多或者有长任务阻塞了主线程需要做代码分割和任务拆分。我见过一个典型的案例一个React项目首屏JS 1.8MBLCP时间4.2秒。分析后发现首屏真正需要的组件只有Header、Banner、商品列表但打包时把整个应用的路由、状态管理、工具库全打进去了。做了路由分割后首屏JS降到420KBLCP降到1.8秒。这个提升不是靠什么黑科技就是老老实实做代码分割。关键CSS内联是另一个立竿见影的优化。首屏渲染需要的CSS通常只占整个CSS文件的10%-20%把这部分内联到HTML的style标签里剩下的CSS用link relpreload asstyle onloadthis.relstylesheet异步加载能消除CSS阻塞渲染的时间。但要注意内联CSS会增加HTML体积如果HTML本身已经很大就要权衡了。我的经验是内联CSS不超过14KB因为TCP慢启动阶段第一个往返大约能传输14KB超过这个数就考虑拆分。3.2 图片与字体的异步加载策略图片通常是页面中体积最大的资源但也是最容易做异步加载的。原生img loadinglazy已经能覆盖大部分场景但有几个细节要注意。首先是占位符。懒加载的图片在加载完成前如果没有任何占位会导致布局偏移CLS。我的做法是给图片设置固定的宽高比用CSS的aspect-ratio或者padding-top百分比来占位。这样图片加载完成后不会把下面的内容挤下去。CLS是Core Web Vitals的指标之一布局偏移太大会影响SEO排名。其次是响应式图片。img srcset和picture可以根据屏幕尺寸和DPR加载不同分辨率的图片。移动端加载桌面端的大图是典型的浪费。我一般会准备三套尺寸480w、960w、1440w配合sizes属性让浏览器自己选择。这个优化能减少移动端30%-50%的图片流量。字体加载是另一个容易被忽视的点。自定义字体如果同步加载会导致FOITFlash of Invisible Text——文字在字体加载完成前不可见。解决方案是font-display: swap让浏览器先用系统字体渲染字体加载完成后再替换。但swap会导致FOUTFlash of Unstyled Text文字会闪一下。如果对视觉要求高可以用font-display: optional浏览器会判断字体是否能在100ms内加载完成如果不能就放弃自定义字体直接用系统字体。这个策略适合那些“字体不是核心设计元素”的场景。对于图标字体我现在的做法是直接用SVG。SVG图标可以内联到HTML里也可以做成symbol sprite按需引用。这样既没有字体加载的问题又能精确控制每个图标的颜色和大小。唯一的问题是SVG sprite文件如果太大首次加载会慢。我的经验是图标数量少于50个用内联SVG超过50个用sprite。3.3 第三方脚本的异步加载与隔离第三方脚本是性能优化的重灾区。统计代码、客服系统、广告SDK、地图API这些脚本往往体积大、执行慢而且不受你控制。我见过一个项目首屏加载了7个第三方脚本总共1.2MB直接把LCP拖到了5秒以上。处理第三方脚本的核心原则是能异步就异步能延迟就延迟能隔离就隔离。异步加载用script async但要注意async脚本的执行时机不确定如果第三方脚本依赖DOM或者你的全局变量可能会报错。这时候可以用defer它保证在DOMContentLoaded之前、按顺序执行。延迟加载的策略是首屏不需要的第三方脚本等用户交互或者页面空闲时再加载。比如客服系统的脚本用户不点击客服按钮就不加载统计代码可以等requestIdleCallback再执行。我通常会把第三方脚本的加载逻辑封装成一个队列在load事件之后或者用户首次滚动时批量加载。隔离第三方脚本的影响可以用Web Worker或者iframe。Web Worker适合那些纯计算的任务比如数据加密、图片处理。iframe适合那些需要独立DOM环境的脚本比如广告SDK。但iframe也有代价——每个iframe都是一个独立的浏览上下文内存开销不小。所以只对“确实会阻塞主线程且无法异步”的脚本用iframe隔离。还有一个细节第三方脚本的域名要加preconnect。比如你用了Google Fonts、CDN、统计服务在head里加link relpreconnect hrefhttps://fonts.googleapis.com能省下DNS解析和TCP握手的时间。这个优化成本极低但效果很明显。3.4 缓存策略与Service Worker的配合异步加载的资源如果每次都要重新下载那异步的意义就大打折扣。缓存策略是异步加载的“后勤保障”。HTTP缓存是最基础的。对于带hash的静态资源比如main.a1b2c3.js设置Cache-Control: max-age31536000, immutable让浏览器永久缓存。因为文件名带hash内容变了文件名就变了不存在缓存失效的问题。对于HTML文件设置Cache-Control: no-cache让浏览器每次都去服务端验证但可以用304响应减少传输量。Service Worker是更高级的缓存方案。它可以拦截所有网络请求根据自定义策略返回缓存或网络响应。我常用的策略是静态资源用Cache FirstAPI请求用Network FirstHTML用Stale While Revalidate。Cache First的意思是先看缓存缓存没有再去网络Network First是先请求网络网络失败再用缓存Stale While Revalidate是先返回缓存同时后台更新缓存。Service Worker的坑在于更新时机。如果用户一直不关闭页面Service Worker可能一直用旧缓存。我的做法是在Service Worker的install事件里跳过等待self.skipWaiting()在activate事件里清理旧缓存clients.claim()然后在前端监听controllerchange事件提示用户“有新版本点击刷新”。这样既能保证用户及时用上新版本又不会强制刷新打断用户操作。但Service Worker也不是万能的。它只能缓存同源资源第三方CDN的资源如果没配CORS是缓存不了的。而且Service Worker本身也有更新延迟首次注册后要等页面重新加载才生效。所以我的建议是Service Worker作为HTTP缓存的补充而不是替代。先把HTTP缓存配好再考虑用Service Worker做离线能力和更精细的缓存控制。4. 常见问题与排查技巧实录4.1 异步加载后样式丢失或错乱这个问题我遇到过好几次典型表现是异步加载的组件渲染出来了但样式完全不对或者部分样式丢失。原因通常有两个一是CSS没有跟着JS一起异步加载二是CSS加载顺序变了导致优先级错乱。Webpack默认会把异步组件里的CSS提取成单独的chunk文件在JS加载时通过link标签动态插入。但如果你的CSS提取插件配置有问题或者用了style-loader把CSS内联到JS里就可能出现样式丢失。我的建议是生产环境一定要用MiniCssExtractPlugin把CSS提取成独立文件不要用style-loader。这样CSS的加载和JS的加载是并行的不会因为JS执行慢而阻塞样式渲染。另一个原因是CSS优先级。同步加载的CSS先插入异步加载的CSS后插入如果两者有同名类后插入的会覆盖先插入的。这本来没问题但如果异步组件的CSS依赖某个基础样式而基础样式被覆盖了就会出问题。解决方案是给异步组件的样式加命名空间比如用CSS Modules或者BEM命名避免样式冲突。排查这个问题的技巧在DevTools的Elements面板里看异步组件的DOM节点上有没有预期的类名然后在Styles面板里看这些类名对应的样式有没有被划掉。如果被划掉了说明有更高优先级的样式覆盖了它。这时候可以用!important临时验证但正式修复还是要调整选择器优先级或者命名空间。4.2 动态导入的chunk加载失败chunk加载失败的原因很多网络抖动、CDN节点故障、文件被误删、跨域配置错误。表现就是控制台报ChunkLoadError页面白屏或者组件不渲染。排查步骤我一般这样走首先看Network面板找到那个失败的chunk请求看状态码是什么。如果是404说明文件路径不对或者文件不存在检查Webpack的publicPath配置和CDN上的文件是否同步。如果是403说明跨域配置有问题检查CDN的CORS设置。如果是超时或者连接重置说明网络问题需要加重试机制。重试机制前面提过这里补充一个细节重试时要加时间戳或者随机参数避免浏览器缓存了失败的响应。比如import(./module?t Date.now())这样每次重试都是一个新的URL不会命中缓存。但这样也会导致Webpack的chunk文件名对不上所以更好的做法是在Webpack配置里用output.chunkFilename加上[contenthash]然后重试时通过修改publicPath来绕过缓存。还有一个隐藏的坑如果用户长时间不刷新页面而服务端部署了新版本旧的chunk文件可能已经被删除了。这时候用户点击一个异步加载的按钮就会404。解决方案是保留旧版本的chunk文件至少一个发布周期或者在前端检测到ChunkLoadError时强制刷新页面。我通常会在错误边界里捕获这个错误然后window.location.reload()但要注意加个标记避免无限刷新。4.3 预加载资源未被使用link relpreload如果preload了但没用到Chrome控制台会报一个警告“The resource was preloaded but not used within a few seconds.”这个警告不仅烦人还意味着你浪费了带宽。常见原因有几个一是preload的URL和实际请求的URL不一致比如preload了font.woff2但CSS里引用的是font.woff2?v1。二是preload的资源被其他资源阻塞了比如preload了一个图片但图片的加载被JS阻塞了。三是preload的as属性写错了比如字体应该是asfont如果写成asfetch浏览器会按fetch的优先级处理可能不会及时使用。排查方法在Network面板里看preload的请求对比它的URL和实际使用时的URL。如果URL不一致统一它们。如果URL一致但还是没用到检查as属性是否正确。字体的asfont必须配合crossorigin属性因为字体请求是跨域的。图片的asimage不需要crossorigin除非是跨域图片。我的经验是preload只用于首屏关键资源且必须确保URL完全一致。对于不确定是否会用到的资源用prefetch而不是preload。prefetch没有“未使用”的警告因为它本来就是“可能用到”的语义。4.4 异步加载导致的竞态条件竞态条件是异步加载中最隐蔽的bug。典型场景用户快速切换路由路由A的异步组件还在加载用户已经切到了路由B结果路由A的组件加载完成后渲染到了路由B的页面上。或者用户快速点击搜索按钮第一次搜索的请求还没返回第二次搜索已经发出结果第一次的结果覆盖了第二次的。解决竞态条件的核心思路是取消过期的异步操作。对于动态导入可以在组件卸载时设置一个标记导入完成后检查这个标记如果组件已经卸载就不执行后续逻辑。对于网络请求用AbortController取消过期的请求。let currentAbortController null; function search(keyword) { if (currentAbortController) { currentAbortController.abort(); } currentAbortController new AbortController(); fetch(/api/search?q${keyword}, { signal: currentAbortController.signal }) .then(res res.json()) .then(data render(data)) .catch(err { if (err.name ! AbortError) { console.error(err); } }); }React的useEffect里做异步操作时一定要在cleanup函数里取消订阅或者设置标记。Vue的onUnmounted同理。这个习惯能避免大量的“组件已卸载但setState”的警告和内存泄漏。4.5 性能优化效果不明显怎么办有时候你做了代码分割、懒加载、预加载但Lighthouse分数没怎么变或者LCP还是很高。这时候不要慌先确认几件事。第一确认优化真的生效了。在Network面板里看首屏加载的资源列表对比优化前后的请求数量和体积。如果请求数量没减少说明代码分割没生效可能是Webpack配置有问题或者动态导入的模块被其他同步模块引用了导致Webpack把它打回了主chunk。第二确认瓶颈不在前端。如果HTML下载时间很长或者TTFBTime To First Byte很高那瓶颈在服务端或者网络前端优化再多也没用。这时候要看服务端渲染、CDN、数据库查询这些环节。第三确认没有其他性能问题掩盖了优化效果。比如你优化了JS加载但CSS里有一个巨大的背景图或者有一个同步的第三方脚本阻塞了渲染那LCP还是下不来。用Performance面板录制一次完整加载看主线程有没有长任务看渲染有没有被阻塞。我个人的经验是性能优化要抓大放小先解决最明显的瓶颈。如果首屏JS有1MB先做代码分割如果图片有2MB先做压缩和懒加载如果第三方脚本有500KB先做异步和延迟。每次只改一个变量测一次数据确认有效再继续。不要一次性改一堆东西否则出了问题都不知道是哪个改动导致的。5. 移动端与特殊场景的异步加载考量5.1 移动端网络的不稳定性应对移动端和桌面端最大的区别是网络环境。4G信号时好时坏地铁里、电梯里、人群密集的地方网络延迟可能从50ms飙升到2000ms。在这种环境下异步加载的策略要更保守。首先超时时间要设短。桌面端可以等5秒移动端建议2-3秒就超时。超时后走降级方案比如展示缓存数据、展示骨架屏、或者提示用户重试。不要让用户对着loading转圈超过3秒否则大概率会关掉页面。其次重试策略要更积极。移动端网络抖动是常态一次失败不代表真的失败。我的做法是首次请求超时2秒失败后立即重试一次不等待再失败等1秒重试最多重试3次。如果3次都失败才展示错误提示。第三资源体积要更严格。桌面端可以接受200KB的chunk移动端最好控制在100KB以内。因为移动端网络带宽有限而且流量对用户是有成本的。我通常会把移动端的splitChunks.minSize调到1000010KB让更多小模块被合并减少请求数。还有一个细节移动端要监听网络状态变化。navigator.onLine和online/offline事件可以告诉你用户是否在线。如果用户离线了就不要发起异步请求了直接走缓存或者提示。如果用户从离线变为在线可以自动重试之前失败的请求。5.2 低端设备的性能降级低端安卓机的CPU性能和内存都比旗舰机差很多。同样的JS代码在旗舰机上执行50ms在低端机上可能要200ms。异步加载的chunk如果太大解析和执行的时间会很长导致页面卡顿。针对低端设备我通常会做几件事减少首屏JS体积把非关键逻辑尽量往后放降低动画复杂度用CSS动画代替JS动画减少同时加载的资源数量避免内存峰值过高。检测低端设备的方法navigator.hardwareConcurrency可以拿到CPU核心数navigator.deviceMemory可以拿到内存大小单位GB。如果核心数小于4或者内存小于2GB就认为是低端设备启用降级策略。但这两个API的兼容性一般Safari不支持deviceMemory所以只能作为参考不能完全依赖。更可靠的方法是运行时性能检测。在页面加载后用requestAnimationFrame测几帧的耗时如果平均帧耗时超过16ms即低于60fps说明设备性能不足可以动态降低一些非关键功能的加载优先级。比如延迟加载图表库、关闭一些装饰性动画。5.3 服务端渲染与异步加载的配合服务端渲染SSR和异步加载看起来是矛盾的SSR要把内容在服务端渲染好异步加载要把资源延后加载。但实际上它们是互补的。SSR解决的是首屏内容的问题——让用户尽快看到有内容的页面而不是白屏。异步加载解决的是交互的问题——让页面尽快可交互而不是等所有JS都加载完。在SSR场景下首屏的HTML已经包含了内容所以首屏的JS可以更激进地异步加载。我的做法是SSR渲染的页面首屏JS只加载水合hydration必需的代码其余交互逻辑全部异步加载。这样用户看到内容的时间FCP很早但页面可交互的时间TTI可能会晚一点。对于内容型页面新闻、博客、商品详情这个取舍是值得的因为用户主要是来看内容的不是来交互的。但要注意SSR的水合过程如果太慢会导致用户点击按钮没反应。所以水合代码要尽量精简只绑定必要的事件监听。复杂的交互逻辑可以等水合完成后再异步加载和绑定。另一个细节是SSR的HTML里不要包含异步组件的占位内容。如果异步组件在服务端渲染了一个占位符客户端水合时又要替换成真实内容会导致布局偏移。更好的做法是异步组件在服务端不渲染客户端加载完成后再渲染同时用CSS占位符预留空间。6. 我个人的实操心得与避坑清单做了这么多年的性能优化我最大的体会是异步加载不是目的用户体验才是。不要为了异步而异步不要为了Lighthouse分数而优化。用户感知到的快才是真的快。我见过一个项目为了追求极致的首屏速度把首屏JS压到了50KB但代价是用户点击任何按钮都要等1-2秒加载chunk。结果Lighthouse分数很高但用户投诉“点了没反应”。这就是典型的“指标优化了体验变差了”。所以我的原则是首屏要快交互也要快。首屏JS可以小但交互相关的chunk要提前预加载。比如用户鼠标悬停在按钮上时就开始预加载点击后需要的chunk用户滚动到列表底部时就开始预加载下一页的数据。这些“预测性加载”能让用户感觉不到异步的存在。另一个心得是缓存比加载更重要。与其花大量时间优化加载速度不如把缓存做好。用户第二次访问时所有资源都从缓存读取加载时间接近零。Service Worker HTTP缓存 本地存储这三层缓存做好用户体验会有质的提升。最后分享一个排查性能问题的技巧用真实设备测不要只用模拟器。Chrome DevTools的Network throttling只能模拟网络延迟不能模拟CPU性能。低端安卓机的JS执行速度可能只有你开发机的十分之一。我习惯用一台千元安卓机做测试如果在那上面体验流畅那在旗舰机上肯定没问题。避坑清单我整理了一个表格都是实际项目中踩过的坑坑点表现解决方案preload URL不一致控制台警告资源重复加载确保preload的URL和实际请求完全一致动态导入未处理失败白屏控制台ChunkLoadError加重试机制和错误边界异步组件样式冲突样式错乱部分样式丢失用CSS Modules或BEM命名空间竞态条件旧数据覆盖新数据用AbortController取消过期请求低端设备卡顿页面响应慢动画掉帧检测设备性能动态降级Service Worker缓存不更新用户一直看到旧版本skipWaiting clients.claim 提示刷新第三方脚本阻塞LCP高主线程长任务async/defer 延迟加载 iframe隔离图片懒加载布局偏移CLS高内容跳动设置固定宽高比占位这些坑我基本都踩过一遍有些坑踩了好几次才找到原因。希望这份清单能帮你少走点弯路。性能优化这件事没有银弹就是一个个细节抠出来的。但每优化一点用户就能快一点这个投入是值得的。
前端异步加载实战：从代码分割到缓存策略的性能优化指南
1. 异步加载到底在解决什么问题前端性能优化这个话题说起来人人都懂一点但真到了项目里很多人第一反应还是“压缩图片、开个CDN、上懒加载”然后就没下文了。我做了十多年前端见过太多项目把性能优化做成了“玄学调参”——今天看个文章说预加载好明天看个视频说骨架屏香最后代码里堆了一堆互相打架的策略首屏该慢还是慢。异步加载这件事本质上不是某个API的用法问题而是一个资源调度问题。你可以把浏览器想象成一个只有一条主通道的仓库HTML是进货单JS和CSS是必须优先上架的货物图片、视频、字体这些是“可以晚点摆出来”的展示品。异步加载要做的就是决定哪些货物先上架、哪些可以等顾客走到货架前再拿出来。这个决策做得好不好直接决定了三个核心指标首屏渲染时间FCP、最大内容绘制时间LCP、可交互时间TTI。我见过一个后台管理系统首页加载了2.3MB的JS其中真正首屏用到的不到300KB剩下的全是各种图表库、富文本编辑器、地图组件。这就是典型的“同步加载思维”——反正都要用那就一次性全加载了。结果就是用户盯着白屏转圈圈产品经理天天被老板问“为什么这么慢”。所以异步加载的核心目标很明确让首屏只加载首屏需要的东西其余资源按需、分时、分优先级加载。这不是一个技术炫技而是一个成本收益的权衡——你多花一天时间做代码分割和加载策略换来的是用户留存率提升几个百分点这笔账怎么算都划算。适合谁来参考这篇内容如果你是刚接触性能优化的初中级前端这篇能帮你建立一套完整的异步加载认知框架如果你是有经验的开发者里面关于加载优先级、预加载时机、缓存策略的细节应该能给你一些新的思路。我不打算讲太多教科书式的定义而是把我在实际项目里踩过的坑、验证过的方案原原本本拆开来说。2. 异步加载的核心机制与方案选型2.1 浏览器原生的加载优先级体系很多人做异步加载时忽略了一个前提浏览器本身已经有一套资源优先级机制了。Chrome从很早的版本开始就把网络请求分成了五个优先级Highest、High、Medium、Low、Lowest。HTML文档本身是HighestCSS是Highest同步JS是High而图片、字体这些默认是Low或Medium。这意味着什么意味着你写一个img标签浏览器不会立刻去下载它而是等HTML解析到那个位置、布局计算完成后才开始请求。但如果你用fetch或者XMLHttpRequest手动去拉图片反而可能打乱这个优先级。我见过一个项目为了做图片懒加载用Intersection Observer监听图片进入视口然后手动new Image()去加载结果因为手动创建的Image对象优先级被判定为Low加载速度比原生img loadinglazy还慢。所以第一个原则是能用原生属性解决的不要用JS手动干预。img loadinglazy、script defer、script async、link relpreload这些原生能力浏览器厂商已经帮你把优先级调度做得很好了。你手动用JS去控制反而容易适得其反。但原生能力也有局限。比如script async虽然不阻塞HTML解析但它的执行时机是不确定的——可能在DOMContentLoaded之前也可能之后。如果你的脚本依赖DOM结构用async就是给自己埋雷。这时候就需要更精细的控制手段。2.2 代码分割的粒度怎么定代码分割是异步加载的基础。没有分割就没有异步。但分割粒度是个技术活——切得太粗一个chunk还是几百KB异步加载没意义切得太细HTTP请求数量爆炸反而增加开销。我的经验法则是按路由分割是底线按功能模块分割是进阶按组件分割要谨慎。路由级别的分割是最容易做的Webpack的import()配合React Router或者Vue Router每个路由页面打成一个独立的chunk。这个粒度通常比较合适因为用户访问一个页面时确实只需要那个页面的代码。但路由分割有个问题如果两个路由共享了大量组件Webpack默认会把共享部分提取到公共chunk里。这时候你需要配置splitChunks策略。我一般会设置minSize: 2000020KB小于这个大小的模块不单独分割避免产生大量碎片文件。同时设置maxInitialRequests: 6控制首屏并行请求数量因为浏览器对同一域名的并发请求是有限制的HTTP/1.1下通常是6个。功能模块级别的分割更适合大型应用。比如一个电商后台商品管理、订单管理、数据分析这三个模块每个模块内部又有自己的子路由和组件。这时候可以在路由分割的基础上把每个模块的公共依赖比如该模块专用的图表库、表格组件再单独抽出来。这样用户进入商品管理时不会加载订单管理才用的富文本编辑器。组件级别的分割要特别小心。我见过有人把每个Modal弹窗都做成异步组件结果用户点开一个弹窗要等500ms加载chunk体验极差。只有那些“首屏绝对用不到、且体积较大”的组件才值得单独分割比如代码编辑器、地图组件、PDF预览器。判断标准很简单这个组件如果同步加载会让首屏体积增加超过50KB吗如果会就分割如果不会就别折腾。2.3 预加载与预取的时机选择异步加载解决的是“什么时候加载”预加载解决的是“能不能提前加载”。这两者配合使用才能达到最佳效果。link relpreload是告诉浏览器“这个资源我后面肯定要用你尽快下载但先别执行/渲染。”它适合关键路径上的资源比如首屏渲染必需的字体文件、首屏图片、关键的CSS。但preload有个坑如果你preload了一个资源但实际使用时又用另一个URL去请求比如带了不同的query参数浏览器会认为这是两个不同的资源preload就白做了。所以preload的URL必须和实际请求的URL完全一致。link relprefetch则是告诉浏览器“这个资源可能后面会用到你在空闲时间下载。”它适合下一个页面可能用到的资源比如用户从列表页进入详情页详情页的JS就可以在列表页空闲时prefetch。但prefetch的优先级非常低如果网络繁忙或者用户快速跳转可能根本来不及下载。所以prefetch只能作为锦上添花不能作为核心加载策略。link relpreconnect和link reldns-prefetch是更轻量的优化。preconnect会提前建立TCP连接和TLS握手dns-prefetch只做DNS解析。对于第三方域名比如CDN、字体服务这两个能省下100-300ms的延迟。我一般会在head里对关键的第三方域名加preconnect对次要的加dns-prefetch。实际项目中我通常这样组合首屏关键资源用preload下一个路由的chunk用prefetch第三方域名用preconnect。但要注意preload和prefetch都会占用带宽如果滥用反而会拖慢首屏。我的经验是preload的资源不超过3个prefetch的资源不超过5个超过这个数就要重新审视哪些是真正必要的。2.4 动态导入的运行时行为import()是异步加载的语法基础但它的运行时行为很多人没搞清楚。当你调用import(./module)时Webpack会做几件事首先检查这个模块是否已经被加载过如果加载过就直接返回缓存的Promise如果没有就创建一个script标签插入到DOM中src指向对应的chunk文件等script加载并执行完毕后resolve这个Promise。这里有个关键点动态导入的模块其依赖也会被打包进同一个chunk。比如你import(./Chart)而Chart组件内部又import(echarts)那么echarts也会被放进Chart的chunk里。这通常是好事因为减少了请求数。但如果你有多个异步组件都依赖echartsWebpack会把echarts提取到公共chunk避免重复打包。这个行为由splitChunks配置控制。另一个关键点是加载失败的处理。动态导入返回的是Promise如果网络问题导致chunk加载失败Promise会reject。很多人不处理这个reject结果就是用户看到一个空白页面控制台报个错就完了。我的做法是给每个动态导入加一个重试机制配合错误边界Error Boundary展示友好的提示。重试逻辑很简单捕获reject后等待1秒重新import一次最多重试2次。如果还是失败就展示“网络异常请刷新重试”的提示。function lazyImport(factory, retries 2) { return new Promise((resolve, reject) { const attempt () { factory() .then(resolve) .catch((err) { if (retries 0) { retries--; setTimeout(attempt, 1000); } else { reject(err); } }); }; attempt(); }); }这个简单的封装在实际项目里能减少很多“白屏投诉”。尤其是移动端网络不稳定的场景重试机制的价值非常明显。3. 性能优化的实操落地与关键细节3.1 首屏加载的黄金路径分析做性能优化第一步不是写代码而是搞清楚首屏的黄金路径是什么。黄金路径指的是从HTML请求到首屏内容完全渲染出来浏览器必须完成的一系列关键步骤。这个路径上的每一个资源、每一次网络往返都是优化对象。我通常用Chrome DevTools的Performance面板录制一次首屏加载然后看几个关键时间点HTML下载完成时间、CSS下载完成时间、首屏JS执行完成时间、首次内容绘制FCP时间、最大内容绘制LCP时间。把这几个时间点标出来就能看到瓶颈在哪里。如果HTML下载慢说明服务端响应或者网络有问题这时候优化前端代码没用得看服务端渲染SSR或者CDN配置。如果CSS下载慢说明CSS文件太大或者阻塞了渲染需要做关键CSS内联、非关键CSS异步加载。如果JS执行慢说明首屏JS太多或者有长任务阻塞了主线程需要做代码分割和任务拆分。我见过一个典型的案例一个React项目首屏JS 1.8MBLCP时间4.2秒。分析后发现首屏真正需要的组件只有Header、Banner、商品列表但打包时把整个应用的路由、状态管理、工具库全打进去了。做了路由分割后首屏JS降到420KBLCP降到1.8秒。这个提升不是靠什么黑科技就是老老实实做代码分割。关键CSS内联是另一个立竿见影的优化。首屏渲染需要的CSS通常只占整个CSS文件的10%-20%把这部分内联到HTML的style标签里剩下的CSS用link relpreload asstyle onloadthis.relstylesheet异步加载能消除CSS阻塞渲染的时间。但要注意内联CSS会增加HTML体积如果HTML本身已经很大就要权衡了。我的经验是内联CSS不超过14KB因为TCP慢启动阶段第一个往返大约能传输14KB超过这个数就考虑拆分。3.2 图片与字体的异步加载策略图片通常是页面中体积最大的资源但也是最容易做异步加载的。原生img loadinglazy已经能覆盖大部分场景但有几个细节要注意。首先是占位符。懒加载的图片在加载完成前如果没有任何占位会导致布局偏移CLS。我的做法是给图片设置固定的宽高比用CSS的aspect-ratio或者padding-top百分比来占位。这样图片加载完成后不会把下面的内容挤下去。CLS是Core Web Vitals的指标之一布局偏移太大会影响SEO排名。其次是响应式图片。img srcset和picture可以根据屏幕尺寸和DPR加载不同分辨率的图片。移动端加载桌面端的大图是典型的浪费。我一般会准备三套尺寸480w、960w、1440w配合sizes属性让浏览器自己选择。这个优化能减少移动端30%-50%的图片流量。字体加载是另一个容易被忽视的点。自定义字体如果同步加载会导致FOITFlash of Invisible Text——文字在字体加载完成前不可见。解决方案是font-display: swap让浏览器先用系统字体渲染字体加载完成后再替换。但swap会导致FOUTFlash of Unstyled Text文字会闪一下。如果对视觉要求高可以用font-display: optional浏览器会判断字体是否能在100ms内加载完成如果不能就放弃自定义字体直接用系统字体。这个策略适合那些“字体不是核心设计元素”的场景。对于图标字体我现在的做法是直接用SVG。SVG图标可以内联到HTML里也可以做成symbol sprite按需引用。这样既没有字体加载的问题又能精确控制每个图标的颜色和大小。唯一的问题是SVG sprite文件如果太大首次加载会慢。我的经验是图标数量少于50个用内联SVG超过50个用sprite。3.3 第三方脚本的异步加载与隔离第三方脚本是性能优化的重灾区。统计代码、客服系统、广告SDK、地图API这些脚本往往体积大、执行慢而且不受你控制。我见过一个项目首屏加载了7个第三方脚本总共1.2MB直接把LCP拖到了5秒以上。处理第三方脚本的核心原则是能异步就异步能延迟就延迟能隔离就隔离。异步加载用script async但要注意async脚本的执行时机不确定如果第三方脚本依赖DOM或者你的全局变量可能会报错。这时候可以用defer它保证在DOMContentLoaded之前、按顺序执行。延迟加载的策略是首屏不需要的第三方脚本等用户交互或者页面空闲时再加载。比如客服系统的脚本用户不点击客服按钮就不加载统计代码可以等requestIdleCallback再执行。我通常会把第三方脚本的加载逻辑封装成一个队列在load事件之后或者用户首次滚动时批量加载。隔离第三方脚本的影响可以用Web Worker或者iframe。Web Worker适合那些纯计算的任务比如数据加密、图片处理。iframe适合那些需要独立DOM环境的脚本比如广告SDK。但iframe也有代价——每个iframe都是一个独立的浏览上下文内存开销不小。所以只对“确实会阻塞主线程且无法异步”的脚本用iframe隔离。还有一个细节第三方脚本的域名要加preconnect。比如你用了Google Fonts、CDN、统计服务在head里加link relpreconnect hrefhttps://fonts.googleapis.com能省下DNS解析和TCP握手的时间。这个优化成本极低但效果很明显。3.4 缓存策略与Service Worker的配合异步加载的资源如果每次都要重新下载那异步的意义就大打折扣。缓存策略是异步加载的“后勤保障”。HTTP缓存是最基础的。对于带hash的静态资源比如main.a1b2c3.js设置Cache-Control: max-age31536000, immutable让浏览器永久缓存。因为文件名带hash内容变了文件名就变了不存在缓存失效的问题。对于HTML文件设置Cache-Control: no-cache让浏览器每次都去服务端验证但可以用304响应减少传输量。Service Worker是更高级的缓存方案。它可以拦截所有网络请求根据自定义策略返回缓存或网络响应。我常用的策略是静态资源用Cache FirstAPI请求用Network FirstHTML用Stale While Revalidate。Cache First的意思是先看缓存缓存没有再去网络Network First是先请求网络网络失败再用缓存Stale While Revalidate是先返回缓存同时后台更新缓存。Service Worker的坑在于更新时机。如果用户一直不关闭页面Service Worker可能一直用旧缓存。我的做法是在Service Worker的install事件里跳过等待self.skipWaiting()在activate事件里清理旧缓存clients.claim()然后在前端监听controllerchange事件提示用户“有新版本点击刷新”。这样既能保证用户及时用上新版本又不会强制刷新打断用户操作。但Service Worker也不是万能的。它只能缓存同源资源第三方CDN的资源如果没配CORS是缓存不了的。而且Service Worker本身也有更新延迟首次注册后要等页面重新加载才生效。所以我的建议是Service Worker作为HTTP缓存的补充而不是替代。先把HTTP缓存配好再考虑用Service Worker做离线能力和更精细的缓存控制。4. 常见问题与排查技巧实录4.1 异步加载后样式丢失或错乱这个问题我遇到过好几次典型表现是异步加载的组件渲染出来了但样式完全不对或者部分样式丢失。原因通常有两个一是CSS没有跟着JS一起异步加载二是CSS加载顺序变了导致优先级错乱。Webpack默认会把异步组件里的CSS提取成单独的chunk文件在JS加载时通过link标签动态插入。但如果你的CSS提取插件配置有问题或者用了style-loader把CSS内联到JS里就可能出现样式丢失。我的建议是生产环境一定要用MiniCssExtractPlugin把CSS提取成独立文件不要用style-loader。这样CSS的加载和JS的加载是并行的不会因为JS执行慢而阻塞样式渲染。另一个原因是CSS优先级。同步加载的CSS先插入异步加载的CSS后插入如果两者有同名类后插入的会覆盖先插入的。这本来没问题但如果异步组件的CSS依赖某个基础样式而基础样式被覆盖了就会出问题。解决方案是给异步组件的样式加命名空间比如用CSS Modules或者BEM命名避免样式冲突。排查这个问题的技巧在DevTools的Elements面板里看异步组件的DOM节点上有没有预期的类名然后在Styles面板里看这些类名对应的样式有没有被划掉。如果被划掉了说明有更高优先级的样式覆盖了它。这时候可以用!important临时验证但正式修复还是要调整选择器优先级或者命名空间。4.2 动态导入的chunk加载失败chunk加载失败的原因很多网络抖动、CDN节点故障、文件被误删、跨域配置错误。表现就是控制台报ChunkLoadError页面白屏或者组件不渲染。排查步骤我一般这样走首先看Network面板找到那个失败的chunk请求看状态码是什么。如果是404说明文件路径不对或者文件不存在检查Webpack的publicPath配置和CDN上的文件是否同步。如果是403说明跨域配置有问题检查CDN的CORS设置。如果是超时或者连接重置说明网络问题需要加重试机制。重试机制前面提过这里补充一个细节重试时要加时间戳或者随机参数避免浏览器缓存了失败的响应。比如import(./module?t Date.now())这样每次重试都是一个新的URL不会命中缓存。但这样也会导致Webpack的chunk文件名对不上所以更好的做法是在Webpack配置里用output.chunkFilename加上[contenthash]然后重试时通过修改publicPath来绕过缓存。还有一个隐藏的坑如果用户长时间不刷新页面而服务端部署了新版本旧的chunk文件可能已经被删除了。这时候用户点击一个异步加载的按钮就会404。解决方案是保留旧版本的chunk文件至少一个发布周期或者在前端检测到ChunkLoadError时强制刷新页面。我通常会在错误边界里捕获这个错误然后window.location.reload()但要注意加个标记避免无限刷新。4.3 预加载资源未被使用link relpreload如果preload了但没用到Chrome控制台会报一个警告“The resource was preloaded but not used within a few seconds.”这个警告不仅烦人还意味着你浪费了带宽。常见原因有几个一是preload的URL和实际请求的URL不一致比如preload了font.woff2但CSS里引用的是font.woff2?v1。二是preload的资源被其他资源阻塞了比如preload了一个图片但图片的加载被JS阻塞了。三是preload的as属性写错了比如字体应该是asfont如果写成asfetch浏览器会按fetch的优先级处理可能不会及时使用。排查方法在Network面板里看preload的请求对比它的URL和实际使用时的URL。如果URL不一致统一它们。如果URL一致但还是没用到检查as属性是否正确。字体的asfont必须配合crossorigin属性因为字体请求是跨域的。图片的asimage不需要crossorigin除非是跨域图片。我的经验是preload只用于首屏关键资源且必须确保URL完全一致。对于不确定是否会用到的资源用prefetch而不是preload。prefetch没有“未使用”的警告因为它本来就是“可能用到”的语义。4.4 异步加载导致的竞态条件竞态条件是异步加载中最隐蔽的bug。典型场景用户快速切换路由路由A的异步组件还在加载用户已经切到了路由B结果路由A的组件加载完成后渲染到了路由B的页面上。或者用户快速点击搜索按钮第一次搜索的请求还没返回第二次搜索已经发出结果第一次的结果覆盖了第二次的。解决竞态条件的核心思路是取消过期的异步操作。对于动态导入可以在组件卸载时设置一个标记导入完成后检查这个标记如果组件已经卸载就不执行后续逻辑。对于网络请求用AbortController取消过期的请求。let currentAbortController null; function search(keyword) { if (currentAbortController) { currentAbortController.abort(); } currentAbortController new AbortController(); fetch(/api/search?q${keyword}, { signal: currentAbortController.signal }) .then(res res.json()) .then(data render(data)) .catch(err { if (err.name ! AbortError) { console.error(err); } }); }React的useEffect里做异步操作时一定要在cleanup函数里取消订阅或者设置标记。Vue的onUnmounted同理。这个习惯能避免大量的“组件已卸载但setState”的警告和内存泄漏。4.5 性能优化效果不明显怎么办有时候你做了代码分割、懒加载、预加载但Lighthouse分数没怎么变或者LCP还是很高。这时候不要慌先确认几件事。第一确认优化真的生效了。在Network面板里看首屏加载的资源列表对比优化前后的请求数量和体积。如果请求数量没减少说明代码分割没生效可能是Webpack配置有问题或者动态导入的模块被其他同步模块引用了导致Webpack把它打回了主chunk。第二确认瓶颈不在前端。如果HTML下载时间很长或者TTFBTime To First Byte很高那瓶颈在服务端或者网络前端优化再多也没用。这时候要看服务端渲染、CDN、数据库查询这些环节。第三确认没有其他性能问题掩盖了优化效果。比如你优化了JS加载但CSS里有一个巨大的背景图或者有一个同步的第三方脚本阻塞了渲染那LCP还是下不来。用Performance面板录制一次完整加载看主线程有没有长任务看渲染有没有被阻塞。我个人的经验是性能优化要抓大放小先解决最明显的瓶颈。如果首屏JS有1MB先做代码分割如果图片有2MB先做压缩和懒加载如果第三方脚本有500KB先做异步和延迟。每次只改一个变量测一次数据确认有效再继续。不要一次性改一堆东西否则出了问题都不知道是哪个改动导致的。5. 移动端与特殊场景的异步加载考量5.1 移动端网络的不稳定性应对移动端和桌面端最大的区别是网络环境。4G信号时好时坏地铁里、电梯里、人群密集的地方网络延迟可能从50ms飙升到2000ms。在这种环境下异步加载的策略要更保守。首先超时时间要设短。桌面端可以等5秒移动端建议2-3秒就超时。超时后走降级方案比如展示缓存数据、展示骨架屏、或者提示用户重试。不要让用户对着loading转圈超过3秒否则大概率会关掉页面。其次重试策略要更积极。移动端网络抖动是常态一次失败不代表真的失败。我的做法是首次请求超时2秒失败后立即重试一次不等待再失败等1秒重试最多重试3次。如果3次都失败才展示错误提示。第三资源体积要更严格。桌面端可以接受200KB的chunk移动端最好控制在100KB以内。因为移动端网络带宽有限而且流量对用户是有成本的。我通常会把移动端的splitChunks.minSize调到1000010KB让更多小模块被合并减少请求数。还有一个细节移动端要监听网络状态变化。navigator.onLine和online/offline事件可以告诉你用户是否在线。如果用户离线了就不要发起异步请求了直接走缓存或者提示。如果用户从离线变为在线可以自动重试之前失败的请求。5.2 低端设备的性能降级低端安卓机的CPU性能和内存都比旗舰机差很多。同样的JS代码在旗舰机上执行50ms在低端机上可能要200ms。异步加载的chunk如果太大解析和执行的时间会很长导致页面卡顿。针对低端设备我通常会做几件事减少首屏JS体积把非关键逻辑尽量往后放降低动画复杂度用CSS动画代替JS动画减少同时加载的资源数量避免内存峰值过高。检测低端设备的方法navigator.hardwareConcurrency可以拿到CPU核心数navigator.deviceMemory可以拿到内存大小单位GB。如果核心数小于4或者内存小于2GB就认为是低端设备启用降级策略。但这两个API的兼容性一般Safari不支持deviceMemory所以只能作为参考不能完全依赖。更可靠的方法是运行时性能检测。在页面加载后用requestAnimationFrame测几帧的耗时如果平均帧耗时超过16ms即低于60fps说明设备性能不足可以动态降低一些非关键功能的加载优先级。比如延迟加载图表库、关闭一些装饰性动画。5.3 服务端渲染与异步加载的配合服务端渲染SSR和异步加载看起来是矛盾的SSR要把内容在服务端渲染好异步加载要把资源延后加载。但实际上它们是互补的。SSR解决的是首屏内容的问题——让用户尽快看到有内容的页面而不是白屏。异步加载解决的是交互的问题——让页面尽快可交互而不是等所有JS都加载完。在SSR场景下首屏的HTML已经包含了内容所以首屏的JS可以更激进地异步加载。我的做法是SSR渲染的页面首屏JS只加载水合hydration必需的代码其余交互逻辑全部异步加载。这样用户看到内容的时间FCP很早但页面可交互的时间TTI可能会晚一点。对于内容型页面新闻、博客、商品详情这个取舍是值得的因为用户主要是来看内容的不是来交互的。但要注意SSR的水合过程如果太慢会导致用户点击按钮没反应。所以水合代码要尽量精简只绑定必要的事件监听。复杂的交互逻辑可以等水合完成后再异步加载和绑定。另一个细节是SSR的HTML里不要包含异步组件的占位内容。如果异步组件在服务端渲染了一个占位符客户端水合时又要替换成真实内容会导致布局偏移。更好的做法是异步组件在服务端不渲染客户端加载完成后再渲染同时用CSS占位符预留空间。6. 我个人的实操心得与避坑清单做了这么多年的性能优化我最大的体会是异步加载不是目的用户体验才是。不要为了异步而异步不要为了Lighthouse分数而优化。用户感知到的快才是真的快。我见过一个项目为了追求极致的首屏速度把首屏JS压到了50KB但代价是用户点击任何按钮都要等1-2秒加载chunk。结果Lighthouse分数很高但用户投诉“点了没反应”。这就是典型的“指标优化了体验变差了”。所以我的原则是首屏要快交互也要快。首屏JS可以小但交互相关的chunk要提前预加载。比如用户鼠标悬停在按钮上时就开始预加载点击后需要的chunk用户滚动到列表底部时就开始预加载下一页的数据。这些“预测性加载”能让用户感觉不到异步的存在。另一个心得是缓存比加载更重要。与其花大量时间优化加载速度不如把缓存做好。用户第二次访问时所有资源都从缓存读取加载时间接近零。Service Worker HTTP缓存 本地存储这三层缓存做好用户体验会有质的提升。最后分享一个排查性能问题的技巧用真实设备测不要只用模拟器。Chrome DevTools的Network throttling只能模拟网络延迟不能模拟CPU性能。低端安卓机的JS执行速度可能只有你开发机的十分之一。我习惯用一台千元安卓机做测试如果在那上面体验流畅那在旗舰机上肯定没问题。避坑清单我整理了一个表格都是实际项目中踩过的坑坑点表现解决方案preload URL不一致控制台警告资源重复加载确保preload的URL和实际请求完全一致动态导入未处理失败白屏控制台ChunkLoadError加重试机制和错误边界异步组件样式冲突样式错乱部分样式丢失用CSS Modules或BEM命名空间竞态条件旧数据覆盖新数据用AbortController取消过期请求低端设备卡顿页面响应慢动画掉帧检测设备性能动态降级Service Worker缓存不更新用户一直看到旧版本skipWaiting clients.claim 提示刷新第三方脚本阻塞LCP高主线程长任务async/defer 延迟加载 iframe隔离图片懒加载布局偏移CLS高内容跳动设置固定宽高比占位这些坑我基本都踩过一遍有些坑踩了好几次才找到原因。希望这份清单能帮你少走点弯路。性能优化这件事没有银弹就是一个个细节抠出来的。但每优化一点用户就能快一点这个投入是值得的。
