How to Fix Slow Product Pages in PrestaShop

Product pages are usually slower than category pages. But "usually" is not "always", and guessing costs more than measuring. A PrestaShop product page runs more database queries than any other page type, and every module you have installed can add its own — so on most stores it is the slowest page. On a clean store it often is not.

There are five causes. Find which one you have before you change anything — each has a different fix, and only one of them is about images.

What this actually looks like when you measure it

Numbers from a PrestaShop 9.1.1 demo store, three runs per page, same machine, nothing else running:

Page	TTFB	Total	HTML size
Product page	1.34 – 1.41 s	1.74 – 1.82 s	199,597 B
Category page	1.32 – 1.33 s	1.92 – 1.93 s	220,345 B
Homepage	1.24 – 1.25 s	1.65 s	155,110 B

Read that table twice, because it breaks the usual advice:

• **The product page was not the slowest.** Its time-to-first-byte was flat with the category page, and its total time was lower — because the category page has more images to fetch, and the product page has more of its weight already inline in the HTML.
• Every page type sat at roughly the same TTFB. On this store the floor is the server itself, not the page type. No amount of product-page work moves it.
• 199 KB of HTML for one product page. That is the real story, and it is not the same story as "the database is slow". Breaking that HTML down: 14,667 characters of inline CSS in 4 blocks and 23,270 characters of inline JavaScript in 14 blocks — about 38 KB of the page is code the browser must parse before it can paint anything, and it cannot be cached separately from the page.

So measure before you fix. Reproduce the table on your own store with three commands:

curl -o /dev/null -w 'ttfb=%{time_starttransfer}s total=%{time_total}s size=%{size_download}B\n' \
  https://yourstore.com/a-product-page.html

Run it on a product page, a category page and your homepage. Whichever column is out of line tells you which of the five causes below you have. If the shapes match the table above, stop looking at page type and go to cause 1 and cause 4.

First: separate server time from browser time

Open the browser network panel on a product page and look at the document request — the HTML itself. Or just use the curl line above.

Document request	Meaning	Go to
Over 500 ms	The server is slow. Front-end work will not help.	Cause 2 or 3
Under 200 ms, page still slow	The browser is the bottleneck	Cause 1
Around 1 second, only on some products	Something is specific to those products	Cause 4
Same TTFB on every page type	The server's baseline, not the page	Check your host before anything else

This one measurement decides where you look. Skip it and you will spend a day optimising images on a store whose real problem is a database query.

Cause 1 — Images that are too large (browser-side)

The most common cause, and the easiest to confirm: the network panel shows image files of 1 MB or more.

Design → Image Settings controls the thumbnail sizes. Two rules:

• Regenerate thumbnails after changing a size. The setting alone changes nothing; PrestaShop keeps serving files already on disk.
• Keep the product image and the thumbnail separate. A product page that loads the original full-resolution image and scales it down in the browser downloads megabytes it never displays.

Fix: set the large_default size to what the theme actually displays, then regenerate.

Check the format, not just the size. On the same demo product page, the HTML carried 19 <img> tags, 12 of them lazy-loaded — and 0 of the 16 image URLs were WebP or AVIF. Every image was still a JPEG or PNG, even though PrestaShop 9 can generate both better formats and the switch is one checkbox.

That is the cheapest fix on this list and it is usually left off: Design → Image Settings → Image formats to generate → tick WebP. Then look at a product page's image URLs to confirm the theme actually serves it. Generation is the server's job; serving is the theme's. Details: PrestaShop image settings explained.

Cause 2 — The combination table

A product with 20 attributes generates a combination table. A product with 500 combinations generates a page that is slow to render, slow to query, and often impossible for a customer to use.

Check Catalog → Products → Combinations on your slowest product. If the count is in the hundreds:

• Reduce the combinations to the ones you actually sell
• Or set the theme to load the combination table only when the customer opens it

This is the single largest win on many stores, and it is invisible in a page speed score because the score measures a different product.

Cause 3 — Modules loaded on every product page

Every active module can hook into displayProductPage or similar. Ten modules doing that means ten sets of queries and ten script files.

Find the culprit by deactivating modules one at a time on a staging copy and re-measuring. Do not test this on the live store — deactivating a module can remove content customers are looking at.

Common offenders: review modules, related-product sliders, live chat, social share buttons, countdown timers.

Fix: keep the ones that earn money and remove the rest. A live chat widget that nobody answers costs you speed and gives nothing back.

Cause 4 — Slow only on some products

If three products are slow and the rest are fine, the problem is data, not configuration. Look for:

• Products with very long descriptions (the HTML itself is large)
• Products in many categories
• Products with hundreds of combinations
• Products with attributes that trigger a pricing calculation

Fix the specific product, not the store settings.

Cause 5 — No cache for logged-out visitors

If the HTML is generated fresh on every request for every visitor, every other fix above is fighting that. A cache layer for anonymous visitors is the largest structural improvement available.

This is also the riskiest change, because a misconfigured page cache can serve a cached page to a logged-in customer. Read the safety rules before you enable it: Boost PrestaShop speed without breaking it.

Measure, change, measure

1. Record the document request time and page weight on one product page
2. Change one cause above
3. Clear all four cache layers
4. Re-measure the same product page in a private window
5. Only then move to the next cause

Two products to measure, not one: a simple product and your most complex one. If only the complex one is slow, you have cause 2, not a store-wide problem.

Related guides

• How to speed up a PrestaShop store — the whole-store change list
• Boost PrestaShop speed without breaking it — risk order and rollback for each change
• How to clear the PrestaShop cache — the four layers, including the CDN
• PageSpeed module — applies these fixes per page type

Checklist

• ☐ curl timing run on a product page, a category page and the homepage
• ☐ Document request time measured on a simple and a complex product
• ☐ HTML size counted (not just timed) — inline scripts and styles add up
• ☐ Product page checked for modern image formats actually being served
• ☐ Image sizes checked against what the theme displays
• ☐ Thumbnails regenerated
• ☐ Combination counts checked on the slowest products
• ☐ Modules hooked into the product page listed
• ☐ One module deactivated at a time, on staging, re-measured
• ☐ Cache layer for anonymous visitors considered

FAQ

Why is my product page slower than my category page? A category page renders a list of products from one query. A product page loads combinations, prices per customer group, stock, attributes, related products and every module hooked into it. More queries, more modules, slower page.

But check before assuming — see the measurement table above. On a clean store the product page was faster than the category page in total time, because the category page pulled more images.

Will a faster theme fix this? Only if the bottleneck is in the browser. If the document request takes over 500 ms, the theme is not the problem and no theme will fix it.

Does the number of products in the store affect product page speed? Not directly. What matters is how many queries the page runs, not how many products exist. A store with 50,000 products and a clean product page can be faster than a store with 200 products and twelve product-page modules.

How slow is too slow? Measure rather than guess: if the document request is under 500 ms and the page renders within about 2.5 seconds on a normal connection, product pages are not your bottleneck. Spend the effort on content instead.