perf

Name: perf
Author: lightpointventures

36stars6forks

How to install perf?

lightpointventures/claude-code-starter/perf

$npx -y skills add lightpointventures/claude-code-starter --skill perf

Installs into the current project.

Summary

当用户觉得页面慢、接口响应慢、打包慢、想优化性能时使用 — 分析瓶颈并给出具体改进方案

Files · 1

View on GitHub

SKILL.md

1	# 性能优化
2
3	帮用户找到性能瓶颈并给出具体的改进方案。核心原则：先测量，再优化，再验证。
4
5	## 步骤
6
7	### 1. 确定优化目标
8
9	> 你想优化什么？
10	> - 网页加载速度（首屏渲染慢、页面太大）
11	> - 后端响应时间（API 慢、数据库查询慢）
12	> - 构建速度（打包太慢）
13	> - 内存或 CPU 占用
14
15	### 2. 测量当前基线（必做，优化前必须有数字）
16
17	在做任何改动之前，用合适的工具记录当前性能数据作为基线：
18
19	前端性能测量：
20	- Chrome DevTools Performance 面板 — 录制页面加载，查看瀑布图和主线程阻塞
21	- Lighthouse CLI (`npx lighthouse URL --output=json`) — 获取 FCP、LCP、TBT、CLS 评分
22	- WebPageTest (webpagetest.org) — 真实网络条件下的加载瀑布图
23
24	Python 后端：
25	- `cProfile` — 内置分析器，快速定位耗时函数：`python -m cProfile -s cumtime app.py`
26	- `py-spy` — 采样式分析器，可附加到运行中的进程，无需改代码：`py-spy top --pid PID`
27	- `line_profiler` — 逐行分析特定函数耗时，适合定位热点代码
28
29	Node.js 后端：
30	- `--inspect` 标志 + Chrome DevTools — `node --inspect app.js`，然后在 Chrome 打开 `chrome://inspect`
31	- `clinic.js` — 自动诊断工具：`npx clinic doctor -- node app.js`
32
33	数据库：
34	- `EXPLAIN ANALYZE` — 在慢查询前加上，查看执行计划和实际耗时。重点关注全表扫描（Seq Scan）和嵌套循环
35
36	> 记录基线数据：具体的数字（如"首页 LCP 3.2s"、"API 响应 P95 800ms"、"查询耗时 1.4s"）。
37
38	### 3. 分析瓶颈
39
40	根据测量结果，检查常见问题：
41
42	网页加载：
43	- 图片是否压缩、是否使用现代格式（WebP/AVIF）
44	- CSS/JS 是否合并压缩，是否有未使用的代码（Coverage 面板检查）
45	- 是否有阻塞渲染的第三方脚本（加 async/defer）
46	- 是否使用了懒加载（图片、路由、组件）
47
48	后端响应：
49	- 数据库查询是否有 N+1 问题（ORM 日志看查询次数）
50	- 是否缺少索引（EXPLAIN ANALYZE 显示 Seq Scan）
51	- 是否有不必要的重复计算（可加缓存）
52	- 序列化是否是瓶颈（大 JSON 响应考虑分页或字段筛选）
53
54	构建速度：
55	- 是否有不必要的依赖拖慢构建
56	- 是否可以用 esbuild/swc 替代 babel/terser
57
58	### 4. 输出优化方案
59
60	按投入产出比排序，给出具体建议：
61
62	```
63	性能分析报告
64	基线数据：[填入步骤 2 的测量结果]
65
66	高影响（优先做）：
67	- [问题] 具体描述 -> [方案] 怎么改 -> [预期提升] 具体数字
68
69	中影响：
70	- ...
71
72	低影响（可选）：
73	- ...
74	```
75
76	### 5. 执行优化并验证
77
78	用户选择后，逐个执行优化。每个优化完成后，用步骤 2 相同的工具和条件重新测量，对比基线数据：
79	- 记录优化前后的具体数字变化
80	- 如果某项优化效果不明显（提升不到 5%），考虑是否值得保留（增加了代码复杂度但收益小）
81	- 如果某项优化导致性能下降，立即回滚
82
83	> 优化完成。主要改动：xxx。性能对比：[优化前数字] -> [优化后数字]。
84
85	## 遇到问题
86
87	- 优化后反而更慢了 — 最常见的原因：缓存策略不当（缓存了不该缓存的动态数据）、过度拆分导致请求数增加、压缩算法的 CPU 开销超过了节省的传输时间。回滚改动，重新分析基线数据
88	- 测量结果不稳定，每次跑差异很大 — 排除干扰因素：关闭其他占用资源的程序，多次测量取中位数（至少 3 次），前端测试用无痕窗口避免插件影响，后端测试先预热（丢弃前几次请求的结果）
89	- 数据库加了索引但查询没变快 — 用 EXPLAIN ANALYZE 确认索引是否真的被使用。常见原因：查询条件中对列做了函数运算导致索引失效、数据量太小优化器选择全表扫描、索引已创建但统计信息未更新（运行 ANALYZE 命令）
90	- Lighthouse 分数提升了但用户体感没改善 — Lighthouse 是模拟环境，可能与真实用户条件不同。用 Chrome DevTools 的 Network throttling 模拟慢网络（Slow 3G），或查看 Web Vitals 的真实用户数据（RUM）

People who liked this also viewed

6 picks

Type

lark-openapi-explorer飞书/Lark 原生 OpenAPI 探索：从官方文档库中挖掘未经 CLI 封装的原生 OpenAPI 接口。当用户的需求无法被现有 lark-* skill 或 lark-cli 已注册命令满足，需要查找并调用原生飞书 OpenAPI 时使用。SkillsJul 2026378k16k
lark-skill-maker创建 lark-cli 的自定义 Skill。当用户需要把飞书 API 操作封装成可复用的 Skill（包装原子 API 或编排多步流程）时使用。SkillsJul 2026377k16k
azure-cost-optimizationOfficial agent plugin providing skills and MCP server configurations for Azure scenarios.SkillsJul 2026209k1.3k
vercel-react-native-skillsVercel's official collection of agent skillsSkillsJul 2026172k29k
mcp-builderGuide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate externaSkillsJul 202693k163k
gws-sharedgws CLI: Shared patterns for authentication, global flags, and output formatting.SkillsJul 202653k30k

perf

36stars6forks

View on GitHub

How to install perf?

lightpointventures/claude-code-starter/perf

$npx -y skills add lightpointventures/claude-code-starter --skill perf

Installs into the current project.

Summary

当用户觉得页面慢、接口响应慢、打包慢、想优化性能时使用 — 分析瓶颈并给出具体改进方案

Files · 1

View on GitHub

SKILL.md

1	# 性能优化
2
3	帮用户找到性能瓶颈并给出具体的改进方案。核心原则：先测量，再优化，再验证。
4
5	## 步骤
6
7	### 1. 确定优化目标
8
9	> 你想优化什么？
10	> - 网页加载速度（首屏渲染慢、页面太大）
11	> - 后端响应时间（API 慢、数据库查询慢）
12	> - 构建速度（打包太慢）
13	> - 内存或 CPU 占用
14
15	### 2. 测量当前基线（必做，优化前必须有数字）
16
17	在做任何改动之前，用合适的工具记录当前性能数据作为基线：
18
19	前端性能测量：
20	- Chrome DevTools Performance 面板 — 录制页面加载，查看瀑布图和主线程阻塞
21	- Lighthouse CLI (`npx lighthouse URL --output=json`) — 获取 FCP、LCP、TBT、CLS 评分
22	- WebPageTest (webpagetest.org) — 真实网络条件下的加载瀑布图
23
24	Python 后端：
25	- `cProfile` — 内置分析器，快速定位耗时函数：`python -m cProfile -s cumtime app.py`
26	- `py-spy` — 采样式分析器，可附加到运行中的进程，无需改代码：`py-spy top --pid PID`
27	- `line_profiler` — 逐行分析特定函数耗时，适合定位热点代码
28
29	Node.js 后端：
30	- `--inspect` 标志 + Chrome DevTools — `node --inspect app.js`，然后在 Chrome 打开 `chrome://inspect`
31	- `clinic.js` — 自动诊断工具：`npx clinic doctor -- node app.js`
32
33	数据库：
34	- `EXPLAIN ANALYZE` — 在慢查询前加上，查看执行计划和实际耗时。重点关注全表扫描（Seq Scan）和嵌套循环
35
36	> 记录基线数据：具体的数字（如"首页 LCP 3.2s"、"API 响应 P95 800ms"、"查询耗时 1.4s"）。
37
38	### 3. 分析瓶颈
39
40	根据测量结果，检查常见问题：
41
42	网页加载：
43	- 图片是否压缩、是否使用现代格式（WebP/AVIF）
44	- CSS/JS 是否合并压缩，是否有未使用的代码（Coverage 面板检查）
45	- 是否有阻塞渲染的第三方脚本（加 async/defer）
46	- 是否使用了懒加载（图片、路由、组件）
47
48	后端响应：
49	- 数据库查询是否有 N+1 问题（ORM 日志看查询次数）
50	- 是否缺少索引（EXPLAIN ANALYZE 显示 Seq Scan）
51	- 是否有不必要的重复计算（可加缓存）
52	- 序列化是否是瓶颈（大 JSON 响应考虑分页或字段筛选）
53
54	构建速度：
55	- 是否有不必要的依赖拖慢构建
56	- 是否可以用 esbuild/swc 替代 babel/terser
57
58	### 4. 输出优化方案
59
60	按投入产出比排序，给出具体建议：
61
62	```
63	性能分析报告
64	基线数据：[填入步骤 2 的测量结果]
65
66	高影响（优先做）：
67	- [问题] 具体描述 -> [方案] 怎么改 -> [预期提升] 具体数字
68
69	中影响：
70	- ...
71
72	低影响（可选）：
73	- ...
74	```
75
76	### 5. 执行优化并验证
77
78	用户选择后，逐个执行优化。每个优化完成后，用步骤 2 相同的工具和条件重新测量，对比基线数据：
79	- 记录优化前后的具体数字变化
80	- 如果某项优化效果不明显（提升不到 5%），考虑是否值得保留（增加了代码复杂度但收益小）
81	- 如果某项优化导致性能下降，立即回滚
82
83	> 优化完成。主要改动：xxx。性能对比：[优化前数字] -> [优化后数字]。
84
85	## 遇到问题
86
87	- 优化后反而更慢了 — 最常见的原因：缓存策略不当（缓存了不该缓存的动态数据）、过度拆分导致请求数增加、压缩算法的 CPU 开销超过了节省的传输时间。回滚改动，重新分析基线数据
88	- 测量结果不稳定，每次跑差异很大 — 排除干扰因素：关闭其他占用资源的程序，多次测量取中位数（至少 3 次），前端测试用无痕窗口避免插件影响，后端测试先预热（丢弃前几次请求的结果）
89	- 数据库加了索引但查询没变快 — 用 EXPLAIN ANALYZE 确认索引是否真的被使用。常见原因：查询条件中对列做了函数运算导致索引失效、数据量太小优化器选择全表扫描、索引已创建但统计信息未更新（运行 ANALYZE 命令）
90	- Lighthouse 分数提升了但用户体感没改善 — Lighthouse 是模拟环境，可能与真实用户条件不同。用 Chrome DevTools 的 Network throttling 模拟慢网络（Slow 3G），或查看 Web Vitals 的真实用户数据（RUM）

People who liked this also viewed

6 picks

Type