PrestaShop

PrestaShop product image compression: faster product pages without quality loss

ยท Krzysztof Balicki

White and navy vases with flowers on a table in a bright studio

Product image compression cuts the size of your image files, so product pages in PrestaShop load faster. And with a sensible quality setting, customers won’t notice any difference. The trouble usually starts with photos straight from the camera or from a supplier. A few megabytes per file, and both the product listing and the product gallery get sluggish. Below I explain how to choose the format, set up thumbnails and quality, turn on compression when adding products, and deal with the images already sitting in your catalogue.

Why do heavy images slow down PrestaShop product pages?

Because images make up the largest share of the data a browser downloads on a product page. Their size translates directly into how fast your store is. On top of that, PrestaShop creates several versions from a single file: a thumbnail for the listing, the main image, a zoom version and a few others (exactly how many depends on the theme). Original too big or poorly compressed? The problem repeats in every version. Customers feel it as laggy scrolling through the product list and gallery. And on a phone with mobile data, it’s even worse.

Lossy vs lossless compression: which one for product images?

For regular product photos, lossy compression with a well-chosen quality setting is more than enough. I’d keep lossless for graphics with text, sharp edges and transparency. The difference? Lossless compression makes the file smaller without losing a single bit of image data. Lossy compression removes some information, so it saves more, but with settings that are too aggressive you get blur and artifacts. The main slider is the quality parameter on a scale from 0 to 100. In practice, the best approach is to run a few typical photos through several values, e.g. a dark product, a light background and a shot with fine texture, and pick the lowest setting at which the image still looks sharp. That’s it.

WebP in PrestaShop: is it worth switching image formats?

Yes. WebP produces smaller files than JPEG and PNG at comparable quality, and in a store with thousands of images that adds up fast. According to the web.dev guide to WebP, files in this format are usually 25-35% smaller than their JPEG and PNG equivalents. It supports both lossy and lossless compression, so it works for photos and graphics alike.

But there’s a catch: older browsers may not display WebP, so you need a fallback file. You can handle this in the theme code (the browser gets several versions of the image to choose from) or on the server side, where the server checks the request header and sends a format the browser supports. Before you switch the whole catalogue, check on a few products that your theme, slider, zoom module and other add-ons display the new files correctly. Better to catch it on five product pages than on five thousand.

PrestaShop thumbnail sizes: how to set image types without wasted pixels?

Each image type in PrestaShop should have dimensions close to the space where the theme displays it. Pushing a 1200-pixel-wide image into a frame that’s a few hundred pixels wide is simply wasted bandwidth. Before you start optimising, go through a short checklist:

  • review the image types in the appearance settings and note where each one is used,
  • delete types that neither the theme nor any module uses,
  • match the width and height of the rest to the actual frames in the theme,
  • upload originals at a reasonable resolution, not full files from the camera.

After changing image types you need to regenerate the thumbnails. With a large catalogue this puts a heavy load on the server, so I recommend doing it outside peak hours and only after backing up the image folder.

How to automate product image compression on upload?

The most reliable option is compression that runs on its own after an image is uploaded. That way it doesn’t depend on whether the person adding products remembers to optimise them manually (and let’s be honest, by the hundredth product of the week, nobody remembers). This is how, for example, the Compressify module for PrestaShop works: once you set up the API key, it compresses images through the Compressify.eu API. The process starts after the image versions are generated and needs no manual handling. The module can save the originals before compression, lets you compare the before and after versions, restore a file or compress it again. And that’s a real safety net. One of the images came out worse? You go back to the original without digging around on the disk.

What to do with images already in the catalogue?

These need to be compressed in bulk, because automation on upload only covers new files. A safe order of steps:

  1. Back up the image folder.
  2. Test compression on a few products with different kinds of photos.
  3. Run bulk optimisation on all uncompressed files.
  4. Retry the items that ended with an error.
  5. Check selected product pages on a computer and a phone.

Then comes the cleanup. Copies of originals take up space, so it’s a good idea to clear old backups automatically or with a cron job. In the module panel, also keep an eye on the number of available optimisations, limit usage and savings statistics. Otherwise you don’t know how much you’ve actually gained.

In my view, the approach that works best is one where product image compression is a regular part of adding products, not a one-off cleanup every few years. A well-chosen format, thumbnails matched to the theme and automatic optimisation of new files. With that set-up, your store stays light even as the catalogue grows.

Frequently asked questions

Will image compression make them look worse on the product page?

With a sensible quality setting, customers won’t see any difference. Problems only start at very low values of the quality parameter. That’s why you should compare the before and after versions on a few images before running a bulk job.

Do I need to keep the JPEG originals after switching to WebP?

Yes. The originals are a safety copy in case a conversion fails, and at the same time a fallback file for browsers that don’t support WebP. Without them, some customers would see an empty space instead of the image.

Do I need to regenerate thumbnails after compression?

Regeneration is needed after you change image types, meaning their dimensions or number. If compression runs after the image versions are generated, it already covers the finished thumbnails and no extra step is needed. Just note: regenerating again may overwrite the compressed files, so run the optimisation once more afterwards.