Verified against PrestaShop 1.6, 1.7, 8.x and 9.x, including native WebP/AVIF generation in PrestaShop 9 and the prestashop:thumbnails:regenerate console command.
On almost every PrestaShop store we have worked on, images are the single heaviest thing the browser has to download. Product photography, category banners, brand logos, promo graphics. On a typical category page they routinely make up well over half the total page weight. And because your product hero shot is almost always the largest element the visitor sees, it is almost always the element Google times for Largest Contentful Paint. In plain terms: how you handle your images decides, more than anything else on the page, whether your store feels fast or sluggish, and whether Core Web Vitals come back green or red.
This guide is the hands-on, PrestaShop-specific version of that work: where alt tags live in the back office and how to fill them at catalog scale, how to apply lazy loading the way PrestaShop's templates expect, and how those two things translate into a faster page. It deliberately stays narrow. If you want the deeper theory on each piece, the siblings cover it. The formats-and-compression science is in image optimization for PrestaShop, the full case for descriptive image text is in alt tags explained, and how speed actually maps to rankings is in page speed and SEO. Here we focus on doing the three jobs in your back office.
Where PrestaShop image settings actually live
Before you optimize anything, it helps to know that PrestaShop does not serve the image you upload. It generates a set of resized copies, thumbnails, from each upload, one per configured image type, and serves whichever the theme asks for. You manage all of this in one place: Back Office → Design → Image Settings (on PrestaShop 1.6 the path is Preferences → Images).
That screen is where two of the optimizations in this guide are managed: the image types (the sizes your theme uses) and the "Regenerate thumbnails" tool. On PrestaShop versions that support native WebP generation, its format options also live there; on 1.7.8, WebP still needs a module or server-side image workflow.
Image types: stop serving oversized copies
The most common waste we see is a theme serving a 1200 px product image into a slot that displays at 300 px on a phone. The visitor downloads four times the bytes they can see. PrestaShop already has the machinery to prevent this, the image types list, but stores rarely audit it. A sensible product set looks like this:
- small_default, roughly 125×125, used in the cart and mini-cart
- medium_default / home_default, roughly 250–300 px, category listings on mobile
- large_default, roughly 600 px, category listings on desktop and the product gallery
- a high-resolution type, around 1200 px for the product hero and zoom (2× the 600 px display size covers retina screens)
So what? Every image type you trim to its real display size is bytes the customer never waits for. The single biggest page-weight win on most stores is not a fancy format. It is resizing to the size the theme actually renders. The deeper compression and format theory (JPEG vs WebP vs AVIF, quality settings, EXIF stripping) is genuinely its own topic; we keep it in the image optimization guide rather than rush it here.
Turning on WebP in PrestaShop
PrestaShop 1.7.8 does not natively generate WebP copies alongside the JPEG/PNG originals. PrestaShop 8 added native WebP generation, and PrestaShop 9 extends the image-format choice to AVIF as well. On those versions, enable it from Design → Image Settings, under the image-generation options, then regenerate. WebP typically saves a meaningful chunk over JPEG at the same visual quality, and modern browser support is effectively universal. The practical reason many stores still ship JPEG is simply that nobody configured the format workflow and regenerated.
If you are on a PrestaShop version that cannot generate WebP natively, this is one of the things our Performance Revolution module handles for you, WebP/AVIF conversion where the server supports it, plus lazy-loading options from the back office. The benefit framed plainly: you get next-gen images and the speed they buy without a developer touching your template, and without that work breaking at the next core upgrade.
Alt tags in PrestaShop: where they come from and how to fill them at scale
An alt attribute is the text a browser shows when an image fails to load, the text a screen reader reads aloud, and the text Google uses to understand what a picture depicts. The full case for why they matter, accessibility law, image-search traffic, the lot, is laid out in alt tags explained. What that guide does not cover, and what trips up PrestaShop merchants specifically, is where the alt text on a PrestaShop product image actually comes from.
The answer surprises people: by default, PrestaShop populates a product image's alt attribute from the image's caption/legend field, which you set per image in Catalog → Products → (a product) → Images. If you never fill that field, and almost nobody does across a whole catalog, the theme falls back to the product name for every image. So a product with five photos ends up with five identical alt tags, all just the product name. That is not a bug you can see on the page; it is a quiet defect in your markup.
Writing alt text that actually does its job
The same mistakes show up on store after store. Empty alts that say nothing. Filename junk like image1. Single generic words like product. And the keyword-stuffed kind, buy cheap blue leather wallet best price free shipping, which helps neither a screen-reader user nor Google. A useful alt tag follows a simple formula: product name + the distinguishing feature of this specific shot + context. Keep it under about 125 characters, and make each of a product's images describe its own angle rather than repeating the name five times:
| Weak alt text | Useful alt text |
|---|---|
| (empty) | Navy leather bifold wallet, front view showing six card slots |
| wallet | Same wallet open flat, showing the note compartment and lining |
| IMG_0421 | Wallet in its gift box with magnetic closure |
Filling thousands of alt tags without losing a week
Writing captions by hand for a 5,000-product catalog with three to five images each means tens of thousands of fields. That is not realistic, which is exactly why most stores ship empty alts. The pragmatic answer is to generate a sensible baseline automatically from the data PrestaShop already holds, product name, category, key attributes, and then hand-improve only the highest-traffic products. Our Automatic SEO Images Alt Tags module does the baseline pass from the back office. So what? An automated alt tag is not as good as a hand-written one, but it is enormously better than nothing across an entire catalog, and "nothing" is what you almost certainly have right now if you have never touched the caption field.
Lazy loading: the biggest quick win, done the PrestaShop way
Lazy loading defers downloading an image until it is about to scroll into view. On a category page showing forty products, only the first handful are visible before the visitor scrolls. Lazy loading means the other thirty-odd images do not spend bandwidth until they are needed. Modern HTML supports this natively with one attribute on the image tag, loading="lazy": no JavaScript library, no configuration, and browsers that do not understand it simply load the image normally. There is no downside to getting this right.
The mistake that quietly hurts: lazy-loading your hero image
Here is the trap, and it is the most common image performance mistake there is. If you apply loading="lazy" to your LCP image, the product hero on a product page, or the first product on a category page. You make your most important image slower, not faster. The browser now has to render the layout, work out that the image is in view, and only then start fetching it. You have added an artificial delay to the exact element Google is timing.
The correct split is simple to state and is what PrestaShop themes should be doing:
- Product page hero image: load it eagerly and add fetchpriority="high" so the browser fetches it ahead of stylesheets and scripts.
- Category page first visible row (typically three or four products): load eagerly, no lazy attribute.
- Everything below the fold: loading="lazy".
- Logo and navigation images: eager. They are always on screen.
The fetchpriority="high" hint in particular is supported in modern browsers and still used by very few stores on their hero image, a free optimization sitting unused on most PrestaShop sites.
Applying the eager/lazy split in PrestaShop templates
Where do you actually make these changes? In the theme, the product gallery markup lives in themes/your-theme/templates/catalog/_partials/product-images.tpl (and the cover image in the product page templates), while the category grid renders each product through catalog/_partials/miniatures/product.tpl. The honest catch is that you cannot cleanly tell "first row" from "everything else" in a Smarty loop without a counter, and editing core-ish partials is the kind of change that an upgrade or a theme switch can wipe out.
That is the friction our Automatic SEO Images Lazy Tags module removes for the lazy-loading part: it adds loading="lazy" and, optionally, decoding="async" through PrestaShop presenter hooks and content fields. Keep the hero-image eager and fetchpriority="high" logic in the theme where the template can identify the above-the-fold image. The benefit, stated plainly: you get the page-speed win of broad lazy loading without maintaining output-level HTML hacks.
<img
src="{$product.cover.bySize.large_default.url|escape:'htmlall':'UTF-8'}"
alt="{$product.cover.legend|default:$product.name|escape:'htmlall':'UTF-8'}"
width="{$product.cover.bySize.large_default.width|intval}"
height="{$product.cover.bySize.large_default.height|intval}"
fetchpriority="high">If your theme exposes more than one generated size of the cover, you can hand the browser a srcset so a phone downloads the small copy and a desktop the large one, the same bytes-you-never-wait-for principle, applied per device. PrestaShop's product presenter already gives you each image type under bySize, so the markup writes itself from data you have:
<img
src="{$product.cover.bySize.large_default.url|escape:'htmlall':'UTF-8'}"
srcset="{$product.cover.bySize.medium_default.url|escape:'htmlall':'UTF-8'} 300w,
{$product.cover.bySize.large_default.url|escape:'htmlall':'UTF-8'} 600w,
{$product.cover.bySize.large_default.url|escape:'htmlall':'UTF-8'} 1200w"
sizes="(max-width: 768px) 100vw, 600px"
alt="{$product.cover.legend|default:$product.name|escape:'htmlall':'UTF-8'}"
width="{$product.cover.bySize.large_default.width|intval}"
height="{$product.cover.bySize.large_default.height|intval}"
fetchpriority="high">Swap the placeholder image-type keys for whichever sizes your store actually defines in Image Settings. The point is that srcset lets the browser pick the lightest file that fills the slot, rather than every device pulling the same large copy.
Why width and height belong on every image
One detail makes or breaks the visual experience while images load: explicit width and height attributes on the image tag. Without them, each image that arrives shoves the content around it, and the page visibly jumps, the metric Google calls Cumulative Layout Shift, and a real reason visitors mis-tap and bounce. With width and height present, the browser reserves the correct space before the image loads, so nothing moves. You still keep images responsive with a small rule in your theme's CSS, setting max-width: 100% and height: auto, so the dimensions guide the layout without freezing the display size. PrestaShop's default themes generally include these attributes; custom and heavily modified themes are where they go missing.
Regenerating thumbnails after you change anything
Every change above, adding an image type, resizing one, switching on WebP, only affects images generated after the change. To apply it to your existing catalog you have to regenerate the thumbnails, and PrestaShop gives you two ways depending on catalog size.
From the back office (smaller catalogs)
On Design → Image Settings, scroll to the bottom and use Regenerate thumbnails. Choose which types to rebuild (products, categories, manufacturers) and whether to clear old unused thumbnails. This is fine for stores up to roughly a couple of thousand products; beyond that the browser request tends to time out before it finishes.
From the command line (large catalogs)
On PrestaShop 9, the console command has no browser timeout and is the right tool for big catalogs. Run php bin/console prestashop:thumbnails:regenerate from the shop root, and check --help for the filters available on your exact version. For very large catalogs, tens of thousands of images, this is CPU-heavy and can run for a long while, so schedule it off-peak and keep an eye on server load while it works.
cd /var/www/html
php bin/console prestashop:thumbnails:regenerate --help
php bin/console prestashop:thumbnails:regenerateChecking your work: did the page actually get faster?
Do not trust a gut feeling, and do not trust a single test on a warm cache. Run your key templates, home, a busy category, a top product, through Google PageSpeed Insights, on mobile first (Google indexes mobile-first), and read the image-related audits specifically: Properly size images tells you a type is still too big, Serve images in next-gen formats flags missing WebP/AVIF, Efficiently encode images points at compression, and Defer offscreen images confirms whether lazy loading is doing its job. Those four audits map almost one-to-one onto the work in this guide.
Lab tests like PageSpeed are useful for diagnosis, but the scores that affect you are the field data from real visitors. Check the Core Web Vitals report in Google Search Console (under Experience), keeping in mind it runs on a rolling multi-week average, so a genuine improvement takes time to show up there, and reverting a change too early because "the report hasn't moved yet" is a classic mistake.
Getting your images into Google Image Search
Optimization does not stop at making images load fast. For product stores, image search can be a real slice of organic traffic, and Google can only surface images it can discover. That means including your product images in a sitemap (either a dedicated image sitemap or image extensions inside your product sitemap). The image-extension form adds an <image:image> child to each product URL entry, using the image namespace:
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
<url>
<loc>https://yourstore.com/navy-leather-crossbody-bag</loc>
<image:image>
<image:loc>https://yourstore.com/img/p/1/2/12-large_default.webp</image:loc>
</image:image>
</url>
</urlset>Note that Google deprecated the image:caption and image:title tags. image:loc is the field that matters now, and the alt text you filled earlier is what Google reads for context once it crawls the page. Our Advanced SEO Sitemap Builder generates these entries from your catalog automatically, and the full mechanics of sitemap structure are covered in the complete guide to XML sitemaps for PrestaShop.
The PrestaShop image checklist
The priority-ordered version of everything above. The order we actually work through it on a store:
- Audit your image types in Design → Image Settings and size each to what the theme really displays.
- Turn on WebP generation if your version supports it, or let a module handle conversion if it does not.
- Fill the image caption/legend field so alt tags are descriptive, automate the baseline, hand-write the top sellers.
- Confirm width and height attributes are present in your product and category templates to stop layout shift.
- Apply the eager/lazy split, eager plus fetchpriority="high" on the hero, eager on the first visible row, lazy everywhere else.
- Regenerate thumbnails from the back office or the console so every change reaches the existing catalog.
- Include images in your sitemap for image-search discovery.
- Re-test in PageSpeed Insights on mobile and desktop, then watch the Search Console Core Web Vitals report over the following weeks.
FAQ
Does PrestaShop 9 generate WebP and AVIF on its own, or do I still need a module?
PrestaShop 9 generates both natively, set under Design → Image Settings as the image format, provided the server's image library (GD or Imagick) was built with WebP/AVIF support. PrestaShop 8 added WebP; 1.7.8 has neither and needs a module or a server/edge workflow. After switching format you must regenerate thumbnails for the change to reach images already uploaded, the new format only applies to copies generated after the change.
Will adding loading="lazy" to every image speed up my store?
No, applying it to every image actively hurts. Lazy-loading your above-the-fold images, especially the product hero (your LCP element) and the first visible category row, delays the exact pixels Google times, so the page scores worse. Lazy loading only helps below the fold. The correct split is eager plus fetchpriority="high" on the hero, eager on the first visible row, and loading="lazy" on everything else.
Where does PrestaShop get the alt text for a product image?
From the per-image Caption (legend) field in Catalog → Products → (product) → Images, stored in the image_lang.legend column per language. If you leave it blank the theme falls back to the product name, so every photo of one product ends up with the same alt. Fill the caption per image to describe each individual shot.
Do I need width and height attributes if my theme is responsive?
Yes. Width and height let the browser reserve the correct space before the image loads, which prevents the layout from jumping (Cumulative Layout Shift). They do not freeze the display size as long as your CSS sets max-width: 100% and height: auto, the image stays responsive, the slot stays stable. PrestaShop's default themes include these attributes; custom and heavily modified themes are where they go missing.
My PageSpeed score is still red after I switched on WebP. Why?
Almost always one of three things: you enabled WebP but never regenerated thumbnails, so existing images are still JPEG; your image types are still oversized for the slots the theme renders; or you are lazy-loading the LCP image and adding render delay. Check the specific PageSpeed audits, "Serve images in next-gen formats", "Properly size images" and "Defer offscreen images", rather than the single headline number, because each points at one of these causes.
For doing the catalog-wide jobs from one place, generated alt text, sitemap image entries, and the SEO checks that confirm Google can index your photos, our SEO Revolution suite covers the indexation side, the Advanced SEO Sitemap Builder handles image discovery, and Performance Revolution takes on WebP/AVIF conversion and lazy loading where your PrestaShop version can't do it natively.
None of this is exotic. The stores that score well on PageSpeed are not running secret tricks. They have their image types sized correctly, WebP switched on, alt tags filled, and the eager/lazy split applied consistently across every template in the catalog. On PrestaShop specifically, that work lives in a handful of known places: Design → Image Settings, the product image caption field, and the gallery and miniature templates. Do those well and the heaviest part of every page stops being the slowest.
