WordPress 7.1 client-side media processing uses a browser upload queue and Web Workers. The documented design caps concurrent uploads and processing operations, but large files, animated GIF conversion, device memory, browser support, offline transitions, and plugin hooks can still expose stalls or fallback differences.
Use this for agencies, hosts, media-heavy publishers, ecommerce teams, and plugin developers testing WordPress uploads across desktop, mobile, Chromium, Safari, Firefox, modern formats, and constrained devices.
Quick answer
Build a matrix by browser, device, memory, connection, file type, pixel count, and batch size. Record queue position, active upload count, active processing count, worker memory, processing time, bytes, retry, fallback reason, server load, attachment result, and user-visible responsiveness. Compare the same files with client processing enabled and disabled.
What to check first
- Record WordPress Beta 4 build, browser and version, operating system, device memory, CPU, network profile, client-processing gate, CSP, isolation headers, media plugins, and server image library.
- Use controlled JPEG, PNG, HEIC, AVIF, WebP, transparent GIF, opaque animated GIF, Ultra HDR, large panorama, corrupt file, and unsupported-format fixtures with known hashes and sizes.
- Test single upload, five-file batch, ten-file batch, duplicate names, tab backgrounding, screen lock, offline transition, reconnect, slow network, memory pressure, worker failure, and browser fallback.
- Capture queue slot, processing worker count, upload count, peak browser memory, main-thread responsiveness, process time, transfer bytes, retries, fallback, PHP memory, server CPU, and final attachment state.
- Set an operational support boundary by device class, document expected fallback, fix plugin or CSP blockers, and keep large-media guidance aligned with measured user experience.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Define device and file fixtures | Record WordPress Beta 4 build, browser and version, operating system, device memory, CPU, network profile, client-processing gate, CSP, isolation headers, media plugins, and server image library. | Peak upload and processing concurrency never exceeds the intended limits. |
| Measure queue and worker state | Use controlled JPEG, PNG, HEIC, AVIF, WebP, transparent GIF, opaque animated GIF, Ultra HDR, large panorama, corrupt file, and unsupported-format fixtures with known hashes and sizes. | Low-memory and fallback browsers complete or fail with a recoverable user-facing result. |
| Inject network and memory stress | Test single upload, five-file batch, ten-file batch, duplicate names, tab backgrounding, screen lock, offline transition, reconnect, slow network, memory pressure, worker failure, and browser fallback. | Retries and reconnect create one attachment per fixture with correct files and metadata. |
| Compare browser fallback | Capture queue slot, processing worker count, upload count, peak browser memory, main-thread responsiveness, process time, transfer bytes, retries, fallback, PHP memory, server CPU, and final attachment state. | Client and server paths produce acceptable dimensions, format, quality, orientation, and plugin effects. |
Why this usually happens
- Browser memory pressure varies sharply by device and file dimensions.
- Animated media conversion can use a different worker and codec path from still images.
- Unsupported browsers fall back to server-side processing and produce different timing or output.
- A plugin hook can run twice or start expensive work for each metadata phase.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
device: mobile-4gb
browser: chromium
files: 10
active_uploads_peak: 5
active_processors_peak: 2
peak_memory_mb: 1380
main_thread_long_task_ms: 84
fallbacks: 0
failed_files: 0
median_total_seconds: 18.4
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Define device and file fixtures
- Measure queue and worker state
- Inject network and memory stress
- Compare browser fallback
- Publish support thresholds
Decision rule
Pass when supported devices finish intended files within documented memory and responsiveness limits, queue caps hold, retries preserve identity, fallback is understandable, and attachment output remains correct.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Peak upload and processing concurrency never exceeds the intended limits.
- Low-memory and fallback browsers complete or fail with a recoverable user-facing result.
- Retries and reconnect create one attachment per fixture with correct files and metadata.
- Client and server paths produce acceptable dimensions, format, quality, orientation, and plugin effects.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, background work, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer files into tickets or screenshots.
- Do not close the test until the final user-visible state and the server-side evidence agree.
Questions teams ask during testing
Is total upload bandwidth always lower?
No. Client processing can upload the original plus sub-sizes. Measure transfer and serving benefits separately.
Should one desktop pass define support?
No. Include mobile, low-memory, unsupported-browser, offline, and batch scenarios.
When HandL WP should help
Bring in HandL WP when a production checkout, form, editor, security gate, media pipeline, or paid lead workflow is at risk. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, profile WordPress media upload performance.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references