WordPress 变慢要先测基线再改配置，图片、缓存、数据库和 CDN 按顺序处理才能稳定。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
WordPress 变慢时，最常见的错误是一上来就装缓存插件或改主题。真正的问题可能藏在图片体积、数据库 autoload、插件请求和 CDN 缺失里。这套清单按“先测基线，再逐层处理，最后验证”的顺序排，适合独立站长或小团队在没有专职性能工程师的情况下自查。
适用场景
- 页面打开明显变慢，但后台和首页还能正常访问。
- 你要在改主题、换主机或上线新内容前建立性能基线。
- 站点图片很多，或者长期使用页面构建器和大插件。
- 你有主机后台、FTP/SSH 或至少能安装官方性能插件的权限。
不适用场景
- 站点已经返回 500、数据库连接失败或明显被攻击，先恢复可用性再优化。
- 你没有备份，也没有测试环境，直接清理数据库可能造成内容丢失。
- 你只想用一个插件把所有问题“一键解决”，不准备记录前后数据。
- 瓶颈在主机本身，但你没有换主机或升级套餐的权限。
准备材料
- WordPress 后台管理员账号，以及主机控制面板或 SSH/FTP 权限。
- 一个能访问 Chrome 或 Edge 的电脑，用于 Lighthouse 和 PageSpeed Insights。
- 当前 WordPress、PHP、插件和主题版本清单。
- 完整备份，包括数据库、wp-content、wp-config.php 和 .htaccess。
- 测试环境或临时域名，用来验证会影响全局的改动。
步骤一：先测基线，不要凭感觉改
优化前先记录 TTFB、LCP、INP 和 CLS。Google Search Central 把 Core Web Vitals 作为页面体验的一部分，LCP 建议在 2.5 秒内，INP 在 200 毫秒内，CLS 在 0.1 内。这些数字不会告诉你具体是哪一行代码慢，但能判断改动是否真的有效。
- 用 Chrome DevTools 的 Performance 面板记录首屏加载和滚动交互。
- 用 PageSpeed Insights 跑手机和桌面两条结果，保存原始报告。
- 用浏览器无痕模式测 3 次，取中间值，避免缓存和扩展干扰。
- 在服务器端记录 TTFB，比如用 curl 看首字节时间。
步骤二：把图片管线排成第一优先
图片通常占 WordPress 页面重量的主要部分。先做格式和尺寸，再做加载策略。WordPress 从较早版本开始支持 WebP 和原生 lazy loading，但主题或页面构建器可能覆盖这些行为，需要实际检查输出 HTML。
- 把上传前的大图压缩到合理尺寸，不要直接传相机原图。
- 使用 WebP 或 AVIF，确认浏览器支持后服务对应格式。
- 检查 img 是否带 srcset 和 sizes，图片能按视口取合适版本。
- 首屏 LCP 图片不要 lazy loading，应保留 fetchpriority 或预加载。
- 给所有图片写 alt，既服务无障碍，也避免优化后被误判为无意义内容。
步骤三：分层开启缓存
页面缓存、对象缓存、OPcache、浏览器缓存和 CDN 是不同层。页面缓存收益最大，对象缓存减少数据库查询，CDN 减少跨区域延迟。先确认主机支持哪些层，再逐个开启，不要一次全开导致排错困难。
- 开启页面缓存，验证未登录访客能看到缓存命中。
- 如果主机提供 Redis 或 Memcached，再开对象缓存。
- 检查 PHP OPcache 是否启用，并确认缓存目录可写。
- 配置静态资源缓存头和字体显示策略。
- 发布或改设置后清缓存，确认新内容能立即更新。
步骤四：清理数据库和 autoload
数据库慢不总是表太大，autoload 选项会在每次请求时加载。WordPress 官方优化文档把数据库维护列为性能工作的一部分。清理前先备份，并且只处理可以重建的内容。
-- 查看 autoload 体积
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';
-- 查看过期 transient
SELECT option_name, option_value FROM wp_options
WHERE option_name LIKE '_transient_timeout_%' AND option_value < UNIX_TIMESTAMP();
- 限制文章修订版本数，不必要保留每一条历史。
- 清理过期 transient，不要直接删除仍有效的缓存键。
- 删除未使用插件留下的孤立表和选项。
- 对大表做优化前，确认主机锁表时间可以接受。
步骤五：削减脚本、插件和字体
插件数量和页面速度不是简单反比关系，但每个插件都可能增加 PHP 执行和前端脚本。先按功能列出插件，停用不常用的插件，再用 Lighthouse 看脚本请求是否减少。
- 只保留有明确用途的插件，重复功能合并。
- 把第三方脚本放到必要页面，不要全站加载。
- 限制自定义字体数量，设置 font-display: swap。
- 页面构建器生成大量内联样式的，优先考虑替换或重构页面。
步骤六：用 CDN 和线上监控守住结果
CDN 能缓存静态资源并在边缘节点分发，对访问者分布广的站点帮助明显。监控不能只在改版当天看，要设置持续检查，防止插件更新后性能回退。
- 接入 CDN 后，确认 CSS、JS、图片和字体都从 CDN 域名加载。
- 设置 PageSpeed Insights API 或 CrUX 定期检查。
- 把性能报警放到内容发布流程里，重大更新后跑一次线上检查。
- 每月复查插件、缓存和数据库维护记录。
可复制检查表
记录日期：
TTFB：
LCP：
INP：
CLS：
页面总重量：
图片格式/尺寸：
LCP 图片是否预加载：
页面缓存：
对象缓存：
OPcache：
CDN：
数据库 autoload 体积：
最近备份：
未使用插件：
字体数量：
最近一次性能复查：
实际例子：一个内容站从 6 秒首屏降到 2.3 秒
一个中文内容站首页有 18 个插件，图片直接上传相机原图，没有 CDN，TTFB 约 1.2 秒。团队先备份并记录基线，把图片压缩为 WebP，LCP 图片改成预加载；随后开启主机页面缓存和对象缓存，清理了过期 transient 和 40 多万条旧修订。一周后手机 PageSpeed Insights 的 LCP 从 6 秒降到 2.3 秒，INP 稳定在 210 毫秒左右，仍继续观察。
验收清单
- 优化前后都有 TTFB、LCP、INP、CLS 数据。
- 图片使用现代格式，LCP 图片没有 lazy loading。
- 页面缓存、对象缓存或 CDN 至少有一层生效。
- 数据库已备份并完成一次可接受的清理。
- 停用或删除无用插件后，核心功能没有缺失。
- 发布新内容后缓存能被正确刷新。
常见坑
- 把 uploads 目录权限改成 777 来修复图片错误，造成更大的风险。
- 只优化图片，不查数据库和插件，缓存后仍慢。
- 把所有图片都 lazy loading，LCP 反而更慢。
- 清理 transient 时误删正在使用的缓存，导致插件重新拉取大量数据。
- 改完设置不清缓存，测试结果看着没变。
排错路径
- TTFB 高：先看主机资源、页面缓存、对象缓存和数据库查询，再查插件。
- LCP 慢但图片尺寸已经压到合适范围：检查首屏是否有阻塞脚本、字体和第三方 iframe。
- 缓存命中但内容不更新：检查 purge 配置、页面 URL 是否带参数、登录态 cookie。
- 清理数据库后页面报错：从备份恢复，再逐个处理清理项。
- CDN 后图片不显示：检查 CNAME、SSL 证书和源站 Host 设置。
后续维护建议
更新日期：2026-08-20。建议每月跑一次 PageSpeed Insights 和数据库维护，每次 WordPress、主题或插件大版本更新后重新检查缓存和 LCP 图片。站点新增栏目、上传大量图片或更换主机时，重新执行本清单，不要把旧数据当作永久结论。