Investigate and fix crashes and console errors during client-side image upload processing

[adamsilverstein]

Description

During testing of the client-side media processing feature (tracked in #74333), several reports of crashes, console errors, and potential out-of-memory issues have surfaced. These need to be investigated and resolved before wider release. Additionally, we currently lack any benchmarking tooling to establish baseline expectations for processing times, making it difficult to distinguish real regressions from normal variance.

Observed Issues

1. Console errors during AVIF processing

When uploading AVIF images, console errors are consistently produced during conversion. From @sgomes' testing on WordPress 7.0 Beta 5:

These conversions always result in console errors as well, so it's unclear whether they succeeded.

Errors were confirmed across both an M4 Pro MacBook Pro and an HP Chromebook 14 G7.

2. Out-of-memory crashes after repeated uploads

When performing multiple image conversions in succession, out-of-memory crashes occur. @sgomes observed this on the wasm-vips playground and in WordPress:

After a few runs I start getting crashes with out of memory errors (DevTools were closed until it crashed).

This happens on both powerful and modest machines, though it takes more runs to trigger on higher-spec hardware. This suggests memory is not being properly freed between processing runs.

3. HEIC file processing crash

@adamziel reported that processing a HEIC file crashed entirely:

Processing a HEIC file crashed. I've added a client-side script override and then it hang without any photo preview.

4. No benchmarking tooling for processing performance

@sgomes' stopwatch measurements on a MacBook showed variance in end-to-end upload times (particularly for AVIF), but without tooling to isolate client-side processing time from upload time and other factors, it's hard to draw conclusions from these numbers alone. The wasm-vips playground handles AVIF-to-JPEG conversion in ~2.7s on a Chromebook, so we know the underlying library is fast — but we need proper benchmarks to understand where time is actually spent in our integration.

We need benchmarking tooling in tests for client-side media processing to:

• Establish baseline expectations for how long each format/size combination should take to process
• Isolate processing time from upload time so we can measure each independently
• Detect performance regressions in CI
• Provide data-driven answers instead of relying on manual stopwatch measurements

Steps to Reproduce

1. Open WordPress 7.0 Beta 5 (or a Gutenberg build with client-side media enabled)
2. Create a new post
3. Upload an AVIF image and check for console errors
4. Upload several more images (AVIF or JPEG) in succession — note potential crashes
5. Try uploading a HEIC image — success, error, or crash?

Test files from #74333:

• AVIF: https://adamadam.blog/wp-content/uploads/2026/03/Pisa.avif
• HEIC (zipped): attached in Client Side Media iteration for WordPress 7.0 #74333

Investigation Areas

• Identify the source of console errors during AVIF conversion
• Profile memory usage during image processing to find leaks — are WASM memory buffers being properly freed between uploads?
• Investigate why our integration is significantly slower than raw wasm-vips playground performance
• Determine root cause of HEIC processing crash
• Test with bulk uploads (many images at once) to surface additional crash scenarios
• Add instrumentation/logging to measure processing time per step (init, decode, resize, encode, upload)
• Build benchmarking test tooling for client-side media processing that measures processing time per format/size, establishes baselines, and can run in CI to catch regressions

Related

• Client Side Media iteration for WordPress 7.0 #74333 — Client Side Media iteration for WordPress 7.0
• @sgomes' performance testing: Client Side Media iteration for WordPress 7.0 #74333 (comment)
• @adamziel's crash report: Client Side Media iteration for WordPress 7.0 #74333 (comment)

[kleisauke]

libvips may reuse the image from the operation cache after subsequent use, which I suspect could be causing issue (2). You can try disabling this with vips.Cache.max(0).

I'll investigate the other issues later, but issues (1) and (3) could potentially be worked around by reverting PR #76371, which may also help reduce the bundle size.

[adamsilverstein]

libvips may reuse the image from the operation cache after subsequent use, which I suspect could be causing issue (2). You can try disabling this with vips.Cache.max(0).

Thanks for the tip!

I'll investigate the other issues later, but issues (1) and (3) could potentially be worked around by reverting PR #76371, which may also help reduce the bundle size.

We want to keep AVIF support though!

Bundle size won't be as much of a concern for 7.1 when we will be adding several new capabilities as part of the feature, see #76756. It was more a problem for 7.0 with the other large changes, plus the lack of value in the way of new capabilities.

[adamsilverstein]

try disabling this with vips.Cache.max(0).

@kleisauke i'm concerned about the performance hit for setting this at 0. Could we use a small number instead? like vips.Cache.max(50) or vips.Cache.max(100)?