Optimising images for the web

Before any tool, ask the image itself

The lightest image is the one that never gets sent. That is not a slogan, it is a working rule that runs before any compression, and running it is simple: look at every image on the page and ask what the reader would lose if it were gone.

Three families of image usually fail that test. First, decorative ones: the photo of smiling people at a conference table, ornamental icons, the banner above an article that only repeats the title. Second, things that are not images and were saved as one: charts, tables, infographics, icons. Third, screenshots that exist only to prove something the text already says.

The second family matters most because it eats the most bytes and has the easiest replacement. A bar chart saved as a PNG is heavy, unreadable on a phone, and its text is read by no search engine. The same chart in HTML and CSS is a few hundred bytes, stays legible at any size, and its text can be selected and translated. Icons are the same story: an inline SVG comes out lighter than a small PNG and takes its colour from the theme.

This is where we hold a hard position and pay for it: the entire front page of this site contains zero img tags. Everything here that looks like an infographic is drawn with HTML and CSS. We accept the constraint too, because none of these shapes can be a photograph of a real product. If you run a shop, the product photo cannot be deleted, and the rest of this lesson is exactly for that.

The real size, not the size you uploaded

The most common mistake with website images is uploading the camera file or the Photoshop export directly and then displaying it small with CSS. The browser downloads the whole file and then shrinks it. That means the visitor paid for every byte they will never see.

The right work is two steps. First find the size the image is actually displayed at: open the page in a browser, right click the image, inspect it and read the real element width. Second, produce the file at that size, usually at twice it for high density screens. If an image in your theme is always shown at 400 pixels wide, an 800 pixel file is enough and a 3000 pixel file only burns the visitor data allowance.

In WordPress this is fairly automatic: each upload generates several sizes and the theme hands the browser the most suitable one through srcset. There are two places where that chain breaks, and both are common. First, an image dropped into body copy with the address of the original file, which bypasses the whole mechanism. Second, an image whose dimensions exceed every generated size, such as a 4000 pixel photo for which no intermediate size was ever made.

Format and compression, with real numbers

To take this out of the realm of taste, we took a real file from this server and produced it at two widths in three formats. The original is a 1200 by 630 share cover weighing 57.8 kilobytes as it was uploaded. With ImageMagick, quality 78 for JPEG and WebP and quality 55 for AVIF, this is the table:

Two things fall out of this. First, both moves work and neither replaces the other: changing format at the same width roughly halves the weight, and halving the width roughly halves it again. Second, doing both took that 57.8 kilobyte file down to 11.7 kilobytes, about a fifth, with nothing visible to the eye.

One necessary warning: these numbers are for one image. A photo with a flat sky compresses far better and a screenshot full of small text far worse, and in lossy compression small text is the first thing to fall apart. The comparison of the formats themselves and which suits what is opened in the image formats lesson; here only their effect on weight matters.

The command that produced these outputs is one line and works over a folder too:

for f in *.jpg; do convert "$f" -resize '800x>' -strip -quality 78 "${f%.jpg}.webp"; done

Three things in that command are deliberate. The greater-than sign after the width means only shrink images that are larger, never enlarge a smaller one, and without it the command inflates your small files. strip removes extra data such as the camera model and the GPS coordinates, which is both bytes and sometimes information you did not mean to publish. And quality 78 is a starting point rather than a law; try a few values on your own images.

Which image must not be lazy loaded

Lazy loading means the browser does not download an image that is not yet near the viewport. It is switched on with one HTML attribute and it is a large win on a page with dozens of images.

And this is exactly where the most common speed mistake happens: someone installs a plugin that lazy loads everything, including the big image at the top of the page. Now the browser deliberately delays the image that should arrive first, and LCP gets worse rather than better. Google documentation is explicit: do not lazy load images that are likely to be in the viewport when the page loads, especially LCP images.

The rule that follows is simple. Any image the user sees without scrolling is not lazy. Anything below that is. For that top image there is one extra step available: you can tell the browser with a fetch priority attribute that this one matters more than the rest. And combining lazy with high priority does not work; Google documentation says such an image is still delayed while it is off screen and then fetched with high priority, which is not what you wanted.

Checking it is manual and takes a minute: open the page, view the source, and look for the lazy attribute on the first large image. If it is there, you have found it.

Explicit dimensions, and the trap we fell into ourselves

The last rule is the simplest and the most ignored: every image tag needs its own real width and height. Without them the browser does not know how much space to leave, so it lays the text out and pushes everything down when the image arrives. That is the shift counted in CLS.

With those two attributes the browser computes the aspect ratio from them and reserves the space in advance. So even if your CSS makes the image fluid, the reserved space is right and no shift occurs. That is what lets a site have a CLS of zero and still have responsive images.

And now the trap we fell into ourselves, because no tutorial writes it down. Almost every responsive site carries a global rule that makes image height automatic; the main stylesheet of this site carries exactly that rule. For preventing shift this is fine and correct. But it also means something that gets expensive at the wrong moment: if you set the width in CSS somewhere and leave the height to the HTML attribute, that global rule wins and the box collapses to the file own natural ratio. For us it happened on the avatars of the freelancers page: boxes that were meant to be circles came out as ovals, and the worst case was a photo that was really a tall phone screenshot. The right fix is to let the CSS own the shape, giving both width and height itself and setting the crop with object-fit; the HTML attributes are there to reserve space, not to shape a box.