Frontend Performance

核心用法

frontend-performance 是一个面向前端加载性能与运行性能的诊断与优化技能。它通过 Lighthouse 报告、Performance 录屏或用户描述的现象，定位真正的性能瓶颈（而非凭感觉），并给出可落地的分级优化方案。

典型使用流程：
1. 诊断先行：先判断用户问题是「加载慢」「运行时卡顿」还是「bundle 体积大」，没有数据时拒绝给出方案，要求先跑 Lighthouse 或 Performance 录屏
2. 瓶颈定位：根据具体指标（LCP>2.5s、FCP>1.8s、CLS 高、长任务>50ms 等）按优先级排查网络瀑布图、渲染阻塞、服务端响应、DOM 操作等
3. 分级方案：按「快速见效（1天内）→ 中等改动（1-3天）→ 大改动（需评估）」给出优化建议，每项标注改动量、预期收益与风险
4. 验证闭环：每项优化后提供验证方式（Lighthouse 分数对比、Performance 长任务对比、bundle 体积对比）

核心覆盖领域：

• 加载性能：LCP、FCP、TTI、TTFB 优化
• 体验稳定性：CLS 治理、滚动与操作卡顿
• 资源与打包：代码分割、tree-shaking、图片优化、CDN 策略
• 框架专项：Next.js 动态加载、React 渲染优化、虚拟列表

显著优点

• 数据驱动：强制要求 Lighthouse/Performance 数据，杜绝「感觉慢」的盲目优化
• 分级决策：明确区分快速方案与大改动，避免一上来就推荐 SSR/换构建工具等高成本操作
• 风险透明：每项方案标注改动成本与潜在风险，便于技术决策
• 验证闭环：提供可量化的验证方式，确保优化效果可追踪
• 框架适配：针对 Next.js、React 等主流框架给出具体工具链建议

潜在缺点与局限性

• 依赖用户配合：需要用户提供 Lighthouse 报告或 Performance 录屏，若用户无法提供则无法深入诊断
• 服务端瓶颈受限：TTFB>600ms 时判定为服务端问题，前端技能在此边界停止，需额外协调后端
• 复杂场景简化：部分性能问题涉及网络环境、硬件差异等外部因素，标准化方案可能无法覆盖所有边缘情况
• 框架限制：专项建议以 React/Next.js 为主，Vue/Svelte 等其他框架用户需自行迁移概念

适合人群

• 前端开发者遇到首屏慢、页面卡顿、打包体积大等问题
• 技术负责人需要评估性能优化的投入产出比
• 希望系统提升 Core Web Vitals 指标、改善 SEO 与用户体验的团队

常规风险

• 过早优化：未确认瓶颈就实施大改动（如 CSR 改 SSR），可能投入高成本低收益
• 指标回归：优化后未持续监控，随业务迭代性能再次恶化
• 副作用引入：如过度使用 memo/useMemo 反而增加内存开销，或 preload 过多关键资源导致带宽竞争
• 数据误读：Lighthouse 实验室数据与用户真实环境（RUM）存在偏差，需结合两者判断

核心用法

本技能是一套系统化前端性能优化指导框架，专注于解决现代Web应用中的加载性能与运行性能问题。用户可通过描述具体场景（如"首屏慢""页面卡顿""打包体积大"）触发分析，或直接提供Lighthouse报告、Performance录屏等诊断数据。

技能采用分层诊断法：首先通过用户描述判定问题类型（加载性能/运行时性能/资源体积），然后要求提供量化数据，最后按优先级给出可落地的优化方案。输出采用标准化模板，包含现状分析、按ROI排序的优化方案表、落地顺序建议及验证方式。

显著优点

1. 数据驱动决策：强调"没有数据就不给优化方案"，避免凭感觉推荐无效改动，确保每条建议都有针对性。

2. 成本收益清晰：所有方案标注"改动量/预期收益/风险"三要素，并严格按"快速见效→中等改动→大改动"分层推荐，防止团队过早投入高风险的架构重构。

3. 覆盖主流技术栈：针对Next.js、React等框架提供专属优化建议（如dynamic懒加载、Image组件、useMemo优化等），实用性强。

4. 标准工具链整合：深度结合Lighthouse、Chrome Performance、bundle-analyzer等业界标准工具，方案可直接落地。

潜在缺点与局限性

1. 纯文档型限制：本技能为T-MD纯Markdown文档，无可执行代码，无法自动分析用户提供的数据（如无法直接解析Lighthouse JSON），需人工引导用户完成诊断步骤。

2. 框架偏向性：虽然提及Vue生态的部分工具（如vite-bundle-visualizer），但整体以React/Next.js为核心场景，对其他框架（如Angular、Svelte）的覆盖不足。

3. 服务端瓶颈边界：当问题根源在服务端（TTFB>600ms）时，技能仅能识别边界，无法提供深入的SSR优化或后端性能调优方案。

4. 缺乏自动化验证：优化后的效果验证需用户手动执行，无法提供CI/CD集成或自动化回归检测建议。

适合的目标群体

• 前端工程师：尤其是负责性能专项或需要向团队输出优化方案的技术Owner
• 技术团队Lead：需要评估性能优化投入产出比，制定技术决策
• 中高级React/Next.js开发者：熟悉基础概念，希望系统掌握Core Web Vitals优化方法论
• 性能优化初学者：通过结构化诊断流程，建立性能问题分析的思维框架

使用风险

1. 执行风险：文档推荐的npx命令（如bundle-analyzer）需确保来源可信，避免误执行恶意包
2. 过度优化风险：部分方案（如滥用useMemo/useCallback）可能引入代码复杂度而无实际收益，需结合实际Profiler数据判断
3. T3来源限制：维护者为个人开发者账号，建议重要生产环境使用前进行人工审查，关注后续更新与社区反馈
4. 版本兼容性：部分优化建议（如AVIF格式、CSS containment）需确认目标浏览器支持度，避免方案不可落地