AI Coding · 首页 LCP 性能治理复盘
模型协作： gpt-5.5-medium（约 8%）、claude-fable-5-thinking-high（约 24.7% / 601.4 万 tokens）
优化目标： 降低首页 LCP（最大内容绘制）；约束条件为小幅改动、不删功能、具备全量回滚能力。
测试口径： 本地生产构建（Production Build）+ Lighthouse 模拟环境（默认 CPU/网络节流）。
基线分析：LCP 阶段拆解与瓶颈识别
性能治理的前提是建立高置信度的度量基线。基于首轮 Lighthouse 审计报告 lh-home3.json（测试环境：http://localhost:3100/），核心指标特征如下：
核心指标特征
后端响应与网络首字节到达极快，排除服务端性能瓶颈。
呈现同步阻塞特征，首帧绘制即呈现最大内容。
基线状态下主线程无长任务（Long Task）阻塞。
LCP 生命周期深度拆解
通过对 LCP 元素的指标序列进行物理拆解，其四个核心阶段的表现为：
四阶段物理占比
此外，基线 LCP 元素落在列表区的文章摘要 <p> 而非 Hero 区域的 <h1>，反映出首屏 DOM 结构的视觉权重分布不合理。
优化动作实施与分项控制变量分析
本轮迭代共实施三项技术改动。由于上线初期未严格执行单变量对照，团队在复盘阶段对各项改动的实际产出进行了二次隔离审计与重新归类。
2.1 服务端预计算与客户端边界清洗
实施方案： 将首页日期格式化、专题展示对象构造等动态抽象逻辑全量收拢至服务端 page.tsx。客户端组件 HomeArticlePanel 转换为纯粹的展示型组件，仅接收裁剪后的 HomeArticleListItemData 契约数据。
物理验证： 走读构建产物，首页最大 JS 核心 Chunk（b60ddc...，transfer 约 320 KB）体积在改动前后完全一致；Lighthouse unused-javascript 审计项依然提示存在约 398 KiB 的冗余代码。
定量结论： 该项改动未兑现任何 Bundle 缩减收益。本质上属于预防性架构治理（理清了客户端依赖边界），不应作为性能优化的直接战果。
2.2 关闭 experimental.inlineCss 配置
这是本轮唯一捕获到明确物理变形的结构性改动。通过对首页 HTML 构建产物进行 A/B 定量实测：
首页 HTML 构建产物定量对比
| 维度 | inlineCss 开启（基线） | inlineCss 关闭（当前） | 净变化 |
|---|---|---|---|
| HTML 总字符数 | 387,268 | 50,557 | -86.9% |
内联 <style> 体积 | 167,531 chars | 0 | -167.5 KB |
内联 <script> 体积 | 200,601 chars | 31,485 | -169.1 KB |
| 外链 Stylesheet 数量 | 0 | 1 | +1 |
收益确认： 首页 HTML 文本实现结构性瘦身，成功将 168 KB 的内联样式移出文档流，转化为支持浏览器级强缓存的独立外链 CSS。
潜在风险（验证缺口）： 由于本地测试基于 localhost（RTT ≈ 0ms），外链 CSS 的网络请求损耗被掩盖。在真实物理网络（尤其首访用户）下，多出的一次 CSS 关键资源请求若遭遇 TCP 握手或拥塞，存在劣化 FCP/LCP 的结构性风险。此外，该配置为全局生效，文章详情页等次级路由的联动影响尚未复测。
2.3 移除无效字体栈配置
实施方案： 将全站 font-family 从 'Inter', ... 改为系统字体优先的 system-ui, ...。
事后走读审计： 确认全站源码及构建配置中均未包含 @font-face 声明，亦未启用 next/font 模块。这意味着 'Inter' 字体在基线期从未发生过实际的网络加载。
定量结论： 所谓"中日韩（CJK）字体回退导致绘制延迟"的原始假设破产。移除该字体栈属于无价值改动，且代码中遗留的 font-feature-settings: 'cv02'... 已沦为无效死代码，亟待清理。
跑分数据客观呈现：拒绝非统计学"摘樱桃"
为排除实验室内噪声干扰，团队拒绝采信单次跑分的最优解，将多轮演进的连续采样数据客观对齐：
3.1 模拟节流口径（Throttling: Simulated Desktop）
Throttling: Simulated Desktop
初始对照组
架构边界清洗
HTML 结构性瘦身
全量改动叠加
3.2 无节流口径（Throttling Method: Provided）
基线单次采样： LCP 1.5 s / TBT 0 ms - 最终形态单次采样： LCP 1.3 ~ 1.4 s / TBT 10 ms
无节流环境下 LCP 呈现微弱下行趋势，但因样本量极小（仅单次测算），在统计学上属于孤证，无法推导具备普遍意义的强结论。
确定性结构收益： 最终形态下，首页 LCP 元素成功由文章摘要 <p> 移转至 Hero 区域的 <h1>。这证明首屏视口内的元素布局与渲染权重达到了预期中的更优状态，但该收益并未直接转化为 LCP 时间指标的胜势。
AI 协同效能的边界反思
本轮优化引入了双模型协作（claude-fable-5-thinking-high 消耗约 601.4 万 tokens，gpt-5.5-medium 承担约 8% 辅助工作）。通过复盘，团队重新确立了 AI 在复杂性能工程中的效能边界：
长上下文思考模型的合法边界： 极度擅长跨文件走读（如 Layout、Page、Chunk 联动审查）、代码仓库风险扫描（脏工作树、幽灵生成文件）以及 A/B 测试的假设架构设计。 - 中等模型的合法边界： 负责确定性原子代码的快速搬砖实现、测试断言补全以及质量门禁脚本编写。
结论： AI 优化的是研发团队的"决策流速"与"线索整理效率"，而非"投入的 Token 越多，产出的技术结论越正确"。将 600 万 Token 的消耗视作方案严谨性的背书，是典型的将研发成本与技术质量混淆的逻辑谬误。性能科学的严谨性，只取决于控制变量的纯净度与度量数据的采样规模。
下一阶段：高 ROI 性能攻坚行动指南
为扭转当前"体积变瘦、主线程变卡"的被动局面，后续行动必须严格遵循数据驱动的工程纪律：
数据驱动的工程纪律
确立可信度量纪律
废除单次跑分汇报制。后续任何本地 Lighthouse 评估必须执行 10 次高密度采样并计算标准差与中位数；同时立刻在线上对齐 Vercel Speed Insights 的真实用户（RUM）P75 LCP 数据。
隔离回滚与清理死代码
立刻全量回退字体栈改动，彻底清空 font-feature-settings 死代码，消除混杂变量。
抓取 Performance Trace 火焰图
开启 Chrome DevTools 生产环境 Profile，全力复核那 98% Render Delay 的耗时占比，重点捕获 React hydrateRoot 的执行耗时与长任务分布。
验证 Link Prefetch 暴政假说
首页高频出现的 1 MB 级巨型 Chunk，强烈怀疑是 Next.js Link 标签在首屏大规模自动执行 prefetch 所致。立刻全量核对 Network 面板中的 as=script 触发频次。
全路由联动压测
针对关闭 inlineCss 的核心改动，立刻补测文章详情页等非首页路由的 FCP/LCP 波动；同步运行全量 vitest 端到端单元测试。
固化 CI 性能预算门禁
正式在 CI/CD 流程中集入 lighthouse-ci (LHCI)，针对首页 HTML Document 体积注入硬性阈值预算（Budget < 60 KB）。
本文属于 AI 实用主义流派 的第 40 篇肉身实战。
发表评论
分享你的想法和反馈