A shift in the proper sizes of images on web pages

May 18, 2017

In the old days, one of the ways that you could irritate people was to build your web pages using full-sized, full-resolution images and then tell the user's browser to resize them for you. This was the lazy person's way of building your pages (because it didn't require you to find a good image resizing program), and while it generally tested okay on your local network, it made a whole lot of people annoyed as their browsers slowly downloaded your big images only to, in effect, throw most of them away. Good web design was to resize your images to their final size on the server and only serve that size (in a suitable streamlined image format, too, often JPEG instead of a PNG original).

Then quietly things changed. Along came devices with very different screen sizes and resolutions, which created responsive design, and as part of responsive design you suddenly wanted images to scale down to fit into the available screen space. And generally once you're scaling down you also want to be able to go large(r), so that people browsing on relatively large screens don't get postage-stamp sized images that don't look too appealing.

(As I found out, you probably don't want to give the client a small image and have it resize it larger. Resizing images larger rarely works very well.)

In other words, suddenly it makes a lot of sense to put large size images in your web pages and have the browser downsize them for you in the name of responsive design. If your design has a maximum width or height in pixels that you can easily determine, you can make your initial images fit into that; otherwise, it's very tempting to just leave them pretty large just in case, let the client resize the image down to fit its size and resolution desires, and count on fast networks to make this work. A lot of people may not even really notice any more, given that typical web pages are now huge in general. Your carefully designed page with one or two large images may still be significantly smaller than, say, the Twitter page for a Tweet with all its HTML tangle and CSS and JavaScript (and perhaps images).

Of course this is a privileged position. Not everyone has fast and inexpensive networking; a significant portion of the world has relatively slow and often expensive connectivity and is often using small devices on top of that. When you (or I) chose to serve up big images all the time, we are harming these less network-privileged people in various ways. If we care (and maybe we should), we should try to do better. For example, there are probably ways to use CSS media queries to select appropriate starting point images.

(The 'big image' situation of the past was also a privileged position; it's just that fewer people were inside the circle of network privilege and the people outside it were better placed to be vocal about things, since they were in the West and were people that designers and companies wanted to appeal to. The fundamental difference between then and now is how many people in our audience we assume have fast networking and good devices.)

PS: If you routinely use 'view page in no style', you rapidly get an appreciation for how many people serve quite large images. It's a lot, even (or especially) for blogs and other less commercial websites. My own shift makes me rather late to this particular party.


Comments on this page:

You may want to check out HTML5's "srcset" attribute for the <img> tag:

What does <img srcset=""> do?

Defines multiple sizes of the same image, allowing the browser to select the appropriate image source.

HTML5 also has the <picture> element:

The former does not work in Microsoft browsers at this time though:

So one doesn't have to serve up big images all the time, but given the web browser the option to figure it out.

P.S. I remember surfing the 'net in Netscape 4.x with the "load images" option turned off to make things go more quickly.

Written on 18 May 2017.
« Unfortunately I don't feel personally passionate about OmniOS
I'm not sure what I feel about this web spider's User-Agent value »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu May 18 01:17:49 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.