WordPress Image Optimiser Not Working: LiteSpeed, Elementor and Others

Why WordPress image optimisers stop working

Every WordPress image optimisation plugin does the same three jobs, and a failure in any one of them looks the same from the dashboard: the numbers do not move, or the images on the page are still heavy JPEGs.

1. Queue. When you upload an image, WordPress creates several resized copies (thumbnail, medium, large and any sizes your theme registers). The plugin adds the original and those copies to a queue, usually processed in the background by WP-Cron.
2. Process. The plugin compresses each file and often makes a WebP or AVIF copy. Cloud plugins such as LiteSpeed Cache (through QUIC.cloud) and Elementor's image optimiser send the files, or a link to them, to an external service and fetch the results back. Local plugins use the image libraries in your own PHP, GD or Imagick.
3. Deliver. The smaller file has to reach the visitor. That means rewriting the HTML to point at the new file, wrapping images in a <picture> element, or a server rule that swaps the file when the browser says it accepts WebP.

Most "not working" reports are not a broken plugin. They are a stalled queue, a service that cannot reach your images, a used-up monthly allowance, or new files that exist on disk but are never served because the web server or a CDN ignores the rewrite. Finding which of the three stages has stopped is the whole diagnosis.

Common causes, by symptom

How to diagnose it with a few commands

If you have SSH access, these checks take a couple of minutes and tell you which stage has failed. Replace the paths and domain with your own. On Plesk the site usually lives under /var/www/vhosts/example.com/httpdocs.

1. Were optimised copies created at all?

cd /var/www/vhosts/example.com/httpdocs
find wp-content/uploads -name '*.webp' | wc -l
find wp-content/uploads -name '*.avif' | wc -l
ls -la wp-content/uploads/2026/09/ | head -20

A count of zero means the process stage has never completed. LiteSpeed Cache stores its copies next to the original with an extra extension, for example hero.jpg.webp. Other plugins use hero.webp or a separate folder.

2. Are background jobs running?

grep -n "DISABLE_WP_CRON" wp-config.php
wp cron test
wp cron event list --fields=hook,next_run_relative | grep -iE 'litespeed|image|optim'

If wp cron test fails, or events show as overdue by hours, the queue cannot move. WP-CLI comes with Plesk and most managed hosts.

3. Does the server deliver the new file?

curl -sI -H "Accept: image/webp,*/*" https://example.com/wp-content/uploads/2026/09/hero.jpg | grep -iE 'content-type|vary|cf-cache-status'
curl -s https://example.com/ | grep -oE 'src="[^"]+\.(webp|avif|jpe?g|png)"' | head

The first command shows whether a server rewrite swaps the JPEG for WebP, and whether a Vary: Accept header is sent. The second shows what the page HTML actually references. If the plugin rewrites URLs, you should see .webp addresses in the HTML.

4. Can PHP make WebP and AVIF?

php -r 'echo function_exists("imagewebp") ? "GD WebP yes\n" : "GD WebP no\n";'
php -r 'echo function_exists("imageavif") ? "GD AVIF yes\n" : "GD AVIF no\n";'
php -r 'echo class_exists("Imagick") ? implode(",", Imagick::queryFormats("WEBP")) . "\n" : "no Imagick\n";'

Run these with the same PHP version the site uses. On Plesk that may be /opt/plesk/php/8.3/bin/php rather than the system php, and the two can have different extensions loaded.

LiteSpeed Cache image optimisation not working

LiteSpeed Cache does not compress images on your server. It sends a request to QUIC.cloud, which downloads your originals, processes them and makes them ready to pull back. The image optimisation part works on any web server, not only LiteSpeed, although page caching needs a LiteSpeed server.

• Connection. The site has to be linked to QUIC.cloud from the plugin's general settings. A cloned staging site, a changed domain or a move from http to https can leave the link pointing at the wrong address. Reconnect from the live domain.
• Request and pull are separate. On the image optimisation screen you send a request, and the results are fetched later. If the auto pull cron is off and WP-Cron is not running, finished images sit on QUIC.cloud and never arrive. Turn on the auto request and auto pull options, or press the pull button by hand to test.
• Allowance. The free tier processes a limited number of images and requests are sent in batches. Large libraries take days, not minutes. Check the summary for how many are waiting.
• Blocked downloads. If Cloudflare bot protection, Wordfence, a hosting firewall or hotlink protection blocks unknown visitors to /wp-content/uploads/, QUIC.cloud cannot fetch the originals. Allow its servers or relax the rule for that folder while the queue runs.
• WebP replacement. Creating WebP copies and serving them are separate settings. The replacement option rewrites image addresses in the HTML so visitors receive the .webp file. After switching it on, purge the LiteSpeed cache and any CDN cache, or visitors keep getting the old cached HTML.

Elementor image optimiser and choosing a plugin

Elementor's image optimiser plugin is also a cloud service. It needs the site connected to an Elementor account, works through a monthly allowance on the free plan, and processes existing images through a bulk screen. When it does nothing, check that the site is still connected after any domain change, that allowance is left this month, and that the bulk screen shows no errors against single files.

Elementor's own lazy loading and image settings are separate from compression. If images are compressed but load late or not at all, see loading lazy not working rather than the optimiser.

Choosing an image optimisation plugin for WordPress

Pick one. The best choice is the one whose delivery method suits your server: URL rewriting in the HTML works everywhere, while Accept-header rewrites need server rules. For format choices see image format fixes, and for the wider WordPress picture see image fixes in WordPress.

Server and CDN notes: Apache, nginx, Plesk and Cloudflare

Plugins that swap files based on the browser's Accept header write their rules to .htaccess. That works on Apache and LiteSpeed. It does nothing on nginx, which never reads .htaccess.

Apache or LiteSpeed (.htaccess)

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule ^(wp-content/uploads/.+\.(?:jpe?g|png))$ $1.webp [T=image/webp,L]
</IfModule>
<IfModule mod_headers.c>
<FilesMatch "\.(jpe?g|png)$">
Header append Vary Accept
</FilesMatch>
</IfModule>

nginx

The map block belongs in the http context, for example in its own file under /etc/nginx/conf.d/. The location block goes in the site's server configuration. This version suits copies named hero.jpg.webp:

map $http_accept $webp_suffix {
    default   "";
    "~*webp"  ".webp";
}

location ~* ^/wp-content/uploads/.+\.(png|jpe?g)$ {
    add_header Vary Accept;
    try_files $uri$webp_suffix $uri =404;
}

Test with sudo nginx -t and reload with sudo systemctl reload nginx.

Plesk

In Apache and nginx Settings, the option to serve static files directly by nginx means JPEG and PNG requests never reach Apache, so the plugin's .htaccess rules are skipped. Either remove jpg, jpeg and png from that list, or add the nginx rules above. The additional nginx directives box sits inside the server block, so put the map in a file under /etc/nginx/conf.d/ instead.

Cloudflare and other CDNs

Standard Cloudflare plans do not keep separate cached copies of an image for each Accept value, so an Accept-based swap behind the CDN can cache whichever version was requested first. Behind a CDN, prefer a plugin mode that rewrites the image URLs in the HTML to .webp files, then purge the cache. More on this in image CDN fixes.

The fix, step by step

Edge cases worth knowing

• Background images in CSS. HTML rewriting does not reach images set in stylesheets or by a page builder's background setting. These stay as JPEG unless the plugin also rewrites CSS or you swap them by hand.
• Images from another domain. Plugins only optimise files in your media library. Images pulled from a different site or a third-party embed are untouched.
• Visually worse images. Aggressive or lossy modes can add artefacts to product photos and text in images. Use a balanced mode and compare a few files at full size.
• The hero is now lazy-loaded. Some optimisation plugins also switch on lazy loading for every image. That can slow the first screen; see the LCP guide.

Keeping image optimisation working

1. Set up a real server cron that triggers WP-Cron every five minutes, so queues move even when the site has no visitors.
2. Keep one optimiser active, and note in your site records which plugin owns compression, WebP and lazy loading.
3. After any domain change, staging push or migration, reconnect the cloud service and check the allowance.
4. Once a month, run the curl check on a recent upload and spot-check a page's HTML for .webp or .avif addresses.
5. Resize originals before upload. A 6,000 pixel photo compressed well is still far heavier than a 2,000 pixel one; see image size fixes.

For the speed effect of all this across your theme, the WordPress page speed guide covers caching and scripts alongside images.