用途
本技能是一套基于 Web Vitals 核心指标的前端性能诊断与优化系统，用于定位页面加载慢、交互卡顿、布局抖动等性能问题，并给出对应的优化策略。核心原则是「以用户为中心——优化是做得更少，而不是更多」。
主要能力
指标阈值速查
提供 LCP、FCP、INP、CLS、TTFB、FID、TBT 等指标的 Good / Needs Improvement / Poor 阈值与单位、关注点。测量建议：不要只依赖单一 P75，应结合 P60/P75/P90/P99 分位数与每日平均/最大/最小趋势线；桌面端目标 P98+，移动端核心页面目标 P95–P99。
诊断决策树
按「页面加载慢」逐层判断：TTFB > 800ms 归为网络/服务端问题；FCP > 1.8s 归为资源阻塞/大文件；LCP > 2.5s 时若 TTFB 与 FCP 正常则归为视口资源加载慢，否则先修上游指标；INP > 200ms 归为主线程长任务阻塞；CLS > 0.1 归为布局偏移。Lighthouse 性能分 > 80 问题较少，60–80 需重点分析（优先级 FCP → LCP → CLS），< 60 需全面审计。
各指标优化策略
- INP（交互响应）：将长任务拆分为短任务，可用 setTimeout、Promise.resolve().then、requestAnimationFrame、requestIdleCallback、scheduler.postTask（优先级 user-blocking > user-visible > background）；布局与渲染方面减少 calc()、避免循环中交替读写 DOM（布局抖动）、长列表虚拟化、Swiper 仅预加载当前项 ±1；CSS 方面避免 table 布局、使用 transform/opacity 触发合成层、使用语义化标签。
- TTFB（网络与服务端）：诊断公式为 TTFB ≈ HTTP 请求时间 + 服务端处理时间 + HTTP 响应时间；通用策略含 CDN 加速（部署后主动刷新 CDN 缓存）、HTTP/2、Gzip、代码分割与动态导入；UX 策略含 Web Worker、DNS 预取、preconnect；SSR 服务端可用内网 API、Redis 缓存、减少重定向、构建期预生成静态页；资源缓存可用 App 热更新本地预下载、PWA Service Worker 离线缓存。
- FCP（白屏与首屏内容）：诊断公式为 FCP ≈ TTFB + 资源下载时间 + DOM 解析时间 + 渲染时间；策略含移除渲染阻塞资源（defer/async）、减小 JS/CSS 体积、控制网络负载、缓存策略（Cache-Control: max-age=31536000）、缩短关键请求深度、字体优化、白屏方案（PWA / App 热更新）。
- 字体优化：限制字体数量、优先 WOFF2、unicode-range 子集化、local() 本地字体、font-display 策略（swap/optional/block/fallback/auto）、CSS Font Loading API、弱网回退（navigator.connection）。
- LCP（最大内容绘制）：LCP 可标记的元素类型包括 img 与 SVG 内 image、video poster 或首帧、CSS url() 背景图、含文本节点的块级元素；关键结论是 LCP 时间恒 ≥ FCP 时间，SPA 更看重 FCP，SSR/MPA 更看重 LCP；策略含 preload LCP 图片、框架图片组件（如 next/image 的 priority）、大图切片、WebP/AVIF 格式、云图片参数、富文本图片预加载、避免重复预加载。采样建议：PV < 1M 全量采集 LCP，超过则比例采样或阈值上报。
- CLS（布局偏移）：诊断公式为布局偏移分数 = 影响比例 × 距离比例，CLS = 所有偏移分数之和；元素偏移越远、影响视口面积越大，CLS 越高。策略含为图片设置宽高、动态内容预留占位、CSS 动画用 transform 替代 top/left/width/height、字体使用 font-display: optional + preload 或 swap。
通用优化技巧
网络感知（navigator.connection.effectiveType 降级）、小图标用 SVG、响应式降级、缓存优先（LocalStorage 先渲染再异步刷新）、请求合并、按场景选择 SSR/CSR/SSG 渲染模式。
外部服务实践示例
提供三段代码示例：阿里云 OSS 按网络自适应图片质量（根据 effectiveType 调整 resize/quality/format 参数）；CDN 部署后主动刷新（curl 调用 purge 接口，密钥不得暴露在前端）；SSR + Redis 缓存降低 TTFB（ioredis 读取缓存，未命中则请求 API 并缓存 60 秒）。
工具使用建议
Lighthouse 三种模式：Navigation 模式用于单页全流程分析，Timespan 模式用于 SPA 路由切换与表单交互的 INP/CLS 分析，Snapshot 模式用于活动页、动画与变化状态页面。Performance 面板用于长任务火焰图、资源加载顺序时间线、逐帧布局偏移分析；Network 面板用于请求数/总大小/TTFB/排队时间判断是否需要 CDN/预取/HTTP2。关键分析路径：FCP 出现晚查 JS/CSS 加载时间；FP 与 FCP 间隔大查阻塞渲染的长任务；FCP 与 LCP 差距大查视口资源过多或过大；CLS 多次尖峰且总和 > 0.25 需优先修复。
使用方式
标准执行流程：1）收集现状——获取 LCP/FCP/INP/CLS/TTFB 核心指标（至少 P75 与日均值），收集手动 Lighthouse + Performance + Network 证据；2）确定优先级——先修最差（Poor）指标，再修 Needs Improvement，建议顺序 FCP → LCP → CLS → INP → TTFB（按业务调整）；3）匹配策略——按诊断决策树选择优化分支，外部服务优先参考实践示例；4）实施与验证——小步增量提交，每次只做一类优化，尽量复测 2–3 次取中位数确认改善；5）记录与防回归——记录改动前后指标，考虑将关键检查加入 CI（Lighthouse / 性能预算）。
手动测量要求：默认将 Lighthouse 与 Performance 证据视为手动采集数据；优先对同一页面/路由测量 2–3 次取中位数；记录设备类型、浏览器版本、网络状况及页面是 SPA/SSR/SSG；前后对比尽量保持测量环境稳定。手动采集流程：打开 Chrome DevTools → 手动运行 Lighthouse → 记录 LCP/FCP/INP/CLS/TTFB → 打开 Performance 面板录制同一场景 trace → 用 Network 面板确认 TTFB、请求瀑布与重资源 → 保留截图或导出 trace 作为前后对比证据。
若缺少手动测量：不得断言根因，应明确说明诊断是在无手动测量下推断的，按可见症状、代码结构与页面类型给出假设性建议，并标注每条建议最可能改善的指标，建议改动后手动测量 Lighthouse 与 Performance。无数据时的回退建议：明显长时间白屏优先 FCP；首屏图片或内容出现晚优先 LCP；点击或输入延迟优先 INP/TBT；加载中页面跳动优先 CLS；整页在内容出现前就启动慢优先 TTFB。这些建议是尽力而为的假设，而非已验证结论。
交付模板包含优化目标（页面/功能、目标指标、当前值、目标值）、证据（手动 Lighthouse/Performance/Network 证据）、执行策略（方案、涉及外部服务、风险与回滚）、结果验证（改动前、改动后、结论）。
适用场景
适用于前端页面性能诊断与优化，包括首屏白屏、视口资源加载慢、交互卡顿、布局抖动、服务端响应慢等问题；可用于 SPA、SSR、MPA、SSG 等不同渲染模式；可独立使用，无需访问任何课程文档。
限制
使用约束：不要为感知速度牺牲核心功能正确性；不要把单个用户的异常当作全局性能问题；未经验证不得声称优化成功；若缺少手动 Lighthouse / Performance 测量，须明确标注建议为推断并建议后续验证。