Delayed Image Import — Frequently Asked Questions
What does this plugin actually do?
It splits “import the products” from “download the images”. Your import writes each image’s URL to post meta and finishes in a fraction of the time; the plugin then downloads the images slowly in the background (a cron batch every minute) and via WP-CLI, while visitors see the real images immediately served straight from the supplier’s URL. Once an image is downloaded locally, the local copy is served from then on.
Why is Delayed Image Import actually needed?
Because fast importers created a new problem. With Super Speedy Imports, the import itself is now so quick that the image requests become a firehose: thousands of downloads fired at the supplier’s server or CDN in a few minutes, from one IP. Image providers read that as abuse — you get rate-limited, 403’d, or banned outright, and suddenly half your catalogue has no images and the supplier won’t talk to your server any more. (Slow importers never surfaced this because they trickled requests out over hours by accident.)
Delayed Image Import fixes both ends at once. The import gets even faster, because it stops downloading images entirely. And the image requests get slower and politer: the background queue fetches them in small batches, round-robining across supplier domains so no single server gets hammered, backing off automatically when a host starts failing. In the meantime your visitors aren’t staring at placeholders — the images are hot-linked from the supplier’s own URLs from the very first page view, then swapped to local copies as the queue works through them.
The point is not just speed. It is that a fast importer downloading images inline looks exactly like an attack to the supplier’s CDN — and a banned supplier costs you the whole catalogue’s imagery.
Why is downloading images during import so slow anyway?
Images dominate import time. A 50,000-product import might move a few hundred MB of CSV data but tens of GB of images, one HTTP request per image, plus thumbnail generation for each. That’s hours of wall-clock time and exactly the access pattern that gets your server rate-limited or blacklisted by image CDNs. Deferring turns a 4-hour import into minutes, and spreads the downloads politely over time with per-domain round-robin.
Do visitors see placeholders until images are downloaded?
No. The renderer outputs the supplier’s real URL in the <img src>, so visitors (and search engines) see the actual product image from the first page view — served from the supplier’s CDN. There’s no JavaScript, no AJAX, no loading spinner. If the supplier’s URL fails in the browser, a neutral SVG placeholder is swapped in via onerror.
I use Super Speedy Imports — do I need to configure anything?
No. With both plugins active, deferring is on by default (DII 2.26+ with SSI 2.72+): map your image columns in SSI as normal and the URLs are redirected to the delayed meta keys automatically at run time. To opt a specific import out, un-tick Defer image downloads in that import’s Additional Options panel. SSI’s “Only refresh images” mode always downloads inline regardless.
I use WP All Import / another importer — does it work?
Yes, with any importer that can write custom post meta. Map your featured-image URL column to the delayed_image_url meta key and your gallery URLs (pipe-separated) to delayed_gallery_image_urls, and make sure the importer’s own image handling is switched off. Optional alt / title / caption / description keys are documented in the Quick Start Guide.
How long until all my images are downloaded?
With the default settings (one cron tick per minute, batch of 100 posts), roughly 6,000 posts’ worth of images per hour — so a 50,000-product catalogue drains overnight. In a hurry? wp dii load-all downloads everything now with a progress bar. Most-viewed products are always downloaded first, so the images your visitors actually look at hydrate ahead of the long tail.
Why are my gallery URLs separated by pipes and not commas?
Because supplier URLs routinely contain commas in their query strings, and a comma-splitter mangles them. Pipe (|) is the only supported separator — it never legitimately appears un-encoded in a URL.
Will the same image be downloaded once per product that uses it?
No. Before downloading, the plugin checks whether an attachment already exists for that exact URL and reuses it — 100 products sharing one image produce one attachment. The Loaded Images tab shows a “Dupes” count per URL so you can spot anything that slipped through (exact-URL matching means the same image at two different URLs still downloads twice).
What happens when a download fails?
It’s retried automatically up an escalating-timeout ladder: the timeout starts at 3 seconds and doubles on each failure (3, 6, 12, 24) up to a 30-second ceiling — effectively “no timeout” for an image — with the wait between retries growing each time so nothing gets hammered. Three failures at the ceiling mark the image failed; it stops being retried and appears in the Failed Images tab with its reason, attempt count, a live preview of the remote URL and one-click Retry / Dismiss actions. wp dii retry-failed re-queues failures with a completely fresh ladder once you’ve fixed the source.
Does it hammer my supplier’s server?
The opposite — that’s half the point. Every download path (the background cron AND the bulk WP-CLI commands) round-robins across image domains, one image at a time — even a single product’s 12-image gallery is interleaved across suppliers rather than fired at one host back-to-back. A host that keeps failing trips a circuit breaker with an escalating backoff (2 minutes doubling up to an hour), so dead suppliers aren’t hammered every tick either. And the batch/interval settings cap the overall rate. Compare that with a normal import firing thousands of requests at one supplier in minutes. There’s a full guide to the round-robin, circuit breaker and timeout system — see How Delayed Image Import Works Under the Hood.
Some images show a placeholder in the browser but download fine via CLI — why?
Your supplier blocks hot-linking: they refuse browser requests coming from your domain while allowing server-side downloads. Add that hostname to Settings → Hot-link blocklist so the plugin skips the doomed browser request and shows the SVG until the local copy exists. The background downloads are unaffected.
Can I serve images from the supplier forever and never download them?
Yes — un-tick Enable cron in Settings and don’t run the CLI commands. Images then only exist as remote URLs. Bear in mind you’re depending on the supplier’s uptime and their tolerance for hot-linking, and you’re forgoing local thumbnails/srcset. Most shops should let the downloads happen.
- You need local thumbnails and srcset for Core Web Vitals
- Your supplier’s tolerance for hot-linking is unknown or already strained
- You cannot accept product images disappearing if the supplier goes down or reorganises their CDN
What’s the difference between Delayed Image Import and External Images?
Where the images end up. With Delayed Image Import, every image eventually ends up on your site: the supplier’s URL is a temporary bridge, and the background queue works through it until each image is an ordinary WordPress attachment in your media library. With External Images, they never do — the images stay wherever they already live (a CDN, Amazon S3, a Digital Ocean space, an affiliate feed) and are served from there permanently. Nothing is ever downloaded.
| Delayed Image Import | External Images | |
|---|---|---|
| Where images end up | In your media library, as normal attachments | Never on your server |
| Remote URLs are | A temporary bridge while the queue drains | The permanent arrangement |
| Disk usage | The same as a normal import, just spread over time | Effectively none |
| Thumbnails / srcset | Generated locally once hydrated | Served from the remote source |
| Depends on the source staying up | Only until the backlog drains | Always |
| Deactivate it later and | Hydrated posts keep working | Images stop resolving |
So Delayed Image Import is a transition and External Images is a destination. Choose Delayed Image Import when you want to own the files and you just don’t want the import to wait for them. Choose External Images when you deliberately never want them on disk — a huge or constantly-changing affiliate catalogue where downloading is pointless, or where disk cost is the actual problem. External Images is also the right tool for the previous question: you can approximate “serve from the supplier forever” by turning the cron off here, but External Images does it properly, with an SSL image proxy and full support for WooCommerce variations and galleries.
The two solve different problems and are not alternatives to each other. If your images belong on your site and the import is the bottleneck, that’s Delayed Image Import. If your images belong somewhere else permanently, that’s External Images.
Is it safe to deactivate the plugin?
Deactivate after the backlog is drained and everything just keeps working — hydrated posts are normal WordPress attachments with no dependency on this plugin. Deactivate while images are still delayed and those posts show no image (the renderer that serves the remote URLs is gone; the meta remains, so reactivating picks up where it left off). Rule of thumb: run wp dii pending, and if the counts aren’t zero, run wp dii load-all before deactivating.
Does it change my theme or my images’ quality?
No theme changes — it works through standard WordPress and WooCommerce filters. Downloaded images are full originals with all registered thumbnail sizes generated at download time, identical to what a normal import would have produced.
Where do I see what’s pending, loaded, or failed?
Super Speedy → Delayed Image Import. The Status tab has a progress bar, image-level counts, throughput with an ETA, a cron heartbeat and per-supplier stats — auto-refreshing while images are pending — plus Process-a-batch-now and Pause buttons; Delayed Images lists what’s still queued (most-viewed first, each with a “Hydrate now” action); Loaded Images lists every downloaded attachment with its remote and local URL; Failed Images lists failures with reasons, previews and Retry / Dismiss actions. There’s also a dashboard widget, an admin-bar pending count, and two Site Health checks. On the CLI, wp dii status --watch and wp dii failed give the same picture.
Comments