跳到正文
原文
Advanced Custom Fields 官方博客· Iain Poulson·· 13 天前编辑评分27

WooCommerce 商店最安全的缓存插件

Safest Caching Plugin for WooCommerce Stores

编辑导读

NitroPack 被评为最适合多数 WooCommerce 商店的一体化性能优化方案,可自动排除 Cart、Checkout、My Account,并提供付费 Cart Cache。其整合缓存、前端优化、图片优化和 CDN 交付;使用前应先检查主机已有缓存,必要时再搭配 Redis 或 Memcached。

要点:

  • 最安全的 WooCommerce® 缓存配置会确保面向客户特定的内容保持动态。购物车结账、我的账户、会话数据及其他个性化响应绝不应通过共享页面缓存提供。
  • NitroPack 是适用于 WooCommerce 商店的一体化网站性能优化解决方案,因为它结合了缓存、前端优化、图像优化和 CDN 分发,同时会自动排除购物车、结账和我的账户页面,并提供购物车缓存。
  • 在添加另一层页面缓存之前,请检查您的主机提供商。在 WP Engine 上,EverCache® 已提供支持 WooCommerce 的页面缓存,而 NitroPack 插件则在这一基础上扩展了更广泛的前端性能优化,无需再安装另一个独立缓存插件。
  • 当动态请求反复执行数据库操作时,持久对象缓存对 WooCommerce 最为有用。Redis 或 Memcached 可以帮助优化已登录、结账、会员、个性化和元数据密集型 WooCommerce 使用体验,但并非每家商店都需要。
  • 高级自定义字段(ACF®)是一种 WordPress® 内容建模解决方案,使开发者能够在制定缓存策略的同时,构建和管理自定义的 WooCommerce 产品数据。Local JSON、重复字段分页、缓存失效钩子以及 ACF PRO 字段类型等功能,可以支持规模更大且更易维护的商店。

为 WooCommerce® 商店添加缓存比缓存典型的 WordPress®1 网站更复杂,因为部分店面内容可以在访客之间安全共享,而其他页面和数据则因每位购物者而异。

如果未把握好这种平衡,客户可能会在购买过程中看到过时的购物车内容、过期价格或其他错误的动态信息。最安全的 WooCommerce 缓存插件应能提升店面性能,同时不妨碍必须保持动态的用户体验。

本指南比较了主要的 WooCommerce 缓存选项,介绍了主机级缓存和对象缓存的适用场景,并展示如何在不危及结账功能的情况下测试缓存配置。

WooCommerce 安全缓存绝不能存储什么?

WooCommerce 安全的共享页面缓存绝不能将某位客户的购物车、结账、账户或其他个性化状态提供给另一位购物者。WooCommerce® 要求购物车、结账和我的账户页面位于共享页面缓存之外,因为其内容取决于当前客户和会话。

页面缓存更适合应用于对许多访客而言可以安全地呈现相同内容的 HTML,例如许多产品、分类、落地页和内容页面。复杂之处在于,仅排除 URL 并不足够。安全的缓存层还必须识别 WooCommerce 用于区分购物者的状态。

有三个重要的 WooCommerce Cookie:

  1. woocommerce_cart_hash,用于帮助 WooCommerce 检测购物车内容的变化。
  2. woocommerce_items_in_cart,表示购物者的购物车中有商品。
  3. wp_woocommerce_session_,包含 WooCommerce 用于在数据库中定位该客户购物车数据的唯一标识符。

当存在这些 Cookie 时,缓存层可能需要绕过缓存或改变其行为。WooCommerce 的缓存指南还指出,?add-to-cart= 请求及相关的 WooCommerce API 请求会绕过全页缓存,因为这些请求可能更改或获取动态商店状态。

这就是为什么,仅仅将 /cart/、/checkout/ 和 /my-account/ 添加到排除列表中,并不能构成完整的 WooCommerce 安全测试。自定义定价、会员规则、货币、迷你购物车、主题、扩展及其他个性化功能,都可能引入额外的动态行为,而缓存必须正确处理这些行为。

将页面缓存与动态购物车更新分开也很重要。公开的产品页面仍可通过缓存交付,而客户专属的购物车信息则通过 JavaScript、AJAX 或 API 请求在浏览器中单独更新。目标是让可重复使用的 HTML 保持可缓存,同时确保特定于购物者的状态绝不会泄露到共享响应中。

哪款缓存插件适合你的团队?

对于大多数 WooCommerce 商店而言,NitroPack 是最强大且最安全的解决方案。它将 WooCommerce 感知缓存与更广泛的网站优化相结合,并自动将购物车、结账和我的账户页面排除在缓存之外。 

如果商店需要替代方案,最合适的 WooCommerce 缓存插件取决于它自动提供多少 WooCommerce 专属处理、是否适合你的服务器环境,以及你的团队愿意维护多少缓存配置。

在比较 WooCommerce 缓存插件之前,请先查看主机已经提供了哪些功能。有些主机(如 WP Engine)会在平台层面管理整页缓存,有些主机会限制某些缓存插件,还有一些只与特定的缓存技术集成。未经检查就安装另一层页面缓存,可能会造成缓存冗余或不必要的配置。

检查主机后,如果你仍需要 WooCommerce 缓存插件,可以考虑以下选项:

插件WooCommerce 安全性适用对象主要限制
NitroPack自动排除敏感的 WooCommerce 页面,并提供 Cart Cache,让商品加入购物车后,店面中仍有更多内容可以保持缓存。希望通过一套解决方案处理缓存、前端优化、图片优化和 CDN 分发的 WooCommerce 商店。Cart Cache 是高级功能。
WP Rocket自动排除购物车、结账、我的账户和 WooCommerce REST API 请求。明确需要独立缓存与性能插件的商店。自定义动态内容仍可能需要额外的排除规则。
LiteSpeed Cache自动排除 WooCommerce 核心动态页面,并支持边缘侧包含(ESI)。已在兼容的 LiteSpeed 缓存技术栈上运行的商店。整页缓存功能依赖 LiteSpeed 基础设施,而 OpenLiteSpeed 不支持 ESI。
FlyingPress自动排除核心动态页面,并在产品发生变化时清除相关缓存。希望逐项调整页面缓存和前端优化的团队。自定义购物车行为和激进的 frontend 优化仍需进行测试。
W3 Total Cache提供精细的页面、对象、CDN 和片段缓存(Pro)控制。熟悉围绕商店配置缓存的开发者。更高的灵活性也带来了更多配置不安全的可能性。

NitroPack

NitroPack 是 WooCommerce 网站最强大的解决方案,因为它将缓存与图片优化、Critical CSS 生成、JavaScript 优化和延迟脚本以及内置 CDN 相结合。这样可以减少商店需要配置和维护的独立性能工具数量。

NitroPack 会自动将购物车、结账页和我的账户等敏感的客户专属区域排除在页面缓存之外。其购物车缓存功能更进一步:当购物者购物车中有商品时,它仍会继续提供缓存的店面页面,而不是在后续浏览时禁用缓存。

NitroPack 还能让缓存内容保持最新,而无需不必要地重建整个站点缓存。智能缓存失效会将受影响的缓存内容标记为过期,并在后台准备最新版本,而需要立即显示的更改则可以触发缓存清除。

NitroPack’s homepage.

WP Rocket

WP Rocket 会自动排除购物车、结账页、我的账户和 WooCommerce REST API 请求,从而减少手动配置 WooCommerce 的工作,但自定义店面行为仍可能需要额外的排除规则。

例如,如果某个主题将客户专属的购物车信息直接呈现在缓存的 HTML 中,就可能需要基于 Cookie 的缓存绕过规则。其 WooCommerce 默认设置可以减少配置工作,但并不能取代对自定义主题、定价、会员和个性化功能的测试。

WP Rocket’s homepage.

LiteSpeed Cache

LiteSpeed Cache 将其 WordPress 控制项与底层 LSCache 基础设施相连接,使兼容的 WooCommerce 商店能够自动排除动态页面并使用 ESI,同时这些优势也依赖于托管环境。

ESI 可以将私密片段与原本可缓存的页面分离,但需要 LiteSpeed Web Server Enterprise、LiteSpeed Web ADC 或 QUIC.cloud,无法直接通过 OpenLiteSpeed 使用。

该插件还提供 Redis 和 Memcached 集成,但持久对象缓存服务本身仍与插件分开。

LiteSpeed Cache’s homepage.

FlyingPress

FlyingPress 将自动排除 WooCommerce 页面与在相关产品数据发生变化时清除缓存相结合,但自定义购物车行为及其更广泛的前端优化仍需针对具体商店进行测试。

许多主题可以单独更新购物车信息,而无需更新缓存的 HTML,但直接呈现在页面中的购物车状态可能需要基于 Cookie 的缓存绕过规则。JavaScript 和 CSS 优化可能带来额外的结账兼容性问题,因此仍应针对实际主题和支付技术栈验证自动 WooCommerce 支持。

FlyingPress’s homepage.

W3 Total Cache

W3 Total Cache 对页面缓存、对象缓存、CDN 集成和动态片段(Pro)提供相对精细的控制,但这种灵活性也让开发者承担更多 WooCommerce 安全配置工作。

动态 URL、客户会话和个性化内容需要有针对性地排除或正确处理,而在支持的情况下,可以将 Redis 或 Memcached 配置为持久对象缓存后端。

这种可配置性适合自定义环境,但当团队中无人了解 WooCommerce 的动态页面和会话要求时,也会增加不安全配置的机会。

W3 Total Cache’s homepage.

在安装另一个插件前,请检查你的主机已经缓存了哪些内容

在添加 WooCommerce 缓存插件之前,请先检查你的主机是否已经提供整页缓存或边缘缓存。再添加一层页面缓存可能会造成重复、不受支持,或者当两套系统都试图控制同一响应时更难排查。

例如,WP Engine 已在平台层面应用 WooCommerce 专属缓存规则。当 WP Engine 检测到 WooCommerce 时,它会为相关页面、API 请求、查询参数和 Cookie 添加排除规则。

使用 WP Engine 的 EverCache® for WooCommerce 的商店可以在此基础上进一步扩展该模式,缓存适合缓存的店面页面,同时让结账等客户专属页面保持动态。

WP Engine 还提供 NitroPack 附加服务,在 WP Engine 的 EverCache® 技术之外,带来针对图片、CSS、JavaScript、缓存和内容交付的自动化前端优化。

关键要点是,在安装另一层性能优化之前,先了解你的主机已经缓存了什么。重叠的系统越少,通常意味着需要协调的缓存规则越少,WooCommerce 动态行为可能出错的位置也越少。

商店什么时候需要对象缓存?

当相当一部分流量无法使用整页缓存,并且 WordPress 需要反复使用相同的数据库数据来构建动态响应时,持久对象缓存能让 WooCommerce 商店受益最大。这通常包括:

  • 已登录客户的浏览体验。
  • 购物车和结账请求。
  • “我的账户”页面。
  • 批发、会员或个性化定价商店。
  • 动态流量占比很高的商店。
  • 大量使用 Advanced Custom Fields (ACF®) 的模板,它们会反复访问产品元数据、选项、分类法数据或其他结构化内容。

它与页面缓存的区别很重要。页面缓存存储已经生成的 HTML 响应,因此 WordPress 可能根本不需要运行。对象缓存则存储 WordPress 在构建响应时所需的可复用数据,例如文章、用户、选项、分类术语和元数据。

WordPress 已经内置对象缓存,但默认情况下仅在当前请求期间有效。Redis 或 Memcached 等持久对象缓存后端可让适合缓存的对象在不同请求之间持续存在,从而减少后续动态请求中重复的数据库操作。

对于使用 ACF 驱动的 WooCommerce 网站,这一点也很重要,因为自定义字段值通常存储为 WordPress 元数据。当通过 WordPress 的元数据 API 请求这些值时,底层对象缓存层有助于避免不必要地重复读取数据库。

不过,并非每家 WooCommerce 商店都自动需要持久对象缓存。如果大多数访客都是匿名用户,且其请求已经通过整页缓存高效提供,那么 Redis 带来的提升可能较小。最有力的使用场景是,性能分析显示数据库查询或重复数据检索在动态且未缓存的请求中占用了大量时间。

使用 ACF PRO 高级功能为您的网站提速

借助 ACF Blocks 和选项页面加快工作流并解锁功能,以更好地开发网站,还可使用灵活内容、重复器、 克隆、图库字段及更多功能。

探索功能 查看定价

PRO 功能

ACF Blocks 选项页面

PRO 字段

重复器 灵活内容 图库 克隆

压缩脚本会不会导致结账出现问题?

是的,当 JavaScript 压缩及相关脚本优化改变了购买流程所依赖的脚本、依赖项或执行时机时,可能导致 WooCommerce 结账功能失效。

压缩本身并非天然不安全。WooCommerce 通常建议压缩和优化前端代码,但其缓存指南明确建议在使用 WP Rocket 时避免压缩 JavaScript 文件。

实际风险不仅限于压缩。问题还可能源于:

  • 合并 JavaScript 文件。
  • 推迟执行需要更早运行的脚本。
  • 将 JavaScript 延迟到用户交互时再执行。
  • 更改依赖关系或执行顺序。

当这些优化与 WooCommerce 发生冲突时,商店可能会出现以下问题:加入购物车操作不再更新、小购物车内容过期、结账验证失效、支付或配送界面无法初始化,或者按钮不再响应。

某项设置可能在产品页和分类页上完全正常,却仍然会破坏结账流程,因此每项重要的 JavaScript 更改都应分别以访客和已登录客户的身份进行测试。添加产品、更改购物车数量、在适用时使用优惠券,并完成支付方式初始化及提交订单的整个结账流程。

如果特定脚本导致问题,请仅将相关的 WooCommerce、主题或支付脚本从受影响的优化中排除,而不是禁用所有前端优化。目标是在商店的实际行为证明安全的情况下,才进行积极优化。

如何在不破坏结账流程的情况下测试 WooCommerce 缓存

测试 WooCommerce 缓存时,应针对真实的购物行为进行测试,而不只是关注 PageSpeed 分数或更快的产品页首次字节时间(TTFB)。商店页面看起来加载很快,但仍可能提供过期的购物车状态,或破坏针对特定客户定制的请求。

理想情况下,应先在预发布环境中验证更改,然后在部署后测试相同的路径。WooCommerce 要求购物车、结账和我的账户页面保持动态,因此这些流程应得到特别关注。

至少测试以下内容:

  • 以匿名购物者的身份浏览,并使用空购物车。
  • 添加产品,然后在已缓存的产品页和分类页之间切换。
  • 确认购物车计数器和迷你购物车正确更新。
  • 更改数量、移除产品并使用优惠券。
  • 完成结账流程,包括支付方式初始化和测试订单。
  • 登录并验证我的账户、订单历史记录及退出登录功能。
  • 测试可变产品、库存变化、个性化定价以及商店的其他特定功能。
  • 更新产品,并确认受影响的缓存页面已失效。
  • 启用 JavaScript 延迟、推迟执行、压缩或类似优化后,再次进行测试。

如果可用,还应检查缓存层的 HIT/MISS 或同等响应指标。缓存插件处于启用状态,并不能证明 WooCommerce 排除规则运行正确。

缓存命中和未命中都应进行测试。有些问题只会在响应被缓存后出现,另一些则会在 WordPress 必须重新生成响应时出现。WooCommerce 在当前的缓存工作中强调了这一区别,因为缓存行为和失效机制可能会影响原本完全相同的请求。

最安全的配置,是能够在整个购买流程中保持正确,而不仅仅是生成最快的匿名产品页。

使用 ACF 保持缓存的 WooCommerce 产品数据新鲜

最安全的 WooCommerce 缓存设置并不是缓存最多的设置,而是大力缓存可重复使用的店面内容,同时让购物车、结账、账户及其他客户特定行为保持动态。一旦这些边界划分正确,下一个性能问题就是 WordPress 实际需要构建页面时会发生什么。

ACF 为开发者提供了一种结构化方式,用于建模产品规格、商品营销内容、关系、技术细节及其他自定义 WooCommerce 数据,同时提供有助于让大型实现保持可管理的工具:

  • 本地 JSON 可以从 JSON 文件加载字段组及其他 ACF 配置,从而减少加载这些设置所需的数据库调用。
  • 重复字段分页可减少 WordPress 管理后台中针对超大重复字段一次渲染的行数,在不改变前端模板输出的情况下改善编辑体验。
  • acf/save_post 为开发者提供了一个可靠的触发点,以便在 ACF 数据保存后触发自定义缓存失效,当一次产品更新影响到归档页、对比页面或共享组件时尤其有用。
  • 当性能分析表明默认的 wp_postmeta 模型在大规模应用中已成为瓶颈时,可以通过 acf/load_value 和 acf/update_value 等 ACF 钩子实现自定义存储策略。

ACF PRO 内容建模工具包包括重复字段、灵活内容、克隆、图库和选项页,为 WooCommerce 开发者提供了更多工具,可构建更丰富的产品数据模型,而不会让底层内容架构变成一堆一次性的字段和模板。

使用 ACF 构建更结构化、更易维护的 WooCommerce 数据层。

文章《适用于 WooCommerce 商店的最安全缓存插件》最初发布于 ACF。

来源:Advanced Custom Fields 官方博客 · https://www.advancedcustomfields.com/blog/best-caching-plugin-for-woocommerce/

部分链接为推广/关联链接。