WooCommerce 的商品页通常加载得还算可以。商店页、分类列表和搜索结果往往就不是了，而店主常常对此感到意外，因为单个商品看起来都没问题。差别在于算术。商品页显示一张主图。一个展示二十四件商品的分类页至少显示二十四张，一旦把悬停效果和相册预览算进去，经常是两倍。

正是这个乘法，让目录页通常成为整个商店里最慢的部分，也让它们成为商业上最重要的页面。它们正好卡在访客抵达和访客找到可买之物这两件事之间。

多数慢目录背后的固定模式： 主题请求了一个 WordPress 从未生成过的缩略图尺寸，于是浏览器下载完整尺寸的原图，再在页面里缩小。二十四件商品，每件都发送一张两兆字节的照片只为在三百像素上显示，就是一个五十兆字节的分类页，无论你加多少缓存，分数都好不了。

目录页为什么表现不同

列表页上有三件事会叠加，而商品页上不会。

数量。 网格里的每件商品至少产生一次图片请求。WooCommerce 的默认设置常常每页显示十六或二十四件，规模更大的商店还会继续调高，以减少翻页。

悬停图和相册图。 很多主题会为每件商品预加载第二张图，用于悬停切换。这会悄悄把页面的图片数量翻倍，而且第二张图在发生交互前从不可见，所以它对首屏渲染毫无贡献，却消耗同样的带宽。

布局不稳定。 没有为图片预留空间的网格，会随着每张图到达而位移。在商品页上，一次位移还能忍受。在二十四格的网格里，累积的移动正是糟糕的 Cumulative Layout Shift 分数的来源，体感上就是你想点击时页面在跳。

结果是，目录页因为商品页所没有的原因而在 Core Web Vitals 上失分，而优化商品模板对它们毫无作用。这也是为什么很多店主反复优化商品页却看不到整体改善：被测的那个页面本来就不是问题所在，真正拖慢生意的是访客抵达后最先看到的那一批列表页。

造成大部分问题的尺寸错配

WordPress 在上传时生成一组图片尺寸。WooCommerce 在此之上注册自己的尺寸。主题再注册更多。浏览器实际收到什么，取决于模板请求了其中哪一个尺寸，以及那个尺寸是否存在。

失败方式是安静的。如果主题请求的尺寸是在你的商品上传之后才注册的，WordPress 从未生成过它，于是回退到完整尺寸的原图。页面看起来依然正确，因为浏览器把图片缩小以适配。它只是为了显示一张缩略图而搬运了好几兆字节。

不用任何工具你也能发现这一点。打开一个分类页，打开网络面板，按大小排序图片请求。如果传输大小接近原始上传文件的重量，而不是它的一小部分，那就是在提供错误的尺寸。把已加载图片的固有尺寸和它在屏幕上占据的空间作比较。一张以两千像素宽度抵达、只为填满三百像素方块的照片，一次观察就说明了全部问题。

修复办法要么是重新生成缩略图，让被请求的尺寸真实存在；要么是在分发时提供正确尺寸，让这个问题根本不会出现。

懒加载，以及它出错的地方

WordPress 默认对图片启用懒加载，这对目录页的帮助超过几乎任何其他页面类型，因为长网格的大部分都在首屏之下。

但有两个错误会抵消这份收益。

对第一行使用懒加载。 打开页面时就可见的图片应当立即加载。如果其中最大的那张被懒加载，浏览器会很晚才发现它，而它通常正是 Largest Contentful Paint 元素，于是这项指标直接受损。多数主题在这里出错，因为它们对每一个商品方块一视同仁地套用懒加载。

懒加载插件与浏览器原生实现打架。 在浏览器机制之上再叠一层插件自己的懒加载，会产生永远不加载、加载两次或者闪烁的图片。如果你装了性能插件，检查一下它是不是在重复浏览器已经做过的事。

分发：真正能扩展的那一部分

重新生成缩略图修好的是今天的目录。它修不了下个月的，比如新供应商发来不同宽高比的照片时，或者你换了主题、所需尺寸又变了的时候。

在分发时转换图片可以避开这个原地打转。原图保持上传时的样子，而提供的尺寸由 URL 决定，而不是由几个月前生成了什么决定。改网格就改参数。没有重新生成的过程，也没有缺失尺寸回退到完整原图的风险。

这一点特别适合目录，因为同一张商品照片通常以三种尺寸出现：网格方块、商品页图片，以及放大或灯箱视图。在按图片计费的模型下，这是每件商品三笔费用。在 Cloudflare 的模型下，无论你有多少商品，这都是三个不同的变体，而同月内的重复请求不产生费用。

我们对 Cloudflare Image Transformations 与 WordPress 图片插件 的比较，讲了计费模型的差异，以及哪一种适合哪种形态的媒体库。

按顺序该改什么

按顺序做这几件事。每一件都能单独衡量，顺序乱了就很难判断到底是哪一步起了作用。

先弄清楚你是否存在尺寸错配，因为如果存在，在修好它之前其他都不重要。把网格图片的传输大小和它们占据的空间作对比。

然后减少页面请求的图片数量。如果主题会预加载悬停图，而你可以不要这个效果，就关掉它。再想一想每页二十四件商品到底服务了谁，还是十六件配上更快的加载转化更好。

然后修正懒加载的边界，让第一屏可见的那一行立即加载，而它下面的都不加载。

然后处理分发，让提供的尺寸与显示的尺寸一致，并在目录变化时依然正确。

只有在这一切之后，缓存才会有实质帮助。缓存一个慢页面只会让它稳定地慢，而不是变快，而它偏偏是人们最先伸手去拿的一步，因为它最容易安装。

关于图片之外更广的情况，WooCommerce 性能 一文讲了数据库查询、插件开销和未缓存的片段，这些同样会拖慢商店。

找人把它测准

店主通常知道商店感觉很慢，却不知道十几种可能原因里究竟是哪一个。猜测的代价很高，因为那些显而易见的修复往往正是已经试过的。

Mecanik 提供的 WordPress 性能审计 会专门测量目录页，而不是测一测首页就算完事；当修复超出配置层面时，也会通过 WordPress 开发 工作承接实施。如果正在流失访客的是你的分类页，那么测量就该从那里开始。

相关文章: WooCommerce 为什么慢：真正的四个原因 、网站迁移不丢流量：2026 年完整指南 、Image Transformations 与 WordPress 图片插件对比 、电商网站开发：Shopify与定制开发对比 、电商 GEO：进入 AI 答案的商品数据 。

常见问题

为什么 WooCommerce 分类页比商品页慢？ 商品页加载一张主图。分类页每件商品加载一张，常常因悬停图而翻倍，所以二十四件商品可能意味着四十八次图片请求。同样的图片处理方式在商品页上没问题，在网格上却会糟糕地累积。

我怎么知道 WooCommerce 提供的图片尺寸不对？ 打开一个分类页和浏览器网络面板，把网格图片的传输大小与原始上传文件作比较。如果两者相近而不是只有一小部分，说明主题请求了 WordPress 从未生成过的尺寸，完整原图正在浏览器里被缩小。

该重新生成缩略图，还是在分发时转换？ 重新生成能修好当前的目录，但每次尺寸或主题变动都得重来一次。分发时转换由 URL 决定尺寸，因此在换主题和新上传之后依然正确，不需要任何重新生成的过程。

懒加载对 WooCommerce 目录页是帮助还是伤害？ 是帮助，因为长网格的大部分都在首屏之下，但第一屏可见的那一行应当立即加载。把可见的最大图片设为懒加载会直接推迟 Largest Contentful Paint 的测量，而这正是很多主题的默认行为。

每页放多少商品对性能最好？ 图片越少页面越快，但翻页越多浏览时就要点越多次。十六到二十四是常见的取值。这个数字远不如每张图片是否尺寸正确重要，因为尺寸得当的二十四张网格胜过尺寸过大的十二张。