Stop manually resizing images and fighting with video formats. A component-based approach can automate media optimization directly in your frontend, saving dev time and improving site performance.

I Saw a Dev Automate Media Optimization and It Reminded Me How We Used to Suffer

I remember a launch that went sideways about five years ago. We were deploying a huge marketing site for a new product. Everything looked great on our 1Gbps office internet. Then we pushed it live. The site immediately ground to a halt for anyone on a normal connection. Why? The marketing team had uploaded a 12 MB, 4K video file for the hero background. It was set to autoplay. On a phone. Our Core Web Vitals score was so low, I think Google’s crawlers just felt sorry for us.

That incident cost us a weekend and a whole lot of frantic re-encoding. It’s a classic problem: developers build the car, but someone else puts jet fuel in a go-kart engine. Seeing a developer on Reddit build a React component to solve this at the source—react-media-optimizer—brought all those painful memories back. It’s a smart solution to a problem that bites every single team eventually.

The “Why”: The Browser is a Dumb, Obedient Worker

Let’s get one thing straight. The root cause of this issue isn’t really the giant media file itself. It’s that we, the developers, are telling the browser to do a stupid thing, and the browser is dutifully obeying. When you write <img src="/assets/giant-image.png" width="300" />, you are not telling the browser to load a 300px image. You are telling it to download the entire 5MB file and then shrink it down to 300px.

The network cost is paid in full, upfront. This murders your Largest Contentful Paint (LCP) score, drains mobile data plans, and makes your app feel sluggish and unprofessional. We need to stop asking the browser to do the impossible and instead give it what it actually needs: a file that’s already the right size and format.

The Fixes: From Duct Tape to a Proper CI/CD Pipeline

Over the years, we’ve developed a few ways to tackle this. Some are better than others, but they all have their place.

1. The Quick Fix: “Just Squoosh It”

This is the “Oh crap, the production build is 50MB” solution. You grab the offending image, drag it into a tool like Squoosh or save it for the web in Photoshop, and manually replace the file. It’s fast, it’s dirty, and it works right now.

But it’s a terrible long-term strategy. It’s not repeatable, it’s not scalable, and the next time a non-technical user uploads a new hero image through the CMS, you’re right back where you started. You’re fixing the symptom, not the disease.

Warning: The “Manual Fix” is a form of technical debt. It solves the immediate fire but creates a process that relies on a human remembering to do a specific, manual task. This process will fail, it’s just a matter of when.

2. The Permanent Fix: The Centralized Asset Pipeline

This is my preferred solution as a DevOps lead. You solve the problem at the infrastructure level, before it ever gets to the React developer. The idea is to build an automated pipeline that intercepts all media uploads and processes them.

A common pattern we use is an AWS S3 bucket for uploads, which triggers a Lambda function on every new object. That Lambda function uses a library like Sharp to generate multiple sizes and formats (e.g., .webp, .avif) of the image, saving them back to a “processed” S3 bucket or a CDN.

Another great option is using a third-party service like Cloudinary or Imgix. The developer uploads one high-res original, and the service handles the rest via URL parameters. For example, with Cloudinary:

<!-- Original Image URL -->
https://res.cloudinary.com/demo/image/upload/sample.jpg

<!-- The same image, resized to 400px wide, with auto format and quality -->
https://res.cloudinary.com/demo/image/upload/w_400,f_auto,q_auto/sample.jpg

This is robust and powerful. The downside? It can get complex and expensive. You’re now managing a new piece of infrastructure or paying for another SaaS subscription.

3. The Developer-First Fix: The Smart Component

This brings us back to the original Reddit post. The idea behind a component like react-media-optimizer is to abstract away the complexity right inside the frontend code. The developer doesn’t need to know about the pipeline or the URL transformations. They just use a component that handles it for them.

Here’s the conceptual difference:

Before (The “Naive” Way):

function Hero() {
  return <img src="/images/massive-hero.jpg" alt="A very large hero image" />;
}

After (The “Smart Component” Way):

import { OptimizedMedia } from 'react-media-optimizer';

function Hero() {
  // The component now handles resizing, format conversion (e.g., to WebP),
  // and even generating a low-quality placeholder.
  return <OptimizedMedia src="/images/massive-hero.jpg" alt="An optimized hero image" />;
}

This is a brilliant middle ground. It empowers frontend developers to solve the problem themselves without needing a full-blown infrastructure project. It combines the ease of a simple <img> tag with the power of a backend processing pipeline, often by integrating with one of the services mentioned in Fix #2 under the hood.

Pro Tip: Whether you use a smart component or not, learn about the native HTML <picture> element and the srcset attribute on <img>. These are the underlying browser technologies that allow you to serve different image sources based on screen size and device capabilities. A good component will use these for you.

So, Which One Should You Choose?

Like any engineering problem, the answer is “it depends”. I’ve put together a quick table to help you decide.

My take? If you’re starting a new project, build in a centralized pipeline from day one. It’s the “right” way to do it. But for the 90% of us working on existing codebases where an infrastructure overhaul isn’t an option, a smart component is a fantastic, pragmatic solution that can make a real impact on performance today. It’s a great example of shifting responsibility to where it can be handled most effectively.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions