← Back to blog
63 MB of screenshots, 1.3 MB served

63 MB of screenshots, 1.3 MB served

imagestoolsbugs

Pictures are the heaviest thing on a website. A whole page of text weighs less than one photograph of a coffee cup. I knew that, and I still let mine collect: different formats, different sizes, whatever each program happened to hand me.

Then I counted. The project screenshots alone were 63 MB.

That number is what made me build one way of doing it. One folder for the originals, one tool that makes the version the site really needs. Nothing clever.

What changed

The same set of screenshots as web images is about 1.3 MB. Nearly fifty times smaller, and I cannot see the difference at normal size.

That was the easy half, and I thought it was the whole thing. It was not.

Why it works

The old format keeps every pixel exactly as it was. That is what you want for a screenshot you are going to edit, and not what you want for one you are going to show. The newer format throws away the detail the eye will not miss.

And the site stopped sending the full file. It sends a version sized to the box the picture sits in, so a phone does not download a picture made for a desktop.

The half that file size does not see

A picture can be small and still wrong. Two things taught me that in the same week.

The first was a screenshot of a long page. I captured it from top to bottom, 30,700 pixels tall, and the tool shrank it to fit a normal box. Shrinking keeps the whole picture, so I lost nothing. I had turned a page into a thin line. The honest fix is to crop, not to shrink: keep the part worth showing and cut the rest away.

The second was worse, because it looked fine.

Ten screenshots showed a page sitting in one corner with a wide empty area around it. The file itself was not broken. What happened is that the file was larger than what had been drawn on it. The page was painted in the top left, and the rest of the file was the page's own background colour.

So the file looked perfect in a viewer. Very tidy, plenty of space around the content. On the site it showed the page in a quarter of the frame. Ten of those had gone out before anyone noticed, and the one who should have noticed was me.

Both cases come down to the same thing. Compression decides how heavy a picture is. The capture decides whether it is the right picture, and no amount of compression will tell you that.

The check

So I stopped trusting my eye. My eye was looking at the file. The reader was looking at the page.

The check is small. It reads every screenshot before it goes out and measures the empty space at the edges. If a file has a wide margin, it says so. Ten files had gone out wrong. Since the check exists, none has.

What to do with your own

Open the folder where your site's pictures live and sort by size. The top of that list is what your readers download.

Then open one of them. Not in the file viewer, where a picture is shown in whatever shape the window happens to have, but in the place where it actually appears. That is the picture your readers see.

Nine times out of ten nothing is wrong. The tenth time you will find a page hiding in the corner of its own frame.

The rule

A smaller file is not a better picture. Compression decides how heavy it is. You decide whether it is the right one.