浏览器端深度学习推理实战：TensorFlow.js多后端调度与生产避坑指南
2026/9/30 9:36:45
1. 异步加载到底在解决什么问题
前端性能优化这个话题，说起来人人都懂一点，但真到了项目里，很多人第一反应还是“压缩图片、开个CDN、上懒加载”，然后就没下文了。我做了十多年前端，见过太多项目把性能优化做成了“玄学调参”——今天看个文章说预加载好，明天看个视频说骨架屏香，最后代码里堆了一堆互相打架的策略，首屏该慢还是慢。
异步加载这件事，本质上不是某个API的用法问题，而是一个资源调度问题。你可以把浏览器想象成一个只有一条主通道的仓库，HTML是进货单，JS和CSS是必须优先上架的货物，图片、视频、字体这些是“可以晚点摆出来”的展示品。异步加载要做的，就是决定哪些货物先上架、哪些可以等顾客走到货架前再拿出来。
这个决策做得好不好，直接决定了三个核心指标：首屏渲染时间（FCP）、最大内容绘制时间（LCP）、可交互时间（TTI）。我见过一个后台管理系统，首页加载了2.3MB的JS，其中真正首屏用到的不到300KB，剩下的全是各种图表库、富文本编辑器、地图组件。这就是典型的“同步加载思维”——反正都要用，那就一次性全加载了。结果就是用户盯着白屏转圈圈，产品经理天天被老板问“为什么这么慢”。
所以异步加载的核心目标很明确：让首屏只加载首屏需要的东西，其余资源按需、分时、分优先级加载。这不是一个技术炫技，而是一个成本收益的权衡——你多花一天时间做代码分割和加载策略，换来的是用户留存率提升几个百分点，这笔账怎么算都划算。
适合谁来参考这篇内容？如果你是刚接触性能优化的初中级前端，这篇能帮你建立一套完整的异步加载认知框架；如果你是有经验的开发者，里面关于加载优先级、预加载时机、缓存策略的细节应该能给你一些新的思路。我不打算讲太多教科书式的定义，而是把我在实际项目里踩过的坑、验证过的方案，原原本本拆开来说。
2. 异步加载的核心机制与方案选型
2.1 浏览器原生的加载优先级体系
很多人做异步加载时忽略了一个前提：浏览器本身已经有一套资源优先级机制了。Chrome从很早的版本开始，就把网络请求分成了五个优先级：Highest、High、Medium、Low、Lowest。HTML文档本身是Highest，CSS是Highest，同步JS是High，而图片、字体这些默认是Low或Medium。
这意味着什么？意味着你写一个<img>标签，浏览器不会立刻去下载它，而是等HTML解析到那个位置、布局计算完成后才开始请求。但如果你用fetch或者XMLHttpRequest手动去拉图片，反而可能打乱这个优先级。我见过一个项目，为了做图片懒加载，用Intersection Observer监听图片进入视口，然后手动new Image()去加载，结果因为手动创建的Image对象优先级被判定为Low，加载速度比原生<img loading="lazy">还慢。
所以第一个原则是：能用原生属性解决的，不要用JS手动干预。<img loading="lazy">、<script defer>、<script async>、<link rel="preload">这些原生能力，浏览器厂商已经帮你把优先级调度做得很好了。你手动用JS去控制，反而容易适得其反。
但原生能力也有局限。比如<script async>虽然不阻塞HTML解析，但它的执行时机是不确定的——可能在DOMContentLoaded之前，也可能之后。如果你的脚本依赖DOM结构，用async就是给自己埋雷。这时候就需要更精细的控制手段。
2.2 代码分割的粒度怎么定
代码分割是异步加载的基础。没有分割，就没有异步。但分割粒度是个技术活——切得太粗，一个chunk还是几百KB，异步加载没意义；切得太细，HTTP请求数量爆炸，反而增加开销。
我的经验法则是：按路由分割是底线，按功能模块分割是进阶，按组件分割要谨慎。路由级别的分割是最容易做的，Webpack的import()配合React Router或者Vue Router，每个路由页面打成一个独立的chunk。这个粒度通常比较合适，因为用户访问一个页面时，确实只需要那个页面的代码。
但路由分割有个问题：如果两个路由共享了大量组件，Webpack默认会把共享部分提取到公共chunk里。这时候你需要配置splitChunks策略。我一般会设置minSize: 20000（20KB），小于这个大小的模块不单独分割，避免产生大量碎片文件。同时设置maxInitialRequests: 6，控制首屏并行请求数量，因为浏览器对同一域名的并发请求是有限制的（HTTP/1.1下通常是6个）。
功能模块级别的分割更适合大型应用。比如一个电商后台，商品管理、订单管理、数据分析这三个模块，每个模块内部又有自己的子路由和组件。这时候可以在路由分割的基础上，把每个模块的公共依赖（比如该模块专用的图表库、表格组件）再单独抽出来。这样用户进入商品管理时，不会加载订单管理才用的富文本编辑器。
组件级别的分割要特别小心。我见过有人把每个Modal弹窗都做成异步组件，结果用户点开一个弹窗要等500ms加载chunk，体验极差。只有那些“首屏绝对用不到、且体积较大”的组件才值得单独分割，比如代码编辑器、地图组件、PDF预览器。判断标准很简单：这个组件如果同步加载，会让首屏体积增加超过50KB吗？如果会，就分割；如果不会，就别折腾。
2.3 预加载与预取的时机选择
异步加载解决的是“什么时候加载”，预加载解决的是“能不能提前加载”。这两者配合使用，才能达到最佳效果。
<link rel="preload">是告诉浏览器：“这个资源我后面肯定要用，你尽快下载，但先别执行/渲染。”它适合关键路径上的资源，比如首屏渲染必需的字体文件、首屏图片、关键的CSS。但preload有个坑：如果你preload了一个资源，但实际使用时又用另一个URL去请求（比如带了不同的query参数），浏览器会认为这是两个不同的资源，preload就白做了。所以preload的URL必须和实际请求的URL完全一致。
<link rel="prefetch">则是告诉浏览器：“这个资源可能后面会用到，你在空闲时间下载。”它适合下一个页面可能用到的资源，比如用户从列表页进入详情页，详情页的JS就可以在列表页空闲时prefetch。但prefetch的优先级非常低，如果网络繁忙或者用户快速跳转，可能根本来不及下载。所以prefetch只能作为锦上添花，不能作为核心加载策略。
<link rel="preconnect">和<link rel="dns-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里。这通常是好事，因为减少了请求数。但如果你有多个异步组件都依赖echarts，Webpack会把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.8MB，LCP时间4.2秒。分析后发现，首屏真正需要的组件只有Header、Banner、商品列表，但打包时把整个应用的路由、状态管理、工具库全打进去了。做了路由分割后，首屏JS降到420KB，LCP降到1.8秒。这个提升不是靠什么黑科技，就是老老实实做代码分割。
关键CSS内联是另一个立竿见影的优化。首屏渲染需要的CSS通常只占整个CSS文件的10%-20%，把这部分内联到HTML的<style>标签里，剩下的CSS用<link rel="preload" as="style" onload="this.rel='stylesheet'">异步加载，能消除CSS阻塞渲染的时间。但要注意，内联CSS会增加HTML体积，如果HTML本身已经很大，就要权衡了。我的经验是：内联CSS不超过14KB（因为TCP慢启动阶段第一个往返大约能传输14KB），超过这个数就考虑拆分。
3.2 图片与字体的异步加载策略
图片通常是页面中体积最大的资源，但也是最容易做异步加载的。原生<img loading="lazy">已经能覆盖大部分场景，但有几个细节要注意。
首先是占位符。懒加载的图片在加载完成前，如果没有任何占位，会导致布局偏移（CLS）。我的做法是给图片设置固定的宽高比，用CSS的aspect-ratio或者padding-top百分比来占位。这样图片加载完成后，不会把下面的内容挤下去。CLS是Core Web Vitals的指标之一，布局偏移太大会影响SEO排名。
其次是响应式图片。<img srcset>和<picture>可以根据屏幕尺寸和DPR加载不同分辨率的图片。移动端加载桌面端的大图，是典型的浪费。我一般会准备三套尺寸：480w、960w、1440w，配合sizes属性让浏览器自己选择。这个优化能减少移动端30%-50%的图片流量。
字体加载是另一个容易被忽视的点。自定义字体如果同步加载，会导致FOIT（Flash of Invisible Text）——文字在字体加载完成前不可见。解决方案是font-display: swap，让浏览器先用系统字体渲染，字体加载完成后再替换。但swap会导致FOUT（Flash 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 rel="preconnect" href="https://fonts.googleapis.com">，能省下DNS解析和TCP握手的时间。这个优化成本极低，但效果很明显。
3.4 缓存策略与Service Worker的配合
异步加载的资源，如果每次都要重新下载，那异步的意义就大打折扣。缓存策略是异步加载的“后勤保障”。
HTTP缓存是最基础的。对于带hash的静态资源（比如main.a1b2c3.js），设置Cache-Control: max-age=31536000, immutable，让浏览器永久缓存。因为文件名带hash，内容变了文件名就变了，不存在缓存失效的问题。对于HTML文件，设置Cache-Control: no-cache，让浏览器每次都去服务端验证，但可以用304响应减少传输量。
Service Worker是更高级的缓存方案。它可以拦截所有网络请求，根据自定义策略返回缓存或网络响应。我常用的策略是：静态资源用Cache First，API请求用Network First，HTML用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 rel="preload">如果preload了但没用到，Chrome控制台会报一个警告：“The resource was preloaded but not used within a few seconds.”这个警告不仅烦人，还意味着你浪费了带宽。
常见原因有几个：一是preload的URL和实际请求的URL不一致，比如preload了font.woff2，但CSS里引用的是font.woff2?v=1。二是preload的资源被其他资源阻塞了，比如preload了一个图片，但图片的加载被JS阻塞了。三是preload的as属性写错了，比如字体应该是as="font"，如果写成as="fetch"，浏览器会按fetch的优先级处理，可能不会及时使用。
排查方法：在Network面板里看preload的请求，对比它的URL和实际使用时的URL。如果URL不一致，统一它们。如果URL一致但还是没用到，检查as属性是否正确。字体的as="font"必须配合crossorigin属性，因为字体请求是跨域的。图片的as="image"不需要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下载时间很长，或者TTFB（Time 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调到10000（10KB），让更多小模块被合并，减少请求数。
还有一个细节：移动端要监听网络状态变化。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高，内容跳动 | 设置固定宽高比占位 |
这些坑我基本都踩过一遍，有些坑踩了好几次才找到原因。希望这份清单能帮你少走点弯路。性能优化这件事，没有银弹，就是一个个细节抠出来的。但每优化一点，用户就能快一点，这个投入是值得的。