Performance Profiling 是一个关于性能分析（profiling）的原则与工作流技能，核心主张是按“测量（Measure）、分析（Analyze）、优化（Optimize）”的顺序推进性能工作。
一、用途 用于指导 Web 性能的诊断与优化实践：先建立基线，定位瓶颈，再做针对性修改，最后验证效果。资料强调不要凭猜测优化，也不要过早做微优化，应优先解决最大的问题，并参考真实用户数据。
二、运行脚本 资料提供了一个自动化分析脚本：
- 脚本：scripts/lighthouse_audit.py
- 用途：Lighthouse 性能审计
- 用法：python scripts/lighthouse_audit.py https://example.com
三、Core Web Vitals 资料给出三项核心指标的良好与较差阈值及衡量维度：
- LCP：良好 < 2.5s，较差 > 4.0s，衡量加载；
- INP：良好 < 200ms，较差 > 500ms，衡量交互性；
- CLS：良好 < 0.1，较差 > 0.25，衡量稳定性。 测量时机：开发阶段使用本地 Lighthouse，CI/CD 使用 Lighthouse CI，生产环境使用 RUM（真实用户监控）。
四、分析工作流 四步流程：1）BASELINE 测量当前状态；2）IDENTIFY 找到瓶颈；3）FIX 做针对性修改；4）VALIDATE 确认改进。 工具选型按问题划分：页面加载用 Lighthouse，打包体积用打包分析器，运行时用 DevTools Performance，内存用 DevTools Memory，网络用 DevTools Network。
五、打包分析 需关注的问题及指标：大依赖位于打包顶部、重复代码分布在多个 chunk、未使用代码覆盖率低、缺少拆分导致单个大 chunk。对应的优化动作：大库改为按需导入具体模块，重复依赖去重并更新版本，主包中的路由做代码分割，未使用的导出做 tree shaking。
六、运行时分析 Performance 面板中：长任务（>50ms）表示 UI 阻塞，大量小任务可能存在批处理机会，大量 layout/paint 属渲染瓶颈，script 为 JavaScript 执行。Memory 面板中：堆持续增长可能存在泄漏，大量 retained 需检查引用，detached DOM 表示未清理。
七、常见瓶颈与快速优化 按症状定位：初次加载慢多为大 JS 与阻塞渲染；交互慢多为事件处理过重；滚动卡顿多为布局抖动；内存增长多为泄漏与保留引用。 快速优化优先级依次为：开启压缩（高）、图片懒加载（高）、路由代码分割（高）、静态资源缓存（中）、图片优化（中）。
八、反模式 资料列出应避免的做法与应做的做法：不要猜测问题，应先分析；不要微优化，应先解决最大问题；不要过早优化，应在需要时优化；不要忽略真实用户，应使用 RUM 数据。核心提醒是：最快的代码是不运行的代码，应先移除再优化。
九、适用场景与限制 适用场景为 Web 前端性能审计、加载与交互性能诊断、打包体积与运行时性能排查。限制方面，资料未提供该技能的具体安装方式、依赖环境、支持框架范围及许可信息，这些暂未提供。