Image optimisation for websites improves speed, Core Web Vitals and UX. Learn formats, sizing, compression and loading choices that matter.
A 4 MB hero image can quietly wreck an otherwise decent site. You tweak your CSS, trim your JavaScript, feel quite pleased with yourself – then Lighthouse still gives you that look. More often than not, the real culprit is images, which is why image optimisation for websites deserves more attention than it usually gets.
For front-end developers, this is one of the highest-impact performance wins available. It affects load time, layout stability, mobile data usage and how responsive a page feels. Better still, most image problems are fixable without rewriting your whole stack or making your design team cry.
Image optimisation for websites is the process of delivering the smallest possible image file without making the result look rubbish. That includes choosing the right format, exporting at sensible dimensions, compressing assets properly, and loading them in a way that matches how people actually browse.
That last bit matters. Optimisation is not just about file size. An image can be tiny and still be wrong for the layout, blurry on high-density screens, or delayed so badly that the page jumps about like it has stage fright. Good optimisation balances visual quality, performance and implementation complexity.
A common mistake is treating every image the same. A product photo, a logo, an illustration and a full-width background image do not need the same format or handling. If you optimise blindly, you usually end up with either oversized files or ugly artefacts.
Ask a few basic questions first. Is the image photographic or graphic? Does it need transparency? Will it scale across breakpoints? Is it above the fold? Does it need to look pin-sharp, or just good enough on a mobile screen? Those answers shape the technical decisions.
The format choice does a lot of heavy lifting. Get this wrong and everything else becomes damage control.
JPEG is still useful for photographs, especially when compatibility matters and your pipeline is simple. It compresses continuous-tone imagery well, but it does not support transparency and tends to produce visible artefacts at lower quality settings.
PNG is better for graphics with sharp edges, simple colours or transparency. It is not usually the best option for large photographic assets unless you enjoy shipping huge files for no good reason.
WebP is often the sensible default now. It usually beats JPEG and PNG on file size while supporting both lossy and lossless compression, plus transparency. Browser support is broad enough that most projects can use it confidently.
AVIF can deliver even smaller files than WebP, especially for photographic content. The trade-off is encoding speed, occasional tooling friction and the fact that some assets can look worse if you push compression too far. It is brilliant when your workflow supports it, but not every project needs to sprint there on day one.
SVG deserves its own mention. For logos, icons and simple illustrations, SVG is often the best answer because it scales cleanly and stays tiny. Just do not use it as a magic replacement for all images. Complex SVGs can become surprisingly heavy and awkward to maintain.
One of the oldest web performance crimes is sending a 2400 px image to a slot that displays at 400 px. Browsers are good, but they are not miracle workers. If the layout never needs that much data, do not send it.
Responsive images exist for a reason. Using srcset and sizes lets the browser choose the best candidate based on viewport and pixel density. That means a smaller image can go to a small screen, while sharper versions are available for larger or denser displays.
This is where image optimisation for websites becomes more than a design export task. It is part of front-end implementation. A well-prepared asset still needs correct markup, otherwise the browser gets forced into wasteful choices.
There is a practical limit. Yes, a 2x or 3x asset can look lovely on a sharp display. No, not every image on your page needs to be exported like it is heading for a billboard. Decorative thumbnails, supporting images and lower-priority content can often be slightly less crisp without harming the experience.
If you optimise every image for best-case visual fidelity, you usually punish everyone else with larger downloads. That is not craftsmanship. That is overachieving in the wrong direction.
Compression reduces file size by stripping unnecessary data or simplifying image information. The key phrase here is unnecessary. You are aiming for the point where the image still looks good in context, not under forensic zoom at 500%.
Lossy compression usually gives the biggest savings. It works well for photographs and most UI imagery where tiny quality losses are acceptable. Lossless compression preserves more data, which is useful for certain graphics, but the files stay larger.
The sweet spot depends on the image. A soft background photo can often handle aggressive compression. A screenshot with small text cannot. This is why a single export preset for every asset tends to be a bit lazy.
If your workflow allows automated compression during build or upload, use it. That removes guesswork and stops oversized assets sneaking into production because someone exported a PNG straight from Figma and called it a day.
Even well-compressed images can hurt performance if they load at the wrong time.
Lazy loading is a straightforward win for content further down the page. It delays loading until the image is near the viewport, which reduces initial page weight and speeds up first render.
That said, do not lazily load your main hero image. If the user needs it immediately, delaying it just makes the page feel sluggish. Lazy loading is useful, not holy.
For above-the-fold content, especially the Largest Contentful Paint image, priority matters. The browser should know that this asset is important. If the page headline appears quickly but the hero image turns up much later, your performance metrics and user perception both take a hit.
Always set width and height attributes, or otherwise ensure the browser knows the image dimensions before it loads. This prevents cumulative layout shift, which is the web equivalent of someone moving your chair as you sit down.
A fast page that jumps around still feels broken. Stability is part of performance.
Different image types deserve different treatment.
Product images need clarity because people make buying decisions from them. Here, you might accept slightly larger files for better detail, especially on zoomable views.
Blog illustrations and decorative graphics can usually be compressed more aggressively. Their job is to support the content, not pass an eye test.
Screenshots are awkward little beasts. Text and sharp UI lines can degrade quickly under heavy lossy compression, so they often need careful format selection and gentler settings. If a screenshot becomes fuzzy, it stops being useful.
Background images sit in the middle. They often look fine with stronger compression because they are not meant to carry fine detail. If they are covered by text or overlays, viewers are even less likely to notice subtle degradation.
A modern image pipeline can generate multiple formats, compress variants, resize assets and serve them efficiently. That is excellent. It also creates a temptation to stop thinking.
Do not. Automation is brilliant at scale, but it cannot always decide whether a soft AVIF at a tiny file size is better than a slightly heavier WebP that actually looks nicer. It cannot tell whether a background image should exist at all, or whether CSS could do the job more cheaply.
The best workflows combine tooling with human judgement. Let the machines do the repetitive bits. Keep the final say for cases where quality and context matter.
The usual suspects are predictable: using PNG for everything, serving original upload dimensions, ignoring srcset, compressing screenshots too aggressively, lazy loading above-the-fold media, and forgetting explicit dimensions.
Another common one is optimising images once and never revisiting them. Formats improve, browser support changes, and your site evolves. An image strategy that was reasonable two years ago may now be leaving easy gains on the table.
If you write for a site like Front Runner, or build one, that kind of periodic clean-up is worth doing. Image performance debt accumulates quietly.
A solid setup is not glamorous. It looks like using SVG for simple graphics, WebP or AVIF for most raster images, JPEG where needed, responsive image markup, sensible compression defaults, eager loading for critical assets, lazy loading for lower-priority content, and reserved space for every image.
It also looks like restraint. Not every section needs a giant decorative banner. Not every card needs a bespoke thumbnail. Sometimes the best optimisation is simply using fewer images, which is not flashy advice, but it works.
If you remember one thing, make it this: image optimisation for websites is not a finishing touch. It is part of building the page properly. Treat it like a core front-end concern, and your users, your metrics and your future self will all complain a bit less.