1
// FID 为什么被 INP 取代？
2
// FID 只测量"第一次交互的输入延迟"，忽略处理耗时和绘制耗时
3
// INP 测量页面整个生命周期内所有交互的响应性，取最差值（P98）
4
// INP = 输入延迟 + 处理时间 + 渲染延迟（全部计入）

1
// 1. Performance API（LCP 示例）
2
new PerformanceObserver((list) => {
3
  const entries = list.getEntries();
4
  const lastEntry = entries[entries.length - 1];
5
  console.log('LCP:', lastEntry.startTime);
6
}).observe({ type: 'largest-contentful-paint', buffered: true });
7

8
// 2. CLS
9
let clsScore = 0;
10
new PerformanceObserver((list) => {
11
  for (const entry of list.getEntries()) {
12
    if (!entry.hadRecentInput) clsScore += entry.value;
13
  }
14
}).observe({ type: 'layout-shift', buffered: true });
15

16
// 3. web-vitals 库（Google 官方，一行搞定）
17
import { onLCP, onINP, onCLS } from 'web-vitals';
18
onLCP(console.log);
19
onINP(console.log);
20
onCLS(console.log);
21

22
// 4. 工具：Lighthouse（实验室数据）、Chrome DevTools Performance 面板、
23
//    线上 RUM（真实用户监控，上报到自建平台）
24
// 实验室数据（Lab）：Lighthouse，可复现但非真实用户
25
// 真实用户数据（Field/RUM）： CrUX、自建上报，反映真实体验

1
输入 URL → DNS → TCP/TLS → HTTP 请求 → 服务器处理 → 响应 → 解析渲染
2

3
各阶段优化手段：
4
┌─────────────┬──────────────────────────────────────┐
5
│ DNS         │ dns-prefetch 预解析                   │
6
│ TCP/TLS     │ preconnect 预连接、TLS1.3、HTTP/2     │
7
│ HTTP 请求   │ CDN、缓存（强缓存/协商缓存）、         │
8
│             │ Gzip/Brotli、减少请求数（合并/雪碧图） │
9
│ 服务器      │ SSR、接口聚合（BFF）、数据库优化       │
10
│ 资源体积    │ 压缩、Tree Shaking、代码分割、         │
11
│             │ 图片 WebP/AVIF、按需加载              │
12
│ 解析渲染    │ defer/async、关键 CSS 内联、           │
13
│             │ 减少重排重绘、GPU 加速                │
14
└─────────────┴──────────────────────────────────────┘

1
<!-- 资源提示（Resource Hints）-->
2
<link rel="dns-prefetch" href="//api.example.com">
3
<link rel="preconnect" href="//cdn.example.com" crossorigin>
4
<link rel="preload" href="/fonts/main.woff2" as="font" crossorigin>
5
<link rel="prefetch" href="/next-page.js">  <!-- 空闲时预取下一页 -->

1
<script src="a.js"></script>          <!-- 同步：阻塞解析，顺序执行 -->
2
<script src="b.js" async></script>    <!-- 异步下载，下载完立即执行（打断解析，顺序不定）-->
3
<script src="c.js" defer></script>    <!-- 异步下载，HTML 解析完后按顺序执行 -->
4

5
/*
6
时间线对比：
7
普通:   解析──停─下载─执行─解析──停─下载─执行─解析
8
async:  解析────解析────解析（下载完就插队执行）
9
defer:  解析────解析────解析│DOMContentLoaded前统一执行
10

11
使用建议：
12
- 无依赖的统计脚本 → async
13
- 有依赖顺序的业务脚本 → defer
14
- 都不加 → 阻塞渲染，尽量避免
15
*/

1
// 1. 路由懒加载（收益最大，首屏只加载当前路由）
2
// Vue Router
3
const routes = [
4
  { path: '/detail', component: () => import('./Detail.vue') },
5
];
6
// React Router
7
const Detail = React.lazy(() => import('./Detail'));
8

9
// 2. 组件级懒加载（重型组件：编辑器、图表库）
10
const Editor = defineAsyncComponent(() => import('./Editor.vue'));
11

12
// 3. 第三方库拆分（Vite manualChunks）
13
build: {
14
  rollupOptions: {
15
    output: {
16
      manualChunks: {
17
        vue: ['vue', 'vue-router', 'pinia'],
18
        echarts: ['echarts'],      // 大库独立 chunk，可长期缓存
19
      },
20
    },
21
  },
22
}
23

24
// 4. 条件加载（按环境/权限）
25
if (needExport) {
26
  const { exportToExcel } = await import('./excel-utils');
27
}
28

29
// 分割原则：
30
// - 首屏必需 → 主包；非首屏 → 懒加载
31
// - 体积大、更新少的库 → 独立 chunk（利用缓存）
32
// - 过度分割反而增加请求数，HTTP/2 下控制在合理范围

1
<!-- 1. 现代格式：WebP（体积约为 JPEG 的 1/3）、AVIF -->
2
<picture>
3
  <source srcset="img.avif" type="image/avif">
4
  <source srcset="img.webp" type="image/webp">
5
  <img src="img.jpg" alt="desc">
6
</picture>
7

8
<!-- 2. 响应式图片：按屏幕加载合适尺寸 -->
9
<img srcset="img-480.jpg 480w, img-800.jpg 800w"
10
     sizes="(max-width: 600px) 480px, 800px"
11
     src="img-800.jpg" alt="desc">
12

13
<!-- 3. 原生懒加载 -->
14
<img src="img.jpg" loading="lazy" alt="desc">
15

16
<!-- 4. LCP 图片反而要 preload + fetchpriority -->
17
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
18
<img src="/hero.webp" fetchpriority="high" alt="hero">
19

20
<!-- 5. 占位防抖动（配合 CLS）：必须写宽高 -->
21
<img src="img.jpg" width="800" height="450" alt="desc">

1
// 6. 虚拟滚动场景：IntersectionObserver 手动懒加载
2
const observer = new IntersectionObserver((entries) => {
3
  entries.forEach(e => {
4
    if (e.isIntersecting) {
5
      const img = e.target;
6
      img.src = img.dataset.src;   // data-src 存真实地址
7
      observer.unobserve(img);
8
    }
9
  });
10
});
11
document.querySelectorAll('img[data-src]').forEach(img => observer.observe(img));
12

13
// 7. 构建层：vite-plugin-imagemin 压缩、雪碧图（SVG symbol）
14
// 8. CDN：URL 参数动态裁剪缩放（?x-oss-process=image/resize,w_400）

1
白屏时间构成：DNS + TCP + TTFB + HTML下载 + CSS/JS下载解析
2

3
优化手段（按投入产出比排序）：
4

5
1. 静态资源上 CDN（TTFB 大幅下降）
6
2. 开启 Gzip/Brotli（体积降 60-80%）
7
3. 强缓存 + 文件 hash（二次访问秒开）
8
4. 路由懒加载 + 分包（减小首屏 JS）
9
5. 骨架屏 / Loading（体验兜底，非真优化）
10
6. SSR / SSG（HTML 直出，FCP 最快）
11
   - SSG：构建时生成（博客、官网）
12
   - SSR：请求时渲染（个性化内容）
13
   - 流式 SSR / 岛屿架构：更快 TTFB + 局部 hydration
14
7. 预渲染（prerender）：SSG 的轻量替代
15
8. 关键 CSS 内联到 <head>，非关键 CSS 异步加载
16
9. 接口预请求：HTML 内联 script 提前发起首屏接口，
17
   与 JS 下载并行，省掉串行等待
18
10. 客户端缓存首屏数据（localStorage），
19
    先渲染缓存再静默刷新（SWR 模式）

1
HTML → DOM 树
2
              ↘
3
               Render 树 → Layout（布局）→ Paint（绘制）→ Composite（合成）
4
              ↗
5
CSS  → CSSOM
6

7
阻塞点：
8
1. CSS 阻塞渲染：CSSOM 构建完才能合成 Render 树
9
2. CSS 间接阻塞 JS：JS 执行前要等前面的 CSS 下载完
10
3. JS 阻塞解析：同步 script 会暂停 HTML 解析
11
4. Layout 抖动：JS 频繁读写几何属性触发强制同步布局

1
// 重排（Reflow/Layout）：几何变化 → 重新计算布局（贵）
2
// 重绘（Repaint）：外观变化不影响布局（较贵）
3
// 合成（Composite）：仅 transform/opacity → GPU 处理（最便宜）
4
// 关系：重排必重绘，重绘不一定重排
5

6
// 触发重排的操作：
7
// - 改变窗口大小、字体
8
// - 增删 DOM、元素位置/尺寸变化
9
// - 读取几何属性（offsetTop/clientWidth/getComputedStyle）
10
//   ← 高频坑！读取会强制刷新布局队列（强制同步布局）
11

12
// ❌ 布局抖动（Layout Thrashing）
13
for (let i = 0; i < 1000; i++) {
14
  const el = document.getElementById(`item-${i}`);
15
  el.style.width = el.offsetWidth + 10 + 'px';  // 读写交替，1000 次强制布局
16
}
17

18
// ✅ 读写分离：先批量读，再批量写
19
const widths = els.map(el => el.offsetWidth);   // 集中读
20
els.forEach((el, i) => el.style.width = widths[i] + 10 + 'px');  // 集中写
21

22
// ✅ requestAnimationFrame 分批写
23
function batchUpdate() {
24
  els.forEach(el => el.style.transform = 'translateX(10px)');
25
}
26
requestAnimationFrame(batchUpdate);
27

28
// 其他手段：
29
// - transform/opacity 代替 top/left（走合成层，不重排）
30
// - will-change: transform 提升合成层（慎用，层爆炸）
31
// - 绝对定位让动画元素脱离文档流
32
// - display: none 批量修改后一次显示
33
// - DocumentFragment 批量 DOM 操作

1
虚拟列表（Virtual List）核心思想：
2
只渲染可视区域 + 上下缓冲区的 DOM（约 20-30 个），
3
滚动时动态替换内容和位置。
4

5
┌─────────────┐ ← 外层容器（撑开总高度：10万 × 行高）
6
│  (占位)      │ ← transform: translateY(偏移)
7
│ ┌─────────┐ │
8
│ │ 可视区   │ │ ← 只渲染这一屏的条目
9
│ │ item 51 │ │
10
│ │ item 52 │ │
11
│ │ ...     │ │
12
│ └─────────┘ │
13
│  (占位)      │
14
└─────────────┘
15

16
核心计算：
17
startIndex = Math.floor(scrollTop / itemHeight)
18
endIndex = startIndex + Math.ceil(viewportHeight / itemHeight)
19
visibleData = list.slice(startIndex - buffer, endIndex + buffer)
20
offsetY = startIndex * itemHeight

1
// 简易实现（固定行高）
2
function VirtualList({ container, itemHeight, total, renderItem }) {
3
  const viewportH = container.clientHeight;
4
  const visibleCount = Math.ceil(viewportH / itemHeight);
5
  const buffer = 5;
6

7
  container.addEventListener('scroll', () => {
8
    const scrollTop = container.scrollTop;
9
    const start = Math.max(0, Math.floor(scrollTop / itemHeight) - buffer);
10
    const end = Math.min(total, start + visibleCount + buffer * 2);
11

12
    // 只更新可视数据 + 偏移
13
    renderItems(start, end);
14
    content.style.transform = `translateY(${start * itemHeight}px)`;
15
  });
16
}
17
// 现成方案：vue-virtual-scroller、react-window、react-virtuoso
18
// 不定高场景：预估高度 + 渲染后实测缓存高度（react-virtuoso 内置）

1
// 防抖（debounce）：停止触发 n 秒后才执行（结果导向）
2
// 场景：搜索联想、窗口 resize 后重算、表单校验
3
function debounce(fn, delay = 300) {
4
  let timer = null;
5
  return function (...args) {
6
    clearTimeout(timer);
7
    timer = setTimeout(() => fn.apply(this, args), delay);
8
  };
9
}
10

11
// 节流（throttle）：每 n 秒最多执行一次（频率导向）
12
// 场景：scroll 滚动加载、mousemove、射击游戏
13
function throttle(fn, interval = 200) {
14
  let last = 0;
15
  return function (...args) {
16
    const now = Date.now();
17
    if (now - last >= interval) {
18
      last = now;
19
      fn.apply(this, args);
20
    }
21
  };
22
}
23

24
// 选择口诀：
25
// 只关心最终结果 → 防抖（搜索框）
26
// 需要持续响应但要限频 → 节流（滚动条）

1
// 常见原因：
2
// 1. 意外的全局变量
3
function leak() { data = 'huge string'; }  // 忘写 let/var → 挂到 window
4

5
// 2. 未清理的定时器
6
setInterval(() => { /* 引用了组件数据 */ }, 1000);  // 组件销毁未 clearInterval
7

8
// 3. 未解绑的事件监听
9
element.addEventListener('click', handler);  // 组件卸载未 removeEventListener
10

11
// 4. 闭包引用
12
function outer() {
13
  const huge = new Array(1e6).fill('x');
14
  return function inner() { /* 只用了 huge.length，但整个 huge 被引用 */ };
15
}
16

17
// 5. 游离 DOM（detached DOM）
18
// JS 变量还引用着已从文档移除的节点
19

20
// 6. console.log 引用对象（开发环境）
21

22
// 7. 第三方库实例未销毁（echarts 实例、地图实例）

1
排查流程（Chrome DevTools）：
2

3
1. Performance 面板：录制操作，看 JS Heap 是否只增不减（锯齿应该回落）
4
2. Memory 面板 → Heap Snapshot：
5
   - 操作前拍一次 → 操作后拍一次 → Comparison 视图对比
6
   - 按 Retained Size 排序，找 Detached / 可疑构造器
7
3. Allocation instrumentation on timeline：实时看内存分配，
8
   蓝色柱（存活）持续增长即泄漏点
9
4. 常见修复：
10
   - Vue：onUnmounted 里清理定时器/监听/实例
11
   - React：useEffect 返回清理函数
12
   - WeakMap/WeakSet 存"附属数据"，键被回收时自动释放

1
分析工具先行：
2
- rollup-plugin-visualizer / webpack-bundle-analyzer
3
- 打包产物看：du -sh dist/_astro/* | sort -h
4

5
优化清单：
6
1. Tree Shaking：ESM 导入 + sideEffects: false
7
   （lodash → lodash-es，import { debounce } 而非 import _）
8
2. 按需引入组件库：Element Plus / Ant Design 自动按需插件
9
3. 大依赖替换：moment(300KB+) → dayjs(7KB)
10
   axios → fetch 封装；完整 echarts → 按需注册组件
11
4. 图片/字体：WebP、字体子集化（fontmin，中文字体必做）
12
5. Gzip/Brotli：构建时预压缩（vite-plugin-compression）
13
   或交给 Nginx 动态压缩
14
6. 代码分割 + 懒加载（见 Q5）
15
7. 检查重复依赖：npm ls lodash，多版本共存要 dedupe
16
8. 移除 sourcemap 生产配置或改为 hidden-source-map
17

18
量化表达（面试加分）：
19
"主包从 2.1MB 降到 480KB，首屏 JS 传输体积下降 77%"

1
// 自建监控的采集内容：
2
// 1. 指标采集：web-vitals 库 → LCP/INP/CLS/TTFB/FCP
3
// 2. 资源加载：PerformanceObserver 监听 resource，
4
//    采集慢资源（duration > 阈值）
5
// 3. 接口耗时：拦截 fetch/XHR 记录 duration 和状态码
6
// 4. 长任务：PerformanceObserver 监听 longtask（>50ms）
7
// 5. 错误：window.onerror + unhandledrejection
8

9
// 上报策略（关键，防止监控本身拖慢页面）：
10
// - navigator.sendBeacon：页面卸载也能发，不阻塞
11
// - 批量合并 + 节流上报（每 10s 或 20 条）
12
// - 采样率控制（大流量站点 10%）
13
// - requestIdleCallback 空闲时上报
14

15
window.addEventListener('beforeunload', () => {
16
  navigator.sendBeacon('/api/monitor', JSON.stringify(bufferedMetrics));
17
});
18

19
// 现成方案：Sentry（错误+性能）、阿里 ARMS、
20
// 腾讯 RUM、字节 volcengine APMPlus、开源 web-see

1
模板：场景 → 问题定位 → 手段 → 量化结果 → 沉淀
2

3
示例回答（管理后台项目）：
4

5
【场景】中后台管理系统，用户反馈打开报表页要 6-7 秒白屏。
6

7
【定位】Lighthouse + bundle analyzer 分析：
8
1. 主包 3.2MB（echarts 全量引入 + moment）
9
2. 报表页串行等 4 个接口
10
3. 表格一次渲染 5000 行 DOM
11

12
【手段】
13
1. echarts 按需注册组件，moment → dayjs（体积 -1.4MB）
14
2. 路由级代码分割，报表页独立 chunk
15
3. 4 个接口合并为 BFF 聚合接口 + Promise.all 并行
16
4. 表格虚拟滚动（只渲染可视区 30 行）
17
5. 开启 Gzip + CDN + 接口数据 SWR 缓存
18

19
【结果】
20
- 首屏 LCP：6.8s → 1.9s（-72%）
21
- 主包体积：3.2MB → 780KB
22
- 报表页交互卡顿（INP）：600ms → 80ms
23

24
【沉淀】
25
- 把"分包配置 + 按需引入"沉淀为团队脚手架默认配置
26
- CI 加 bundlesize 检查，主包超 500KB 构建失败

1
CSR 首屏流程（两次请求才能看到内容）：
2
请求 HTML（空壳）→ 下载 JS → 执行 JS → 请求接口 → 渲染内容
3

4
SSR 首屏流程：
5
请求 HTML（服务端已渲染好内容）→ 直接显示 → hydration 绑定事件
6

7
优势：
8
1. FCP/LCP 快：HTML 到达即可见
9
2. SEO 友好：爬虫直接拿到完整内容
10
3. 弱网/低端设备体验好
11

12
代价：
13
1. 服务器压力大（每个请求都要渲染）
14
2. TTFB 可能变长（服务端渲染耗时）
15
3. hydration 成本：JS 加载后还有一次"注水"
16
4. 开发复杂度：数据获取、环境判断（window 不存在）
17

18
折中方案：
19
- SSG：构建时生成静态 HTML（博客、文档站）
20
- 增量静态再生（ISR）：静态 + 定时更新
21
- 流式 SSR：分块吐 HTML，边渲染边下发
22
- 岛屿架构（Astro）：静态为主，局部交互组件才加载 JS