Image Optimization for Speed and Search

When I look at the network capture from a slow site, the first thing I check is images. Not JavaScript, not fonts, not the server. Images. They are almost always the heaviest thing on the page, and almost always the least examined. Someone spent a week arguing about which framework to use and then dropped a 4 megabyte photograph into the hero section without thinking about it once.

This happens because images feel like content, not code. Code gets reviewed. Content gets pasted. A designer exports a PNG at whatever size the design tool produced, a developer references it, and nobody in the chain feels responsible for the fact that the file is twenty times larger than it needs to be. The build pipeline that minifies every line of JavaScript will happily ship a screenshot saved as a lossless PNG when a JPEG at eighty percent quality would look identical and be a fraction of the size.

The physics here are simple. A browser cannot paint what it has not downloaded. If your largest image is the hero photo, then the time it takes to fetch that photo is roughly the floor on how fast your page can feel. You can optimize everything else and still lose, because the thing users are waiting to see is the thing you never compressed.

So the first question is format. Photographs should be JPEG or, better, a modern format like WebP or AVIF, which encode the same visual quality in fewer bytes. PNG is for things with sharp edges and flat colors, like screenshots and diagrams, and even then a modern format usually beats it. SVG is for logos and icons, because it is a description of shapes rather than a grid of pixels, so it scales to any size and is often tiny. Most bloated sites I see are bloated because someone used PNG for a photograph. That one mistake can cost megabytes.

The second question is dimensions. If the image is displayed at 600 pixels wide, sending a 3000 pixel wide file means the browser downloads twenty-five times the pixels it needs and then throws most of them away. The fix is to generate several sizes of each image and let the browser pick, which HTML supports directly through the srcset attribute. This sounds like busywork, and done by hand it is, which is why it should be automated. Every serious static site generator and image CDN can do it. The point is not to do it manually; the point is to set it up once and never think about it again.

The third question is timing. Not every image needs to load immediately. An image far down the page can wait until the user scrolls near it, and browsers now support this natively with loading equal to lazy on the img tag. But there is a trap: people lazy-load everything, including the hero image at the top. That makes the most important image on the page load later, not earlier, because the browser deprioritizes it. The rule is the opposite of uniform. Load the image the user sees first as eagerly as possible, and defer the rest.

Then there is layout. An img tag without width and height attributes gives the browser no idea how much space to reserve, so when the image finally arrives, the text below it jumps. Users hate this more than slowness. They go to tap a link and the page shifts and they tap something else. Putting explicit dimensions on images costs nothing and eliminates the jump entirely, because the browser can reserve the space before a single byte of the image arrives.

What does any of this have to do with search? More than people expect, in two ways. The direct way is that search engines measure page experience, and a page that loads slowly and jumps around measures badly. The indirect way matters more: slow pages lose visitors before the content renders, and a page that people abandon is a page that fails at whatever it ranked for. You did the hard work of getting the click and then wasted it on a file you never looked at.

There is also image search itself, which people forget is a search engine. An image named final-v3-export.png with no alt text is invisible to it. An image with a descriptive filename and honest alt text can rank for queries where a picture is the answer. For some businesses, products and recipes and travel especially, that is real traffic. But that is a subject for its own essay.

I built GazeSite to catch this class of problem, and the reason image findings show up so often in its reports is not that the checks are aggressive. It is that image optimization sits in a gap between roles. Designers own how images look. Developers own how pages load. Nobody owns the connection between them, so the connection is where the waste accumulates.

The good news is that this is the rare performance problem that is mostly mechanical. You do not need to rearchitect anything. Pick the right format, serve the right size, load the top image first and the rest lazily, declare dimensions. Any one of these is an afternoon of work. Together they will often cut page weight more than every other optimization combined. Speed problems usually feel hard. This one only feels boring, and boring is the easiest kind of hard problem to solve.