WebP & AVIF Image Optimizer — Complete Guide
Install, configure and use the WebP/AVIF image optimizer: Imagick/GD/binary engines, transparent delivery via .htaccess or picture rewrite, native lazy-loading, original compression, bulk conversion, CRON and CLI for PrestaShop 8 and 9.
Overview
The WebP & AVIF Image Optimizer converts and compresses your store’s images directly on your own server, then automatically serves each visitor the lightest format their browser can display. All conversion is local: no image is sent to a third-party service, and there are no quotas or credits.
The key point: your original files are never overwritten. For each image product.jpg, the module generates product.jpg.webp and product.jpg.avif next to the original, then serves them only to compatible browsers. The operation is therefore fully reversible. The module is compatible with PrestaShop 1.7.6, 8 and 9, and works with Imagick, GD or the cwebp and avifenc binaries.
Requirements and compatibility
- PrestaShop — 1.7.6 to 9.x, including multistore.
- PHP — 7.2 to 8.3.
- At least one image engine — the Imagick extension (recommended, compiled with WebP/AVIF support), or the GD extension with WebP/AVIF support, or the system binaries
cwebpandavifenc. - Web server — Apache (transparent
.htaccessdelivery) or Nginx (picturemode).
Not sure what your server supports? The module includes a Test engines button that converts a sample image and tells you, format by format, which engine is available and what size it produces.
Installation
- In the back office, open Modules > Module Manager.
- Click Upload a module and drop in the module’s ZIP archive.
- Once installation is complete, click Configure.
On install, the module creates its two tables (statistics and queue), registers its hooks, applies ready-to-use defaults and, if the .htaccess delivery mode is active, writes its rules block into the /img folder. The presence of at least one image library (GD or Imagick) is checked: if none is available, installation is aborted with an explicit message.
Getting started
Three steps are enough to optimise your entire existing catalogue:
- Test the engines — on the configuration page, click Test engines to confirm that WebP and AVIF can be produced.
- Scan the media library — click Scan the media library: the module walks the target folders and fills the queue with the images to process.
- Start the conversion — click Start the conversion: processing runs in batches, with a progress bar, and can be paused and resumed at any time.
New images added afterwards in the back office are converted automatically (see Automatic conversion on upload).
Configuration
The configuration page brings together a dashboard (server capabilities and savings achieved), the batch-processing tool, the settings form and a maintenance panel.
Next-gen formats
- Generate WebP — enables the creation of
.webpfiles. - WebP quality — from 1 to 100. The 80–85 range offers the best quality/size trade-off.
- Generate AVIF — enables the creation of
.aviffiles. - AVIF quality — AVIF is denser than WebP: a value of 45 to 55 is usually enough for excellent quality.
Engine & delivery
- Conversion engine — Automatic (recommended), Imagick, GD or Binaries. In automatic mode, the module picks the best available engine for each format, in the order Imagick, then GD, then binaries.
- Delivery mode — .htaccess (transparent Apache negotiation), picture (HTML rewrite for Nginx) or none. On Apache, leave
.htaccess: there is nothing else to do. On Nginx, choosepicture.
Lazy loading
- Native lazy-loading — adds
loading="lazy"anddecoding="async"to images, with no JavaScript and no SEO impact. - Fade-in effect — a subtle cosmetic fade as the image appears (optional).
Original compression
- Recompress originals — resaves the original JPEG/PNG files in an optimised version. A
.dforigbackup is kept to allow restoration. - JPEG quality (originals) — the quality applied when recompressing the original JPEGs.
Recompressing the originals is optional and disabled by default. WebP/AVIF conversion already delivers most of the gain; enable recompression only if you also want to lighten the files served to older browsers.
Scope
- Image types to process — products, categories, manufacturers, suppliers, stores and CMS pages. The types actually available on your installation are detected automatically.
- Theme images — also processes your theme’s
assets/imgfolder (and manages a dedicated.htaccessthere under Apache delivery). - Exclude — one pattern per line: any path containing one of these fragments is skipped (for example
logoor/img/cms/banner).
Advanced
- Auto-convert on upload — converts each product image as soon as it is (re)generated in the back office.
- Skip animated images — animated GIFs and PNGs (APNG) are detected and left intact.
- Minimum size (bytes) — below this size, the image is skipped: very small images gain nothing from being converted.
- Batch size — the number of images processed per AJAX request or cron pass. 10 to 30 is recommended on shared hosting.
After every change, remember to save. If you change the delivery mode, the .htaccess block is added or removed automatically as a result.
How delivery works
The module only generates the next-gen files and tells the server how to serve them. Your image URLs never change.
.htaccess mode (Apache)
The module writes a rules block into /img/.htaccess. When a browser requests product.jpg, the server reads the Accept header: if it advertises AVIF support and product.jpg.avif exists, that file is returned; otherwise WebP is attempted, then the original JPEG as a fallback. A Vary: Accept header is added so caches and CDNs keep the right version per browser. Everything is transparent: your theme is not modified, and nothing breaks if you disable the module.
The block is written into /img/.htaccess and not into the root, because PrestaShop regularly regenerates its root .htaccess. The /img folder, however, is not managed by PrestaShop: the block stays stable there.
picture mode (Nginx)
On Nginx servers, .htaccess negotiation is not available. The picture mode then rewrites the page’s img tags into picture with AVIF and WebP sources, just before the page is sent. The browser itself picks the first source it can display.
Optimising a large catalogue (CRON and CLI)
The AJAX batch-processing tool suits most stores. For thousands of images or to automate handling of new images, use cron or the command line.
CRON task
Schedule a regular request to the URL shown in the Automation panel of the configuration. It is secured by a token:
https://your-store/index.php?fc=module&module=datafireflyimageoptimizer&controller=cron&token=YOUR_TOKEN&scan=1&limit=200
The scan=1 parameter runs a scan before processing (useful to detect new images) and limit sets the number of images processed per pass.
CLI command
For very large media libraries, the command line processes the queue in the background, with no timeout:
php modules/datafireflyimageoptimizer/cli/optimize.php --scan --loop
Available options: --scan (scan before processing), --loop (keep going until the queue is empty), --limit=N (batch size), --types=products,categories (restrict the targets for this run), --force (force reconversion even if the next-gen files are up to date) and --quiet (minimal output).
Restoration and reversibility
Because the originals are never overwritten, you can roll back at any time. In the Maintenance panel, the Restore everything button removes the generated .webp and .avif files, restores recompressed originals from their .dforig backup, removes the .htaccess block and clears the statistics. The same panel also lets you regenerate the .htaccess if needed.
Built-in safety: if a next-gen version turns out to be heavier than the original (which happens on some already heavily compressed images), it is automatically discarded. The browser then receives the original file.
Uninstallation
Uninstalling removes the .htaccess block, drops the tables and the module’s configuration. The .webp and .avif files already generated remain on disk. To start from a clean media library, first use Restore everything in the Maintenance tab, then uninstall the module.
Troubleshooting
Next-gen images are not being served. In Apache mode, check that mod_rewrite and mod_headers are active and that .htaccess files are taken into account (AllowOverride directive). Also confirm, using your browser’s tools, that the image request indeed returns an image/avif or image/webp type.
- The engine test fails for AVIF — your Imagick/GD is probably not compiled with AVIF support. Install the
avifencbinaries, or disable AVIF and keep WebP. - Blank front-office page after activation — this is usually linked to
picturemode on a heavily customised theme. Switch back to.htaccessmode (Apache) or none, then contact support. - Conversion is slow — reduce the batch size, or offload processing to cron or the CLI, designed for large volumes.
- Some images are not converted — check that they exceed the minimum size, that they are not animated (if the option is active) and that no exclusion pattern applies to them.
FAQ
Are my images sent to an external service?
No. All conversion is 100% local, on your own server. No image is sent to any third party, and there are no quotas or credits.
Are my original files modified?
Not by default: the WebP and AVIF versions are created next to the original. If you enable original recompression, a .dforig backup is kept to restore them.
Do I need to modify my theme or server?
In Apache mode, no: the .htaccess block takes care of everything. On Nginx, simply enable picture mode in the settings.
Which formats are supported?
The module generates WebP and AVIF from your JPEG, PNG and GIF (non-animated) files.
Is it compatible with PrestaShop 9 and multistore?
Yes, the module is compatible with PrestaShop 1.7.6 to 9.x and works in a multistore context. It uses official hooks only.
How do I process a catalogue of several thousand images?
Run the scan then the batch conversion in AJAX, or schedule the CRON task or the CLI command, which process the queue in the background with no timeout.