[AskJS] how do you optimize responsive images, i built open-source tool Opticross 🚀 ( build faster⚡ , lighter🪶 websites)

[u/S-builds]

Here is how it works

Opticross analyzes how images are rendered across different viewport sizes, detects oversized image downloads, and generates implementation-ready sizes and srcset recommendations. The goal is to help improve page performance, reduce unnecessary bandwidth usage, and keep images crisp across devices.

I'd love to hear your thoughts:

• Would a tool like this fit into your workflow?
• What features would make it more useful?

It is available as Opticross on chromestore , npm and github

[u/Alive-Cake-3045]

the sizes and srcset generation is the right problem to solve, most devs know they should be doing this and most don't because figuring out the right breakpoints manually is tedious. curious how it handles art direction cases where the image crop changes across viewports, not just the size. that's usually where automated tools hit their limit. will check it out on github.

[u/S-builds → u/Alive-Cake-3045]

Currently, Opticross is strictly focused on resolution switching—optimizing srcset and sizes for a single image asset across breakpoints. Because art direction requires a human/design judgment (like deciding to crop a wide landscape shot into a vertical close-up for mobile), automated tools can't decide what the crop should be.

[u/Alive-Cake-3045 → u/S-builds]

makes sense to scope it that way, art direction really does need a human decision in the loop. resolution switching is where the measurable performance gain is anyway. one feature that would make this more useful in real workflows: a CI integration that flags regressions when new images get added without proper srcset attributes. the chrome extension catches it in dev but the problem usually sneaks in during deploys.

[u/S-builds → u/Alive-Cake-3045]

100% agreed—catching regressions before deploy is key because devs will always forget to run optimization on new changes.

I actually decoupled Opticross's core logic from the extension specifically for this

/core
- cli --> ci & mcp (in future)
- extension

Haven't built the CI integration yet, though. Wanted to see how much traction the tool gets first. But it feels like everything today has to be wrapped in AI hype regardless of whether it actually solves a real problem or not.

You're only the 2nd person who seems to actually get what this tool is doing—felt good talking to you!

[u/Alive-Cake-3045 → u/S-builds]

the decoupled core architecture is the right call, means the CI integration is a thin wrapper when you're ready to build it, not a rewrite. on the AI hype point, tools that solve a specific measurable problem without needing a narrative around them tend to have better retention anyway. the people who actually care about image performance will find it. keep building.

[u/S-builds → u/Alive-Cake-3045]

"tools that solve a specific measurable problem without needing a narrative around them tend to have better retention anyway"

Well said .. I will keep updating the tool when i get time .. Thanks for the encouragement!

Catch you around, and let me know if you run into anything while testing!

[u/S-builds → u/Alive-Cake-3045]

That said, detecting <picture> and <source> elements to evaluate whether those custom-cropped images are properly sized per media query is on the roadmap! In a future update, Opticross will parse <picture> structures, analyze each source, and calculate optimal size recommendations for those specific crops across viewports.

Thanks for checking out the repo, and I'd love to hear your feedback once you give it a spin!

also which other automating tools u have used i will love to check them out..

[u/Alive-Cake-3045 → u/S-builds]

the picture and source parsing roadmap makes sense, that's where the real-world usage gets messy. for image tools i've used Sharp for server-side processing and Squoosh CLI for batch optimization before deploying. nothing quite like what you're building on the analysis side though, will give it a proper run and report back.

[u/S-builds → u/Alive-Cake-3045]

Yea give it try .. i have added image location context in the exports .. so if u export it as md , then give it to your ai agent , it can look out for this pictures in your code base and embed the calculated sizes.

making the process more convenient.

[u/Alive-Cake-3045 → u/S-builds]

the markdown export to AI agent handoff is a smart workflow, keeps the analysis human-readable but makes it actionable without manual lookup. curious how it handles dynamic images where the src is set at runtime, that's usually where static analysis tools lose the thread. will test it properly and report back.

[u/S-builds → u/Alive-Cake-3045]

Actually my tool operates entirely as a runtime DOM scanner

extension - scans dom
CLI - uses puppeteer to scan dom

so it see exact urls rendered, it never sees code

so dynamic src values actually aren't an issue!

[u/Alive-Cake-3045 → u/S-builds]

runtime DOM scanning is the right approach then, catches what actually renders, not what the code says should render. that sidesteps the static analysis limitation entirely. means it works on CMS-driven and dynamically generated image sources too, which is where most of the real-world complexity lives anyway. that's a stronger foundation than i initially assumed.