Google Core Web Vitals 把企业搞焦虑了。
LCP 要在 2.5 秒内完成，TTI 要在 3.8 秒内，CLS 要低于 0.1。这套标准出来之后，SEO 圈掀起了一股"极致性能"的风潮：图片要压缩到最小、JS 要按需加载、CSS 要内联首屏……企业 SEO 团队 KPI 里多了一项"Core Web Vitals 得分"，分数越高越好。
然后 AI 时代来了。
企业官网开始接 AI 客服、AI Agent、AI 驱动的个性化推荐。每个 AI 组件都会增加前端的 JS 体积、增加后端的 API 调用、增加额外的网络请求。Core Web Vitals 分数应声下跌。
很多企业陷入了一个尴尬的境地：要性能，就接不了 AI；要 AI，就牺牲性能。SEO 那边还在催"你们分数跌了会影响排名"。
首先要搞清楚：性能的意义到底是什么
性能不是数字，是用户体验。
你追求 LCP 2.5 秒，本质上是为了让用户尽快看到页面内容、尽快能操作页面。但如果为了这个目标，你把 AI 客服的代码延迟加载到"页面完全加载完之后再初始化"——用户可能在页面加载的那几秒里还挺满意的，但当他滚动到中间、想找 AI 客服问个问题时，AI 还没加载好。
这种场景下，你实际上牺牲了一个用户体验（"随时可以问问题"）来换另一个用户体验（"页面加载快"）。哪个更重要？要看你的业务。
对于一个追求"让访客尽快联系上我们"的企业官网来说，AI 客服的即时可用，比 LCP 快 0.5 秒重要得多。因为访客找 AI 客服的那个瞬间，就是他最接近成交的那个瞬间。
两套指标要分开看
我们建议企业在看性能的时候，把指标分成两套。
传统 Web 性能指标（Core Web Vitals）：
- LCP 首屏加载时间
- TTI 可交互时间
- CLS 布局稳定性
这套指标反映的是"静态页面本身的性能"，目标是让页面尽快能看。
AI 功能体验指标：
- AI 客服首次响应时间
- AI Agent 完成一次完整工具调用的耗时
- AI 组件的初始化失败率
- AI 组件的平均每日调用次数
这套指标反映的是"AI 功能的实际可用性"，目标是让 AI 真的能用、好用。
很多企业只盯着前一套指标，把后一套指标完全忽略了。然后 AI 功能确实"不影响首屏加载"——但用户想用的时候发现它还在转圈圈，或者根本点不开。这就是典型的"为了数字而牺牲体验"。
几个实用的优化策略
性能和 AI 不是完全对立的，有几个方法能在两者之间找到平衡。
策略一：AI 组件按需加载。
不要让 AI 客服的代码在页面首屏就加载完。可以等用户滚动到一定位置，或者用户鼠标在页面停留超过 3 秒，再开始异步加载 AI 组件。这样首屏的 Core Web Vitals 不受影响，同时 AI 的初始化时机也不会让用户等太久。
策略二：大模型调用做中间缓存。
很多 AI Agent 的请求其实是重复的。今天有 20 个人问"你们有没有 XX 型号的产品"，你没必要让大模型回答 20 次。在 AI 调用链中间加一层缓存，把高频问题的回答存起来，命中缓存直接返回，不需要再调大模型 API。这样既能减少大模型 API 消耗的成本，也能大幅提升 AI 的响应速度。
策略三：给 AI 功能做降级方案。
万一 AI 服务挂了怎么办？或者大模型 API 超时了怎么办？这时候要有一个明确的降级方案。比如 AI 客服答不上来，自动展示一个表单让用户留资；AI Agent 调用工具失败，提示用户"稍后再试"同时推一条提示消息到企业微信。降级方案的关键是：让用户知道"AI 暂时不行，但还有别的办法"，而不是让他对着一个转圈圈的界面发呆。
策略四：不要把 Core Web Vitals 得分当唯一 KPI。
SEO 团队的 KPI 应该和业务指标挂钩：AI 客服带来的留资量、AI Agent 带来的询价量、AI 功能的日活使用率。这些才是真正反映 AI 价值的指标。Core Web Vitals 得分是中间指标，不是最终目标。
写在最后
在 AI 时代，一个"加载极快但没 AI 功能"的官网，和一个"首屏稍慢但能主动帮用户解决问题"的官网，哪个对企业更有价值？答案显然是后者。
性能是工具，不是目的。让用户真的能在你的官网上完成他想做的事——这才是一个好官网该追求的。
