8 月 17 日，奶爸接了一个 WordPress + WooCommerce B2C 电商网站的 PageSpeed Insights 评分优化工作。

这个网站优化之前使用 Google PageSpeed Insights 测试：

• 移动端：45 分左右
• 电脑端：56 分左右

对于一个正在实际运营的 WooCommerce 网站来说，这个成绩确实还有比较大的优化空间。

不过实际开始处理以后，我发现这个网站的问题并不是简单安装一个“WordPress 加速插件”就能够解决的。

从服务器环境、WordPress 插件、缓存，到商业主题的 CSS 和字体加载方式，再到 Elementor 页面结构和 Cloudflare 配置，基本每一层都存在一些可以优化的地方。

最终完成优化后：

• 移动端平均大约 60～70 分
• 电脑端平均稳定在 90 分以上

这篇文章就完整记录一下这次网站速度优化的过程。

一、网站优化前的基本情况

客户网站使用的是比较典型的 WordPress 外贸 B2C 电商架构：

• WordPress
• WooCommerce
• Elementor
• Blonwe 商业主题
• 阿里云 ECS
• 4 核 CPU
• 8GB 内存
• 10 Mbps 公网带宽
• Cloudflare CDN

单纯看服务器配置已经很不错了，唯一的短板就是服务器带宽太小，10 Mbps公网最高下载速度才1兆多，碰到一张几兆大小的图就可以让你等两三秒时间，只不过接入了Cloudflare CDN，短板没有那么明显。

客户的服务器要27年4月份才到期，不可能一上来就让用户换服务器，对于 WordPress 网站来说，服务器性能只是一方面，网站本身做的怎么样、服务器设置是否合理，也会影响评分的高低。

所以我们需要一步一步的排查每一个可能影响速度和评分的方面。

二、第一步：服务器从宝塔切换到 WP Panel

客户原来的服务器使用宝塔面板。我做的第一件事情就是把服务器重装，换成了针对WordPress网站开发的WP Panel面板。

WP Panel是融合了奶爸这么多年使用WordPress建站的经验而开发的服务器管理面板，相对于比较通用的服务器面板，它的功能会更加偏向 WordPress。

例如可以直接开启：

• Nginx FastCGI 缓存；
• 数据库缓存；
• WordPress 相关优化；
• WordPress 安全防护规则。

对于普通用户来说，不需要自己去研究复杂的 Nginx 配置文件，基本通过面板操作就可以完成。

截至本文发布时，客户这台服务器的WP Panel安全规则已经自动帮我们拦截了几十个恶意IP。

上面截图中判定为404泛滥检测而拦截的记录，基本上都是机器人在批量扫描网站的漏洞，这种通常是一分钟扫描几十次服务器的文件，导致服务器CPU飙升，如果你服务器CPU资源经常100%占用，那么多半就是碰到机器人扫描的情况了。

如果你也打算迁移到WP Panel面板，可以参考：如何将WordPress网站从宝塔面板搬家到WP Panel

需要说明的是：

更换服务器面板并不会明显的提升 PageSpeed 评分。更换为WP Panel纯粹是因为它更加适合WordPress网站站点，带有自动安全规则帮用户拦截恶意请求，同时内置了Nginx FastCGI 缓存和数据库缓存功能，支持一键开启。

这个客户的网站最初没有任何缓存优化插件。所以奶爸选择使用WP Panel从服务器端做的Nginx FastCGI缓存优化。

三、第二步：精简 WordPress 插件

这个网站优化之前一共启用了 26 个 WordPress 插件。

26 个插件本身并不能直接说明网站一定很慢。需要根据实际情况分析这个插件是否在前台使用，有没有功能可以取舍或者使用代码实现的，有没有功能冲突的插件。

有些插件虽然功能复杂，但是只在 WordPress 后台运行，对前台速度影响很小；反过来，有些看起来很简单的插件，却可能在每个页面加载额外的 CSS、JavaScript 或第三方请求。

经过排查，首先移除了Chatway Live Chat 这个使用频率很低的在线聊天插件，这种插件通常都会在前台加载很多的js和css文件，而且本身中国和美国都有时差，在线聊天的实用性并不是很高。

然后是将Google广告、Facebook广告等代码管理插件进行了清理，改为直接子主题代码插入的方式。客户之前同样的功能插件安装了4个，所以是严重的功能重复。

同时停用了Wordfence防火墙插件。

可能有的用户会惊讶，为什么你要停用安全插件？

根据奶爸的经验来看，网站真的中毒了，Wordfence并没有实际作用，奶爸之前亲手给人处理过安装Wordfence网站依然中毒且扫描不出来病毒的案例。同时WP Panel的安全规则已经做了必要的防护规则，除非是网站本身插件或者主题的代码漏洞被精准利用，不然多数机器人都会被拦截在扫描阶段。

而且这种安全插件因为功能比较多，服务器资源占用也是相当可观的，删除后网站会更轻快。

当然，并不是说使用WP Panel网站就一定不会中毒，网站不要使用破解资源，保持WP核心、插件、主题的更新，加上复杂的账号密码，配合WP Panel现有防护规则，网站被攻破的几率会比较低。

四、第三步：增加数据库缓存和 Nginx FastCGI 缓存

清理完不必要的插件后，就是新增优化插件，最开始这网站一个优化插件都没有，所以我直接在WP Panel面板后台开启了Nginx FastCGI 页面缓存，并且启用了Redis Object Cache缓存。

当然，最后优化完毕还装了Autoptimize插件来合并css文件，装了Debloat来延迟加载js文件。

FastCGI 缓存有什么作用？

WordPress 本质上是一个动态程序。

正常访问一个 WordPress 页面，大致需要经过：

浏览器请求 → Nginx → PHP → WordPress → 数据库 → PHP 生成 HTML → 返回浏览器

如果是没有频繁变化的页面，每次访问都重新执行整套 PHP 和数据库流程，其实会产生很多重复计算。

开启 FastCGI 缓存之后，对于符合缓存条件的页面，Nginx 可以直接返回之前生成好的页面内容。

也就是说：

很多访问甚至不需要再次进入 PHP 和 WordPress。

这对于文章页、产品页以及大部分游客访问页面都会比较有帮助。

不过 WooCommerce 和普通博客不同。

购物车、结账、用户登录状态等页面存在动态数据，因此缓存策略不能简单粗暴地把整个网站全部缓存。

WP Panel的配置文件默认已经考虑到了B2C场景的缓存，不需要用户手动处理。

五、真正的大头：Blonwe主题代码优化

服务器和缓存优化完成以后，后面才是这次项目真正比较麻烦的部分。

客户网站之前的建站公司使用的是 Blonwe 商业主题。

检查以后，我发现主题当前版本已经和最新版本相差了几个版本，但是网站后台无法正常更新。

从现有情况来看，之前建站公司可能没有购买正版授权，或者虽然购买了正版，但是没有把可更新的授权配置交付给客户。

联系过建站公司那边更新，不过截止奶爸优化完毕都还没更新，呵呵。

Elementor Pro 也存在类似的问题：

后台虽然显示已经授权，但是无法更新。

因为我自己有正版 Elementor Pro（优惠购买），所以这次直接把 Elementor Pro 更新到了当前可用版本。（为什么要更新呢？因为Elementor Pro和免费版通常都是同步更新的，两个的版本相差太多，可能会造成功能不可用或者兼容性问题）

但 Blonwe 主题没有办法直接更新，只能基于客户正在使用的当前版本进行优化。

这也是大家在找建站公司建站时需要确认的一点：

网站使用到的资源是正版还是破解版？网站交付以后，主题和插件授权归不归客户？后续还能不能正常更新？

如果网站准备长期运营，尤其是 WooCommerce 商城，我认为这一点非常重要。

六、这个主题最大的坑：把字体 Base64 写进 CSS

服务器、插件、缓存都优化了，评分还上不去，进一步排查就到了主题代码头上。这个主题把字体文件通过 Base64 的形式直接写进了 CSS 文件，导致一直拖累LCP评分。

这样操作意味着本来只需要加载css的地方，非要一起加载一个字体文件。本来几十k的内容搞成几百k，属于性能负优化。

我通过子主题把CSS和字体文件给拆分开了。这样浏览器就可以分别处理 CSS 和字体加载，而不是下载 CSS 时被迫把一大段字体数据一起下载下来。

为什么使用子主题修改？

因为客户正在使用商业主题。

如果直接修改父主题：

wp-content/themes/blonwe/

以后只要主题能够恢复更新，一升级，修改内容就可能全部被覆盖。

所以这种针对主题代码的修改，用子主题来修改是比较合理的做法。

七、重新优化 Elementor 页面结构

除了主题代码，这个网站另外一个比较明显的问题就是：

页面结构太复杂。

Elementor 本身并不代表网站一定慢。

很多时候真正的问题是，建站时为了实现一个很简单的视觉效果，却堆了大量：

• Section；
• Container；
• Column；
• Widget；
• 嵌套容器。

页面一层套一层以后，最终生成出来的 HTML DOM 会非常复杂。

浏览器不仅需要解析更多 HTML，CSS 选择器匹配、页面布局计算和重新渲染也都会变得更加复杂。

所以这次我把一部分比较复杂的页面结构重新进行了精简。

八、Hero首屏模块直接重新设计

首页 Hero 是这次重点处理的模块之一。

原来的 Hero 结构比较复杂，而且实际测试下来也会影响页面首屏加载和布局稳定性。

因为之前Hero是使用主题自带的元素设计的，没办法进行调整，所以我直接使用 Elementor 自带的基础功能重新设计这个 Hero。

这样做的好处是：

• DOM 层级减少；
• 不再依赖原来复杂的主题组件；
• 图片和文字结构更容易控制；
• CSS 更容易管理；
• 后续客户自己修改内容也更方便。

上图中左侧是原来的Hero结构，右侧是奶爸重新使用Elementor自带元素设计的Hero结构。

最初可以看到Text Grid这个元素是主题自带的，它上面一共有3层容器，实际上只需要一层容器就行了。而奶爸将另外两个容器删除后测试评分，依然没有什么提升。这是因为本身Text Grid这个组件比较复杂，所以采用了右边的Elementor原生结构设计，修改后评分明显提升。

这也是奶爸为什么在Elementor教程里面推荐大家尽量不要安装太多Elementor扩展的原因，新手自己做网站实现不了的效果就用插件来组合，最后一个页面使用了好几个Elementor扩展，导致页面臃肿，最后怪Elementor垃圾，速度慢。

如果一个简单的首屏，需要十几层 DOM 和大量 JavaScript 才能实现，那么后期再怎么压缩 CSS、延迟 JS，本质上也只是在弥补前期结构上的问题。

九、跑马灯模块改成纯代码实现

网站另外还有一个跑马灯切换模块。

原来的实现方式同样比较复杂。

这类功能本身其实并不需要一个庞大的 Elementor 小工具或者主题组件才能完成，所以最后我直接改成了简单的代码实现。

对于 WordPress 页面设计，我一般会在两个方向之间做取舍：

客户以后需要频繁修改的内容：

尽量使用 Elementor。

基本不会修改，而且功能非常简单的效果：

可以考虑用少量 HTML / CSS / JavaScript 实现。

这样既方便维护，也可以减少不必要的前端资源。

不是所有东西都应该自己写代码，也不是所有东西都一定要塞进 Elementor。现在AI很厉害，一些简单的效果你都可以借助AI帮你生成html代码然后插入到Elementor页面里，不是非要借助插件来实现，插件意味着你因为一个功能可能要引入多个你用不到的资源，最终导致网页加载缓慢。

十、Cloudflare配置错误也会拖累WooCommerce

到这里实际上优化效果已经基本上到顶了，电脑端已经稳定在了90分以上，移动端想要再往上提分，需要首页所有设计大概，最根本的是更换一个轻量的主题，这明显是扩大化修改了，不符合当前情况。

不过最后检查时奶爸发现游客状态网站没有什么控制台报错，登录用户的控制台出现十几个503错误，这些都是js报错。

最开始我以为是因为禁用插件导致了什么bug，恢复插件问题依旧。

以为是优化哪里出了问题，在测试服务器上恢复了优化前的备份数据，问题依旧。

检查实际js文件，真实存在。

所以这个问题并不是因为我们优化产生的，而是一开始就存在。

最后排查我发现是客户的Cloudflare 配置存在问题。

不知道是用户自己配置还是之前建站公司配置，无脑的把Cloudflare推荐配置都开启，导致的本次503错误。

重新调整 Cloudflare 配置之后，相关 503 错误消失。

这也是为什么奶爸一般不愿意接WordPress速度优化，一个完整网站的访问链路太长，如果网站不是你自己经手制作的，你不知道哪个环节可能给你埋了坑，任何一层配置异常，都可能最终表现成“WordPress 网站很慢”。

十一、最终PageSpeed Insights优化结果

所有优化完成以后，再次使用 Google PageSpeed Insights 测试。

最终成绩大约为：

因为 PageSpeed Insights 的实验室测试成绩每次都可能存在波动，所以我连续测试几次，多次测试后平均结果电脑端都是90分以上，移动端在60多70多之间变化，网站整体的评分比优化前还是有明显的提升。

十二、这次优化真正起作用的是什么？

这次这个WordPress网站的PageSpeed Insights评分优化，起作用的并不是某一点，而是多个修改的结合。

1. 服务器运行环境

从宝塔切换到更加偏向 WordPress 使用场景的 WP Panel，同时配置缓存。

2. 清理无效插件

不是单纯减少插件数量，而是删除不用的插件和重复功能。

3. FastCGI 和数据库缓存

减少重复 PHP 运算和数据库请求。

4. 主题代码

处理不合理的 CSS 和字体加载方式。

5. Elementor页面结构

减少不必要的嵌套和复杂 DOM。

6. 重做性能较差的模块

例如 Hero 不继续打补丁，而是直接重新设计。

7. 简单功能简单实现

跑马灯等不需要复杂组件的效果，通过轻量代码实现。

8. 排查Cloudflare

解决 CDN 配置导致的 WooCommerce 请求异常。

这几个环节缺少任何一个，最终效果可能都会打折扣。

十三、WordPress速度优化不能只看PageSpeed分数

最后奶爸还是重申一下自己的观点。

PageSpeed Insights 分数很重要，但它不是 WordPress 网站速度优化的全部。

为了得到一个漂亮的测试数字，可以使用很多非常激进的方法，比如：

• 延迟大量 JavaScript；
• 删除 CSS；
• 强行延迟第三方脚本；
• 对所有页面进行缓存。

甚至更简单一点，你网站首页只放纯文字内容，这样做你可以轻轻松松拿双百分。

但是过分激进的优化可能会出现：

• WooCommerce 加购失效；
• 结账页面异常；
• 登录用户看到错误缓存；
• Elementor 动画无法运行；
• 页面第一次点击没有反应；

那么测试分数再高也没有意义。

尤其是 B2C 电商网站，网站首先要保证：

商品浏览、加入购物车、用户登录和结账流程正常。

然后再尽可能优化性能。

对于PageSpeed Insights的评分，奶爸认为只要不是低的过分，能过及格线，然后让国外的用户帮你真机测试，打开网站速度不慢，那么你的重心就应该放到网站运营上，而不是PageSpeed Insights评分优化上。

十四、不要迷信“装一个插件就100分”

如果你在网上搜索WordPress速度优化，增加PageSpeed Insights评分，大概率会碰到推荐WP Rocket这款付费插件。

奶爸之前也用过WP Rocket优化网站，优化效果确实不错，但是并不是说用其他免费插件就不能达到的地步。只是说WP Rocket使用更简单一些。

但对于：

WooCommerce + Elementor + 商业主题

这种组合，真实的网站通常要复杂得多，这次客户网站就是一个很典型的例子：

服务器缓存只是其中一部分，后面真正花时间的反而是：

• 商业主题；
• 字体；
• CSS；
• Elementor；
• 页面结构；
• Cloudflare。

所以如果你的 WordPress 网站 PageSpeed 分数比较低，我更建议先搞清楚：

到底是什么东西拖慢了网站？

然后针对问题优化。

而不是看到评分低，就继续安装下一个“加速插件”。

总结

这次 WooCommerce 网站优化前的 PageSpeed Insights 大约只有：

移动端 45 分、电脑端 56 分。

经过服务器环境、WordPress 插件、FastCGI 缓存、数据库缓存、主题 CSS 与字体、Elementor 页面结构、Hero 模块和 Cloudflare 等一系列优化以后：

移动端平均可以达到 60～70 分，电脑端平均达到 90 分以上。

奶爸希望可以通过我对这次网站优化的实操过程，让你可以了解WordPress 网站速度优化本质上是一个排查问题的过程。

服务器有服务器的问题，插件有插件的问题，主题有主题的问题，页面设计也可能有页面设计的问题。

找到真正的瓶颈，再把这些问题一个一个解决，往往比不停安装所谓的 WordPress 加速插件更有效。