Heavy product images in PrestaShop: sizes, thumbnails and lazy loading

You open a category with forty products on your phone and the page takes a while to appear. In most stores, the culprit is neither the server nor PHP: it is the images. Photos uploaded at camera resolution, thumbnails generated at a size the theme no longer uses, heavy formats and every image downloading at once even though the customer only sees the first four.

This article is about how PrestaShop handles product images and what you can adjust.

How PrestaShop generates images

When you upload a photo to a product, PrestaShop keeps the original and, from it, generates a copy for each image type defined for products: the listing thumbnail, the cart one, the large one on the product page, the gallery one, and so on. The theme requests the appropriate size in each place.

Sizes are configured in the back office, under Image Settings (in the Design menu in recent versions). Each one has a name, width, height and the content types it applies to: products, categories, brands, suppliers or stores.

This has two consequences:

• The weight the customer receives depends on the generated size, not the original photo. A huge photo does not weigh anything in the listing if the thumbnail is small.
• If a size does not match the space the theme gives it on screen, the browser downloads an image larger than necessary and shrinks it, or a smaller one and enlarges it (and it looks blurry).

Sizes you do not need and sizes you are missing

Over the years, a store accumulates image types from previous themes, from modules that are no longer there or from tests. Every extra size means:

• One more file for every product photo, taking up disk space and backups.
• More time when uploading an image and when regenerating.

Check which sizes your theme actually uses (its templates and its configuration file name them) and which ones your modules use. Those nobody uses can be deleted, but check on a copy first: a module that requests a size that no longer exists shows broken images.

And the other way round: if the theme displays listing thumbnails larger than the generated size, for example after a redesign, the photos look blurry. Adjust the size to the real space, taking high-density screens into account.

When thumbnails need regenerating

Existing thumbnails do not change on their own when you modify a size. You have to regenerate them, from the same Image Settings screen. It is needed when:

• You change the dimensions of a size.
• You add a new size (for example, when changing theme).
• You change the output format or the compression quality.
• You restore images from a backup and thumbnails are missing.

The original photo matters too

Even though the customer does not download the original, it does affect:

• Disk space and backups. Photos of several megabytes multiplied by thousands of products are gigabytes copied every night.
• Generation time. Resizing a huge image uses memory and CPU; with very large photos, the process can fail for lack of memory.
• The zoom on some product pages, which does serve the large image.

Good practice is to upload photos already reduced to a reasonable size for the largest use the store makes of them (the product page zoom), rather than straight from the camera.

Formats

• JPEG for photographs. With a well-chosen quality setting, the saving compared with maximum quality is large and the difference is barely visible.
• PNG only if you need transparency or it is a graphic with flat colours. For product photos, it weighs much more than a JPEG.
• WebP and other modern formats offer less weight at the same quality, and recent versions of PrestaShop can generate them. Check that your theme and modules support them before enabling them.

Changing format is another reason to regenerate, with the same precautions as above.

Lazy loading

In a long category, the customer initially sees a few images. The rest are further down and they may never get to see them. Lazy loading makes the browser download images only when they approach the screen.

• Modern browsers do it on their own with the loading="lazy" attribute on the image tag. Many themes already include it in listings.
• Do not apply lazy loading to the first visible image: the main photo on the product page or the first thumbnails in the category. Delaying them worsens the time it takes for the most important part of the page to be painted.
• Specify the width and height on images (or reserve the space with CSS), so that the page does not jump when they finish loading.

A quick review

1. Open a category and a product page with the browser's developer tools and see how much the images weigh compared with the rest of the page.
2. Compare the pixel size of the downloaded thumbnails with the space they take up on screen.
3. Review the list of image types and remove the ones nobody uses (on a copy first).
4. Check that off-screen images use lazy loading and that the main one does not.
5. If you change anything, regenerate outside peak hours and check that no broken images remain.

How to solve it in PrestaShop

Images are one part; the rest of the page weight is usually in the CSS and JavaScript. RKR OptiMatters takes an inventory of the CSS and JS each page type loads, with their weight and the module they come from, and lets you remove the unnecessary ones, apply defer or async, delay third-party scripts until the first interaction and serve Google Fonts from your own server; it has a test mode to compare the page with and without optimisation. All In One Cache includes, within its page cache, an optional lightening feature with minification of HTML and inline JS and CSS and lazy loading of images, as well as full page cache, query caching in Redis and OPcache management.