The browser should receive an image close to the size it will display. Serving one large file to every screen wastes most of it on phones.

The mismatch

A design has a slot for an image, and the slot is a certain number of pixels wide depending on the screen.

The file being sent is whatever was uploaded, which is usually the same file to every visitor.

So a desktop showing an image at twelve hundred pixels and a phone showing it at four hundred both receive the same file.

The phone downloads roughly nine times more data than it can display, on the connection least able to afford it.

This is different from compression

Worth separating, since the two get conflated and both matter.

Compression reduces the file size of an image at a given dimension, by discarding detail nobody sees.

Sizing reduces the dimensions themselves, so there is less image to compress.

A well-compressed image at four times the needed dimensions is still four times too much data.

Doing both is the answer, and sizing usually saves considerably more than compression alone.

Most sites have done neither, some have done the compression, and few have done the sizing.

How to find the mismatch

The last is the quickest route. Most speed testing tools list images served larger than displayed, with the saving available for each, which turns this from an investigation into a list.

Let the browser choose

The mechanism that solves it properly.

A page can offer several versions of the same image at different widths and let the browser take the one that fits the screen it is on.

That means a phone downloads the small version and a desktop the large one, from the same page and the same markup.

Most platforms and content systems do this automatically now, generating the sizes on upload.

So the first question is whether yours is doing it, which is worth asking rather than assuming.

Where it is not, enabling it is usually a setting or a plugin rather than a rebuild.

A worked example

A business had a gallery page loading nineteen photographs, each about two megabytes and each displayed at a fraction of its dimensions.

On a phone the page transferred nearly forty megabytes to display images totalling perhaps two.

The platform was capable of generating multiple sizes and had been configured not to, by a previous developer, for a reason nobody could recall.

Turning it back on regenerated the sizes overnight and the page went from about nine seconds to under three on a phone.

No image was recompressed and none looked different.

The whole fix was a setting.

Set a maximum before upload

Since the automatic sizing works from whatever it is given.

A photograph straight from a phone is several thousand pixels wide and a few megabytes, and generating six sizes from it still leaves the original on the server.

Agree a maximum dimension for uploads, around two thousand pixels on the long edge for anything shown full width, and less for smaller slots.

That keeps the storage sensible and means the largest generated version is not absurd.

Tell whoever uploads images what the limit is, since this is a habit rather than a technical control.

Most phones can be set to take smaller photographs, or the resizing can happen as part of the upload.

Watch the high-resolution question

Because it is the reason images are sometimes deliberately larger.

Modern screens pack more pixels into the same space, so an image displayed at four hundred pixels wide can usefully be about eight hundred to look sharp.

That is a genuine reason for a file larger than the slot, and it is a factor of two rather than of nine.

So the target is roughly double the displayed width, not the same, and certainly not five times.

Anything beyond double is waste rather than sharpness, which is the useful rule.

Fix the biggest first

Since the distribution is uneven.

On most sites two or three images account for the majority of the wasted weight.

The speed test list is ordered by saving, so working down it from the top produces most of the benefit in the first few items.

Start with the largest image on your most-arrived-at page, which is frequently the same image.

That single fix is often worth more than everything else on the list combined.

Set the dimensions in the page

A related fix worth doing at the same time, since it costs nothing and solves a different problem.

An image without stated dimensions gives the browser no idea how much room to leave, so the text around it moves once the image arrives.

That is the jumping people notice while a page loads, and it is particularly annoying on a phone where somebody has started reading.

Stating the width and height in the markup lets the space be reserved before the file arrives, which removes the shift entirely.

Most platforms now do this automatically, and images inserted by hand or by an older page builder frequently lack it.

Delay the ones below the screen

The other half of the image question, and it pairs with sizing.

Images further down a page do not need to arrive before the visitor has scrolled to them, and loading them later means the top of the page appears sooner.

Most platforms now do this automatically for images below the first screen, which is the correct default.

The mistake is applying it to the image at the top as well, which delays the very thing the visitor is waiting to see.

Check that your first image is not being deferred, since that single misapplication makes a page measurably worse rather than better.

The counter-case

Sizing is not always the priority.

On a text-heavy site with few images the whole subject matters little, and the effort belongs elsewhere.

Some images genuinely need to be large, such as a detail shot somebody will zoom into, and forcing those down loses the point of them.

And modern platforms handle most of this automatically, so a recent site may need nothing.

Check whether multiple sizes are being generated, set an upload maximum, and fix the two or three worst images.

What to do

  1. Run a speed test and read the image list.
  2. Ask whether multiple sizes are generated.
  3. Turn that on if it is not.
  4. Target double the displayed width.
  5. Set an upload maximum.
  6. Tell whoever uploads what it is.
  7. Fix the largest image on your busiest page.

Step two is worth asking before anything else, since a platform already capable of this and switched off is a setting rather than a project.

The upload side of the problem is covered in images uploaded at camera resolution.


Frequently asked questions

What is the mismatch?

A slot displays an image at a certain width and the same file goes to every visitor, so a phone showing four hundred pixels downloads the twelve hundred pixel version.

How is this different from compression?

Compression reduces file size at a given dimension. Sizing reduces the dimensions themselves. A well-compressed image at four times the needed size is still four times too much data.

How do I find it?

Run a speed test and read the list of images served larger than displayed, with the saving for each. That turns an investigation into a list.

What is the proper fix?

Offering several versions and letting the browser take the one that fits. Most platforms do this automatically, so first ask whether yours is switched on.

How large should the file be?

About double the displayed width, because modern screens pack more pixels into the same space. Beyond double is waste rather than sharpness.

Where should I start?

The largest image on your most-arrived-at page. Two or three images usually account for the majority of the wasted weight.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Gallery slow on a phone?

Ask whether your platform generates multiple image sizes. It usually can, and it is sometimes switched off.

Start a Conversation