性能优化

┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐
│  FCP    │ → │  LCP    │ → │  CLS    │ → │  INP    │
│ 首次内容│   │ 最大内容│   │ 布局偏移│   │ 交互响应│
└─────────┘   └─────────┘   └─────────┘   └─────────┘
  加载感知      主体可见      视觉稳定      交互跟手

问题：性能指标太多，开发者不知道该优化什么

十几个指标（FCP、TTI、TBT、FID、LCP、CLS、SI...）
→ 不知道哪个重要
→ 优化了一个反而恶化了另一个

解决：收敛为三个核心指标，另以 FCP 作为辅助观测

FCP（辅助）：用户何时看到第一个内容？    目标 ≤ 1.8s
LCP（加载）：页面主要内容多久能看到？    目标 ≤ 2.5s
CLS（稳定）：加载过程中元素会不会跳？    目标 ≤ 0.1
INP（交互）：用户操作后多久有反馈？      目标 ≤ 200ms

// 使用 PerformanceObserver 采集 FCP
const observer = new PerformanceObserver((list) => {
  const entries = list.getEntriesByName("first-contentful-paint");
  if (entries.length > 0) {
    const fcp = entries[0];
    console.log("FCP:", fcp.startTime.toFixed(2), "ms");
    // 上报到监控平台
    reportMetric("FCP", fcp.startTime);
  }
});
observer.observe({ type: "paint", buffered: true });

// 优化 1：内联关键 CSS（控制在 14KB 以内，一次 TCP 往返就能送达）
<head>
  <style>
    /* 首屏关键 CSS 直接内联 */
    .header {
      background: #fff;
      padding: 16px;
    }
    .hero {
      height: 100vh;
      display: flex;
      align-items: center;
    }
  </style>
  <!-- 非关键 CSS 异步加载 -->
  <link
    rel="preload"
    href="/non-critical.css"
    as="style"
    onload="this.rel='stylesheet'"
  />
</head>

// 优化 2：字体优化 @font-face { font-family: 'MyFont'; src:
url('/fonts/myfont.woff2') format('woff2'); font-display: swap; /*
字体加载期间用后备字体，加载完成后替换 */ } // 优化 3：预加载关键资源
<link rel="preload" href="/critical.js" as="script" />
<link rel="preload" href="/hero.webp" as="image" />

┌───────────────────────────────────────┐
│       1. 优化资源发现时机              │  ← preload、SSR 直出
└─────────────────┬─────────────────────┘
                  ▼
┌───────────────────────────────────────┐
│       2. 降低 TTFB                     │  ← CDN、减少重定向、HTTP/2
└─────────────────┬─────────────────────┘
                  ▼
┌───────────────────────────────────────┐
│       3. 减少关键资源字节数            │  ← WebP/AVIF、Brotli 压缩
└─────────────────┬─────────────────────┘
                  ▼
┌───────────────────────────────────────┐
│       4. 优化渲染路径                  │  ← 内联关键 CSS、defer JS
└───────────────────────────────────────┘

// 使用 PerformanceObserver 采集 LCP
const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];
  console.log("LCP:", lastEntry.startTime.toFixed(2), "ms");
  console.log("LCP 元素:", lastEntry.element);
  console.log("LCP URL:", lastEntry.url);
  // 上报到监控平台
  reportMetric("LCP", lastEntry.startTime);
});
observer.observe({ type: "largest-contentful-paint", buffered: true });

// 优化 1：预加载 LCP 资源 + fetchpriority
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />

// 优化 2：图片格式降级
<picture>
  <source srcset="/hero.avif" type="image/avif" />
  <source srcset="/hero.webp" type="image/webp" />
  <img src="/hero.jpg" alt="首屏大图" width="1200" height="800" />
</picture>

// 优化 3：关键 CSS 内联（控制在 14KB 以内）
<head>
  <style>
    /* 首屏关键 CSS */
  </style>
  <link
    rel="preload"
    href="/non-critical.css"
    as="style"
    onload="this.rel='stylesheet'"
  />
</head>

布局偏移分数 = 影响分数（Impact Fraction）× 距离分数（Distance Fraction）

影响分数：不稳定元素影响的可视区域比例
距离分数：元素移动的最大距离占视口的比例

例：一个 50% 宽度的元素向下移动了 25%
CLS = 0.5 × 0.25 = 0.125（超过阈值！）

// 使用 PerformanceObserver 采集 CLS（Session Window 方案）
let clsValue = 0;
let sessionEntries = [];

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // 只统计非用户交互引起的布局偏移
    if (!entry.hadRecentInput) {
      // Session Window：间隔小于 1s 的连续偏移算同一窗口，窗口最长 5s
      const firstEntry = sessionEntries[0];
      const lastEntry = sessionEntries[sessionEntries.length - 1];
      const isSameSession =
        lastEntry !== undefined &&
        entry.startTime - lastEntry.startTime < 1000 &&
        entry.startTime - firstEntry.startTime < 5000;
      if (isSameSession) {
        sessionEntries.push(entry);
      } else {
        sessionEntries = [entry];
      }
      // 取当前 session 的最大 CLS 值
      const sessionCLS = sessionEntries.reduce((sum, e) => sum + e.value, 0);
      clsValue = Math.max(clsValue, sessionCLS);
    }
  }
  console.log("CLS:", clsValue.toFixed(4));
  reportMetric("CLS", clsValue);
});
observer.observe({ type: "layout-shift", buffered: true });

// 优化 1：图片设置宽高比（最常见也最有效的 CLS 优化） // ❌
错误：没有宽高比，图片加载前高度为 0
<img src="/photo.jpg" alt="照片" />

// ✅ 正确：设置 width/height，浏览器自动计算宽高比
<img src="/photo.jpg" alt="照片" width="800" height="600" />

// ✅ 或者用 CSS aspect-ratio
<img src="/photo.jpg" alt="照片" style="aspect-ratio: 4/3; width: 100%;" />

// 优化 2：骨架屏预留空间
<div class="skeleton" style="min-height: 200px;">
  <!-- 内容加载前显示骨架屏 -->
</div>

// 优化 3：字体加载策略 @font-face { font-family: 'MyFont'; src:
url('/fonts/myfont.woff2') format('woff2'); font-display: optional; /*
加载太慢就不用，避免文字重排 */ } // 优化 4：动态内容用 fixed 定位 // ❌ Cookie
Banner 推挤页面内容
<div class="cookie-banner">...</div>

// ✅ Cookie Banner 固定在底部，不影响布局
<div class="cookie-banner" style="position: fixed; bottom: 0;">...</div>

FID 的问题：只测量第一次交互的输入延迟

用户首次点击 → 测量延迟（只看"从输入到回调开始"）
                不看回调执行时间
                不看后续交互

INP 的改进：测量所有交互的完整耗时

用户每次交互 → 测量完整耗时（从输入到下一帧视觉更新）
              取 P95（去除 5% 异常值）
              更准确反映整体交互体验

// 使用 PerformanceObserver 采集 INP
const interactions = [];

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.interactionId) {
      interactions.push({
        interactionId: entry.interactionId,
        duration: entry.duration,
        name: entry.name,
        startTime: entry.startTime,
      });
    }
  }

  // 取 P95（去除 5% 的最大值）
  if (interactions.length > 0) {
    interactions.sort((a, b) => b.duration - a.duration);
    const p95Index = Math.floor(interactions.length * 0.05);
    const inp = interactions[p95Index].duration;
    console.log("INP:", inp.toFixed(2), "ms");
    console.log(
      "最慢交互:",
      interactions[0].name,
      interactions[0].duration.toFixed(2),
      "ms",
    );
    reportMetric("INP", inp);
  }
});
observer.observe({ type: "event", buffered: true });

// 优化 1：scheduler.yield() 主动让出主线程
async function handleClick() {
  // 第一部分计算
  heavyComputation1();
  // 主动让出主线程，让浏览器有机会渲染和响应用户输入
  await scheduler.yield();
  // 第二部分计算
  heavyComputation2();
  // 再次让出
  await scheduler.yield();
  // 第三部分计算
  heavyComputation3();
}

// 优化 2：拆分长任务
function processLargeList(items) {
  let index = 0;
  function processChunk() {
    const end = Math.min(index + 100, items.length);
    for (; index < end; index++) {
      processItem(items[index]);
    }
    if (index < items.length) {
      // 用 setTimeout 让出主线程
      setTimeout(processChunk, 0);
    }
  }
  processChunk();
}

// 优化 3：Web Worker 处理计算密集型任务
// main.js
const worker = new Worker("/worker.js");
worker.postMessage({ data: largeArray });
worker.onmessage = (e) => {
  updateUI(e.data); // 主线程只做 UI 更新
};

// worker.js
self.onmessage = (e) => {
  const result = heavyComputation(e.data);
  self.postMessage(result);
};

┌─────────────────────────────────────────────────┐
│              性能优化的完整框架                    │
├─────────────┬─────────────┬─────────────────────┤
│  构建优化   │  网络优化   │     渲染优化          │
│             │             │  (Core Web Vitals)   │
│ Tree Shaking│ HTTP/2      │  FCP / LCP / CLS    │
│ Code Split  │ CDN         │  INP                 │
│ 压缩混淆    │ gzip/brotli │                      │
├─────────────┼─────────────┼─────────────────────┤
│  缓存策略   │  框架优化   │     监控度量          │
│             │             │                      │
│ 强缓存      │ SSR/SSG/ISR │  Lighthouse          │
│ 协商缓存    │ 懒加载      │  web-vitals          │
│ Service Wkr │ 虚拟列表    │  Performance API     │
└─────────────┴─────────────┴─────────────────────┘

用户请求流程（无 CDN）：

浏览器 → DNS 解析 → 源站（可能在美国）→ 返回资源
                      ↑
                  延迟 200-500ms（跨洋网络）

用户请求流程（有 CDN）：

浏览器 → DNS 智能解析 → 最近的边缘节点（北京）→ 命中缓存直接返回
                                              ↓ 未命中
                                          回源到源站 → 缓存到边缘节点

# Nginx CDN 缓存配置示例

# 带 hash 的静态资源：强缓存 1 年（文件名变了就是新资源）
location ~* \.(js|css|woff2)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

# 图片资源：缓存 30 天，支持 WebP/AVIF 协商
location ~* \.(jpg|png|webp|avif)$ {
    add_header Cache-Control "public, max-age=2592000";
    add_header Vary "Accept";
}

# HTML 文件：不缓存或短缓存 + 协商缓存（保证用户总是拿到最新版本）
location ~* \.html$ {
    add_header Cache-Control "no-cache";
    add_header ETag "";
}

<!-- 前端资源引用：用版本号或 hash 控制缓存更新 -->
<!-- Webpack/Vite 构建自动加 hash，文件内容变了 hash 就变 -->
<link rel="stylesheet" href="/assets/main.a1b2c3d4.css" />
<script src="/assets/vendor.e5f6g7h8.js"></script>

<!-- CDN 域名收敛：静态资源用独立域名，避免 Cookie 污染 -->
<!-- ❌ Cookie 会随请求发送到所有同域资源 -->
<img src="https://www.example.com/photo.jpg" />

<!-- ✅ 静态资源用独立域名，无 Cookie 开销 -->
<img src="https://cdn.example.com/photo.jpg" />

冷启动问题：

用户首次请求 → 缓存为空 → 回源/查询数据库 → 响应慢（500ms+）
                                            ↓
                                     缓存写入（后续请求才快）

接口预热方案：

定时任务/用户预测 → 提前请求接口 → 缓存预热完成
                                    ↓
用户首次请求 → 命中缓存 → 响应快（50ms 内）

// 方案 1：Service Worker 预请求（利用浏览器空闲时间预热缓存）
// sw.js
const PRE_WARM_URLS = [
  "/api/user/info",
  "/api/home/recommend",
  "/api/home/banners",
];

self.addEventListener("install", (event) => {
  // Service Worker 安装时预热关键接口
  event.waitUntil(
    caches.open("api-cache").then((cache) => {
      return Promise.all(
        PRE_WARM_URLS.map((url) =>
          fetch(url)
            .then((response) => cache.put(url, response))
            .catch(() => {
              /* 预热失败不影响安装 */
            }),
        ),
      );
    }),
  );
});

// 方案 2：页面空闲时预请求（利用 requestIdleCallback）
function preWarmAPIs() {
  const criticalAPIs = ["/api/user/info", "/api/notifications/unread"];

  if ("requestIdleCallback" in window) {
    requestIdleCallback(() => {
      criticalAPIs.forEach((url) => {
        fetch(url, { priority: "low" }).then((res) => {
          // 将响应存入缓存或状态管理
          res.json().then((data) => apiCache.set(url, data));
        });
      });
    });
  }
}

// 方案 3：部署后自动预热脚本（Node.js）
// pre-warm.js
const https = require("https");

const ENDPOINTS = [
  "https://api.example.com/home/recommend",
  "https://api.example.com/home/banners",
  "https://api.example.com/config/app",
];

async function preWarm() {
  console.log("Starting API pre-warming...");
  for (const url of ENDPOINTS) {
    const start = Date.now();
    try {
      await new Promise((resolve, reject) => {
        https
          .get(url, (res) => {
            res.on("data", () => {});
            res.on("end", resolve);
          })
          .on("error", reject);
      });
      console.log(`  ${url} - ${Date.now() - start}ms`);
    } catch (err) {
      console.error(`  ${url} - FAILED: ${err.message}`);
    }
  }
  console.log("Pre-warming complete.");
}

preWarm();

HTTP 协议演进：

HTTP/1.1 (1997)          HTTP/2 (2015)           HTTP/3 (2022)
┌──────────────┐    ┌──────────────────┐    ┌──────────────────┐
│ 一个请求一个  │    │  一个 TCP 连接    │    │  基于 QUIC/UDP   │
│ TCP 连接      │    │  多路复用多个流   │    │  独立流无队头阻塞│
│ 6 个并发限制  │    │  二进制帧         │    │  0-RTT 连接建立  │
│ 队头阻塞严重  │    │  TCP 队头阻塞     │    │  内置加密        │
└──────────────┘    └──────────────────┘    └──────────────────┘

TCP 队头阻塞问题：

HTTP/2 流 A: [帧1] [帧2] [帧3]    ← 流 A 的帧2 丢失
HTTP/2 流 B: [帧1] [帧2] [帧3]    ← 流 B 的帧2、3 也被阻塞！

QUIC 无队头阻塞：

QUIC 流 A: [帧1] [帧2] [帧3]    ← 流 A 的帧2 丢失，只等帧2 重传
QUIC 流 B: [帧1] [帧2] [帧3]    ← 流 B 正常交付，不受影响！

// LCP 的核心逻辑：
// 1. 监听所有资源加载和 DOM 变化
// 2. 维护一个"候选元素"列表
// 3. 每次有新元素进入视口且尺寸大于当前最大元素时，更新候选
// 4. 在用户交互（点击、按键）后停止观测

// 候选元素类型：
// - <img> 标签
// - <svg> 中的 <image>
// - <video> 的封面图
// - background-image 加载的元素
// - 包含文本节点的块级元素

void LargestContentfulPaint::OnPaintFinished() {
  // 检查是否有新的最大内容元素
  if (candidate.size > current_largest.size) {
    current_largest = candidate;
    // 记录 LCP 时间点
  }
}

// INP（Interaction to Next Paint）的测量：
// 记录每个用户交互的完整耗时
// 从事件触发 → 事件处理 → DOM 更新 → 浏览器绘制
// 取最差交互的延迟（去除异常值后取 P95）

// EventTiming 模块在每个交互事件开始时记录时间戳
// 在下一帧渲染完成后计算耗时
void EventTiming::OnNextPaintAfterInteraction() {
  duration = paint_time - interaction_start_time;
  // 记录到 INP 观测器
}