性能优化需以指标为依据：fcp/lcp定位渲染瓶颈，tti/长任务识别交互卡顿，内存指标发现泄漏，performance.mark/measurement量化重构效果。
性能分析指标不是摆设，而是重构决策的依据。只有把指标和代码改动明确挂钩，优化才不会变成“我觉得变快了”的主观判断。
用 FCP 和 LCP 定位首屏瓶颈，决定加载逻辑怎么拆
FCP（首次内容绘制）超过 1.8 秒，说明关键内容渲染太慢；LCP（最大内容渲染）延迟，则大概率是首屏主模块（比如 Banner、商品列表）的资源或 JS 执行拖了后腿。这时候别急着压缩代码，先看指标指向哪一层：
- 如果 FCP 滞后但网络请求已结束，问题可能在 HTML 解析或关键 CSS/JS 阻塞 —— 考虑内联首屏 CSS、标记 async/defer、移除无用 polyfill
- 如果 LCP 元素是图片，检查是否缺失 loading="lazy" 或未设置宽高导致重排 —— 改用 fetchpriority="high" + 显式尺寸
- 如果 LCP 是动态渲染的组件（如 React 的 ProductList），说明 JS 执行或数据获取耗时过长 —— 引入骨架屏 + 数据预取，或对渲染逻辑做时间分片
靠 TTI 和长任务（Long Task）识别交互卡顿根源
TTI（可交互时间）大于 3.9 秒，通常意味着主线程被长时间占用。打开 Chrome DevTools 的 Performance 面板录制操作，重点看火焰图里持续 >50ms 的长任务：
- 若长任务中大量出现 forEach、JSON.parse、正则匹配 等函数调用 —— 属于 CPU 密集型，适合用 Web Worker 搬离主线程，或改用更高效算法（如用 Map 替代遍历数组查 ID）
- 若长任务集中在 layout、updateLayerTree、paint —— 是渲染密集型，要查 DOM 更新方式：是否在循环里反复 innerHTML +=？是否没用 DocumentFragment 批量插入？是否样式触发了强制同步布局（如读 offsetHeight 后立刻改 class）？
- 若长任务开头是第三方 SDK（如埋点、广告）的初始化脚本 —— 不要重构业务代码，而是用 requestIdleCallback 延迟加载，或配置其异步加载策略
靠内存指标（堆增长、GC 频次）发现泄漏，指导对象生命周期管理
Memory 面板中堆内存持续上涨、或频繁触发垃圾回收（GC），往往对应着隐蔽的泄漏。这时指标直接告诉你该动哪部分代码：
- 堆快照对比发现某类对象实例数只增不减（如 EventListener、闭包引用的 data 数组）—— 检查事件监听器是否漏掉 removeEventListener，或组件卸载时是否清空定时器、取消 Promise 订阅
- GC 频繁且单次耗时高 —— 很可能是循环中不断创建新对象（如每次 render 都 new Date()、生成新数组）—— 改为复用对象、用 Object.assign 浅拷贝，或提前分配好数组长度
- 存在大量 detached DOM 节点 —— 说明 DOM 引用未释放，常见于缓存了父容器却忘了清空子节点引用 —— 改用 WeakMap 存储私有状态，或显式调用 node.remove()
用 performance.mark/measurement 埋点，让每次重构都有数据反馈
别等上线后再看 Lighthouse 报告。在关键路径主动打点，把优化效果量化到毫秒级：
- 在数据请求开始前打 performance.mark('api-start')，响应解析后打 performance.mark('parse-end')，再用 performance.measure 计算耗时 —— 这样换了个 JSON 解析库，效果一目了然
- 对列表渲染加 mark('render-start') 和 mark('render-end')，对比优化前后 measure.duration —— 比如把 1000 条 appendChild 改成 DocumentFragment，能从 240ms 降到 18ms
- 把测量逻辑封装成高阶函数，比如 withPerf('filter-list', fn)，避免重复写 mark/measure —— 让性能意识融入日常编码习惯
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
