这是「华为云码道实战」系列的第十一篇。前十篇覆盖了成长、观点、安全、性能（后端）、部署、数据、技术债、需求、MCP、可观测性。这一篇回到前端——页面能打开不等于体验好，Core Web Vitals 不达标就是丢用户。

我造了一个"典型有问题"的电商商品列表页，丢给华为云码道的前端性能优化专家，让它做一次性能剖析与优化——12 项对比、Core Web Vitals 三项全部从"差"变"优"。

一、造一个"典型有问题"的页面

真实的前端性能问题不是"写错了代码"，而是"能跑就行"的惯性积累。我按这个思路造了一个电商商品列表页（index.html），60 个商品卡片，埋了 8 类问题：

<head>
  <!-- 4 个同步 JS 阻塞渲染 -->
  <script src=".../jquery@2.2.4"></script>
  <script src=".../bootstrap@3.4.1"></script>
  <script src=".../lodash@4.17.21"></script>      <!-- 全量71KB，只用了4个方法 -->
  <script src=".../moment@2.29.4"></script>        <!-- 全量70KB，只用了格式化 -->
</head>

// 60次 appendChild，无 DocumentFragment，60次 reflow
products.forEach(function(p) {
  var card = document.createElement('div');
  // ...
  document.getElementById('productGrid').appendChild(card);
});

// setInterval 每2秒轮询库存
setInterval(function() {
  $.getJSON('...');  // jQuery 全量引入就为了这个
}, 2000);

这些问题在开发环境"感觉不到慢"——因为本地网络快、图片缓存了、DevTools 不开。但到了真实用户那里：LCP 5 秒、FID 600ms、CLS 0.3，全是"差"评级。

二、把页面交给前端性能优化专家

我调用了华为云码道的前端性能优化专家（frontend-performance）子智能体，给它一句话需求：

"对 /workspace/frontend-perf-demo/index.html 做性能剖析与优化，产出优化后页面和前后对比报告。"

它自己读完了源码，逐项分析每个问题对 Core Web Vitals 的影响，然后产出了优化后的页面（index_optimized.html）和对比报告。下面每一项都是它真实改出来的。

三、8 项性能问题剖析

注意一个规律：很多问题的根因不是"代码写错了"，而是"引入了不需要的东西"。jQuery、Lodash、Moment.js、Bootstrap——全量引入但实际只用了几个方法。移除它们不是"优化"，是"减负"。

四、12 项优化对比

挑几个关键优化解读：

4.1 DocumentFragment：60 次 reflow → 1 次

// Before: 60 次 appendChild，每次触发 reflow
products.forEach(function(p) {
  grid.appendChild(card);  // ×60
});

// After: 先攒到 fragment，一次性插入
var fragment = document.createDocumentFragment();
products.forEach(function(p) {
  fragment.appendChild(card);
});
grid.appendChild(fragment);  // ×1

reflow 从 60 次降到 1 次。这不是微优化——在低端安卓机上，60 次 reflow 的差异是"卡 300ms"和"丝滑"的区别。

4.2 setInterval → IntersectionObserver：零轮询

// Before: 每 2 秒无脑轮询
setInterval(function() { $.getJSON('...'); }, 2000);

// After: 仅当卡片进入视口时检查一次，检查完 unobserve
var observer = new IntersectionObserver(function(entries) {
  entries.forEach(function(entry) {
    if (entry.isIntersecting) {
      checkStock(entry.target);
      observer.unobserve(entry.target);  // 检查一次就不再观察
    }
  });
}, { rootMargin: '200px' });

从"每 2 秒一次 forever"变成"每张卡片进入视口时检查一次"。用户不滚到的卡片不检查，网络和主线程零浪费。

4.3 第三方库原生化：141KB → 0KB

Lodash 的 range/map/sortBy/sum → 原生 Array.from/map/sort/reduce。Moment.js 的 format → 原生 Date + 补零函数。页面根本不需要这些库——它们是历史遗留，当时图方便引入的，后来再没人敢删。

五、Core Web Vitals：三项全部从"差"变"优"

首屏传输从 400KB 降到 5KB——不是压缩，是移除了不需要的东西。400KB 里有 250KB 是四个 JS 库，51KB 是 Bootstrap CSS，31KB 是 Font Awesome，加上 60 张大图。优化后这些全没了，首屏只剩内联 CSS + banner 图 + 2 个字体。

六、复盘：前端性能优化专家替我做了什么

回看整个过程，我作为"前端开发"只做了一件事：把页面路径给它。它自己完成了：

有问题的 HTML
    │
    ├─ 逐项剖析      → 8 个问题，每个标注对 CWV 的影响
    ├─ 代码优化      → 12 项改动，产出 index_optimized.html
    ├─ 前后对比      → 12 行差异表
    └─ CWV 预估      → LCP/INP/CLS 三项从"差"变"优"

这和"让 AI 帮我加个 loading=lazy"有三个本质区别：

最让我意外的是它对"不需要的东西"的判断。普通 AI 优化倾向于"加东西"——加 preload、加 cache-control、加 CDN。但前端性能优化专家做的第一件事是减东西——移除 jQuery、移除 Lodash、移除 Moment.js、移除 Bootstrap。最好的优化是不加载，而不是加载得更快。

七、哪些地方它还没法替代人

1. 真实用户监控（RUM）：它给的是预估值（LCP 1.2~2.0s），真实用户的 LCP 取决于设备、网络、地理位置——需要部署后用 RUM 数据校准。
2. 业务逻辑权衡：它说"移除 jQuery"，但如果页面后续要加的交互都依赖 jQuery 呢？移除前要确认没有其他页面引用同一个 JS bundle。
3. 视觉回归：移除 Bootstrap CSS 后样式是否完全一致？需要视觉回归测试确认，不能只看 CWV 数字。

八、结语

前端性能是一个用户体验的直接乘数。研究表明 LCP 每增加 1 秒，转化率下降 7%。一个 LCP 5 秒的电商页面，优化到 2 秒不只是"技术指标达标"——是真金白银的转化提升。

华为云码道的前端性能优化专家，让"给页面做 Core Web Vitals 体检"的成本低到——一句话需求 + 一个 HTML 路径。而体检 + 优化一起做，从"差"到"优"只要一次调用。

系列十一篇，从"后端性能"到"前端性能"： 成长 → 观点 → 安全 → 性能(后端) → 部署 → 数据 → 技术债 → 需求 → MCP → 可观测性 → 性能(前端)。 第十一篇和第四篇（后端 52 倍提速）遥相呼应——一个优化接口延迟，一个优化页面加载，合在一起才是完整的"用户体验提速"。下一份见。

本文所有优化均由华为云码道前端性能优化专家（frontend-performance）对 /workspace/frontend-perf-demo/index.html 真实执行。优化后页面 index_optimized.html 已验证 8 项优化特征全部就位，可直接浏览器打开。