Good afternoon! Two answers:
Speed. With the default settings the queue is deliberately gentle, so on a large library it’s slow. The right way to speed it up — without risking overloading your server — is to let the plugin measure your actual hardware first:
- In the plugin settings, run the Benchmark. It converts a sample image using the same encoder your site really uses and times it, then suggests a safe “Images per batch” value tuned to your server. Use that suggested number rather than just maxing it out — that keeps you fast without pushing the server into timeouts.
- Then lower “Cron interval (minutes)” (e.g. to 1–2 minutes) so batches run more frequently.
- For a big initial backlog like yours, I’d also set up a real server cron hitting wp-cron.php on that interval — otherwise processing depends on visitor traffic, which is unreliable for bulk work. A server cron drives the queue steadily around the clock.
One honest caveat: AVIF encoding is CPU-intensive, and 26,000 images is many more actual files once you count all the thumbnail sizes — so even tuned well, a library this size is a multi-day job. But benchmarking + a server cron will make a big difference versus the default pace, and the plugin also auto-reduces the batch if it detects memory or time pressure, so it won’t crash the site.
Media library indicator. You’re right — there’s currently no per-image marker in the Media Library. For now, track progress on the plugin’s own dashboard, which shows converted versus total. A “converted” column in the Media Library is a good idea, and I’ll add it to the roadmap.
Thanks for the questions!
Marco
I-PR AVIF Converter
Could you also tell me why this indicator is so low? And where is the photo list? That part doesn’t scroll for me — is that supposed to happen?
https://prnt.sc/p8oLeq2YZjz6
https://prnt.sc/LHCFp8Dh3oze
And for some reason, browsers aren’t serving AVIF; please take a look and see what’s going on.
Good questions — let me take them one at a time.
1. Why the score is “only” 67. Nothing’s wrong — 67 is already in the “Good” band, and it will climb as you convert more. The score is a weighted proxy: estimated LCP improvement (50%), bandwidth savings (30%), and a Core Web Vitals component (20%). Part of that CWV component only unlocks once at least half of your library is converted. You’ve only just started on 26,000 images, so a chunk of the score is still “unrealized” — it reflects that the job is early, not that the conversion quality is poor. Your underlying numbers are excellent (71% efficiency, 100/100 CWV proxy, 1.21 GB saved, 0% failures). As the queue works through the library, the score rises on its own.
2. The photo list that doesn’t scroll. That panel is a “Top 20 biggest savings” list, not the full library — so it’s not meant to scroll; it just shows your 20 largest wins. There isn’t a complete per-file list in the dashboard yet (a full converted-files view is something I’m planning to add).
3. AVIF not being served. With only a small fraction of 26,000 done so far, the most likely reason is simply that the specific images on the page you’re viewing haven’t been converted yet — for those, the plugin correctly serves the original until their turn in the queue. To check properly: pick an image you know is converted (one from the Top 20 list), open its .avif URL directly in the browser, and see what happens:
- If it downloads as text or won’t display, your server isn’t sending the right content type. On your host, add this one line to .htaccess: AddType image/avif .avif — then clear your cache.
- If it displays fine on its own but the page still serves the original, it’s a caching layer — purge your page cache / CDN.
- If the image simply isn’t converted yet, it’ll switch to AVIF automatically once the queue reaches it.
Tell me which of those three you see and I can point you to the exact fix.
Marco
I-PR AVIF Converter
I mean, when I check it via the console, it shows JPEG, but the page already displays AVIF everywhere. And I also wanted to ask, are background images processed the same way?
Good — “AVIF everywhere” is exactly what should happen, and the JPEG you see in the console is expected, not a problem. Here’s why: the plugin wraps images in a tag. The inner ![]()
keeps the original JPEG in its src as a fallback for older browsers, so that’s what you see in the Elements/HTML panel. But a modern browser reads the and actually downloads the AVIF. If you open the browser’s Network tab (instead of Elements) and reload, you’ll see the real requests are .avif files. So it’s working correctly — the JPEG in the markup is just the safety net.
On background images: partially. The plugin converts CSS background-image URLs for Gutenberg blocks (it rewrites the url() inside the block’s inline style). But background images set through Elementor or your theme are a different case — Elementor applies them via its own generated CSS / widget styles, which don’t pass through the filter the plugin uses, so those aren’t converted yet. Your regular content images (the ![]()
tags) are all handled, which is why the page looks fully AVIF — it’s specifically Elementor/theme CSS backgrounds that currently stay as the original.
Extending background-image conversion to cover Elementor and theme CSS is on my list, but it’s a bigger piece of work, so I don’t want to promise a date. For now: content images and Gutenberg block backgrounds = AVIF; Elementor/theme CSS backgrounds = original for the moment.
Thanks for the thoughtful questions!
Marco
I-PR AVIF Converter
I’m having a problem with one PNG image on the main page. I’ve added it to the exclusion list, but the background is still black. I’m setting the background manually, but it doesn’t change.
https://prnt.sc/RXQ1bSp7pp8s
Thanks — I can see what’s happening. That PNG has a transparent background, and the black you’re seeing is the transparency being lost during AVIF conversion. On your server, ImageMagick’s AVIF encoder isn’t preserving the alpha channel, so transparent areas come out black. (Converting it to JPG wouldn’t help — JPG has no transparency at all, so it would just bake in a background permanently.)
Why excluding it didn’t fix it: adding the image to the exclusion list stops it from being re-converted, but it doesn’t remove the broken .avif that was already generated — and that file (plus your cache) is still being served. So to fix it right now:
- Make sure the image is in the exclusion list (so it won’t be re-converted). If you have several transparent PNGs, you can also enable the “Skip PNG” option in settings.
- Remove the already-generated .avif for that image. The quickest way is the “Delete generated images (revert)” button on the settings page (it removes generated AVIF/WebP and leaves your originals untouched) — or, if you want to remove just that one, delete its .avif file next to the original via FTP.
- Purge your cache / CDN so the original PNG is served again.
After that, the transparent PNG will display correctly.
Longer term, I’m going to make the plugin detect transparent images and handle the alpha channel properly (or skip them automatically) so this doesn’t happen silently on servers whose AVIF encoder drops transparency. Thanks for flagging it — transparency handling is exactly the kind of edge case that’s easy to miss.
Marco
I-PR AVIF Converter
