Why should you compress images before storing them, and should you do it in the browser or on the server?

The interviewer wants to know that you understand how images affect storage size and page load speed, and whether you think about the details that are easy to get wrong when processing images.

The main reason is that original photos from a phone or screenshots are often several MB to tens of MB, while the page shows them a few hundred pixels wide. Storing the originals fills your storage fast (free plans often give only a few hundred MB to a few GB) and makes readers on mobile networks download data they don't need. The biggest saving usually comes from scaling the image down to a sufficient size, for example 1600 px on the long side, which is still sharp on a retina screen. Changing the format to WebP or AVIF saves more, but how much depends on the image, so measure on real images.

For where to compress, there are two directions. Compressing in the browser (redrawing the image onto a canvas) saves bandwidth during upload and costs the server nothing, which suits the case where the uploader is a trusted author. Compressing on the server (for example with sharp) suits cases where you don't trust the uploader, or need several sizes for several screens, but it costs time and memory in the processing function. A framework image component (like next/image) only optimizes at serving time, and the original stays in storage.

Details that are easy to get wrong: portrait photos carry an EXIF Orientation tag, so you must rotate the pixels before stripping metadata, otherwise the image shows up sideways. A GIF may be animated, so don't recompress it like a still image. An already small image can come out heavier after compression, so keep the original when the compressed version is not smaller.

Bonus points: mention that stripping metadata also hides the GPS location in phone photos, and that a size limit on the storage side works as a second line of defense.