mcpField
W
wp-performance

wp-performance

github.com/wordpress开发2.3k6.2k 次安装1 周前更新
代码仓库

关于 wp-performance

wp-performance 是用于诊断和优化 WordPress 后端性能的技能，适合排查网站、管理界面、REST 接口和 WP-Cron 的速度问题。它强调先测量基线，再用 WP-CLI 和日志定位瓶颈并复测。

主要功能

  1. 01采集性能基线并检查环境
  2. 02使用 WP-CLI 进行诊断和分析
  3. 03检查自动加载选项与对象缓存
  4. 04定位数据库、远程请求和 Cron 瓶颈
  5. 05对比优化前后的性能数据

适用场景

  1. 01调查页面或 REST 接口响应缓慢
  2. 02定位管理界面或 WP-Cron 的性能问题
  3. 03分析数据库查询与自动加载选项
  4. 04验证缓存或代码优化效果

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/wordpress/agent-skills --skill wp-performance

安装后在 Claude Code 中输入/wp-performance确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

references/
autoload-options.md
cron.md
database.md
http-api.md
measurement.md
object-cache.md
query-monitor-headless.md
server-timing.md
wp-cli-doctor.md
wp-cli-profile.md
scripts/
perf_inspect.mjs

详细介绍

WP Performance（仅后端）

适用场景

在以下情况下使用此技能：

  • WordPress 网站／页面／端点速度慢（前端 TTFB、管理后台、REST、WP-Cron）
  • 需要分析方案和工具建议（WP-CLI profile/doctor、Query Monitor、Xdebug/XHProf、APM）
  • 正在优化数据库查询、自动加载的选项、对象缓存、cron 任务或远程 HTTP 调用

此技能假设 Agent 无法使用浏览器界面。优先使用 WP-CLI、日志和 HTTP 请求。

所需输入

  • 环境和安全限制：dev/staging/prod、任何限制（禁止写入、禁止安装插件）。
  • 如何指定安装位置：
    • WordPress 根目录 --path=<path>
    • （多站点／站点指定）--url=<url>
  • 性能症状和范围：
    • 涉及哪个 URL／REST 路由／管理界面
    • 发生时间（始终发生还是偶发；已登录还是未登录）

流程

0) 安全措施：先测量，避免高风险操作
  1. 确认是否允许执行写入操作（安装插件、修改配置、清空缓存）。
  2. 选择一个可复现的目标（URL 或 REST 路由）并记录基线：
    • 如可行，使用 curl 测量 TTFB／耗时
    • 如可用，使用 WP-CLI 进行性能分析

阅读：

  • references/measurement.md
1) 生成仅后端的性能报告（确定性）

运行：

  • node skills/wp-performance/scripts/perf_inspect.mjs --path=<path> [--url=<url>]

此命令会检测：

  • WP-CLI 是否可用以及核心版本
  • wp doctor / wp profile 是否可用
  • 自动加载的选项大小（如可行）
  • 是否存在 object-cache drop-in
2) 快速见效：先运行诊断，再进行深入分析

如果可以使用 WP-CLI，优先运行：

  • wp doctor check --all（添加 --spotlight，仅显示警告和错误）
  • 或指定检查项，进行以性能为重点的检查：wp doctor check autoload-options-size constant-savequeries-falsy constant-wp-debug-falsy

如果 wp doctor check 未指定检查项且没有 --all，就会报错退出，而不会运行任何检查。

它可以发现常见的生产环境隐患（自动加载内容膨胀、SAVEQUERIES/WP_DEBUG、插件数量、更新）。

阅读：

  • references/wp-cli-doctor.md
3) 深入分析（无需浏览器）

优先顺序：

  1. 使用 wp profile stage 查看耗时分布（bootstrap/main_query/template）。
  2. 使用 wp profile hook（可选添加 --url=）查找耗时较长的钩子／回调。
  3. 使用 wp profile eval 分析指定代码路径。

阅读：

  • references/wp-cli-profile.md
4) Query Monitor（仅后端使用）

Query Monitor 通常通过界面操作，但也可以通过 REST API 响应标头和 _envelope 响应以无界面方式使用：

  • 进行身份验证（nonce 或 Application Password）。
  • 请求 REST 响应并检查标头（x-qm-*），和／或使用 ?_envelope 时检查 qm 属性。

阅读：

  • references/query-monitor-headless.md
5) 按类别修复（选择主要瓶颈）

根据性能分析输出，选择一个主要瓶颈类别：

  • 数据库查询 → 减少查询次数、修复 N+1 模式、优化索引、避免开销大的 meta 查询。
    • references/database.md
  • 自动加载的选项 → 找出占用最大的自动加载选项，并停止自动加载大型数据块。
    • references/autoload-options.md
  • 对象缓存未命中 → 添加缓存或修复缓存键／组的用法；在适当情况下添加持久化对象缓存。
    • references/object-cache.md
  • 远程 HTTP 调用 → 添加超时、缓存和批处理；避免每次请求都调用远程 API。
    • references/http-api.md
  • Cron → 减少到期任务集中执行造成的峰值、去重事件，并将繁重任务移出请求路径。
    • references/cron.md
6) 验证（重复相同的测量）
  • 重新运行相同的 wp profile / wp doctor / REST 请求。
  • 确认性能变化，并确保行为未变。
  • 如果修复存在风险，尽可能通过功能开关或分阶段推出。

WordPress 6.9 性能改进

性能分析时，请注意 6.9 的以下变化：

经典主题的按需 CSS：

  • 经典主题现在也支持按需加载 CSS（此前只有区块主题支持）。
  • 仅加载页面上实际使用的区块样式，可减少 30-65% 的 CSS 载荷。
  • 如果你正在分析经典主题，这项改进应该已经生效。

没有渲染阻塞资源的区块主题：

  • 未定义自定义样式表的区块主题（例如 Twenty Twenty-Three/Four）现在可以在完全没有渲染阻塞 CSS 的情况下加载。
  • 样式来自全局样式（theme.json）和单独的区块样式，并且全部内联。
  • 这会显著改善 LCP（最大内容绘制）。

提高内联 CSS 限制：

  • 提高了内联小型样式表的阈值，从而减少渲染阻塞资源。

参考：https://make.wordpress.org/core/2025/11/18/wordpress-6-9-frontend-performance-field-guide/

验证

  • 已记录基线与改进后的数据（环境和 URL/路由相同）。
  • 适用时，wp doctor check --all 检查结果正常（或有所改善）。
  • 日志中没有新增 PHP 错误或警告。
  • 正确性不依赖清除缓存（清除缓存应作为最后手段）。

故障模式／调试

  • 代码更改后“没有变化”：
    • 测量的是不同的 URL/站点（--url 不匹配）、缓存掩盖了结果，或者操作码缓存已过期
  • 性能分析数据波动较大：
    • 排除后台任务的影响，在缓存预热后测试，并运行多次采样
  • SAVEQUERIES/Query Monitor 会造成开销：
    • 除非获得明确批准，否则不要在生产环境中运行

升级处理

  • 如果这是生产环境且你没有明确批准，请勿：
    • 在流量高峰期间安装插件、启用 SAVEQUERIES、运行负载测试或清除缓存
  • 如果需要进行系统级性能分析（APM、PHP 性能分析扩展），请与运维／托管服务提供方协调。

评论

支持 Markdown