TABLE OF CONTENTS
Image Optimization for Web Performance: Formats and Compression
Ask a developer why a page feels slow, and the honest answer is often sitting right in the middle of it. A single unoptimised hero image can outweigh all the scripts and styles on the page combined. That is why image optimization for web performance is usually the fastest win available to any team, and one of the few that helps users, search rankings and infrastructure bills at the same time.
This guide covers the practical side of it. You will see how the main formats compare, how lossy and lossless compression differ, and how to load images without hurting your Core Web Vitals. If you also run a store on Magento, our walkthrough on Magento performance tuning and caching pairs nicely with the image steps below.
Why images decide your page speed
Images are usually the heaviest assets on a page, and they often become the Largest Contentful Paint element, the moment the main content appears. Google’s explanation of Largest Contentful Paint shows why that single element matters so much for perceived speed. If your biggest image is huge, slow to fetch or discovered late by the browser, the whole page feels sluggish no matter how clean your code is.
The good news is that image problems are highly fixable. Right sizing, modern formats, sensible compression and smarter loading rules can often cut image weight dramatically without any visible change in quality. Most sites do not need a redesign. They need a checklist and some discipline.
Choosing the right image format
There is no single best format, only the best format for a job. The browser support for each is broad today, and the MDN guide to image file types is a reliable reference when you are unsure. Here is the short version for everyday work.
| Format | Best for | Watch out for |
|---|---|---|
| JPEG | Photos with wide compatibility | No transparency, older compression |
| PNG | Sharp graphics with transparency | Large files for photos |
| WebP | Photos and graphics on the web | Slightly less compact than AVIF |
| AVIF | Best compression for photos | Slower encoding, check tooling |
| SVG | Icons and logos | Not for photographs |
The WebP vs AVIF comparison comes up in nearly every project. WebP is a safe default. It supports both lossy and lossless modes and transparency, it encodes quickly and it is supported almost everywhere. AVIF often produces smaller files at the same visual quality, especially for photos, but it takes longer to encode and some tools handle it less gracefully.
A sensible strategy is to serve AVIF where it is supported, WebP as the second choice and JPEG as the fallback. The HTML picture element makes this straightforward, since the browser picks the first format it understands. Vector graphics like logos and icons should stay as SVG, because they scale perfectly and are usually tiny.
Lossy vs lossless compression in plain words
Compression is what shrinks a file, and there are two families. Lossless compression reduces size without discarding any picture data, so the image looks identical after decoding. Lossy compression throws away detail that the human eye is unlikely to notice, and that is how it reaches much smaller sizes.
| Type | What happens | Use it for |
|---|---|---|
| Lossless | No visual data lost | Logos, screenshots, UI graphics |
| Lossy | Some detail discarded | Photos and banners |
For photographs, lossy is almost always the right choice. A quality setting somewhere in the middle to upper range usually looks the same to viewers but is far lighter than the original. Test a few values on your own images, view them at real size and pick the lowest setting that still looks clean. Screenshots and interface graphics with text and flat colours benefit more from lossless, where artefacts around letters would be very noticeable.
”Need
Right size before you compress
Compression cannot save an image that is ten times bigger than it needs to be. A common mistake is uploading a wide camera photo and letting CSS shrink it to a small card. The browser still downloads every pixel. Resize images to the largest size they will be shown, and no more.
Responsive images take this a step further. With the srcset and sizes attributes, you give the browser several versions of the same picture and let it choose according to the screen width and pixel density. A phone then downloads a small file, and a large desktop monitor gets a sharper one. This alone can save a large share of data on mobile visits.
- Export each image at the largest displayed width, plus a higher density version if needed.
- Create three or four width steps for responsive use.
- Always set width and height attributes so the layout does not jump while images load.
- Strip unnecessary metadata from exports.
Lazy loading images the right way
Lazy loading delays images until the visitor is about to scroll to them. In modern browsers, the loading attribute set to lazy handles this with no extra script. It saves bandwidth and speeds up the first render, especially on long pages with many pictures.
But there is a catch that trips up many teams. Never lazy load the image that appears at the top of the page, especially the one that becomes your Largest Contentful Paint element. Delaying it makes the page slower, not faster. For that hero image, load it eagerly and consider marking it as high priority so the browser fetches it early.
| Image position | Loading approach |
|---|---|
| Top of page, main hero | Load eagerly with high priority |
| Just below the fold | Load normally or lazy with care |
| Far down the page | Lazy load |
| Off screen sliders | Lazy load |
Automating optimization in your workflow
Manual optimisation does not scale. If every editor must remember to compress and resize images by hand, some pages will inevitably ship with a heavy file. The reliable approach is to automate. Build tools, image services and CDNs can convert formats, resize on demand and cache the results.
On WordPress, this often means a plugin or a service that converts uploads to modern formats and serves responsive sizes. If you need a team to set this up properly, our WordPress development services include performance tuning as part of a build. For component driven front ends, a proper image component in a framework such as React handles sizing, lazy loading and format selection consistently, and our React.js development team can help you standardise it across a project.
Whatever tools you choose, set a performance budget. Decide the maximum weight for a hero image and for a typical page, and fail the build or raise a warning when it is exceeded. Budgets turn good intentions into a habit that survives busy sprints.
Measuring what you gained
Optimisation without measurement is guesswork. Before you change anything, record the page weight, the number of image requests and your Largest Contentful Paint time for a few key pages. After the work, test again under the same conditions. Use both lab tools and real user data if you have it, because lab tests show what is possible while field data shows what visitors actually experience.
Look beyond a single score. A page that scores well in a lab test on a fast connection can still feel slow on a mid range phone over mobile data. Test on a throttled connection to see the real picture, and pay attention to how quickly the main image appears, not just the overall load time.
Background images, icons and other small wins
Images set through CSS backgrounds are easy to forget, yet they add weight too. The browser discovers them later than regular image tags, so a background hero can delay your key content. Where possible, use a normal image element for important visuals so that you can apply sizing, priority and lazy loading properly.
Small icons deserve attention as well. Dozens of tiny image files create many requests, so combine them into an SVG sprite or use inline SVG for critical ones. Keep animated content under control, too. Animated GIFs are notoriously heavy, and a short video or an animated WebP is usually far lighter for the same effect.
Common mistakes to avoid
A handful of errors appear in almost every audit. Uploading original camera files straight from a phone or DSLR is the first. Using PNG for photographs is the second, which can produce huge files for no visible benefit. Skipping width and height attributes causes layout shifts that hurt the user experience. Lazy loading everything, including the hero, quietly damages the metric you are trying to improve.
Another quiet mistake is optimising once and never checking again. New banners, product photos and blog images are added every week. Schedule a regular review, using a performance testing tool, to catch the new offenders before they pile up.
”Talk to Askan engineers”
A practical order of work
If you are not sure where to begin, follow this order. First, find the largest images on your key pages using a performance report. Second, resize them to their real display size. Third, convert them to WebP or AVIF with sensible quality. Fourth, add responsive sizes and dimensions. Fifth, lazy load the images below the fold and keep the hero eager.
Each step is small, and together they can change how your site feels. Measure before and after, and share the numbers with your team, since visible wins make it easier to keep the habit going. If your online store or a large content site needs a deeper review, the Askan Technologies team is ready to help you plan the work and keep your pages fast as they grow.
Most popular pages
Monolith vs Microservices: Choosing the Right Architecture for Your Team
Microservices have dominated architecture conversations for years, to the point where choosing a monolith can feel like admitting you're behind the times. In practice,...
Magento Performance Tuning: Caching Layers Explained
Magento has a reputation for being resource-heavy, and while some of that is inherent to running a full-featured enterprise commerce platform, a large share...
Choosing Between REST and GraphQL for Your Next API
REST and GraphQL both solve the same underlying problem, letting a frontend fetch and modify data from a backend, but they approach it with...


