客户找到我们的时候，只有一句话："这站太慢了，客户等不了。"
这是一个做户外用品的外贸独立站，WooCommerce 商城，商品 400 多个，日均 UV 约 800。主关键词排名首页，流量不算差，但询盘转化一直上不去。客户自己测过 PageSpeed，移动端 42 分，LCP 4.2 秒，TTFB 680ms。
这篇文章完整记录了整次优化的过程：先做了什么、为什么做、改完之后指标变成什么样。
第 0 步：先看数据，别急着动手
很多人一上来就装缓存插件、压图片，这其实是反的。你得先知道慢在哪里。
我们用了三个工具交叉验证：
- PageSpeed Insights：看 Core Web Vitals 和具体资源加载时间
- WebPageTest：看瀑布图，判断是服务器慢还是资源阻塞
- Query Monitor：WordPress 插件，直接看后台 PHP 执行时间
测下来的结果：
TTFB (首字节响应): 680ms ← 服务器慢
LCP (最大内容绘制): 4.2s ← 图片 + 阻塞
CLS (布局偏移): 0.18 ← 字体加载问题
页面总大小: 6.4MB ← 图片太大
请求数: 128 ← 插件太多结论很明确：服务器是根本瓶颈，图片和代码是次要但也要处理的问题。
如果 TTFB 超过 500ms，先优化服务器。否则前端怎么调，LCP 也压不下去——因为浏览器拿不到 HTML，后面一切都没开始。
第 1 步：服务器层优化（TTFB 680ms → 218ms）
服务器是地基。地基不动，上面装修得再好也白搭。
1.1 换主机
客户原本用的是某海外共享主机，月费 $3.99。这种主机的问题是：
- 同服务器上跑着几百个站点，资源竞争严重
- PHP 版本还停在 7.4（现在是 8.3）
- 没有 OPcache，每次请求都重新编译 PHP
我们建议他换到 Cloudways 的 2GB 套餐（$14/月），机房选新加坡节点（客户主要客户在东南亚和欧美）。
1.2 开启 OPcache 和 PHP 8.3
PHP 从 7.4 升到 8.3，配合 OPcache，执行效率提升大概 40%。这个升级是在主机后台一键操作的，大概 5 分钟。
1.3 部署 Redis 对象缓存
WordPress 每次加载都会重复查询数据库。对象缓存把常用查询结果存到内存里，直接读取。我们用的是 Redis，安装后 TTFB 又降了 100ms 左右。
# 安装 Redis 对象缓存插件后
wp redis enable
# 或者手动配置 wp-config.php
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);做完这三件事，TTFB 从 680ms 降到 218ms。这一步是整个优化里收益最大的。
第 2 步：图片优化（6.4MB → 1.2MB）
页面总大小 6.4MB 里，图片占了 4.8MB。一张商品主图 2.3MB——这个大小，就算网络再快也要好几秒才加载完。
2.1 批量压缩 + 转 WebP
我们用 ShortPixel 做批处理。免费额度是每月 100 张，400 个商品 + 详情图一共大概 2000 张，花了 $9.99 买了 5000 张的额度，一次性处理完。
WebP 相比 JPG 平均能减 30%–50% 的体积，画质几乎看不出差别。现在所有主流浏览器都支持 WebP。
2.2 延迟加载 + 首屏预加载
非首屏图片全部加 loading="lazy"，浏览器滑到才加载。首屏那张主图设置 fetchpriority="high"，让它优先加载。
<!-- 首屏主图：优先加载 -->
<img src="hero.webp" fetchpriority="high" alt="...">
<!-- 非首屏图片：延迟加载 -->
<img src="product.webp" loading="lazy" alt="...">这一步做完，页面总大小从 6.4MB 降到 1.2MB，LCP 从 4.2 秒压到 1.8 秒。
第 3 步：代码和资源优化（LCP 1.8s → 0.9s）
到这一步，服务器和图片都处理完了。剩下的问题在前端渲染：CSS 阻塞、JS 太多、字体加载慢。
3.1 关键 CSS 内联
网站首屏的 CSS 大概 8KB，直接内联到 HTML 的 <head> 里。剩下的 CSS 异步加载。
这一步让首屏渲染时间直接减少了 400ms。
3.2 延迟加载非关键 JS
WordPress 默认会把所有 JS 都放在头部阻塞渲染。我们用了 defer 和 async 属性，让非首屏必需的 JS 延后执行。
3.3 字体本地化 + 子集化
客户之前用的是 Google Fonts 的在线字体。问题是：
- 每次加载都要连 fonts.googleapis.com，国内访问尤其慢
- 字体文件包含所有字符，实际用到的可能只有 10%
我们把字体下载到服务器本地，然后用 Font Squirrel 做了子集化，只保留常用的 2000 个中文字符。字体文件从 800KB 减到 68KB。
3.4 引入 CDN
客户的主要用户在东南亚和欧美，而服务器在新加坡。欧美用户访问时，物理距离仍然造成延迟。
我们接了 Cloudflare 免费版做 CDN，静态资源（图片、CSS、JS、字体）全部走 CDN 节点。这一步之后，欧美用户的 TTFB 从 380ms 降到 90ms。
第 4 步：数据库清理
网站跑了 3 年，数据库里攒了不少垃圾：
文章修订版本: 4,218 条 ← 每条都在库里占空间
垃圾评论: 1,847 条
过期 transient: 3,542 条
未使用的标签: 412 个我们用 WP-Optimize 插件清理了这些数据，数据库从 168MB 减到 34MB。查询速度提升了不少。
我们清理前完整导出了数据库。清理脚本如果配置错误，可能误删正在使用的内容。这一步一定不要跳过备份。
最终结果
整个优化花了 3 天。前后对比：
| 指标 | 优化前 | 优化后 |
|---|---|---|
| PageSpeed（移动端） | 42 | 92 |
| LCP | 4.2s | 0.9s |
| TTFB | 680ms | 218ms |
| CLS | 0.18 | 0.02 |
| 页面总大小 | 6.4MB | 1.2MB |
| 询盘转化率 | 0.8% | 2.1% |
询盘率翻了一倍多。客户说："以前一天 3-5 个询盘，现在稳定 10 个以上。"
一些总结
这次优化的核心不是某个神奇插件，而是按正确的顺序做事：
- 先诊断，再动手。知道慢在哪里，比盲目优化重要得多。
- 服务器优先，图片其次，代码最后。顺序错了，前端做再多也白费。
- 每一步都测量。不测数据，你永远不知道某个改动是不是真的有效。
- 不要一次改太多。同时改十处，出了问题你都不知道是哪一处。
很多人以为速度优化就是"装个缓存插件"。实际上它是系统工程——服务器、前端、数据库、CDN，每一层都有优化空间。而真正拉开差距的，是你能不能在正确的层、正确的顺序上做正确的事。
如果你的网站也有速度问题，欢迎找我们做一次免费诊断。我们会告诉你慢在哪里、能优化到什么程度、大概需要多少时间和预算。