Resize images to roughly the size they are displayed at, then compress them. A phone photograph is typically ten to twenty times larger than the page needs, and images are usually most of a slow site's weight.

The arithmetic

A modern phone photograph is around four thousand pixels wide and several megabytes.

The space it occupies on a web page is usually eight hundred pixels wide, sometimes four hundred on a phone.

So the visitor downloads five times more image than can possibly be displayed, and the browser then does the work of shrinking it.

Ten such images on a page is thirty or forty megabytes, which on mobile data is both slow and, for somebody on a limited plan, expensive.

Why it happens

Because nothing prevents it and nothing warns about it.

The upload works. The image appears correctly. It looks fine on the office computer. There is no error and no indication that anything is wrong.

Most site builders will happily accept a twelve megabyte file and display it, and some generate smaller versions automatically while others do not.

Which means this is entirely invisible unless somebody looks for it, and it is the single most common cause of a slow small business site.

What the numbers should be

Those are rough and generous. A page whose images all sit inside them will not be slow because of images.

Compare that against four megabytes, which is ten to twenty times the upper figure.

A worked example

A photographer's portfolio page with twelve images, uploaded at full resolution because quality mattered.

The page weighed forty-six megabytes. On mobile data it took over thirty seconds to finish loading.

The concern about quality was legitimate and misplaced: at the size the images were displayed, a properly resized and compressed version was visually indistinguishable on any screen anybody was using.

Resized to 1600 pixels and compressed, the page came to about two megabytes and loaded in under three seconds.

Enquiries from that page rose noticeably over the following months, which is unsurprising given that most visitors had previously never seen it finish loading.

The images looked the same. There had never been a trade-off, only a belief that there was one.

Doing it without special software

The practical part, since this needs to be easy or it will not happen.

Most phones and computers can resize an image in their built-in photo tools, and most will let you do a batch at once.

There are free online tools that resize and compress in one step, which is sufficient for a small business and requires nothing installed.

And several site platforms have a plugin or setting that compresses on upload, which is the best arrangement because it removes the discipline requirement entirely.

The order matters: resize first, then compress. Compressing a four thousand pixel image leaves it four thousand pixels wide and still far too heavy for the page.

The counter-case

Where large images are justified.

A site where the image is the product and the customer will zoom: fine art, textiles, anything with detail that matters at close range.

Even then, the answer is a smaller image on the page with a larger one loaded on demand when somebody clicks, rather than serving the full file to everybody.

And print-resolution downloads for customers, which should be a deliberate download rather than an embedded image.

What is never justified is a large file displayed small, which is the situation on most sites.

Serving different sizes to different screens

The refinement that removes the remaining waste once resizing is done.

A phone displaying an image four hundred pixels wide does not need the same file as a desktop showing it at twelve hundred.

Modern pages can offer several sizes and let the browser choose, which means the phone downloads the small one and the desktop the large one.

Most site platforms generate these versions automatically on upload, and whether they are actually being served is worth checking rather than assuming.

Where it works, mobile visitors download a fraction of what a desktop does, which is exactly the right way round given who has the slower connection.

Format matters less than size

Worth mentioning because it is where advice frequently starts.

Choosing between formats produces a modest improvement. Resizing a four thousand pixel image produces a large one.

The rough guidance: photographs as JPEG, graphics and logos with flat colour as PNG, and anything simple and geometric as SVG where the platform supports it.

Newer formats offer better compression and support varies, so a fallback is needed, which is why this is a refinement rather than a starting point.

Get the dimensions right first. The format decision is worth perhaps a tenth of what resizing is worth.

Loading them only when needed

The other half of the improvement.

Images below the visible part of the page do not need to load until somebody scrolls to them.

That is a standard capability now and many platforms do it automatically, which means a long page loads only what is on screen.

The caution: the image at the very top should not be deferred, because deferring the first thing somebody sees makes the page feel slower rather than faster.

The originals you should keep

A caution before anybody starts deleting.

Resize copies for the website and keep the originals somewhere else at full size.

You will want them for printed material, for a future redesign at different dimensions, and for anything that needs detail the web version does not carry.

Once an image has been resized and compressed, the discarded detail cannot be recovered, and re-photographing a job finished two years ago is not an option.

Cloud storage or an external drive, organised by job, is sufficient for this. What does not work is treating the website itself as the archive, which is exactly what happens when nobody decides otherwise.

Auditing what you have

  1. Open your busiest page and note how long it takes on a phone.
  2. Check the largest images in your media library by file size.
  3. Anything over a megabyte is a candidate.
  4. Resize and re-upload the worst dozen.
  5. Set up compression on upload so it does not recur.

The fifth is what makes this permanent. Fixing the existing images without changing how new ones are uploaded means being back in exactly this position within a year.

How to measure the result honestly is covered in why your site feels slow on a phone.


Frequently asked questions

What is the arithmetic?

A phone photograph is around four thousand pixels wide and several megabytes. The space it occupies is usually eight hundred pixels, so most of the download is wasted.

Why does it happen?

Nothing prevents or warns about it. The upload works, the image appears correctly, and it looks fine on an office computer. It is invisible unless somebody checks.

What should the numbers be?

Header images around 1600 to 2000 pixels, content images 800 to 1200, thumbnails 300 to 400, and file sizes under 200 kilobytes for most.

Will resizing hurt quality?

At the size images are displayed, a properly resized version is visually indistinguishable. The trade-off people worry about mostly does not exist.

Does the format matter?

Less than the dimensions. Resizing a four thousand pixel image produces a large improvement; choosing a format produces a modest one. Get dimensions right first.

How do I stop it recurring?

Set up compression on upload, so images are handled automatically. Fixing existing files without changing the process means being back here in a year.

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.

Page taking thirty seconds on mobile data?

It is nearly always the images, and resizing a dozen of them is an afternoon.

Start a Conversation