Technology
Compressing an image isn't a performance strategy. A look at what actually moves Core Web Vitals — and what's just busywork.
Ask most teams how they'll improve site speed and you'll hear the same three answers: compress the images, add a CDN, minify the JavaScript. All three are fine ideas. None of them are usually the actual problem.
Real-world performance problems tend to live in a small number of places: unbounded third-party scripts, layout that shifts as content loads, and JavaScript that blocks the main thread before a page becomes interactive. Image weight matters, but it's rarely the biggest lever.
A page can serve perfectly optimized images and still fail Largest Contentful Paint because a tag manager is loading twelve scripts before anything renders. That's an architecture problem, not an asset problem.
The fastest way to waste a sprint is to "optimize performance" without first identifying which specific metric is failing and why. LCP, INP and CLS fail for different reasons and get fixed with different tools. Treating them as one generic "speed" problem usually means fixing the wrong thing first.
Fast sites are usually the result of restraint, not cleverness: fewer third-party scripts, deliberate use of client-side JavaScript instead of defaulting to it, and image and font loading strategies decided at build time instead of patched in afterward.
None of that is exciting to write in a case study. It's also the difference between a site that's actually fast and one that just has a few compressed images.