frontend-fullchain-optimization

前端全链路性能优化指南

基于 Web Vitals 核心指标的前端性能诊断与优化系统。核心原则：以用户为中心——优化的关键在于少做，而非多做。

指标阈值速查

指标	良好	需要改进	较差	单位	关注点
LCP	≤ 2.5s	2.5s - 4s	> 4s	时间	最大内容绘制
FCP	≤ 1.8s	1.8s - 3s	> 3s	时间	首次内容绘制
INP	≤ 200ms	200ms - 500ms	> 500ms	时间	交互到下一次绘制
CLS	≤ 0.1	0.1 - 0.25	> 0.25	分数	视觉稳定性
TTFB	≤ 800ms	800ms - 1.8s	> 1.8s	时间	首字节时间
FID	≤ 100ms	100ms - 300ms	> 300ms	时间	首次输入延迟
TBT	超过 50ms 的任务属于长任务	—	—	时间	总阻塞时间

测量建议：不要只依赖单个 P75。应结合 P60/P75/P90/P99 百分位，以及每日平均值/最大值/最小值趋势线。桌面端：目标为 P98 及以上；移动端核心页面：目标为 P95–P99。

诊断决策树

Page loads slowly?
├── TTFB > 800ms → Network/server issue → See "TTFB Optimization"
├── FCP > 1.8s → Resource blocking/large files → See "FCP Optimization"
├── LCP > 2.5s
│   ├── TTFB & FCP normal → Slow viewport resource loading → See "LCP Optimization"
│   └── TTFB or FCP abnormal → Fix upstream metrics first
├── INP > 200ms → Long tasks blocking main thread → See "INP Optimization"
├── CLS > 0.1 → Layout shifts → See "CLS Optimization"
└── Lighthouse Performance Score
    ├── > 80: Few issues
    ├── 60-80: Needs focused analysis, priority: FCP → LCP → CLS
    └── < 60: Severe issues, full audit required

INP 优化（交互响应性）

诊断：使用 Chrome Performance 面板，查找长任务（> 50ms，以红色突出显示）；在火焰图中检查事件处理程序的耗时。

策略——将长任务拆分为更短的任务：

方法	机制	适用场景
setTimeout(fn, 0)	在队列末尾创建新的宏任务	非紧急网络请求、数据库操作
Promise.resolve().then(fn)	创建微任务，在当前宏任务后立即运行	需要更快执行的次级任务
requestAnimationFrame(fn)	在下一次重绘前运行	与渲染相关的任务
requestIdleCallback(fn)	优先级最低，在主线程空闲时运行	分析、日志记录
scheduler.postTask(fn, {priority})	精细控制优先级	需要精确调度的场景

postTask 优先级：user-blocking（高）> user-visible（中）> background（低）

布局与渲染优化：

• 减少 calc() 的使用频率；避免不必要的伪类选择器（nth-child、nth-last-child、not()）
• 避免频繁使用 JS 修改元素的位置/大小；使用 className 或 cssText 批量更新
• 避免在循环中交替读取/写入 DOM（布局抖动）：先将读取结果缓存到变量中，再批量写入
• 为延迟加载的内容使用骨架屏
• 使用 <></>（Fragment）代替无意义的 <div> 包装元素
• DOM 节点数超过 800：需谨慎；超过 1400：过多
• 对长列表使用虚拟化（react-window / vue-virtual-scroll-list）
• Swiper 列表：仅预加载当前项及其前后各 1 项

CSS 优化：

• 避免使用 table 布局；减少深层嵌套的 CSS 选择器
• 使用 GPU 加速动画：transform/opacity 会触发合成层；避免使用会触发回流的 top/left
• 使用语义化 HTML 元素；避免无意义的标签（例如，按钮使用 <button>，而非 <div>）

TTFB 优化（网络与服务器）

诊断公式：TTFB ≈ HTTP request time + Server processing time + HTTP response time

诊断：DevTools Network 面板 → 点击请求 → Timing → “Waiting for server response” = TTFB。

不同页面类型的 TTFB 差异：静态页面（CDN 直连，最快）< SPA（HTML 外壳极小，接近静态页面）< SSR（需要 Node.js 计算，最慢）。根据页面类型调整基准值。

方向	策略
通用	CDN 加速（可解决 90% 以上的问题；部署后主动清除 CDN 缓存）、HTTP/2 多路复用、Gzip 压缩、代码拆分与动态导入
UX	使用 Web Workers 处理繁重请求、DNS 预解析 <link rel="dns-prefetch">、预连接 <link rel="preconnect">
服务器（SSR）	API 使用内部网络、用 Redis 缓存低频数据、减少重定向、在构建时预生成静态页面
资源缓存	App 热更新：在本地预下载 HTML/JS/CSS（TTFB ≈ 0），PWA Service Worker 离线缓存

FCP 优化（白屏与首屏内容）

诊断公式：FCP ≈ TTFB + Resource download time + DOM parse time + Render time

白屏时间 ≈ FCP 时间。目标：打开即显示（< 1s）。

策略	详情
移除阻塞渲染的资源	为 script 标签添加 defer 或 async；非关键 JS → NPM 包或框架组件（例如 next/script）
减小 JS/CSS 体积	移除未使用的代码、Tree Shaking、代码拆分
控制网络负载	压缩首屏可见区域的图片，使用 WebP/AVIF，为视频添加占位符并延迟加载
缓存策略	Cache-Control: max-age=31536000（静态资源缓存 1 年）；根据需要缓存 JS/CSS
缩短关键请求深度	减少嵌套的资源依赖（例如 CSS @import 链）；扁平化关键资源请求链
字体优化	参见下文“字体优化策略”
白屏解决方案	PWA（国际市场）；App 热更新本地加载（国内市场）

字体优化策略

方法	描述
限制字体数量	仅使用一种自定义字体，并回退到系统字体；正文和 p 不要使用不同的 Web Fonts
优先使用 WOFF2	压缩率比 WOFF 高 30%，所有现代浏览器均支持
unicode-range 子集化	定义字符范围（例如 CJK U+4E00-9FA5）；浏览器只下载所需子集
local() 本地字体	对于捆绑了字体的应用：src: local('Font Name'), url(...) 会优先读取本地字体，无需网络请求
font-display 策略	swap：先显示系统字体，再替换（CLS 最低）；optional：配合预加载使用（加载失败时不重新布局）；block：等待（阻塞渲染）；fallback/auto：折中方案
CSS Font Loading API	new FontFace() + font.load() + document.fonts.ready.then() — 以编程方式控制字体下载时机和替换逻辑
慢速网络回退	使用 navigator.connection 检测；为网络较慢的用户提供系统默认字体

LCP 优化（最大内容绘制）

诊断：在 Performance 面板中查找 LCP 标记元素；查看 Lighthouse 报告中的“最大内容绘制元素”条目。

LCP 可标记的 4 种元素类型：

1. <img> 元素（最常见）以及 SVG 中的 <image>
2. <video> 的 poster 属性图像或首帧
3. 使用 CSS url() 背景图像的元素
4. 包含文本节点的块级元素

关键见解：

• LCP 时间始终 ≥ FCP 时间
• 如果 TTFB 和 FCP 正常，但 LCP 异常 → 问题在于视口资源加载
• SPA：FCP 比 LCP 更重要；SSR/MPA：LCP 比 FCP 更重要

策略	详情
预加载 LCP 图像	<link rel="preload" href="..." as="image">
框架图像组件	使用 next/image（包含优先级和格式优化）；设置 priority={true}
拆分大图像	将大型背景图像切分为较小的部分
图像格式	PNG/JPEG → WebP/AVIF，可节省 30% 以上的体积
云图像参数	根据设备动态设置图像大小/质量/格式（例如，阿里云 OSS 参数）
富文本图像	从内容中提取图像 URL，并提前设置 <link rel="preload">
避免重复预加载	使用带有 priority 的框架图像组件（例如 next/image）时，不要再手动添加 <link rel="preload"> — 重复预加载会浪费带宽

采样建议：PV < 1M 时 → 全量采集 LCP；超过此值时 → 按比例采样或基于阈值上报。

CLS 优化（布局偏移）

诊断公式：布局偏移分数 = 影响比例 × 距离比例，CLS = SUM(所有偏移分数)

关键结论：元素偏移越远 + 受影响的视口区域越大 → CLS 越高。

场景	优化策略
图像	为所有 <img> 设置 width/height；在移动设备上使用 aspect-ratio；对响应式图像使用 srcset/<picture>
动态内容	为广告/iframe 预留固定尺寸的占位容器；避免在没有交互的情况下于视口顶部插入内容；在底部附近插入的 CLS 影响较小
CSS 动画	使用 transform 替代 top/left/width/height；使用 transform: scale() 替代修改尺寸
字体	使用 font-display: optional + 预加载；或使用 font-display: swap 以减轻 CLS 影响

通用优化建议

建议	说明
网络感知	使用 navigator.connection.effectiveType 检测 2G/3G/4G；针对网络较慢的用户进行降级（更小的图像、系统字体、减少加载内容）
SVG 图标	所有小图标（< 5KB / < 50px）都应使用 SVG 替代图像，以减少异步请求
响应式降级	使用 CSS 媒体查询按屏幕尺寸拆分 CSS；在小屏幕上跳过背景图像
缓存优先	在 LocalStorage 中缓存列表数据；先渲染缓存，再异步刷新，以减少白屏
合并请求	合并资源，减少 HTTP 请求数和域名数
渲染模式	根据场景选择 SSR（首次绘制快）/ CSR（交互性强）/ SSG（静态内容）

使用外部服务的实用示例

以下示例演示如何结合 CDN、OSS、Redis 和其他外部服务实施相关策略。

示例 1：阿里云 OSS — 根据网络自适应图像质量

使用场景：为网络较慢的用户优先加载可见内容；减小图像体积和下载时间。

const BASE_IMAGE_URL =
  "https://oss-console-img-demo-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/example.jpg";

function getNetworkLevel() {
  const connection = navigator.connection || {};
  const type = connection.effectiveType || "4g";
  // Slow network: slow-2g / 2g / 3g
  if (/slow-2g|2g|3g/.test(type)) return "slow";
  return "fast";
}

function buildOssImageUrl(baseUrl) {
  const level = getNetworkLevel();
  // OSS image processing params: lower resolution + quality for slow networks
  const ossParams =
    level === "slow"
      ? "x-oss-process=image/resize,w_100/quality,q_60/format,webp"
      : "x-oss-process=image/resize,w_300/quality,q_82/format,webp";

  return `${baseUrl}?${ossParams}`;
}

function updateHeroImage(imgEl) {
  imgEl.src = buildOssImageUrl(BASE_IMAGE_URL);
}

const heroImage = document.querySelector("#hero-image");
if (heroImage) {
  updateHeroImage(heroImage);
  // Update resource strategy on network change
  navigator.connection?.addEventListener("change", () => updateHeroImage(heroImage));
}

示例 2：主动清理 CDN 缓存（部署后）

使用场景：防止 SPA 部署后 CDN 提供过期资源，避免版本不一致。

# Executed by CI/CD or server-side — never expose keys in frontend
# Example: proactively purge entry HTML and critical static assets after deploy
curl -X POST "https://your-cdn-provider.example.com/purge" \
  -H "Authorization: Bearer $CDN_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "urls": [
      "https://example.com/index.html",
      "https://example.com/assets/app.abc123.js",
      "https://example.com/assets/app.abc123.css"
    ]
  }'

示例 3：SSR + Redis 缓存以降低 TTFB

使用场景：SSR 页面读取低频配置或首屏数据；减少每次请求的数据库/远程 API 延迟。

// Node.js (SSR) example
import Redis from "ioredis";

const redis = new Redis(process.env.REDIS_URL);

export async function getHomepageData() {
  const cacheKey = "homepage:data:v1";
  const cached = await redis.get(cacheKey);
  if (cached) return JSON.parse(cached);

  // Assume this is a slow API or DB query
  const data = await fetch("https://api.example.com/homepage").then((r) => r.json());

  // Cache for 60s to reduce backend pressure under high concurrency
  await redis.set(cacheKey, JSON.stringify(data), "EX", 60);
  return data;
}

工具使用建议

工具模式	使用场景
Lighthouse Navigation 模式	分析单个页面从请求到加载完成的完整过程
Lighthouse Timespan 模式	分析 SPA 路由切换和表单交互的 INP/CLS
Lighthouse Snapshot 模式	分析营销活动、动画和状态变化页面
Performance 面板	使用火焰图分析长任务，使用时间线分析资源加载顺序，逐帧分析布局偏移
Network 面板	查看请求数量/总大小/TTFB/排队时间，判断是否需要 CDN/预取/HTTP2

关键分析路径：

1. FCP 出现较晚 → 检查 JS/CSS 加载时间；对于 SSR，检查服务器 API 延迟
2. FP 和 FCP 之间间隔较长 → 检查阻塞渲染的长任务
3. FCP 和 LCP 之间间隔较大 → 视口资源过多或过大；SSR 利用不足
4. CLS 多次飙升 → 总值 > 0.25 时需要优先修复

手动测量要求

• 默认将 Lighthouse 和 Performance 证据视为手动采集的数据
• 优先对同一页面/路由测量 2–3 次，并使用中位数结果
• 记录设备类型、浏览器版本、网络状况，以及页面是 SPA / SSR / SSG
• 如果可能，在前后对比期间保持测量环境稳定

建议的手动采集流程

1. 打开 Chrome DevTools
2. 对目标页面或路由手动运行 Lighthouse
3. 记录关键指标：LCP / FCP / INP / CLS / TTFB
4. 打开 Performance 面板，并针对相同场景手动记录一次跟踪
5. 使用 Network 面板确认 TTFB、请求瀑布流和较大的资源
6. 保留截图或导出的跟踪记录，作为前后对比的证据

缺少手动测量时

如果用户尚无手动 Lighthouse 或 Performance 测量结果，不要断言根因。

请改为：

1. 明确说明诊断是在没有手动测量的情况下推断得出的
2. 根据可见症状、代码结构和页面类型提供基于假设的建议
3. 为每条建议标注最可能改善的指标
4. 建议更改后手动测量 Lighthouse 和 Performance

缺少手动数据时的建议

• 如果页面明显出现长时间白屏 → 优先提供 FCP 建议
• 如果主视觉图片或首屏内容出现较晚 → 优先提供 LCP 建议
• 如果点击或输入响应迟缓 → 优先提供 INP / TBT 建议
• 如果页面加载时发生跳动 → 优先提供 CLS 建议
• 如果页面在任何内容出现前整体启动缓慢 → 优先提供 TTFB 建议

这些建议是尽力而为的假设，并非经过验证的结论。

独立使用模式

此 Skill 包含可执行的判断标准、优化策略、代码示例和外部服务实现模式。无需访问任何课程文档，即可独立使用。

标准执行流程

1. 收集当前状态
   • 获取核心指标：LCP/FCP/INP/CLS/TTFB（至少包括 P75 和每日平均值）
   • 收集手动 Lighthouse + Performance + Network 测量的证据
2. 确定优先级
   • 先修复最差的指标（差），再处理需要改进的指标
   • 建议顺序：FCP → LCP → CLS → INP → TTFB（根据业务需求调整）
3. 匹配策略
   • 按照此 Skill 的诊断决策树，选择相应的优化分支
   • 对于外部服务，优先参考上文的“实用示例”部分
4. 实施并验证
   • 采用小幅增量提交；每次更改只进行一种类型的优化
   • 如果可能，重新测试 2–3 次并使用中位数值，以确认实际改进
5. 记录并防止回归
   • 记录更改前后的指标
   • 考虑在 CI 中添加关键检查（Lighthouse / 性能预算）

交付模板

## Optimization Target
- Page/Feature:
- Target Metric:
- Current Value:
- Target Value:

## Evidence
- Manual Lighthouse evidence:
- Manual Performance evidence:
- Network evidence:

## Execution Strategy
- Approach:
- External services involved:
- Risk & rollback:

## Result Verification
- Before:
- After:
- Conclusion:

使用限制

• 不要为了追求表面上的速度而牺牲核心功能的正确性
• 不要将单个用户的异常情况视为全局性能问题
• 未经验证，不要声称优化成功
• 如果缺少手动 Lighthouse / Performance 测量结果，请明确标注建议为推断，并建议后续进行验证