ThriftbyZee Field Notes: Image Quality Is a Backend Problem

Short Field Note — ThriftbyZee

---

I used to think image optimization was a frontend concern. Lazy loading, responsive images, blur placeholders — that's React and CSS, right?

Wrong. In ThriftbyZee, the backend does 80% of the image work. The frontend just consumes what the backend produces.

Three backend decisions that mattered more than any frontend optimization:

1. Pre-generate variants at upload time, not request time.

Generating image variants on-the-fly ("resize on first request") is a classic trap. The first user to view a listing pays the cost of generating 4 variants. On a cold start, this is seconds of latency. We generate all variants in a Celery task at upload time. The request path is pure S3 fetch — fast, predictable, cacheable.

2. Store blur placeholders as data URIs, not separate files.

A blur placeholder is a 20x20 pixel image, heavily compressed. Instead of storing it as a separate file and making another HTTP request, we inline it as a base64 data URI in the API response. The frontend renders it instantly with zero additional network overhead. This is a tiny optimization that eliminates an entire class of perceived slowness.

3. The image pipeline is a product feature, not infrastructure.

Sellers didn't understand "upload high-res images, we'll optimize them." They uploaded 2MB phone photos and wondered why their listings looked bad. We built an upload-time validation pipeline: check resolution (minimum 1200px on shortest side), check aspect ratio (must be 3:4 or 4:3), check for blur (Laplacian variance threshold). If an image fails, the seller gets immediate feedback with specific instructions. This reduced bad listings by 70%.

---

ThriftbyZee is live at [thriftbyzee.com](https://thriftbyzee.com)