Magento 2 Image Resize via Queue instead of the First Page View
SKU: IMAGERESIZEQUEUE1
- precompute image variants through queue and cron
- sizes from the view.xml of the active theme
- priority for new products, time window and load limit
- dashboard with progress, failure reason and retries
Einmaliger Kauf · inkl. 12 Monate Updates · zzgl. MwSt.
Magento 2 Image Resize: image sizes in advance, not on first view
With Magento 2 Image Resize from Mironsoft you precompute product image variants in a queue instead of leaving the work to the first visitor. By default Magento creates the sizes for listing, detail page and cart only when a page is first viewed. That costs time, burdens the CPU and slows down exactly the pages you have just imported. The module puts jobs into a queue, processes them by cron or queue consumer and shows progress in the admin. Magento 2 Image Resize then runs outside of visitor requests.
Precompute via queue
New and changed product images are queued and converted into all required sizes in the background.
Sizes from the theme
The module reads the image sizes from the view.xml of the active theme, so only variants that are really needed are created.
Priority
New and changed products go before the old catalog. Categories with heavy traffic can be favoured.
Progress
The admin dashboard shows open, running and finished jobs as well as the error rate.
Retries
Failed jobs are retried automatically. Broken source files are reported, not silently skipped.
Time window
Processing can be limited to quiet hours and capped per run.
Why Magento 2 Image Resize works better in the background
After a product import the first visitor of a category often sees a sluggish page because Magento is creating dozens of images at that moment. Anyone who searches for slow Magento 2 product images or how to generate the Magento 2 image cache knows the problem. The standard command for regenerating all images is a one-off, heavy run on the command line.
With Magento 2 Image Resize via queue the work is spread out. Small batches are processed continuously, the server stays responsive and the first visitor receives variants that already exist. That improves load time and protects the server without slowing down the import.
Queue and process Magento 2 Image Resize jobs
As soon as a product image is uploaded, replaced or created by an import, the module puts a job into the queue. A consumer or cron processes the jobs in adjustable batches. Duplicate jobs for the same image are merged. If an image already exists in all sizes, the job is skipped. That keeps the load even and avoids unnecessary work.
- Job on upload, replacement and import
- Duplicate jobs are merged
- Batches with adjustable size per run
Image sizes from the theme and order of processing
The module reads the image types and dimensions from the view.xml of your theme and computes only those variants. If you change the theme, a check detects which sizes are missing and queues them. You control priority by recency and category: freshly imported products and bestsellers come first. For the old catalog there is a separate slow pass in the background.
- Only sizes from the active theme view.xml
- Queue missing variants after a theme change
- Priority by recency and category
See progress, understand errors, retry
The dashboard shows how many jobs are open, running and done and how long the current backlog is expected to take. If a job fails, the reason appears in the list: source file missing, file damaged, memory limit reached. The module retries several times with a pause and then sets the job to failed so it does not return forever. From the list you can restart jobs by hand.
- Dashboard with open, running and finished jobs
- Failure reason per job
- Limited retries with a pause
Run Magento 2 Image Resize in a time window with storage control
Define the hours in which Magento 2 Image Resize may run, for example only at night, and how many jobs per minute the server can take. A memory guard stops the run before the PHP limit is exceeded. In addition you can find image variants that no theme uses any more. You see these leftovers as a list and remove them deliberately, never automatically.
- Set the hours for processing
- Memory guard before the PHP limit
- List of unused variants for deliberate removal
Where Magento 2 Image Resize via queue helps in daily work
Typical situations in shops with many product images.
Large import
After importing thousands of products Magento 2 Image Resize makes sure the image variants are ready before the first customer opens the category.
Theme change or relaunch
New image sizes in the theme are recomputed systematically without anyone starting a command on the server.
New products every day
Dropshipping and marketplace shops with constant updates keep image output stable, without load spikes.
Weak server
If CPU is scarce, limit jobs per minute and process only at night.
Magento 2 Image Resize: creation at first view versus queue
What changes for visitors and the server.
| Topic | Without module | With Mironsoft Image Resize Queue |
|---|---|---|
| First view | Images are created on page view | Variants are already in place |
| Server load | Spikes from visitors and imports | Even, in batches and time windows |
| Recalculation | One-off command line run | Continuous, only what is missing |
| Errors | Images missing without a hint | Failure reason and retries in the list |
| Overview | None | Dashboard with progress and backlog |
How we set up Magento 2 Image Resize for you
The process after you order.
Consultation
You tell us the time window, priorities and the load your server can take.
Installation
We install the module, set up Magento 2 Image Resize with a queue consumer or cron and read the image sizes of your theme.
First pass
The old catalog is precomputed in small batches while we watch load and memory.
Test
We import test products and check Magento 2 Image Resize: the variants exist before the first page view.
Handover
Your team gets an introduction to the dashboard, error list and time window.
Difference to lazy loading, image formats and cache warming
The Mironsoft lazy loading decides in the browser when an image is loaded. Magento 2 Image Resize decides when the variants are created on the server. The choice of image formats and compression is a topic of its own, and the cache warmer warms pages, not images. All modules can be combined.
The module works in the backend and does not change the Hyvä theme or the storefront.
No download, personal setup instead
Image Resize Queue is not listed here as a ready-made download file for self-installation. The purchase is a service commission: we get in touch after the purchase, install the module in your shop and agree on time window, priority and batch size together with you.
Frequently asked questions
Everything about the queue, sizes, errors and how the purchase works.
How can I have Magento 2 images resized in advance?
How does the module know which image sizes are needed?
What happens with a damaged or missing source image?
Can I restrict processing to the night?
Does this replace the Magento command for regenerating images?
How much storage do the variants need?
Does Magento 2 Image Resize work with Hyvä?
Does it work with a CDN?
How is this different from lazy loading?
Can I download and install the module myself?
Recently Viewed Products
Magento 2 Image Resize – Mironsoft Image Resize Queue