关于 performance-optimizer
performance-optimizer 是一项提供应用性能优化方法的技能，覆盖前端、后端和数据库，并强调先测量再优化。它面向排查延迟或扩展问题的开发者，涵盖性能分析、缓存和监控。
主要功能
- 01性能预算与目标指标
- 02性能分析和瓶颈定位
- 03数据库查询优化指引
- 04分层缓存策略
- 05前端与后端优化阶段
- 06监控与告警指引
适用场景
- 01排查页面加载缓慢
- 02诊断 API 延迟过高
- 03定位数据库查询瓶颈
- 04规划性能监控与告警
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/performance-optimizer确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
references/backend.mdcaching.mddatabase.mdfrontend.mdmonitoring.mdprofiling.md详细介绍
性能优化器
概述
提供一种系统化方法，用于对全栈应用进行性能优化。适用于排查页面加载缓慢、API 延迟过高、数据库瓶颈或扩展性问题。它不能替代针对具体应用的性能分析——优化前务必先测量。
快速参考
性能预算
| 指标 | 目标 | 类别 |
|---|---|---|
| 最大内容绘制（LCP） | < 2.5s | 核心 Web 指标 |
| 下一次绘制交互延迟（INP） | < 200ms | 核心 Web 指标 |
| 累积布局偏移（CLS） | < 0.1 | 核心 Web 指标 |
| 首次内容绘制（FCP） | < 1.8s | 前端 |
| 可交互时间（TTI） | < 3.8s | 前端 |
| 总阻塞时间（TBT） | < 200ms | 前端 |
| API 响应时间（P95） | < 500ms | 后端 |
| 数据库查询时间（P95） | < 100ms | 数据库 |
| 服务器响应时间（TTFB） | < 600ms | 后端 |
优化阶段
| 阶段 | 重点 | 关键操作 |
|---|---|---|
| 1. 性能分析 | 找出实际瓶颈 | Chrome DevTools、React Profiler、EXPLAIN ANALYZE |
| 2. 数据库 | 消除慢查询 | 合理建立索引、修复 N+1 问题、连接池化 |
| 3. 缓存 | 减少重复工作 | Redis、HTTP 标头、为静态资源使用 CDN |
| 4. 前端 | 缩短打包和渲染时间 | 分析打包内容、代码拆分、资源提示、延迟加载 |
| 5. 后端 | 加快 API 响应 | 优化无服务器架构、流式传输、条件请求、队列 |
| 6. 监控 | 保持性能 | APM 工具、告警阈值、仪表板 |
缓存层
| 层级 | 范围 | 持续时间 |
|---|---|---|
| 浏览器缓存 | HTTP 标头 | 静态资源：1 年（immutable）；HTML：no-cache |
| CDN | Cloudflare、CloudFront | 与浏览器缓存相同，部署时清除 |
| 应用层 | Redis、Memcached | 不固定（例如，用户数据缓存 1 小时） |
| 数据库 | 查询缓存 | 自动 |
常见错误
| 错误 | 正确做法 |
|---|---|
| 未进行性能分析就开始优化 | 先使用 Chrome DevTools、EXPLAIN ANALYZE 或 APM 工具进行测量，找出实际瓶颈 |
| 为每一列都添加索引 | 在 WHERE、ORDER BY 和 JOIN 子句中的列上策略性地创建索引；通过慢查询日志进行监控 |
| 在大型表上使用 SELECT * | 只选择所需列，以减少 I/O 和内存占用 |
| 在循环中产生 N+1 查询 | 使用预加载或 DataLoader 批处理 |
| 在 WHERE 子句中使用函数 | 存储规范化值，使用生成列来保留索引的使用 |
| 缓存没有失效策略 | 定义 TTL 和写入时失效策略；过期的缓存比没有缓存更糟 |
| 为单个实用功能加载整个库 | 使用直接导入和摇树优化 |
| 在请求处理程序中同步运行繁重计算 | 将任务转交给后台作业队列（BullMQ），并立即返回 |
委派
处理性能优化时，可委派给：
frontend-builder-- React 专属的性能模式application-security-- 速率限制和 DDoS 防护ci-cd-architecture-- 构建流水线优化
参考资料
评论
支持 Markdown