结论摘要
WordPress「突然变慢」优先按层定位，而不是先换主题：
- TTFB 高：应用未命中缓存、PHP/DB 慢、或主机打满；
- TTFB 尚可但 LCP 差：图片/字体/主 JS 阻塞、首屏过大；
- 仅部分模板慢（商品归档、带筛选列表）：查询与插件 hook，不是「整站废了」。
先分清「后台也慢还是仅前台慢」，再动缓存与 CDN。以下步骤默认你有备份，生产变更放在维护窗口。
适用场景
- 通用 WP 站点；若为 Woo，结账/购物车必须排除全页缓存（见文内注意）。
- 需要：主机面板或 SSH、可看响应头、最好有 staging。
步骤一：定量，不要凭感觉
浏览器开发者工具 Network：看文档请求的 等待时间（约等于 TTFB） 与资源瀑布。
可选命令（把 URL 换成你的）：
bash
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n" https://example.com/预期：重复请求若已开页面缓存，TTFB 应明显低于未缓存的动态响应（具体数值因主机而异，看对比而非绝对值）。
同时看响应头是否出现缓存命中迹象（因方案而异），例如 x-cache、cf-cache-status、age 等------没有也不代表一定没缓存，以你所用 CDN/插件文档为准。
步骤二：确认页面缓存是否真的在工作
- 匿名窗口连续刷新首页 2--3 次，对比 TTFB。
- 登录态下不要用「匿名缓存结果」判断整站 OK（Cookie 常导致旁路缓存）。
- Woo / 会员站：确认购物车、结账、我的账户等路径在缓存插件与 CDN 规则里为 绕过 / 不缓存。
配置注意（原则，非某一家插件广告）：
- 全页缓存适合相对静态的页面；带 nonce、会话、购物车的路径误缓存会导致串号或空车。
- 对象缓存（Redis/Memcached）与全页缓存解决的问题不同：前者减重复查询，后者减整页 PHP。不要叠三套「一键加速」却说不清彼此职责。
步骤三：锁定「最近变更」
列出近 14 天：插件/主题/PHP 升级、新埋点/客服脚本、大批量导入、定时任务（Action Scheduler / cron）。
在 staging 上对变更做二分：一次回退一类，记录 TTFB 与慢查询是否恢复。
步骤四：数据库与查询（仅前台某类页慢时）
- 修订版本、过期 transient、日志型表膨胀会导致管理端与部分前台变慢。
- 备份后做维护；对慢模板用查询监控（主机慢查询日志或成熟 APM）找重复
wp_posts/postmeta扫描。 - 不要在生产直接删表；先导出、先 staging。
步骤五：CDN 是加速还是回源放大
若已接 CDN，检查：
- 动态 HTML 是否被错误长缓存，或相反------静态资源从不缓存导致回源爆炸；
- 缓存键是否包含无必要 Cookie/查询参数，导致命中率极低；
- 回源 Host、HTTPS、压缩是否按文档配置。
详述可对照：https://wordpress.work/cdn/
步骤六：前端 LCP 常见项
- 首屏大图未压缩、未指定尺寸导致布局偏移；
- 阻塞渲染的 CSS/JS、第三方聊天与统计脚本上首屏；
- 字体子集与
font-display策略。
CWV 分数会波动，不要把「实验室 100 分」当唯一验收；以关键模板的真实用户路径为准。
验证
- 同网络、同模板：优化前后 TTFB / LCP 对比（记时间、记是否登录态）。
- 电商路径：加购 → 结账走通，无缓存串会话。
- 观察 24--48h 主机 CPU 与 PHP-FPM 队列是否回落。
常见坑
- 生产直接停用全部插件「测速」导致业务中断；
- 多层缓存清不干净，改了 PHP 仍看到旧 HTML；
- 只在公司宽带测、忽略目标市场节点。
文末
系统说明与清单取向的性能页：https://wordpress.work/performance/
若希望按你的网址输出问题优先级清单：https://wordpress.work/diagnosis/
（WpWork 实操笔记；不承诺 PageSpeed 满分或搜索排名，以你站实测为准。讨论区可贴脱敏响应头与现象，便于对症；讨论区可贴脱敏响应头与现象，便于对症。）