Moving Image Processing to the Browser
Converting and resizing photos in the browser, behind an upload queue, kept heavy image work off the server. In testing, 70+ photos went live in under two minutes.
Property photos are large. Phone cameras produce high-resolution files, often in HEIC format, and a listing can have dozens of them.
On RE/AMP I moved the conversion and resizing work out of the server and into the user’s browser.
The problem
If every photo is uploaded at full size and then processed on the server, the server does the heavy work. Many users uploading at once means a lot of CPU and memory spent on images, and slow uploads for everyone.
What I changed
Convert and downscale before upload
The browser converts HEIC files and downsizes each image before it leaves the user’s device. The server receives smaller files in a usable format.
Control the upload rate
Uploads go through a rate-controlled queue. That prevents dozens of simultaneous requests from overwhelming the browser, the network, or the server.
Send directly to storage
Files go to private storage through short-lived upload URLs, so they do not pass through the application server at all. See Private S3 Storage With Pre-Signed URLs.
Result
In testing, 70+ high-resolution photos were processed and live in under two minutes, with no image-processing load on the server.
That figure comes from testing, not from a production benchmark across users and devices.
Tradeoffs
Client-side work depends on the user’s device. Older phones and browsers are slower, and memory limits matter when handling many large images.
The benefit is that the work happens in parallel across users instead of piling up on one server. The queue also keeps a single device from being overloaded.
Takeaway
Do work where the cost is cheapest. For photos, the user’s device already holds the file and has idle capacity, so processing there saves server resources.
For more, see the RE/AMP case study and the code rescue service for performance problems.