一个常见的误区：不要把 PageSpeed 100 分当成目标
PageSpeed Insights 的评分是参考，不是目标。一个 PageSpeed 93 分、实际用户加载速度很快的站，比一个评分 100 分但各种压缩导致样式错乱的站好得多。真正要盯着的是 Core Web Vitals 的三个指标：
| 指标 | 含义 | Google 建议值 |
|---|---|---|
| LCP（最大内容绘制） | 主要内容加载完成时间 | ≤ 2.5 秒 |
| INP（下次绘制交互） | 用户操作后页面响应时间 | ≤ 200 ms |
| CLS（累积布局偏移） | 页面加载中元素位移程度 | ≤ 0.1 |
再加上 TTFB（首字节时间，建议 < 800ms） 和 Fully Loaded Time（建议 < 3 秒），这五个数字是速度优化的实际评判标准。在 Google Search Console 的"体验"部分可以看到真实用户的 Core Web Vitals 数据，这比在 PageSpeed Insights 里测试一次更有参考价值。
第一层：服务器是一切的基础
插件和配置能优化的空间有限，如果服务器本身资源不足，什么缓存都帮不了你。WooCommerce 商城对数据库查询的需求高于普通博客，选服务器时要按商城体量来评估，不要按"先省钱以后再说"来省。
不同主机方案对速度的影响说清楚：共享主机的资源是和其他用户分摊的，高峰时段可能严重影响 TTFB；VPS 和云服务器资源独立，性能更稳定；Cloudways 这类托管平台在 VPS 基础上管理服务器环境，也预置了 Nginx + Redis 的性能配置，适合不想自己管服务器的运营者。具体选型在《用 Cloudways 搭建 WooCommerce 独立站》那篇里有详细分析。
第二层：缓存配置
缓存是单个改动对速度提升最大的措施。
页面缓存把 PHP 动态生成的页面预先渲染成静态 HTML，下次访问直接读静态文件，跳过 PHP 和数据库查询，TTFB 可以从数秒降到几十毫秒。
选哪个缓存插件，取决于服务器环境——LiteSpeed Cache 在 LiteSpeed 服务器上效果最好，Cloudways 的 DigitalOcean 和 Vultr 方案默认是 Nginx，用 LiteSpeed Cache 意义不大，换 WP Rocket 或 W3 Total Cache。这个判断在前面的《插件清单》文章里已经说过，这里不重复。只装一个缓存插件，不要两个同时开着。
WooCommerce 特别需要注意：购物车页面、结账页面、个人账户页面不能被缓存，因为这些页面是用户个性化的动态内容。主流缓存插件默认会把这几个页面排除在外，如果你自定义了结账流程，要手动确认这些 URL 没有被缓存。
对象缓存（Redis 或 Memcached）针对数据库查询。WooCommerce 商城会频繁查询产品信息、库存、用户 Session，对象缓存把这些查询结果放在内存里，重复查询直接读内存，大幅减少数据库压力。Cloudways 面板里 Server → Manage Services → Redis 可以一键开启。
第三层：图片优化
图片通常占页面体积的 40–60%，是优化收益最大的单一资源类型。
格式选择：WebP 比 JPEG 体积小约 25–35%，现代浏览器支持广泛，优先使用。AVIF 比 WebP 更小，但部分旧浏览器不支持，需要配合回退方案。ShortPixel、Imagify 或 EWWW Image Optimizer 都可以批量转换已上传的图片，同时在新上传时自动压缩。
按实际显示尺寸上传：如果图片在页面上显示为 400×300px，不要上传 2000×1500px 的原图，浏览器会下载整张大图然后在本地缩放，浪费带宽。
Lazy Load（懒加载）：让首屏以下的图片在用户滚动到对应位置时才加载，大幅减少初始页面加载的数据量。WordPress 5.5 之后已经原生支持图片懒加载，大多数情况下不需要额外插件。
第四层：CDN
CDN 把静态资源（图片、CSS、JS、字体）缓存到全球节点，让用户从距离最近的节点加载，而不是每次都从你的服务器拉。对于跨境独立站，这一层优化非常实质——从中国的服务器直接传输资源到欧美用户，和从欧美 CDN 节点传输，延迟差距可以是几倍。
Cloudflare 免费版对大多数跨境独立站已经够用：全球 CDN、基础 DDoS 防护、Brotli 压缩、Auto Minify（CSS/JS/HTML 自动压缩）。配置要点：在 Speed 选项里开启 Brotli、Auto Minify，在 Cache 里设置合理的浏览器缓存时间，不要缓存购物车和结账页面。如果流量更大或者需要更精细的性能控制，Bunny CDN 的价格便宜、性能也不错，可以作为升级选项。
第五层：CSS、JavaScript 和第三方脚本
CSS 和 JS 优化：删除未使用的 CSS（Unused CSS）、延迟加载非首屏需要的 JavaScript，可以显著减少首屏阻塞时间。主流缓存插件（WP Rocket、FlyingPress）都内置了这些功能，直接在插件设置里开启即可。注意：这类优化有时会破坏主题或插件的样式，每次改动后要在不同设备上测试页面是否正常显示。
第三方脚本是最容易被忽略的速度杀手。 Google Analytics、Meta Pixel、TikTok Pixel、在线客服插件、热力图工具——每一个都要向第三方服务器发起请求，加在一起的影响可能比你的主题或图片还大。清查一遍已安装的第三方脚本，删掉不再使用的，把剩余的通过 Google Tag Manager 统一管理（可以延迟加载非关键脚本），是这里最有效的优化手段。
第六层：字体、数据库和 PHP
字体：Google Fonts 在国内访问本来就慢，在跨境独立站上有时也会因为加载多种字体变体导致性能问题。减少使用的字体种类和字重（weight），只加载实际用到的那几个，是简单有效的优化。如果字体授权允许，本地托管字体（把字体文件放在自己服务器上）可以进一步减少外部依赖。
数据库清理：长期运营的网站会积累修订版本（Revisions）、自动草稿、垃圾评论、WooCommerce Session 数据，这些累积起来会拖慢数据库查询。WP-Optimize 或 Advanced Database Cleaner 可以定期清理，清理前记得先备份数据库。
PHP 版本：建议使用 PHP 8.3 或当时最新的受支持版本，新版本的性能比旧版本快很多，安全性也更好。升级前在测试环境确认主题和插件兼容，大多数维护中的插件对 PHP 8.x 支持已经很成熟。
WooCommerce 商城专项优化
WooCommerce 比普通 WordPress 博客消耗更多数据库资源，有几个针对商城的额外优化：
商品图片统一转成 WebP 并通过 CDN 分发，多 SKU 商城图片数量庞大，这一步的收益很明显。搜索功能在商品数量超过数千的商城里会比较慢，可以考虑 ElasticPress 这类插件把搜索查询交给 Elasticsearch 处理，而不是默认的 MySQL 全文搜索。结账页面不要安装过多营销插件（Upsell、弹窗），每个插件都在结账页加载额外脚本，会影响转化最关键的页面的加载速度。
速度优化检查清单
上线前逐项检查：
- [ ] 选择了配置合适的服务器（不是配置不足的共享主机）
- [ ] 安装并正确配置了页面缓存插件（只装一个）
- [ ] 购物车/结账/个人账户页面已排除在缓存之外
- [ ] 开启了 Redis 对象缓存（WooCommerce 站强烈建议）
- [ ] 所有上传图片使用 WebP 格式并已压缩
- [ ] 已开启图片懒加载
- [ ] 接入了 Cloudflare CDN 并开启 Brotli 和 Auto Minify
- [ ] 删除了未使用的第三方脚本
- [ ] CSS 和 JS 做了压缩和延迟加载（测试无样式问题）
- [ ] 减少了字体种类和字重
- [ ] 定期清理数据库（修订版本、草稿、Session）
- [ ] 使用了 PHP 8.3 或当时最新受支持版本
- [ ] 使用 PageSpeed Insights 和 GTmetrix 测试确认关键指标达标
- [ ] 在 Google Search Console 确认 Core Web Vitals 状态
速度优化不是一次性任务，而是持续监测和调整的过程。随着网站内容增多、插件更新、流量增长，性能状态会发生变化，每隔几个月用 Google Search Console 和 GTmetrix 检查一遍，发现问题及时处理，比等出了问题才补救要省力很多。