kscz0000 性能分析
先测量，再分析，最后优化——顺序不能乱。
🔧 运行时脚本
执行以下脚本进行自动化分析：
| 脚本 | 用途 | 用法 |
|---|---|---|
scripts/lighthouse_audit.py |
Lighthouse 性能审计 | python scripts/lighthouse_audit.py https://example.com |
1. Core Web Vitals
目标值
| 指标 | 良好 | 较差 | 衡量维度 |
|---|---|---|---|
| LCP | < 2.5s | > 4.0s | 加载 |
| INP | < 200ms | > 500ms | 交互性 |
| CLS | < 0.1 | > 0.25 | 稳定性 |
何时测量
| 阶段 | 工具 |
|---|---|
| 开发 | 本地 Lighthouse |
| CI/CD | Lighthouse CI |
| 生产 | RUM（真实用户监控） |
2. 分析工作流
四步流程
1. BASELINE → Measure current state
2. IDENTIFY → Find the bottleneck
3. FIX → Make targeted change
4. VALIDATE → Confirm improvement
分析工具选择
| 问题 | 工具 |
|---|---|
| 页面加载 | Lighthouse |
| 包体积 | Bundle analyzer |
| 运行时 | DevTools Performance |
| 内存 | DevTools Memory |
| 网络 | DevTools Network |
3. 包体积分析
关注点
| 问题 | 信号 |
|---|---|
| 大型依赖 | 包体积顶部 |
| 重复代码 | 多个 chunk |
| 未使用代码 | 覆盖率低 |
| 缺少拆分 | 单个大 chunk |
优化动作
| 发现 | 动作 |
|---|---|
| 大型库 | 按需导入具体模块 |
| 重复依赖 | 去重、升级版本 |
| 路由在主包 | 代码拆分 |
| 未使用导出 | Tree shake |
4. 运行时分析
Performance 面板分析
| 模式 | 含义 |
|---|---|
| 长任务（>50ms） | UI 阻塞 |
| 大量小任务 | 可能存在批处理机会 |
| 布局/绘制 | 渲染瓶颈 |
| Script | JavaScript 执行 |
Memory 面板分析
| 模式 | 含义 |
|---|---|
| 堆持续增长 | 可能存在泄漏 |
| 大量保留对象 | 检查引用关系 |
| 游离 DOM | 未被清理 |
5. 常见瓶颈
按症状分类
| 症状 | 可能原因 |
|---|---|
| 初始加载慢 | JS 体积大、渲染阻塞 |
| 交互响应慢 | 事件处理器过重 |
| 滚动卡顿 | 布局抖动 |
| 内存持续增长 | 泄漏、引用未释放 |
6. 快速优化优先级
| 优先级 | 动作 | 影响 |
|---|---|---|
| 1 | 启用压缩 | 高 |
| 2 | 图片懒加载 | 高 |
| 3 | 路由代码拆分 | 高 |
| 4 | 缓存静态资源 | 中 |
| 5 | 优化图片 | 中 |
7. 反模式
| ❌ 别这样做 | ✅ 应该这样做 |
|---|---|
| 凭猜测定位问题 | 先做性能分析 |
| 微观优化 | 修复最大瓶颈 |
| 过早优化 | 需要时再优化 |
| 忽视真实用户 | 使用 RUM 数据 |
记住： 最快的代码是不执行的代码。先删除，再优化。
适用场景
本技能适用于执行概述中描述的工作流或操作。
限制
- 仅当任务明确匹配上述范围时使用本技能。
- 不要将输出视为环境特定验证、测试或专家评审的替代品。
- 如果缺少必要的输入、权限、安全边界或成功标准，请停下来请求澄清。