企业官网建设流程全解析

结论摘要

WordPress「突然变慢」优先按层定位，而不是先换主题：

1. TTFB 高：应用未命中缓存、PHP/DB 慢、或主机打满；
2. TTFB 尚可但 LCP 差：图片/字体/主 JS 阻塞、首屏过大；
3. 仅部分模板慢（商品归档、带筛选列表）：查询与插件 hook，不是「整站废了」。

先分清「后台也慢还是仅前台慢」，再动缓存与 CDN。以下步骤默认你有备份，生产变更放在维护窗口。

适用场景

• 通用 WP 站点；若为 Woo，结账/购物车必须排除全页缓存（见文内注意）。
• 需要：主机面板或 SSH、可看响应头、最好有 staging。

步骤一：定量，不要凭感觉

浏览器开发者工具 Network：看文档请求的 等待时间（约等于 TTFB） 与资源瀑布。
可选命令（把 URL 换成你的）：

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 满分或搜索排名，以你站实测为准。讨论区可贴脱敏响应头与现象，便于对症；讨论区可贴脱敏响应头与现象，便于对症。）