u/No_Refrigerator7738

I’m curious how people handle image compression today.

Do you still use TinyPNG manually, or did you move to things like Squoosh, ImageOptim, CDN optimization, build scripts, browser APIs, or something else?

I’m asking because I keep seeing image compression treated as this tiny boring step, but it still creates real friction, especially when people just need to upload an image and move on.

Curious how many people still use TinyPNG for image compression, or if most of you have moved to Squoosh, ImageOptim, build step automation, CDN optimization, or browser based tools.

I still see it mentioned a lot, but I’m wondering what the actual workflow is today. Manual upload? API? Figma/plugin? Something else?

I’ve been thinking about a gap I see a lot in everyday service products.

A user can complete the flow, but still leave not knowing what happened, what happens next, or whether they did the right thing.

This shows up constantly in banking, healthcare, government services, insurance, onboarding, document submission, claims, approvals, and anything with back office processing.

From a PM perspective, task completion can look fine while the user’s actual understanding is broken.

Curious how others handle this. Do you measure whether users can explain the outcome of a flow, predict the next step, or understand why the system asked for certain info?

Or does that usually get hidden under CSAT, support tickets, and “UX will handle it”?

For a long time I treated image uploads as a backend problem.

Then I realized most of the files arriving at the server were much larger than the application actually needed.

Moving compression to the browser while leveraging the Canvas API turned out to be surprisingly effective. Uploads felt faster, bandwidth dropped, and the backend stopped spending time processing oversized images that users would never notice anyway.

I packaged the approach into a small tool while building a few projects, but the interesting part for me was realizing that changing where a task happens can matter more than making the task itself faster.

It reminded me how often we optimize infrastructure before questioning where the work should happen in the first place.

Has anyone else found frontend changes that ended up having a much bigger backend impact than expected?

Image upload pipelines often look something like this:

Upload the original image.

Transfer it over the network.

Compress it on the server.

Throw away most of the original data.

That works, but it also means the most expensive part, moving the bytes across the network, has already happened.

Moving compression to the client changes the pipeline rather than optimizing a single step. The server receives less data, image processing becomes simpler, and bandwidth usage drops because unnecessary data never leaves the device.

It feels like a broader pattern: some performance wins come from moving computation, not making computation faster.

I put together a small implementation of this idea as compresso.js on GitHub while experimenting with different approaches.

Where else have you seen moving work across the client/server boundary simplify a system more than optimizing the existing implementation?

Every project seemed to follow the same pattern.

Users uploaded huge photos. The backend received them, compressed them, resized them, and threw most of the original data away.

At some point I thought... why am I even sending all that data across the network?

So I built a small browser based image compressor that runs before the upload starts. It reduced upload time, saved bandwidth, and made the backend simpler.

It also made me wonder how many other "backend problems" are really just work happening in the wrong place.

Every project seemed to follow the same pattern.

Users uploaded huge photos. The backend received them, compressed them, resized them, and threw most of the original data away.

At some point I thought... why am I even sending all that data across the network?

So I built a small browser based image compressor that runs before the upload starts. It reduced upload time, saved bandwidth, and made the backend simpler.

It's one of those changes that feels obvious in hindsight.

If you're curious, here's the tool:

https://compresso.izaias.xyz

It also made me wonder how many other "backend problems" are really just work happening in the wrong place.

I got tired of seeing apps upload huge images that didn't need to be huge.

So I built a small tool that compresses images directly in the browser before they're uploaded. The idea is simple: less data over the network, faster uploads, and less work for the backend.

It runs entirely on the client, so your images aren't sent anywhere just to be compressed.

I thought others building apps with image uploads might find it useful.

https://compresso.izaias.xyz

Happy to answer any questions about how it works.

For a long time I treated image uploads as a backend problem.

Then I realized most of the files arriving at the server were much larger than the application actually needed.

Moving compression to the browser turned out to be surprisingly effective. Uploads felt faster, bandwidth dropped, and the backend stopped spending time processing oversized images that users would never notice anyway.

It reminded me how often we optimize infrastructure before questioning where the work should happen in the first place.

I packaged the approach into a small tool while building a few projects, but the interesting part for me wasn't the tool itself. It was realizing that changing where a task happens can matter more than making the task itself faster.

Has anyone else found frontend changes that ended up having a much bigger backend impact than expected?

I kept running into the same issue on side projects. People upload photos straight from their phones, and many of them are much larger than the app actually needs.

Instead of sending the original file to the server, I started compressing images in the browser first. It noticeably reduced upload times and bandwidth usage, and it also meant the backend had less work to do.

I ended up turning that into a small open source tool while building a few projects.

I'm curious how others handle this. Do you compress on the client, on the server, or both?

For anyone interested, this is the little tool I built:

https://compresso.izaias.xyz

I kept running into the same issue on side projects. People upload photos straight from their phones, and many of them are much larger than the app actually needs.

Instead of sending the original file to the server, I started compressing images in the browser first. It noticeably reduced upload times and bandwidth usage, and it also meant the backend had less work to do.

I ended up turning that into a small open source tool while building a few projects.

I'm curious how others handle this. Do you compress on the client, on the server, or both?

For anyone interested, this is the little tool I built:

https://compresso.izaias.xyz

I kept running into the same issue on side projects. People upload photos straight from their phones, and many of them are much larger than the app actually needs.

Instead of sending the original file to the server, I started compressing images in the browser first. It noticeably reduced upload times and bandwidth usage, and it also meant the backend had less work to do.

I ended up turning that into a small open source tool while building a few projects.

I'm curious how others handle this. Do you compress on the client, on the server, or both?

For anyone interested, this is the little tool I built:

https://compresso.izaias.xyz

Most definitions center on collecting, processing, storing, and distributing information to support decision making. Nothing in that definition technically requires a computer.

So is the computer essential to what IS is, or just the tool we happen to use? And does tying the field to a specific technology limit how we define it?

I'm putting together a live hands on Claude workshop for product designers.

We'll design, build, and deploy a real product from scratch.

Give me a product idea in the comments.

If it's good enough, we'll build it live.

I'm in Brazil. I work for clients in the US and Europe. And no matter how good the work is, that question always carries a subtext I've learned to read pretty quickly.

Sometimes it's fine. Sometimes it's the last message they send.

I've shipped things for Fortune 500 legal teams and large payment companies. I design and I build, full stack, using Cursor and Claude Code heavily these days. The timezone thing I've figured out: I cover EU mornings and US afternoons without much trouble. Payment processing took longer to sort out but it's fine now.

What I haven't figured out is how to make "I'm in Brazil" land the same way "I'm in Lisbon" does in an intro call. The work is identical. The output is the same. But something shifts in the conversation the moment geography comes up.

Maybe it gets better. Maybe it doesn't. Curious if others working from South America or similar situations have found something that actually moves the needle on that first impression, before the work gets a chance to speak.

Target: Design Engineer or Product Designer roles at companies in Europe or the US. Remote only, based in Brazil.

I'm a product designer who taught myself to code, and now I design, build, deploy, and maintain production apps myself (Next.js, React, TypeScript, end to end). I can't get a recruiter to look past 10 seconds because I'm freelancing, based in Brazil, and "remote-only" reads as a deal-breaker before anyone opens the case studies.

What I've shipped: designed Visa's global authentication at scale. Designed a CLM workflow engine for Fortune 500 legal teams that cut Time to Audit by 70%. Took an open-source password-visibility component to 14K+ Figma views and production use elsewhere. Solo-built three production platforms for a 24/7 media brand, from a self-hosted streaming server to a live broadcast pipeline. Hand-rolled my own design system, documented end to end and shipped as the actual site linked below, not a Figma deck.

Stack: Figma, Cursor, Claude Code, Next.js, React, TypeScript, Tailwind v4, self-hosted streaming infra, AI-assisted dev.

Looking for: Design Engineer, Product Engineer, Product Designer, UX Engineer, or Frontend/Full-Stack roles where design and code aren't separate jobs.

Location: Remote from Brazil, no relocation, no visa or work permit needed. Flexible across EU and US time zones. Fluent English, freelancing now, available on short notice.

Portfolio: izaias.xyz

All I'm asking is a few minutes to look at the work, and if it fits something you know of, a name dropped in the right channel. If you know a hiring manager, recruiter, or open req, comment or DM.

Target: Design Engineer or Product Designer roles at companies in Europe or the US. Remote only, based in Brazil.

I'm a product designer who taught myself to code, and now I design, build, deploy, and maintain production apps myself (Next.js, React, TypeScript, end to end). I can't get a recruiter to look past 10 seconds because I'm freelancing, based in Brazil, and "remote-only" reads as a deal-breaker before anyone opens the case studies.

What I've shipped: designed Visa's global authentication at scale. Designed a CLM workflow engine for Fortune 500 legal teams that cut Time to Audit by 70%. Took an open-source password-visibility component to 14K+ Figma views and production use elsewhere. Solo-built three production platforms for a 24/7 media brand, from a self-hosted streaming server to a live broadcast pipeline. Hand-rolled my own design system, documented end to end and shipped as the actual site linked below, not a Figma deck.

Stack: Figma, Next.js, React, TypeScript, Tailwind v4, self-hosted streaming infra, AI-assisted dev.

Looking for: Design Engineer, Product Engineer, Product Designer, UX Engineer, or Frontend/Full-Stack roles where design and code aren't separate jobs.

Location: Remote from Brazil, no relocation, no visa or work permit needed. Flexible across EU and US time zones. Fluent English, freelancing now, available on short notice.

Portfolio: izaias.xyz

All I'm asking is a few minutes to look at the work, and if it fits something you know of, a name dropped in the right channel. If you know a hiring manager, recruiter, or open req, comment or DM.