现象:首页 TTFB 超过 1.5 秒,图片一张张往外蹦。不追求写全,只写容易出错的那几步。
这一套动作在 WordPress 站点 上验证过,换环境只需要替换路径和重载命令。
在WordPress 站点上,先看这一处
WordPress 站点先分两半看:一半是主题和插件,一半是服务器。关掉全部插件复测一次,是判断插件问题的唯一可靠办法。
缓存要清三层:插件缓存、对象缓存(Redis/Memcached)、CDN。三层里漏一层,你看到的就是旧页面。
WordPress 站点 下这个问题有几种不同的成因,下面按出现频率排,不用每条都试。
排查顺序
原因通常落在这三类:服务器到用户的链路长,或者机房在境外;主题/插件在首屏同步加载了外部资源;页面 HTML 没有缓存,每次请求都重新查库。按从外到内走,先排除最容易确认的。
- 第 1 步:先量:curl -o /dev/null -s -w “dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total} ” https://你的域名/ ,ttfb 占大头就是服务端问题
- 第 2 步:再测静态资源:把首页资源数一下,超过 60 个请求、总大小超过 2MB 就得合并压缩
- 第 3 步:服务端看慢查询:MySQL 开 slow_query_log,long_query_time=1,跑一天看 top 语句
- 第 4 步:模板层查同步阻塞:外部字体、统计脚本、广告位全部加 defer,或用本地托管
- 第 5 步:上缓存:页面缓存 + 对象缓存两层,缓存命中后 ttfb 应该压到 200ms 内
- 第 6 步:临时关插件测:把 wp-content/plugins 改名,前台不报错就说明是插件冲突
怎么确认修好了
改完重复第一步的 curl,ttfb 下降 50% 以上才算有效;再用手机 4G 实测一次。WordPress 站点下还要多看一眼日志时间戳,确认改动之后没有新的同类记录。
| 核对项 | 通过标准 | 没通过说明什么 |
|---|---|---|
| 固定链接 | 文章页只有一种 URL 形态可访问 | 另一种形态仍返回 200 而非 301 |
| 缓存状态 | 页面缓存与对象缓存均已清空 | 只清了页面缓存,旧内容仍从对象缓存出 |
| 模板输出 | canonical 由程序生成且不重复 | 插件和主题各输出一次 |
| 站点地图 | sitemap 中每个地址只出现一次 | 索引和分片同时收录了同一篇 |
| 搜索表现 | site: 查询同一文章只剩一条 | 收录尚未更新,需要等下一轮抓取 |
| 生效时间 | 改动后至少观察 10 分钟 | 刚改完就判定无效 |
这个环境里容易误判的地方
WordPress 站点最常见的误判是把缓存问题当成程序问题。先清三层缓存再判断改动是否有效,能省掉大量重复劳动。
做完把结果记下来,下次遇到同类问题能省一半时间。
补充两点
部署最容易被忽略的一步是权限。文件属主不对,表现是上传失败、插件装不上、缓存写不进去。
跨域、证书、CDN 这三样配错的表现很像,先用 curl -I 看响应头,能省一半时间。
接着看
常见问题
如何判断是带宽还是 CPU 瓶颈?
看 top 里 CPU 是否持续高位;CPU 不高但访问慢,多半是带宽或磁盘 IO。
证书自动续期可靠吗?
可靠,但要加到期告警。自动续期失败通常无声无息。
多站点要不要独立数据库账号?
要。共用账号出问题无法定位,也无法单独限权。
相关阅读
© 版权声明
文章版权归作者所有,未经允许请勿转载。
相关文章
暂无评论...
苏公网安备32038202001011号