Title: Photo processing speed
Last modified: August 9, 2026

---

# Photo processing speed

 *  Resolved [Kiryamboff](https://wordpress.org/support/users/kirill1986/)
 * (@kirill1986)
 * [1 month, 2 weeks ago](https://wordpress.org/support/topic/photo-processing-speed/)
 * Good afternoon! Tell me, I started converting the images, and in half a day only
   1,300 photos have been converted, including the thumbnails, out of 26,000. Is
   this normal speed, or do I need to do something to speed things up? And one more
   question: is there any indication in the media files that the photo has been 
   converted? I looked through them, but I didn’t see anything.
 * The page I need help with: _[[log in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fphoto-processing-speed%2F%3Foutput_format%3Dmd&locale=en_US)
   to see the link]_

Viewing 8 replies - 1 through 8 (of 8 total)

 *  Plugin Author [Marco Di Giacomantonio](https://wordpress.org/support/users/marcodigiacomantonio/)
 * (@marcodigiacomantonio)
 * [1 month, 2 weeks ago](https://wordpress.org/support/topic/photo-processing-speed/#post-18988438)
 * 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:
    1. 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.
    2. Then lower “Cron interval (minutes)” (e.g. to 1–2 minutes) so batches run more
       frequently.
    3. 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
 *  Thread Starter [Kiryamboff](https://wordpress.org/support/users/kirill1986/)
 * (@kirill1986)
 * [1 month, 2 weeks ago](https://wordpress.org/support/topic/photo-processing-speed/#post-18989036)
 * 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://translate.google.ru/)
   [https://prnt.sc/p8oLeq2YZjz6](https://prnt.sc/p8oLeq2YZjz6)
 * [https://prnt.sc/LHCFp8Dh3oze](https://prnt.sc/LHCFp8Dh3oze)
 *  Thread Starter [Kiryamboff](https://wordpress.org/support/users/kirill1986/)
 * (@kirill1986)
 * [1 month, 2 weeks ago](https://wordpress.org/support/topic/photo-processing-speed/#post-18989038)
 * And for some reason, browsers aren’t serving AVIF; please take a look and see
   what’s going on.
   [](https://translate.google.ru/)
 *  Plugin Author [Marco Di Giacomantonio](https://wordpress.org/support/users/marcodigiacomantonio/)
 * (@marcodigiacomantonio)
 * [1 month, 2 weeks ago](https://wordpress.org/support/topic/photo-processing-speed/#post-18989237)
 * 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
 *  Thread Starter [Kiryamboff](https://wordpress.org/support/users/kirill1986/)
 * (@kirill1986)
 * [1 month, 2 weeks ago](https://wordpress.org/support/topic/photo-processing-speed/#post-18989437)
 * 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?
   [](https://translate.google.com.tn/?hl=ru&tab=TT)
 *  Plugin Author [Marco Di Giacomantonio](https://wordpress.org/support/users/marcodigiacomantonio/)
 * (@marcodigiacomantonio)
 * [1 month, 2 weeks ago](https://wordpress.org/support/topic/photo-processing-speed/#post-18989699)
 * 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
 *  Thread Starter [Kiryamboff](https://wordpress.org/support/users/kirill1986/)
 * (@kirill1986)
 * [1 month, 2 weeks ago](https://wordpress.org/support/topic/photo-processing-speed/#post-18989733)
 * 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](https://prnt.sc/RXQ1bSp7pp8s)
 *  Plugin Author [Marco Di Giacomantonio](https://wordpress.org/support/users/marcodigiacomantonio/)
 * (@marcodigiacomantonio)
 * [1 month, 2 weeks ago](https://wordpress.org/support/topic/photo-processing-speed/#post-18989774)
 * 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:
    1. 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.
    2. 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.
    3. 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

Viewing 8 replies - 1 through 8 (of 8 total)

You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fphoto-processing-speed%2F%3Foutput_format%3Dmd&locale=en_US)
to reply to this topic.

 * ![](https://ps.w.org/ipr-avif-converter/assets/icon-256x256.png?rev=3535303)
 * [I-PR AVIF Converter – Automatic Image Optimization](https://wordpress.org/plugins/ipr-avif-converter/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/ipr-avif-converter/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/ipr-avif-converter/)
 * [Active Topics](https://wordpress.org/support/plugin/ipr-avif-converter/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/ipr-avif-converter/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/ipr-avif-converter/reviews/)

 * 8 replies
 * 2 participants
 * Last reply from: [Marco Di Giacomantonio](https://wordpress.org/support/users/marcodigiacomantonio/)
 * Last activity: [1 month, 2 weeks ago](https://wordpress.org/support/topic/photo-processing-speed/#post-18989774)
 * Status: resolved