按问题类型解析最佳 WordPress 性能插件

要点：

• 最佳的 WordPress® 性能插件，是能解决你网站实际瓶颈的插件。先测试有代表性的页面，以确定主机托管、缓存、前端资源、图片还是数据库工作拖慢了网站。
• 如果你希望获得自动化、基于云端的性能优化，NitroPack 是最强大的全能型选择。它集成了缓存、CDN 分发、代码优化、Critical CSS 和图片优化。
• 你的托管环境决定了哪些缓存工具有意义。WP Engine 等托管平台提供内置的服务器级缓存。LiteSpeed Cache 在使用 LiteSpeed 缓存基础设施时最具优势。
• Perfmatters 和 Autoptimize 等专业插件应当填补缺口，而不是重复你已经拥有的功能。
• 当 WordPress® 仍需动态生成页面时，Advanced Custom Fields 有助于保持内容层高效。合理的字段设计、Local JSON、恰当的元数据查询以及合适的扩展策略，可以补充缓存和性能插件带来的交付改进。

最佳的 WordPress®¹ 性能插件，取决于究竟是什么拖慢了你的网站。

缓存插件可以大幅减少再次访问页面时所需的工作，但它无法解决图片过大、不必要的 JavaScript、低效的数据库查询或糟糕的托管环境。同样，安装一体化优化插件并不意味着网站的每一层都得到了有效优化。WordPress® 性能来自多个相互作用的层面，包括基础设施、缓存、前端资源，以及底层的内容和数据模型。

因此，本指南按问题类型而非受欢迎程度来整理 WordPress® 性能插件。指南还将探讨脚本管理、图片优化、数据库清理，以及当 WordPress® 仍需动态生成页面时，内容架构所发挥的作用。

安装任何插件前，先诊断瓶颈

安装 WordPress® 性能插件前，应建立基准并确定究竟是哪一层较慢。否则，你可能会去优化一个原本就不是问题根源的环节。

从多种有代表性的页面类型开始测试，而不只是首页，测试工具包括： 

• PageSpeed Insights，它将来自真实 Chrome 用户的 Chrome 用户体验报告（CrUX）现场数据（在数据量足够时）与 Lighthouse 实验室测试结合在一起。 
• WebPageTest，它适合用于受控测试，因为你可以保持位置、浏览器和连接等变量不变，并多次运行测试。

然后逐一排查五个问题：

• 托管层是否难以应对？ 查看服务器响应时间，并在假定插件能够解决问题之前，对比已缓存与未缓存的请求。
• WordPress® 是否在不必要地重新生成页面？ 如果重复请求仍会执行 PHP 和数据库工作，请调查整页缓存。
• 脚本和样式是否加载在不需要它们的地方？ 过多的 JavaScript 和 CSS 表明需要优化资源或管理脚本。
• 图片是否不必要地过大？ 检查压缩情况、尺寸，以及是否正在提供现代格式。
• WordPress® 是否执行了过多数据库工作？ 未缓存请求缓慢可能源于低效查询、过多元数据、自动加载的选项或其他应用层工作。

尽管 TTFB 不是核心网页指标，而且 TTFB 较高并不能自动证明你的主机速度较慢，但 web.dev 建议将 800 毫秒或更低作为大致参考标准。请注意，重定向、DNS 查询、连接建立、网络延迟、地理距离和后端处理都可能导致 TTFB 升高。

在可行的情况下，还应使用响应头或你的主机/CDN 工具，对比已确认的缓存 HIT 和 MISS 请求。这一区分有助于将缓存交付的性能与动态生成页面的成本分开来看。

主机在这里很重要，因为它决定了 WordPress® 可用的基础设施和缓存层。例如，在 WP Engine 等托管主机上，服务端 Varnish 缓存和可选的边缘全页缓存均已内置。

这里的目标是先找出速度较慢的层，然后选择能够解决该问题的最小干预措施。

服务器级缓存与 LiteSpeed 问题

LiteSpeed Cache 是安装量最广泛的 WordPress® 性能插件之一，拥有 700 多万次活跃安装，但它是否是正确的缓存插件，很大程度上取决于你的托管技术栈。

重要的区别在于，WordPress® 插件本身并不执行 LiteSpeed 全页缓存。它与 LiteSpeed 的服务器级缓存引擎通信，由该引擎存储和提供缓存页面。当请求的页面尚未缓存时，请求可以继续传递给 WordPress®，由 PHP 和应用程序生成响应。一旦符合条件的响应被缓存，后续缓存命中即可由缓存引擎提供，无需 WordPress® 再次生成页面。

要获得这种页面缓存功能，需要使用受支持的 LiteSpeed 组件，例如带 LSCache 的 LiteSpeed Web Server、OpenLiteSpeed、LiteSpeed Web ADC 和 QUIC.cloud CDN。

该插件仍可在 Apache、Nginx 和其他 Web 服务器上运行，但如果不配备上述 LiteSpeed 缓存组件之一，其服务器级页面缓存将无法使用。不依赖缓存引擎的功能，包括 CSS 和 JavaScript 优化、延迟加载、数据库优化、对象缓存集成以及其他页面优化，仍可使用。

QUIC.cloud 会略微改变这一情况。由于其 CDN 在边缘提供 LiteSpeed 缓存，即使源服务器本身运行 Apache、Nginx 或其他服务器，它也可以启用 LiteSpeed Cache 的页面缓存功能。

选择 LiteSpeed Cache 之前，请检查你的主机实际运行的是什么。你也可以在浏览器的 Network 面板中测试一个未登录且可缓存的页面。首次请求可能返回 X-LiteSpeed-Cache: miss，在响应被缓存后刷新一次，随后便会返回 X-LiteSpeed-Cache: hit。LiteSpeed Web ADC 可能会公开 X-LSADC-Cache，而 QUIC.cloud 可能会公开 X-QC-Cache。

使用 NitroPack 及替代方案进行一体化优化

一体化性能工具将原本需要多个独立插件才能完成的多项工作整合在一起，包括页面缓存、CSS 和 JavaScript 优化、延迟加载，以及在某些情况下提供图像优化和 CDN 交付。主要区别在于，每款产品能代你处理其中多少工作，以及处理过程在哪里进行。

传统的“云端与自托管”之分已不再完全准确：

• NitroPack 的本质是基于云端的，在 NitroPack 基础设施上执行优化，从而减少 WordPress® 服务器的处理开销。 
• WP Rocket 将常规页面缓存以静态 HTML 的形式存储在站点服务器上，但删除未使用的 CSS 等功能依赖 WP Rocket 的外部服务。FlyingPress 同样在本地存储页面缓存。
• FlyingPress 使用基于云的浏览器分析进行高级页面优化，并使用云基础设施进行图片处理。

这使得关键 CSS 成为另一个有价值的比较项目。关键 CSS 会提取渲染首屏内容所需的样式，并直接将其放入 HTML 中，这样浏览器就无需等待站点的完整样式表加载完毕后再渲染这些内容。它可以提升渲染性能，但激进的 CSS 优化也可能破坏动态元素或初始隐藏元素，因此在大范围部署前，应在有代表性的模板上进行测试。

NitroPack

NitroPack 最适合希望将大多数 WordPress® 性能工作（如缓存、图片优化和 CDN）整合为一项云服务的团队。当减少配置工作以及单独优化插件的数量比避免按使用量计费更重要时，它尤其有吸引力。 

下一节介绍的 HTTP Archive 对比数据也将 NitroPack 列为该组中实际 Core Web Vitals 通过率最高或接近最高的选项之一。 

在大多数符合条件的 WP Engine Shared 和 Premium 套餐中，也可将 NitroPack 作为付费产品扩展直接使用。WP Engine 建议先在开发或预发布环境中进行测试，再在生产环境中启用。

其免费套餐每月最多包含 1,000 次页面浏览和 1GB 的 CDN 流量，付费套餐则提供更高的页面浏览量和 CDN 配额。所有套餐均内置 CDN，并提供缓存和前端优化。图片压缩、WebP 转换、延迟加载、关键 CSS 和代码优化均为内置功能。

WP Rocket

如果你希望采用可预测的年度许可费用，而不是按页面浏览量计费，并且更希望对各项优化进行精细控制，这款插件很适合你。激活后，它会自动应用一系列优化，包括缓存和多项前端改进。删除未使用的 CSS、延迟 JavaScript 执行以及其他资源加载调整等高级选项，仍需针对各个站点进行评估和配置。

它也设计为可与托管主机服务协同运行。例如在 WP Engine 上，WP Rocket 会检测该平台并停用功能重叠的缓存行为，同时保留兼容的前端优化。

单个站点价格为每年 $59，三个站点为每年 $119，50 个站点为每年 $299，并提供 14 天退款保证。

FlyingPress

对于希望采用固定年度价格、拥有丰富控制选项，并且内置现代优化功能，同时不依赖 LiteSpeed 服务器缓存的团队来说，这是一个有力替代方案。它适用于各种托管服务商和服务器技术栈，包括 Apache 和 Nginx。其功能集现已涵盖页面缓存、关键 CSS 和未使用 CSS 优化、脚本延迟、数据库优化、真实用户 Core Web Vitals 监控，以及内置图片优化并支持 WebP 或 AVIF 输出。图片处理在 FlyingPress 的云服务器上进行，优化后的文件则会返回并存入 WordPress® 上传目录。

当无法使用 LiteSpeed Cache 的服务器级缓存，但你仍希望使用一款具备精细控制选项且许可费用可预测的单一性能插件时，FlyingPress 就显得尤其合适。

当前定价为单个站点 $59/年、三个站点 $109、25 个站点 $229，以及不限站点 $279。此外，所有方案均可使用 14 天免费试用进行测试。

HTTP Archive 数据对插件性能有何启示

在 HTTP Archive 的真实世界 CrUX 数据中，NitroPack（54%）在所测插件中取得了最高的 Core Web Vitals 通过率。

HTTP Archive 数据为插件对比提供了一个有用的真实世界视角，因为它将技术检测与来自数百万个网站的 CrUX 实测数据结合在一起。以下是其他插件的得分：

NitroPack 在此次比较中领先，不过这些数字来自观察性实测数据，而非受控插件基准测试。请注意，更高的通过率表明其与这些站点良好的 Core Web Vitals 存在关联，并不意味着安装该插件就会自动产生这一结果。

当访问量的第 75 百分位满足以下条件时，Google 认为 Core Web Vitals 表现良好：

• 最大内容绘制（LCP）不超过 2.5 秒。
• 下一次绘制交互（INP）不超过 200 毫秒。
• 累积布局偏移（CLS）不超过 0.1。

此外，测试更改时请牢记实验室数据与实测数据之间的区别。PageSpeed Insights 可以立即显示新的 Lighthouse 实验室结果，而其 CrUX 实测数据反映的是滚动 28 天周期内的数据，并会随着新访问取代旧访问而逐渐变化。启动 Core Web Vitals 修复验证时，Search Console 还会将类似的网址归为一组，并使用单独的 28 天验证周期。

为什么同时运行两个缓存插件可能破坏你的站点

当两个缓存插件都试图控制同一缓存层时，会破坏 WordPress® 站点。 

浏览器缓存、CDN 或边缘缓存整页缓存以及持久对象缓存可以共存。当两个插件试图控制同一缓存层时，问题就开始出现。例如，两个整页缓存插件可能都会管理缓存的 HTML、重写规则、缓存清除行为以及 WordPress® 的 advanced-cache.php 丢弃文件。WordPress® 只会加载一个 advanced-cache.php 文件，因此重叠的实现可能相互干扰，而不是提供双倍缓存。

结果可能包括页面过期、缓存清除不一致、资源过时，或页面行为不符合预期。

托管主机还增加了另一个需要考虑的因素，因为主机可能已经提供页面缓存。WP Engine 使用服务器端 Varnish 缓存，还可以通过其 CDN 提供边缘整页缓存。它明确禁止使用 W3 Total Cache 和 WP File Cache，因为它们会与其内置缓存架构发生冲突。

更好的模式是让每个工具承担明确的职责。例如， 

• 使用 WP Rocket 进行性能优化。
• 使用 Perfmatters 进行精细脚本管理。
• 在禁用重叠功能并正确配置缓存清除的情况下，Imagify 可用于处理图片，并能与上述方案互补。

或者，可以使用 NitroPack 这样的一体化服务，将其中许多任务整合到一个系统中。

使用 Perfmatters 和 Autoptimize 管理代码膨胀与脚本

缓存可以减少交付页面所需的工作，而脚本管理则能减少浏览器最初需要下载、解析和执行的 CSS 与 JavaScript 数量。两者解决的是不同问题，可以协同使用。 

如果你的主机或现有插件已经很好地处理了页面缓存，那么剩下的问题可能只是前端代码过多。这正是专业插件发挥作用的地方。

• Perfmatters 主要适用于你需要精细控制资源加载位置的情况。其 Script Manager 可以在不需要特定 CSS 和 JavaScript 文件的页面上禁用它们。这对于插件较多的站点很有价值，因为电子商务、表单、分析工具或其他功能可能会给网站的大部分区域增加浏览器负担。减少不必要的 JavaScript 还可以通过降低浏览器主线程上的工作量来改善 INP。价格从单个站点每年 $29.95 起，三个站点 $59.95，或不限站点数 $124.95。
• Autoptimize 更适合已经在其他地方处理了缓存，但仍需要更广泛前端优化的站点。其免费版可以压缩和优化 CSS、JavaScript、HTML 和 Google Fonts，但不提供整页缓存。

这些工具可以补充缓存解决方案，而不是取而代之。例如，当你希望使用 WP Rocket 的缓存和广泛优化，同时使用 Perfmatters 进行更精细的资源级控制时，WP Rocket 加 Perfmatters 再加 CDN 的组合是合理的。 

NitroPack 采用了另一种思路，将许多此类优化整合到一项服务中。

图像和数据库优化，以及你是否仍需单独的工具

在添加图像或数据库插件之前，请先检查现有性能工具栈已经处理了哪些内容。例如：

• NitroPack 已经会压缩图像、将其转换为 WebP、进行延迟加载，并通过其 CDN 提供优化后的版本，因此大多数 NitroPack 站点都不需要另一个图像优化工具。
• WP Rocket 则有所不同。它可以优化图像的加载方式，但不会压缩图像文件，也不会生成 WebP 或 AVIF 版本。当需要这些功能时，WP Rocket 建议与 Imagify 等图像优化工具配合使用。
• LiteSpeed Cache 可以通过 QUIC.cloud 压缩图像并生成 WebP 或 AVIF。图像优化需要使用 QUIC.cloud 服务，而且 LiteSpeed 明确建议不要在运行其自身服务的同时再使用另一个图像优化工具。

数据库优化遵循同样的规则——不要仅仅因为你有 WordPress® 数据库就安装 WP-Optimize。WP Rocket 和 LiteSpeed Cache 已经包含数据库清理功能，而当现有工具栈缺少你所需的控制选项时，WP-Optimize 就会很有用。它可以删除修订版本、回收站内容、垃圾信息、过期瞬态和其他不必要的记录，还可以优化选定的数据库表。

在进行破坏性数据库清理之前，务必先备份。更重要的是，清理并不等同于数据库性能工程。删除旧记录可能减少数据库膨胀，但无法解决低效查询、设计不当的元数据查询或自动加载选项过多的问题。这些问题需要性能分析，并在应用层或内容建模层进行更改。

你的内容层和缓存层如何协同工作

缓存可以提高 WordPress® 交付内容的效率，但它无法取代底层高效的内容模型。

以下是整页缓存与持久对象缓存之间的区别：

• 整页缓存会存储生成的 HTML，因此符合条件的请求无需通过 WordPress® 和 PHP 重新构建页面即可得到响应。但缓存未命中以及许多动态请求（包括登录后的体验和管理后台的部分内容）出现时，WordPress® 仍会执行。此时，组装页面所需的数据库查询就再次变得重要。
• 持久对象缓存解决的是另一个问题。Redis 等系统可以在请求之间保留可重复使用的 WordPress® 对象，从而在 WordPress® 确实执行时减少重复的数据库工作。它仍无法重写效率低下的查询，也无法修复设计不良的数据模型。

这就是为什么内容架构应纳入性能讨论。无论网站使用自定义字段、页面构建器、自定义文章类型还是其他建模方式，结构化内容都不可避免地会引入数据检索工作。真正的问题是，随着网站规模扩大，这些数据能否仍被高效检索。

对于使用 Advanced Custom Fields (ACF®) 的文章，字段值默认通过 WordPress® 的元数据系统存储，通常存放在 wp_postmeta 中。这对许多网站效果良好，但对于非常大的数据集或查询密集型架构，可能需要更谨慎的查询设计或替代存储策略。

ACF 还可以通过 Local JSON 减少配置开销。字段组、文章类型、分类法和 Options Page 定义可保存为 JSON 文件并从文件系统加载，而不必每次都从数据库中检索。Local JSON 还可以让这些定义纳入版本控制，并更易于在不同环境之间同步。

对于规模更大、流量更高的构建项目以及更复杂的内容模型，ACF PRO 增加了字段和工作流，让结构化内容更容易大规模构建和维护，其中包括 Repeater、Flexible Content 和 ACF Blocks。

目前有超过 200 万个网站使用 ACF，因此这些考量远不只对小型 WordPress® 构建项目有意义。你的性能插件负责交付层，而 ACF 则让你能够控制底层的结构化内容层。

立即使用 ACF 构建可扩展的内容层。

文章《按问题类型分类的最佳 WordPress 性能插件》最初发布于 ACF。