核心用法
Web Performance Engine 是一套完整的网页性能优化系统，涵盖 10 个阶段的工程化工作流：
1. Phase 1 审计：三层级健康检查（Critical/Important/Polish），快速定位 TTFB、FCP、LCP、TBT、CLS、INP 等瓶颈
2. Phase 2 诊断：基于关键渲染路径的决策树，自动化问题归因
3. Phase 3 修复手册：6 大专题 playbook（服务器优化、渲染阻塞消除、Hero 元素优化、JS 瘦身、布局稳定性、交互优化）
4. Phase 4 资源策略：Preload/Prefetch/Preconnect 精准控制、懒加载分级策略
5. Phase 5 第三方脚本治理：影响评估模板 + 延迟加载策略（交互触发、空闲加载、Facade 模式）
6. Phase 6 移动端专项：4G 网络下的硬性预算（JS < 300KB、Critical CSS < 14KB）
7. Phase 7 性能预算：可量化的 YAML 配置 + CI 拦截规则
8. Phase 8 评分体系：8 维度 100 分制量化评估
9. Phase 9 架构速赢：Next.js、WordPress、SPA、静态站点的针对性方案
10. Phase 10 高级技术：Service Worker 缓存、预测性预取、生产环境 Core Web Vitals 监控
显著优点
- 零工具依赖：通过
web_fetch调用 PageSpeed Insights、搜索 CrUX 数据，无需本地安装 Lighthouse - 决策树驱动：6 层嵌套诊断树，将复杂性能问题转化为可执行的修复路径
- 量化预算体系：从资源体积（KB）到用户体验指标（ms）的完整预算模板，支持 CI/CD 拦截
- 框架适配：覆盖 Next.js/React、WordPress、Vue/Svelte 等主流架构的具体优化代码
- 移动优先设计：所有指标均区分 mobile/desktop，4G/3G 网络条件下的差异化目标
潜在局限
- 执行门槛：需要开发者具备 HTTP、缓存策略、浏览器渲染原理等前置知识
- 外部服务依赖：完全离线审计仍需配合 Chrome DevTools 或 Lighthouse CLI
- 动态内容限制：对高度个性化的 SSR 页面（如千人千面的电商首页）的优化建议相对通用
- 无自动修复：提供诊断和代码模板，但具体实施仍需人工介入
适合人群
- 前端工程师（尤其是负责性能专项的技术负责人）
- 全栈开发者需要快速诊断站点瓶颈
- 技术 PM 设定可量化的性能 SLA
- 运维/SRE 建立性能监控和预算体系
常规风险
- 过度优化风险：激进的预加载策略（>5 个 preload）可能适得其反，文档已明确限制 3-5 个
- 缓存策略误配：immutable 与 must-revalidate 混用可能导致内容更新延迟
- 字体显示策略：
font-display: optional虽消除 CLS，但可能造成 FOIT（不可见文本），需权衡品牌一致性 - 第三方脚本延迟：Facade 模式可能降低转化率，需 A/B 测试验证