Images rendering as "broken icons" in screenshots (WordPress/LiteSpeed/WebP) despite magic=true and wait_for_images=true

[souzadavi]

Describe the bug / question
Hi team! First of all, thank you for the amazing tool. I'm using the Crawl4AI Docker image (unclecode/crawl4ai:0.8.0) to capture full-page screenshots of WordPress websites, but I'm consistently getting "broken image icons" instead of the actual pictures, especially on heavy gallery sites using LiteSpeed Cache and .webp images.

To Reproduce
Target URL: https://xxxxxx.br/
Endpoint: POST /screenshot (or /crawl)

I am sending the following payload directly via curl to the container:

JSON

{
  "url": "https://xxxxxx.br/",
  "output_path": "/screenshots/test_native.png",
  "screenshot_wait_for": 10,
  "magic": true,
  "wait_for_images": true,
  "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36"
}

What I have already tried (without success):

Using the magic: true and wait_for_images: true parameters.

Injecting custom js_code to force smooth scrolling to the bottom (triggering lazy loads), removing loading="lazy" attributes, and forcing data-src to src.

Appending a cache-buster query string (?bypass=123) to bypass LiteSpeed Cache.

Saving the file directly to a mapped Docker volume (output_path) instead of parsing the Base64 response to avoid encoding issues.

Expected behavior
The screenshot should render the gallery images completely.

Actual behavior
The page layout, fonts, and background colors load perfectly, but all the gallery images (.webp formats) render as native broken image icons.

My environment:

• Docker deployment (Ubuntu VPS).
• Image: unclecode/crawl4ai:0.8.0.
• Limits: shm_size: '2gb', memory: 1536M.

Questions:

• Is there a known limitation with the internal headless Chromium engine regarding .webp decoding or specific LiteSpeed lazy-load mechanisms?
• Are there any hidden parameters or specific js_code patterns you recommend for aggressive WordPress galleries?

Thanks in advance for the help!

[hafezparast]

This is likely a lazy-loading issue, not a WebP decoding issue. Headless Chromium supports WebP fine — the problem is that WordPress/LiteSpeed lazy-load plugins use data-src instead of src, and the images only swap to real src when they enter the viewport via scroll.

The current wait_for_images=true only checks img.complete, which returns true even for broken images (images with no valid src). It doesn't trigger the lazy-load swap.

Try this approach — use js_code to force all lazy-loaded images to load before the screenshot:

{
  "url": "https://xxxxxx.br/",
  "output_path": "/screenshots/test.png",
  "screenshot_wait_for": 5,
  "wait_for_images": true,
  "scan_full_page": true,
  "scroll_delay": 1.0,
  "js_code": [
    "document.querySelectorAll('img[data-src]').forEach(img => { img.src = img.dataset.src; });",
    "document.querySelectorAll('img[data-lazy-src]').forEach(img => { img.src = img.dataset.lazySrc; });",
    "document.querySelectorAll('img[loading=lazy]').forEach(img => { img.loading = 'eager'; });",
    "document.querySelectorAll('noscript').forEach(ns => { const tmp = document.createElement('div'); tmp.innerHTML = ns.innerHTML; tmp.querySelectorAll('img').forEach(img => document.body.appendChild(img)); });",
    "await new Promise(r => setTimeout(r, 3000));"
  ]
}

Key points:

• scan_full_page: true with scroll_delay: 1.0 scrolls the page slowly, which triggers viewport-based lazy loaders
• The js_code then force-swaps data-src → src for any remaining images that didn't trigger
• noscript tag handling covers LiteSpeed's fallback pattern where real image tags are hidden inside <noscript>
• The 3s wait gives images time to actually download after the swap

If that doesn't work, also try adding "delay_before_return_html": 10 for an extra wait after everything.

The root cause is that wait_for_images should ideally also handle data-src → src swapping automatically. That could be a good enhancement — happy to look into a PR if this workaround confirms the diagnosis.