Most people find out their images are too heavy the same way: a page speed report flags them, red and unambiguous. The fix looks obvious — run everything through a compressor. But teams do that constantly and still end up back in the same report a month later. The tool isn't the problem. The setting is.
"Compress this image" hides three very different questions: how much detail can this image lose before it looks wrong, how much detail does this image actually need at the size it's displayed, and how much of its file weight is pixels at all versus metadata, color profiles, and editor cruft. A tool that only answers the first question will under-compress a screenshot and over-compress a product photo, because it's applying one answer to three problems.
A 4000px-wide photo compressed carefully to 4000px is still a heavy file if it's only ever shown at 800px on the page. The compression did its job; the export size didn't match the use case. This is the single most common reason a "properly compressed" image still shows up as a warning — nobody asked whether the resolution matched where the image actually lives.
Before running a file through another pass of lossy compression — which has diminishing and eventually damaging returns — check three things: the display resolution versus the export resolution, whether the format matches the content (a screenshot with flat color blocks belongs in PNG, not JPEG), and whether metadata like embedded color profiles or editor history is still attached. Often the fastest win isn't a smaller quality setting; it's removing weight that was never visual information to begin with.
That's the gap Ahangarzada's lossless mode is built to close — it targets exactly that non-visual weight before anything touches pixel quality.