On most of the sites we open to diagnose, images are the heaviest part of the page, and by a wide margin. The good news is that this is also the easiest part to fix. It requires no rewriting. It requires a process.
Why images are almost always the heaviest part of a page
Do the maths on a typical page. The HTML is a few kilobytes. The CSS, a few dozen. The JavaScript, a few hundred. Then a photo taken on a phone and uploaded straight to the site arrives: on its own, it can weigh more than everything else combined.
That matters for two reasons. The first is LCP, the metric measuring when the largest visible element finishes rendering, which on most pages is precisely the top image. The second is the real cost for someone browsing on mobile data over a shaky connection, a situation far more common than a developer test bench suggests. The thresholds for that metric are in Core Web Vitals explained.
JPEG, PNG, WebP and AVIF: when to use each
| Format | Browser support | Transparency | Animation | When to use |
|---|---|---|---|---|
| JPEG | Universal, including old systems | No | No | Photo fallback when support has to be absolute |
| PNG | Universal | Yes | No (only APNG) | Logos, icons, screenshots, anything with flat areas and sharp edges |
| WebP | Every modern browser | Yes | Yes | The safe default for almost everything today |
| AVIF | Broad in current browsers, narrower than WebP | Yes | Yes | Large photography, where the better compression pays off most |
The practical rule is simple. WebP replaces JPEG and PNG in most cases, keeping similar quality at much smaller sizes, and it supports both lossy and lossless compression. AVIF usually compresses even better, especially for photography, at the cost of slower encoding and slightly more recent support.
For interface images such as logos and icons, there is an even better answer: SVG. It is vector, scales to any screen without losing sharpness, and normally weighs a fraction of any bitmap.
A note on GIF, which still shows up a lot: for short animations, GIF is the worst format available today. A few seconds of GIF often weighs several megabytes, while the same content as MP4 or WebM video takes a fraction of that, at better quality. If the animation needs no sound and no controls, a short muted autoplaying video replaces the GIF with nothing lost.
Resize before uploading
This is the most common mistake of all, and the most expensive. A phone photo comes out somewhere between 3000 and 4000 pixels wide. If it will be displayed in an 800-pixel column, the browser downloads the whole file and then throws most of the information away to draw it small. You paid for the bandwidth and gained nothing visible.
Before any conversation about formats, resize. Find the largest width the image actually occupies in the layout, double it to cover high-density screens, and use that as the maximum. An image shown at 800 pixels rarely needs a file wider than 1600.
Only after resizing is compression quality worth discussing. For photography, a quality setting between 75 and 85 is usually indistinguishable from the original to the eye, at far smaller sizes.
Take the chance to strip metadata. A phone photo carries camera data, a date and, in some cases, GPS coordinates of where it was taken. That adds weight, serves no purpose on the site, and can expose information you never meant to publish. Most compression tools remove it by default, but it is worth checking.
srcset and sizes: responsive images in practice
A phone does not need the same file as a large monitor. The srcset attribute lets you offer several versions and let the browser pick the right one for the screen and the connection.
srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1600.webp 1600w"The number followed by w is the real file width in pixels. That alone is not enough: the browser also has to know how much space the image will occupy in the layout, which is what sizes is for.
sizes="(max-width: 700px) 100vw, 800px"Read it as: on screens up to 700 pixels the image takes the full viewport width; above that it takes 800 pixels. Without sizes, the browser assumes the full screen width and tends to download a larger file than needed.
To serve AVIF with an automatic fallback, use <picture> with several <source> tags, putting the most modern format first. The browser uses the first option it can decode and ignores the rest. Nobody is left without an image.
Native lazy loading
There is no sense in downloading an image three screens down before the visitor gets there. The loading="lazy" attribute handles that with no library at all: the browser defers the download until the image approaches the visible area.
Apply it to everything below the fold: galleries, mid-article images, listing cards, the footer. The gain shows up directly in the initial page weight.
The same reasoning applies to heavy iframes, such as embedded maps and videos, which also accept loading="lazy". A map embedded in the footer of a contact page can cost more than every image on the site combined, and hardly anyone scrolls that far on a first visit.
What must NEVER be lazy loaded
The hero image, the large one at the top of the page. It sounds counterintuitive, but putting loading="lazy" on it measurably hurts performance. The reason is that lazy loading defers discovery and download of the image until after layout is computed, and that image is usually the exact element defining LCP. You are deliberately delaying the metric you want to improve.
For the hero, do the opposite: use loading="eager" and fetchpriority="high", telling the browser that file takes priority over the rest.
width and height to avoid CLS
Every image should carry width and height attributes in the HTML, with the real file values. That does not stop CSS from resizing it afterwards. What those attributes do is communicate the aspect ratio before the file arrives, so the browser reserves the correct space and the text does not jump when the image finishes loading.
Without them, the page lays out with zero height at that point and then pushes everything down. It is the most frequent cause of poor CLS and one of the fastest to fix.
When an image is cropped by CSS to fit a fixed slot, such as in a listing card, keep the attributes at the real file values and control the crop with object-fit. Putting made-up numbers in the HTML just to match the layout distorts the ratio the browser uses to reserve space, and the result is the opposite of what you wanted.
Free conversion and compression tools
- Squoosh, from Google, runs in the browser, converts to WebP and AVIF, and shows a side-by-side comparison with the final size of each option. Ideal for calibrating quality without guessing.
- ImageMagick or cwebp, on the command line, when you need to convert a whole folder at once.
- SVGO to clean SVGs exported from design tools, which usually arrive full of useless metadata.
- Optimisation plugins, if the site runs on a CMS, to automate conversion and size generation on upload.
More important than the tool is the routine. Whoever edits the site has to know that images do not go from camera to server directly. That combination of a defined routine and periodic review is part of what we describe in website maintenance: the routine. And it is worth revisiting the image item inside our technical SEO checklist, because format and alt text travel together.
If your site images are heavy and you do not know where to start, talk to ALB Seven. It tends to be the fix with the best return per hour of work.