A WooCommerce product page usually loads acceptably. The shop page, the category listings and the search results often do not, and store owners are frequently surprised by this because the individual products feel fine. The difference is arithmetic. A product page shows one main image. A category page showing twenty-four products shows at least twenty-four, and frequently double that once hover effects and gallery previews are counted.

That multiplication is why catalogue pages are usually the slowest thing on a shop, and why they are also the pages that matter most commercially. They sit between a visitor arriving and a visitor finding something to buy.

The pattern behind most slow catalogues: the theme requests a thumbnail size that WordPress never generated, so the browser downloads the full-size upload and scales it down in the page. Twenty-four products, each shipping a two-megabyte photograph to display at three hundred pixels, is a fifty-megabyte category page that scores badly no matter what caching you add.

Why Catalogue Pages Behave Differently

Three things compound on a listing page that do not on a product page.

Volume. Every product in the grid contributes at least one image request. Default WooCommerce settings often show sixteen or twenty-four per page, and larger stores push that higher to reduce pagination.

Hover and gallery images. Many themes preload a second image per product for the hover swap. That silently doubles the image count on the page, and because the second image is never visible until interaction, it contributes nothing to the initial render while costing the same bandwidth.

Layout instability. Grids that do not reserve space for images shift as each one arrives. On a product page a single shift is survivable. On a grid of twenty-four, the cumulative movement is what produces a poor Cumulative Layout Shift score, and it is felt as the page jumping while you try to click something.

The consequence is that catalogue pages fail Core Web Vitals for reasons a product page does not, and optimising the product template does nothing for them.

The Size Mismatch That Causes Most of It

WordPress generates a set of image sizes at upload. WooCommerce registers its own on top of those. Themes then register more. What the browser actually receives depends on which of those sizes the template asks for, and whether that size exists.

The failure mode is quiet. If a theme requests a size that was registered after your products were uploaded, WordPress has never generated it, so it falls back to the full-size original. The page still looks right, because the browser scales the image down to fit. It is simply moving several megabytes to display a thumbnail.

You can spot this without any tooling. Open a category page, open the network panel, and sort image requests by size. If the transferred sizes are close to what the original uploads weigh, rather than a fraction of them, the wrong size is being served. Compare the intrinsic dimensions of a loaded image against the space it occupies on screen. A photograph arriving at two thousand pixels wide to fill a three-hundred-pixel tile is the entire problem in one observation.

The fix is either regenerating thumbnails so the requested sizes exist, or serving the right size at delivery so the question never arises.

Lazy Loading, and Where It Goes Wrong

WordPress lazy loads images by default, which helps catalogue pages more than almost any other page type, because most of a long grid is below the fold.

Two mistakes undo it.

Lazy loading the first row. The images visible on arrival should load eagerly. If the largest one is lazy loaded, the browser discovers it late, and since it is usually the Largest Contentful Paint element, the measurement suffers directly. Most themes get this wrong by applying lazy loading uniformly to every product tile.

Lazy loading plugins fighting the native implementation. Running a plugin that adds its own lazy loading on top of the browser’s produces images that never load, load twice, or flicker. If you have a performance plugin installed, check whether it is duplicating something the browser already does.

Delivery: The Part That Scales

Regenerating thumbnails fixes today’s catalogue. It does not fix next month’s, when a new supplier sends photographs at a different aspect ratio, or when you change theme and the required sizes change again.

Transforming images at delivery avoids that treadmill. The original stays as uploaded, and the size served is decided by the URL rather than by what was generated months ago. Change the grid, change the parameter. There is no regeneration run and no risk of a missing size falling back to the full original.

This suits catalogues particularly well because the same product photograph typically appears at three sizes: a grid tile, a product page image, and a zoom or lightbox view. Under a per-image billing model that is three charges per product. Under Cloudflare’s model it is three distinct variants regardless of how many products you have, and repeat requests within the month cost nothing.

Our comparison of Cloudflare Image Transformations and the WordPress image plugins covers how the billing models differ and which suits which shape of library.

What To Change, In Order

Work through these in sequence. Each one is measurable on its own, and doing them out of order makes it hard to tell what helped.

Start by finding out whether you have the size mismatch, because if you do, nothing else matters until it is fixed. Check the transferred size of grid images against the space they occupy.

Then reduce how many images the page requests. Turn off hover images if the theme preloads them and you can live without the effect. Consider whether twenty-four products per page is serving anyone, or whether sixteen with faster loading converts better.

Then fix the lazy loading boundary so the first visible row loads eagerly and everything below it does not.

Then address delivery, so the sizes served match the sizes displayed and stay correct when the catalogue changes.

Only after all of that does caching help meaningfully. Caching a slow page makes it consistently slow rather than fast, and it is the step people reach for first because it is the easiest to install.

For the wider picture beyond images, WooCommerce performance covers the database queries, plugin overhead and uncached fragments that also make stores slow.

Getting It Measured Properly

Store owners usually know the shop feels slow and do not know which of a dozen possible causes is responsible. Guessing is expensive, because the obvious fixes are the ones that have already been tried.

Mecanik runs WordPress performance audits that measure catalogue pages specifically rather than testing a homepage and calling it done, and handles the implementation through WordPress development work where the fix goes beyond configuration. If your category pages are the ones losing visitors, that is where the measurement should start.

Related reading: WooCommerce Performance: Why Your Store Is Slow , Website Migration Without Losing Traffic: 2026 Guide , Cloudflare Image Transformations vs WordPress Image Plugins and Ecommerce Website Development: Shopify vs Custom ., GEO for Ecommerce: Product Data in AI Answers

Frequently Asked Questions

Why are WooCommerce category pages slower than product pages? A product page loads one main image. A category page loads one per product, often doubled by hover images, so twenty-four products can mean forty-eight image requests. The same image handling that is fine on a product page compounds badly on a grid.

How do I know if WooCommerce is serving the wrong image size? Open a category page, open the browser network panel, and compare the transferred size of grid images against the original uploads. If they are similar rather than a fraction, the theme is requesting a size WordPress never generated and the full-size original is being scaled down in the browser.

Should I regenerate thumbnails or transform images at delivery? Regenerating fixes the current catalogue but has to be repeated whenever sizes or themes change. Transforming at delivery decides the size from the URL, so it stays correct through theme changes and new uploads without a regeneration run.

Does lazy loading help or hurt WooCommerce catalogue pages? It helps, because most of a long grid sits below the fold, but the first visible row should load eagerly. Lazy loading the largest visible image delays the Largest Contentful Paint measurement directly, and that is a common theme default.

How many products per page is best for performance? Fewer images means a faster page, but more pagination means more clicks to browse. Sixteen to twenty-four is typical. The number matters far less than whether each image is correctly sized, since a right-sized grid of twenty-four beats an oversized grid of twelve.