性能分析原则。测量、分析与优化技术。
npx skills add https://github.com/MisonL/Ling --skill performance-profilingانسخ والصق هذا الأمر في Claude Code لتثبيت المهارة
务实的编码标准—— 简洁、直接、不做过度设计、不写无用注释（Pragmatic coding standards）
API design principles and decision-making（API 设计原则与决策逻辑）。REST vs GraphQL vs tRPC selection（选择）、response formats（响应格式）、versioning（版本控制）、pagination（分页）。
App Builder（应用构建编排器）主编排器。根据自然语言请求创建全栈应用，确定项目类型、选择技术栈并协调智能体。
Project scaffolding templates（项目脚手架模板）。用于从零创建新项目。包含 12 个技术栈模板。
Architectural decision-making framework（架构决策框架）。Requirements analysis（需求分析）、trade-off evaluation（权衡评估）、ADR documentation（架构决策记录）。Use when making architecture decisions or analyzing system design（用于架构决策与系统设计分析）。
AI（人工智能）运行模式（BRAINSTORM、IMPLEMENT、DEBUG、REVIEW、TEACH、SHIP、ORCHESTRATE）。用于根据任务类型自动调整 AI 行为逻辑。
| name | performance-profiling |
| description | 性能分析原则。测量、分析与优化技术。 |
| allowed-tools | Read, Glob, Grep, Bash |
测量、分析、优化 —— 必须严格遵循此顺序。
执行以下脚本进行自动化性能分析：
| 脚本 | 用途 | 执行命令 |
|---|---|---|
scripts/lighthouse_audit.py | Lighthouse（性能审计工具）审计 | python scripts/lighthouse_audit.py https://example.com |
核心 Web 指标（Core Web Vitals）用于衡量加载与交互质量。
| 指标 | 优（Good） | 劣（Poor） | 衡量维度 |
|---|---|---|---|
| LCP | < 2.5s | > 4.0s | 加载体验 |
| INP | < 200ms | > 500ms | 交互响应 |
| CLS | < 0.1 | > 0.25 | 视觉稳定性 |
| 阶段 | 工具选择 |
|---|---|
| 开发环境（Development） | 本地 Lighthouse |
| CI/CD 流程 | Lighthouse CI（持续集成） |
| 生产环境（Production） | RUM（真实用户监控，Real User Monitoring） |
1. 建立基准（Baseline）-> 测量当前状态
2. 识别瓶颈（Identify）-> 找出性能卡点
3. 实施修复（Fix） -> 进行针对性改动
4. 验证改进（Validate）-> 确认性能提升
| 待解决问题 | 推荐工具 |
|---|---|
| 页面加载速度 | Lighthouse |
| 打包体积（Bundle size） | Bundle analyzer（包分析器） |
| 运行时性能 | DevTools（开发者工具）Performance（性能）面板 |
| 内存占用 | DevTools（开发者工具）Memory（内存）面板 |
| 网络请求 | DevTools（开发者工具）Network（网络）面板 |
| 潜在问题 | 识别指标 |
|---|---|
| 巨大的外部依赖 | 位于打包产物顶部 |
| 冗余/重复代码 | 存在于多个 Chunk（代码块）中 |
| 未使用的代码 | 低覆盖率（Coverage） |
| 缺失分包（Splitting） | 产物呈现为一个巨大的单体文件 |
| 发现的问题 | 对应动作 |
|---|---|
| 库文件过大 | 按需导入（Import specific modules） |
| 依赖项重复 | 去重（Dedupe）、更新版本 |
| 主包代码包含路由逻辑 | 实施代码分割（Code split） |
| 存在未引用的导出 | 启用 Tree shake（摇树优化） |
| 模式 | 含义 |
|---|---|
| 长任务（Long tasks > 50ms） | 会导致 UI 阻塞 |
| 密集的小任务 | 可能存在批处理（Batching）的机会 |
| 布局/绘制（Layout/paint） | 渲染层的瓶颈 |
| 脚本执行（Script） | JavaScript（脚本语言）执行开销过高 |
| 模式 | 含义 |
|---|---|
| 堆内存持续增长（Growing heap） | 可能存在内存泄漏 |
| 被持有的对象过多（Retained） | 检查引用关系 |
| Detached DOM（脱离文档树的 DOM，Document Object Model） | 未被正确清理 |
| 症状表现 | 可能的原因 |
|---|---|
| 首次加载缓慢 | JS 体积过大、渲染阻塞（Render blocking） |
| 交互卡顿 | 事件处理器（Event handlers）逻辑过重 |
| 滚动时的掉帧（Jank） | 布局抖动（Layout thrashing） |
| 内存持续上升 | 内存泄漏、未释放的引用 |
| 优先级 | 动作 | 预期影响 |
|---|---|---|
| 1 | 开启资源压缩（Gzip/Brotli，压缩算法） | 高 |
| 2 | 图片懒加载（Lazy load） | 高 |
| 3 | 路由层级的代码分割 | 高 |
| 4 | 配置静态资源缓存 | 中 |
| 5 | 图片压缩与格式优化 | 中 |
| [FAIL] 禁止（Don't） | [OK] 推荐（Do） |
|---|---|
| 凭空猜测性能问题 | 优先进行性能分析（Profile first，先分析） |
| 进行微比例优化（Micro-optimize） | 优先修复最大的性能卡点 |
| 过早优化 | 在真正需要的时候再优化 |
| 忽视真实用户的体验 | 参考 RUM 数据 |
谨记： 最快的代码是那些根本不需要运行的代码。在着手优化之前，先考虑是否可以移除。