I'm a beginner building an image-heavy peer-to-peer marketplace with a Next.js web app and an upcoming Expo mobile app. I currently use Vercel's free tier for hosting, Supabase for the backend, and Cloudflare R2 for photo storage.
My hosting account was recently paused after my Fluid Active CPU usage reached 24 hours, well above the 4-hour free limit. I discovered that my Next.js server downloads every original upload, uses sharp to resize and convert it to WebP, and then uploads the processed file back to R2.
To reduce costs, I'm considering removing sharp from the backend and compressing images in the browser or mobile app before uploading them directly to R2. However, I'm concerned about inconsistent compression, older devices, and browser-specific problems such as Safari failing to create WebP files.
Is client-side compression a sensible approach for an image-heavy service? Would direct uploads, an image-processing service, lazy processing, or an inexpensive alternative be better ways to avoid using up serverless compute hours?
3 Answers
Another option is moving the whole stack to a small fixed-price VPS. A low-cost VPS could run the app, image processing, and supporting services under one predictable monthly bill. It requires more maintenance and has less built-in scaling, but it may be cheaper than exceeding free serverless limits if your traffic is still modest.
The main problem isn’t sharp itself; it’s running image processing inside every Vercel request. Keep sharp if you need it, but move that work somewhere designed for image transformations, such as a managed image service. Since your files are already in R2, a Cloudflare-based image workflow could be a relatively inexpensive fit and would keep the processing off your application server.
Client-side compression is a valid approach, especially for reducing upload size. Have the client resize images to a reasonable maximum dimension, remove EXIF data, and try WebP with a JPEG fallback. Feature-detect WebP support rather than assuming every browser can generate it.
The upload endpoint should ideally only issue a presigned R2 URL and save metadata. The client can then upload directly to R2, so your Next.js server never handles the image bytes. Still validate the stored file’s MIME type, dimensions, and size on the server or through a separate inexpensive worker, because client-side checks can’t be trusted completely.
You can also generate resized variants lazily. Create a particular size only when it is first requested, store that result in R2, and serve it from cache afterward. That avoids processing every possible size during upload and ensures each variant is generated only once.