WebP / AVIF

If you are using Nginx, then make sure your configuration is as follow:

"Proxy mode" must be ON, other options must be OFF.

If, after installing the module, some images on your store, such as the logo, CMS page images, back office images, etc., no longer display, it's likely due to a .htaccess file in the /img, /img/cms and /modules directories. This file blocks all PHP scripts, even if it's just a redirection (the script isn't actually in this directory).

To fix this issue, you need to add an exception for our webp.php converter as follows:

# Disable PHP globally unless explicitly re-enabled
<IfModule mod_php5.c>
    php_flag engine off

    # Enable PHP execution only for avif.php and webp.php (used by Speed Pack)
    <Files "avif.php">
        php_flag engine on
    </Files>
    <Files "webp.php">
        php_flag engine on
    </Files>
</IfModule>

# Apache 2.2 access control
<IfModule !mod_authz_core.c>
    Order deny,allow
    Deny from all

    # Allow access to static image and video files
    <FilesMatch "\.(jpe?g|gif|png|bmp|tiff|svg|pdf|mov|mpeg|mp4|avi|mpg|wma|flv|webm|ico|avif|webp)$">
        Allow from all
    </FilesMatch>

    # Allow access to avif.php and webp.php (for image conversion)
    <Files "avif.php">
        Allow from all
    </Files>
    <Files "webp.php">
        Allow from all
    </Files>
</IfModule>

# Apache 2.4 access control
<IfModule mod_authz_core.c>
    Require all denied

    # Allow access to static image and video files
    <FilesMatch "\.(jpe?g|gif|png|bmp|tiff|svg|pdf|mov|mpeg|mp4|avi|mpg|wma|flv|webm|ico|avif|webp)$">
        Require all granted
    </FilesMatch>

    # Allow access to avif.php and webp.php (for image conversion)
    <Files "avif.php">
        Require all granted
    </Files>
    <Files "webp.php">
        Require all granted
    </Files>
</IfModule>

Or for /img/cms/.htaccess

<IfModule mod_php5.c>
    php_flag engine off

    # Enable PHP only for avif.php and webp.php (Speed Pack)
    <Files "avif.php">
        php_flag engine on
    </Files>
    <Files "webp.php">
        php_flag engine on
    </Files>

</IfModule>

# Enable avif.php and webp.php (Speed Pack)
<Files "avif.php">
    Order allow,deny
    Allow from all
</Files>
<Files "webp.php">
    Order allow,deny
    Allow from all
</Files>


deny from all
<Files ~ "(?i)^.*\.(jpg|jpeg|gif|png|bmp|tiff|svg|pdf|mov|mpeg|mp4|avi|mpg|wma|flv|webm|avif|webp)$">
	order deny,allow
	allow from all
</Files>

Or for /modules/.htaccess

<FilesMatch "^(?!webp\.php$|avif\.php$).*\.(php|log|txt|lock|json|yml|yaml|tpl|twig)$|^config(_[a-z]+)?\.xml$">
    # Apache 2.2
    <IfModule !mod_authz_core.c>
        Order deny,allow
        Deny from all
    </IfModule>

    # Apache 2.4
    <IfModule mod_authz_core.c>
        Require all denied
    </IfModule>
</FilesMatch>

Yes, all images of your shop will be automatically converted into the WEBP format. Even images from CMS or other modules like blog.

YES you still need a WEBP module for Prestashop! Because the feature has a bug in PS 8.0. It should be fixed in PS 8.1 but I will check this as soon as it is released because I don't know if JPG images will be displayed to browsers that cannot read WEBP format like Safari (iPhone).

This configuration allows Nginx to automatically detect the most optimized image format supported by the visitor’s browser: AVIF as priority, otherwise WEBP, and if neither is supported, the original image (JPG/PNG). The server rewrites image URLs to redirect them to a compression script (avif.php or webp.php) that generates the file if necessary.

HTTP headers (Vary: Accept, Cache-Control, etc.) ensure that files are properly cached by browsers and proxies, while delivering the best version possible to each user.

Before the section "server", place this code:

# Detect best supported format (AVIF > WEBP > none)
map $http_accept $format_compressor {
    default "";
    "~*avif" "avif";
    "~*webp" "webp";
}

It will tell us if the browser of the visitor can read WEBP images.

You probably have multiple lines of "rewrite" for all images, place the following code just before it:

# AVIF/WEBP priority handling
if ($format_compressor != "") {
    rewrite "^/c/([0-9]+)(\-[_a-zA-Z0-9-]*)/(.*)\.(jpg|jpeg|png)$" /img/c/$1$2.${format_compressor}_compressor last;
    rewrite "^/c/([_a-zA-Z-]+)/(.*)\.(jpg|jpeg|png)$" /img/c/$1.${format_compressor}_compressor last;
    rewrite "^/([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$1$2.${format_compressor}_compressor last;
    rewrite "^/([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$1$2$3.${format_compressor}_compressor last;
    rewrite "^/([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$1$2$3$4.${format_compressor}_compressor last;
    rewrite "^/([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$4/$1$2$3$4$5.${format_compressor}_compressor last;
    rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6.${format_compressor}_compressor last;
    rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7.${format_compressor}_compressor last;
    rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8.${format_compressor}_compressor last;
    rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9.${format_compressor}_compressor last;
    rewrite "^(.+)\.(jpg|jpeg|png)$" $1.${format_compressor}_compressor last;
}

# Location for AVIF
location ~* ^(.+)\.avif_compressor$ {
    add_header Vary Accept;
    add_header Pragma public;
    add_header Cache-Control "public, must-revalidate, proxy-revalidate";
    expires max;
    access_log off;
    log_not_found off;

    set $url_avif_compressor "/modules/jprestaspeedpack/controllers/front/avif.php?src=$1.jpg";
    try_files $1.avif $url_avif_compressor;
}

# Location for WEBP
location ~* ^(.+)\.webp_compressor$ {
    add_header Vary Accept;
    add_header Pragma public;
    add_header Cache-Control "public, must-revalidate, proxy-revalidate";
    expires max;
    access_log off;
    log_not_found off;

    set $url_webp_compressor "/modules/jprestaspeedpack/controllers/front/webp.php?src=$1.jpg";
    try_files $1.webp $url_webp_compressor;
}

WARNING: if you are using the standalone AVIF/WEBP compression module then you must replace 'jprestaspeedpack' by 'jprestawebp'.

Contact me if you need help or if you can improve the script!

​Yes, browsers that cannot read WEBP format will get the original format (JPG/PNG).

The module does not call the Hook which allows the update.

You must modify the imageResize() function in the /modules/prestablog/prestablog.php file:

Replace this

         return ImageManager::write('jpg', $dest_image, $file_after);

By this

         $ret = ImageManager::write('jpg', $dest_image, $file_after);

         Hook::exec('actionOnImageResizeAfter', ['dst_file' => $file_after, 'file_type' => 'jpg']);

         return $ret;

​​Afterwards your images will be updated.

​

No, our module is designed to convert JPG/PNG images to WEBP format. It is recommended to import images as JPG due to compatibility issues with certain browsers that cannot load WEBP files. Additionally, using JPG as original images ensures better quality since Prestashop creates multiple formats and sizes of images based on the original, emphasizing the need for good-quality originals.

The percentage you can adjust in the module corresponds to a quality level rather than a compression percentage. 100% means maximum quality with no loss, while 50% represents reduced quality with greater compression.

As a general rule, 80% offers a good compromise between quality and file size. However, the choice depends on your needs and the type of image used. That is why we provide a comparison tool directly in the Prestashop module.

AVIF is a new, high-performance image format that is more recent than WEBP. It significantly reduces image file sizes while maintaining excellent visual quality.

On average, AVIF compresses images up to 50% more efficiently than WEBP, which already reduces file sizes by 30–40% compared to JPEG. This means a faster website, a better user experience, and improved SEO.

Short answer: If PHP reports AVIF Support => enabled but AVIF files are empty or imageavif() reports that AVIF support is disabled, the problem may be caused by incompatible PHP GD and libgd3 packages. Updating libgd3 to a version compatible with your PHP installation can fix the issue.

Symptoms

When generating AVIF images with PHP GD, you may encounter the following warning:

PHP Warning: imageavif(): AVIF image support has been disabled

The generated .avif files may also be empty (0 bytes).

However, PHP may report that AVIF support is enabled:

php -i | grep -E "GD Support|AVIF Support|WebP Support"

For example:

GD Support => enabled
WebP Support => enabled
AVIF Support => enabled

Cause

This problem can occur when PHP/GD and the system libgd library come from different repositories or incompatible package versions.

For example, PHP and php8.5-gd may come from the Sury repository while libgd3 is still provided by the Ubuntu repository.

You can check the installed versions with:

apt policy php8.5-gd libgd3

Solution

Update libgd3 so that a version compatible with your PHP/GD installation is installed:

sudo apt update
sudo apt install libgd3

If you are using PHP-FPM, restart it afterward, adapting the PHP version if necessary:

sudo systemctl restart php8.5-fpm

Verify the fix

You can test AVIF generation directly from PHP:

rm -f /tmp/test.avif
php -r '$im=imagecreatetruecolor(100,100); var_dump(imageavif($im,"/tmp/test.avif"));'
ls -lh /tmp/test.avif
file /tmp/test.avif

The generated file should no longer be empty and should be identified as an AVIF image.

Note: AVIF Support => enabled in php -i or gd_info() does not necessarily guarantee that AVIF encoding is working correctly. Incompatible GD libraries can cause AVIF generation to fail even when PHP reports AVIF support as enabled.