Images, formats and why they dominate page weight

On a typical Australian small-business website, images account for more delivered bytes than everything else put together. Not the code, not the fonts, not the tracking scripts — the photographs. That single fact makes image handling and image format choice the highest-yield performance work available to most businesses, and it needs no redesign, no platform migration and no argument about frameworks.

It is also the work most often skipped, because uploading a photograph is something anyone can do and optimising one is not.

Why image file format waste happens

A modern camera or phone produces an image several thousand pixels wide. A stock library serves its originals at similar sizes. That file gets uploaded and placed on a page where it is displayed in a fraction of that width, particularly on a phone.

The browser has no choice about this. It downloads the entire file, decodes it into memory, and then scales it down to the size it is actually shown at. The download is wasted bandwidth and the decode is wasted processor time, which on a budget Android handset is not free.

There is a second, quieter waste. Photographs carry embedded metadata — camera settings, colour profiles, sometimes GPS coordinates from the phone that took them, which is its own problem on a business site. None of it is displayed and all of it is transferred.

AVIF, WebP, JPEG, PNG and SVG image formats, in plain terms

An image format is a set of rules for how a picture is compressed into a file. Older image formats encode the same picture less efficiently than newer formats, so the same visual result costs more bytes in an older format. Five image formats cover almost every case a small-business website will ever need: JPEG, PNG, WebP, AVIF and SVG. Knowing which of these image formats each image on the page should actually use is a small decision with an outsized effect on page weight.

JPEG is the long-standing image format for photographs. The JPEG format works everywhere and is the least efficient of the formats compared here.

WebP is a newer image format supported by all current mainstream browsers. WebP produces meaningfully smaller files than JPEG at comparable visual quality, and unlike JPEG the WebP format also supports transparency, so WebP can replace PNG for graphics as well.

AVIF is a newer image format again, and AVIF generally produces smaller files than WebP at comparable quality, particularly for photographic content. Browser support for the AVIF format is good but not universal, and AVIF takes longer to encode than WebP, which matters when a system is generating hundreds of images in the AVIF or WebP formats.

PNG is for graphics with flat colour, sharp edges or transparency — logos, diagrams, screenshots of text. PNG is a poor choice for photographs, where it produces very large files for no visual benefit. WebP and AVIF can generally replace PNG for this purpose too, at a smaller file size.

SVG is not a photograph format at all. SVG describes shapes mathematically rather than as pixels, which makes it the correct choice for logos, icons and simple diagrams. An SVG stays sharp at any pixel size and is usually tiny.

GIF still turns up for simple animation, but GIF is an old, limited format. A modern animated WebP or a short video file produces a smaller, better-looking result for the same content than a GIF would. GIF is rarely the right choice for anything else.

Two more properties worth knowing the names of. Lossless compression, used by PNG and available as a WebP option, keeps every original pixel’s colour exactly as it was, at the cost of a larger file than lossy WebP or lossy AVIF. Lossy compression is the default for JPEG and the usual choice for AVIF and WebP photographs. It discards information a viewer is unlikely to notice, trading a small amount of accuracy for a much smaller file than a lossless format produces. This is the lossy-versus-lossless compression trade-off discussed further below. Alpha transparency, supported by PNG, WebP and AVIF but not by JPEG, is what lets part of an image show the page behind it, rather than a solid colour block. That is why a logo needing alpha transparency for a see-through background cannot be saved as a JPEG.

Current versions of the major browsers — Chrome, Edge, Firefox and Safari — all support the WebP image format, and AVIF format support is now similarly broad. A fallback image format still matters, though, for the small share of visitors on an older browser without AVIF or WebP support. The sensible arrangement is not to pick one format. It is to serve the newest format each browser can handle — AVIF where supported, WebP as the fallback, JPEG or PNG as the last resort — and fall back automatically for the browsers that cannot handle AVIF or WebP, which every competent build system does without anyone thinking about it.

Responsive images, and why one file for all screens is wasteful

A phone in portrait, a tablet and a desktop monitor need genuinely different images. Sending one file to all three means either the phone downloads far more than it can display, or the desktop shows something soft and blurry. There is no single size that is correct for both.

The mechanism that solves this is a set of image variants at different widths, declared alongside a description of how much space the image will occupy in the layout. The browser then picks the appropriate file for the device it is on, taking screen density into account. It is a standard feature of HTML, not a proprietary trick, and any modern build system can generate the variants automatically at publish time.

Two related points. Art direction is different from resizing: sometimes a wide landscape crop simply does not work on a narrow screen and a different crop is needed, which is a design decision rather than an automatic one. And lazy loading — deferring images until they are near the visible area — is valuable for everything below the fold. It is actively harmful applied to the image at the top of the page, for reasons set out in largest contentful paint.

Lossless and lossy compression, briefly

Compression is where image quality is traded for file size, and the trade is not linear. Reducing quality from the maximum setting typically removes a substantial share of the file size before any difference is visible at normal viewing size. Pushing lossy compression further eventually produces visible artefacts — blotchy skies, halos around edges, mushy detail in foliage — while lossless compression, by definition, never introduces them at all.

The correct setting is a judgement made by looking, not a number applied globally. Photographs of people and product shots on plain backgrounds tolerate different treatment. The one rule worth stating is to compress once, from the original, rather than repeatedly, because each pass compounds the damage of the last.

Also declare the dimensions on every image. This costs nothing, is unrelated to file size, and is the main defence against the layout jumping as pictures arrive — see cumulative layout shift.

Alternative text is part of the image job

Every image that carries meaning needs alternative text describing what it conveys, and every purely decorative image needs empty alternative text so assistive technology skips it. This is not a performance matter, but it is decided at the same moment by the same person. It is far cheaper to do while the image is being placed than to retrofit across hundreds of pages later. The obligation behind it is covered on website accessibility in Australia.

What image formats and files to hand a supplier

Give them the originals, at full resolution, and let the build pipeline do the work. Do not resize or compress by hand before handing over, because that destroys detail the system could have used to produce better variants. Send the largest version you have of each.

Then ask for four things in writing:

• That images are converted automatically to modern formats with fallbacks, rather than manually
• That multiple widths are generated per image and selected responsively
• That metadata is stripped on publish
• That anything below the fold is lazy-loaded and the top-of-page image explicitly is not

Ask what happens when someone in your office uploads a photograph straight from a phone in twelve months’ time. If the answer is that it is served as uploaded, the pipeline does not exist, and the problem returns the first time you edit your own site. That is an ongoing cost question as much as a build one, and belongs in the conversation covered by the ongoing cost of running a website. The retainer figure should be confirmed as inclusive or exclusive of GST, before you compare it with anything.