Images that do not slow the site down

The largest file on a typical business site is a photograph nobody resized. It came off a phone, looked right in the editor, and every visitor since has downloaded it at full size. Making it cheap is mostly arithmetic: how many pixels the page actually draws, then how those pixels are stored, then how hard the encoder was allowed to work. The order matters, because fixing the last one while leaving the first two alone changes almost nothing. This stops being an image problem only when a page is already small and still stalls: then the cost is a script, a font, or the server.

What actually makes an image heavy?

Three things, in descending order of effect.

First, the number of pixels. A photograph from a modern phone holds around twelve million, arranged 4032 wide by 3024 tall. A card in a grid draws it 380 pixels wide. The browser still downloads all twelve million, decodes them into memory, and discards most of the result. That decode is work on a visitor's phone, and on a cheap Android it is the part that hurts: memory is the constraint, not the cable.

Second, the format — how the pixels are stored. A photograph has millions of near-identical shades; a logo has five colours and a hard edge. Store a photograph in a format built for flat colour and you pay for its honesty; store a logo in a format built for photographs and the edges go soft and furry.

Third, the quality setting: the dial everyone reaches for, and the smallest of the three. Re-encoding a twelve-megapixel file at a lower quality still ships twelve megapixels. You have made the same mistake smaller.

Why is a phone photo fine and its raw file not?

The camera is not the problem. It records more than any page can show: more pixels than the box, more colour than the screen, and a note about which way up it was held. Two decisions hide there. Size: what is the largest box this picture will ever be drawn in? Shape: a phone shoots 4:3 and a banner is 16:9, so someone must decide whether to crop the top of the building or squash it. Compression decides neither, which is why a site can be "optimised" and still ship a picture that is too big and the wrong shape. Orientation is the third: a photograph taken sideways carries a note saying so, and a pipeline that strips metadata without applying it turns a portrait into a landscape, permanently.

Which images are content and which are decoration?

Content means the image is the reason the page exists: the product, the dish, the room, the document described. It earns bytes, a proper box, and a caption saying what it shows.

Decoration means furniture: the gradient behind a heading, the wave between two sections, the photograph of a stranger shaking hands in an office that belongs to nobody. It should cost almost nothing — a colour, a shape drawn in the stylesheet, a few kilobytes. A decorative photograph is the most expensive way to add no information.

A third kind is worth naming: an image of text. A menu photographed at an angle, the hours rendered into a graphic — content made unreadable, unsearchable and illegible on a phone unless the visitor pinches. If the information is words, set it as words.

How does the right size reach the right screen?

The browser has to be told what sizes exist, then it chooses. Without that instruction there is one file, and a phone downloads the desktop one. With it, the markup offers several widths and states how wide each will be drawn at every breakpoint; the browser picks the smallest file that still looks right for that screen and density.

Density surprises people. A phone can pack three physical pixels into each layout pixel, so an image drawn 380 wide wants roughly three times that to look sharp. Serving exactly 380 is correct arithmetic and a soft photograph; serving 4032 is the other failure. The responsive images guidance shows how that choice is expressed.

What does lazy loading buy, and what does it break?

It buys the obvious thing: an image far below the fold is not downloaded until the reader approaches it, so a long catalogue page stops paying for photographs nobody scrolled to.

It breaks three things. The image the visitor came for: marking the hero or the first product as lazy delays the picture that decides whether the page looks alive, and the reader sees a grey rectangle where the shop should be. The second slide of a carousel: a slide translated out of view may never count as near the screen, so it is never fetched, and the visitor taps onto an empty frame. And the space the image will occupy: a lazy image with no reserved dimensions is a hole that closes when the file lands, pushing everything below it down mid-sentence. Reserve the box with an aspect ratio or explicit dimensions; that is what the layout-shift measurement in the Core Web Vitals guide actually measures.

The image	What it should do	What happens when it does not
The hero	Load immediately, one honest size	A blank first screen on a slow phone
A product in a grid	Fixed box, several widths offered	The grid jumps as each file lands
Slide two of a carousel	Load with the first slide	An empty frame after the tap

In what order do you fix a page?

1. List the images by file size, largest first. The top three are the whole job.
2. Write down the box each one is drawn in, at the widest screen it will meet.
3. Resize to that width, doubled for sharp screens — most of the weight leaves here.
4. Store it in a format suited to what it shows, keeping a fallback the browser can decode.
5. Lower the quality last, and compare at full size on the product, not on the sky.
6. Reserve the box, then mark what sits below the fold lazy and leave the first screen eager.

Where this goes wrong

• Resizing by dragging a corner and exporting. The canvas keeps its size, and the file ships the same weight.
• One format for everything. Photographs saved as flat graphics, logos as photographs: compression fixes neither.
• One 1600-pixel file for a 390-pixel phone, justified by a laptop screen.
• Alt text written as a keyword list. It is read aloud to someone who cannot see the picture.

What this does not cover

It gives no timings and no file-size targets: both depend on the page and the connection, and a number copied from an article is not a measurement. It says nothing about video, nor whether files come from a build step or a person with an editor.

We build sites where every image is sized to the box it sits in, and the page holds still while it arrives.