Reducing Image Size for better page load times

The ultimate guide to reducing image sizes for more performant web pages

Today I want to cover in some detail the reasons why image size matters on the web and different ways we can achieve small images on the web.

Why Reduce?

There are four main reasons why I think you should care about reducing your image size, lets go through each of them in detail.


The smaller something is the quicker it get can get from your web server to your user’s browser.

Images don’t block the first paint, but users won’t consider a page to be loaded until all assets are viewable. Missing images normally stick out like a sore thumb.

Google talk about this in their article on the critical rendering path.

Finally, notice something interesting: our “awesome photo” did not block the domContentLoaded event! Turns out, we can construct the render tree and even paint the page without waiting for each and every asset on the page: not all resources are critical to deliver the fast first paint. In fact, as we will see, when we talk about the critical rendering path we are typically talking about the HTML markup, CSS, and JavaScript. Images do not block the initial render of the page - although, of course, we should try to make sure that we get the images painted as soon as possible also!

Google likes fast pages, users like fast pages. Smaller image sizes make for faster pages.


Unfortunately I don’t know who said this first, but this quote gets bandied about a lot.

The fastest HTTP request is the one not made.

The state of browser/device caching generally improves year on year but the fact remains that local caching is not unlimited, browsers can only hold onto so much data. The smaller your images are the more of them can be cached.

Other Services

It is easy to fall into the trap of thinking that the only two types of things viewing your website are people and search engines.

There are countless small services which from time to time will need to look at your website, each with its own idea of what makes a reasonably sized image.

An example is when someone shares your post on social media, unless you have set up the appropriate meta data the social network will attempt to grab relevant content from your page. Using nice small images will make the Facebooks and Mastodons of the web much more likely to grab and cache the appropriate content.

Your Bandwidth

The cost of bandwidth has definately dropped in the last 5-10 years but for many setups bandwidth can be the priciest line item.

Making sure your website can be cached is certainly going to help but most people experience these spikes in bandwidth usage during spikes in traffic brought on by a lot of people visiting your website for the first time (hitting top of Hacker News or Reddit or something similar).

Regardless of if you have a CDN serving your image assets or you just serve them from the same machine that serves your code there will be costs.

Smaller images naturally mean smaller costs. This may sound incredibly trite but lets do some back of an envelope style calculations.

  • Original Image: 100Kb
  • Compressed Image: 65Kb
  • Difference: 35Kb

Lets imagine the image downloaded 10,000 times during a traffic spike.

  • Original Image Bandwidth: 10000000Kb (~9.54Gb)
  • Compressed Image Bandwidth: 6500000Kb (~6.2Gb)
  • Difference: 350000Kb (~3.3Gb)

AWS costs roughly $0.09 per Gb (source)

That will save you around $0.30 of hosting, just for one image and using very conservative numbers.

If you want your pages to be seen by lots of people and it does, this cost will soon mount up.

Need more proof?

You don’t need to take my word for it, there are plenty of reports people have shared online about what happens when they reduce overall page size.

You will see from some of the timestamps on these articles this isn’t particularly new news.

Do You Need an Image?

The ultimate image size reduction is to remove the image entirely.

I am not saying that you should have completely imageless websites but for every asset on your page ask what value does it bring to the user.

If an image isn’t providing value then I am guessing it is distracting someone from something that is providing value. Cutting it will have more benefits than just not loading an extra asset.

Do You Need an Image on That Page?

A similar question to asking if you need an image is to ask if you need the image on the page you are currently looking at.

A trend I have seen, mainly I believe because WordPress makes this very easy to do, is to have very small thumbnails leading to the actual image.

In a lot of these cases the thumbnails are not adding anything, the image is so small and the information held within it so squashed that is just looks terrible. Yet an image still had to be loaded on that page.

In these cases I would argue that a nice link performs the task of the thumbnail in a much cleaner way that is way more consistent (the image behind changing doesn’t change how good/bad the thumbnail looks) and with a much smaller footprint.

Picking the right image type

There isn’t one image format that fits every situation so lets go through the major ones in turn.

You should experiment with the different file types to see what produces the smallest image that works for your needs.


  • PNG stands for Portable Network Graphics, but we can call them “Pee-eeN-Gees” (some folk call them pings).
  • PNGs allow for transparency.
  • They were created as a replacement for GIF files.
  • It uses lossless image compression.
  • They have been supported by all standard browsers for a long time. You need to go back to IE6 to start to see support issues.
  • Normally will have a smaller file size than GIF.


  • JPG stands for Joint Photographic Experts Group, lets call them “Jay-Pegs” for short.
  • JPGs do not allow for transparency
  • They use lossy compression, this means information is discarded at the point of save.
  • They don’t work well for very simple images, since not a lot of image can be thrown out during the save sharpness can be effected.
  • They have been supported for a long time by all major browsers.


  • GIF stands for Graphics Interchange Format. There is a minor holy-war about pronunciation, “giff” or “jiff” are the camps.
  • Has been supported for an incredibly long amount of time.
  • GIFs use lossless compression.
  • They allow for transparency.
  • On small images it is possible for GIFs to be smaller than PNGs.


  • SVG stands for Scalable Vector Graphics, you pronounce each letter when you say it. “Ess-Vee-Gee”.
  • They are vector images, which means they are like XML files.
  • SVGs can be interacted with, making them appear animated or to change colour.
  • They can be compressed losslessly
  • You can add a <metadata> tag within the SVG to make them semantic.
  • SVGs are supported on the majority of modern browsers but support quickly falls off the further back in time you go.
  • Because of their vector nature, SVGs look crisp and clear when zoomed in and on a variety of screen resolutions.
  • SVGs support transparency.

SVGs are my go-to image unless there is a compelling reason to use something else.


Here are some interesting points to consider about WebP files.

  • WebP stands for Web Picture and is pronounced “Web-Pee”.
  • It is a relatively new image format being developed by Google.
  • Browser support is very low, it is natively supported by Chrome and Opera.
  • It provides both lossy and lossless compression of images.
  • They support transparency.

Summary Table

Here is a quick summary of the image types we have covered.

Name Pronounced Compression Type Browser Support Transparency Support
PNG Pee Enn Gee Lossless Great Yes
JPG Jay-Peg Lossy Great No
GIF Giff or Jiff Lossless Great Yes
SVG Ess Vee Gee Lossless Good Yes
WebP Web Pee Both Bad Yes

Lossless and Lossy

A few times now I have mentioned if an image is lossless or lossy. These terms sound confusing but are really quite simple.

Lossy compression creates smaller files by LOSING some information about the original image. It removes details and colour changes it deems too small for humans to differentiate. Lossless compression never discards any information about the original file.

Just remember that Lossy loses stuff and Lossless doesn’t.

Tools to Reduce Image Size

The tooling for reducing images sizes comes in two parts really, we either want tools that will keep the existing file format but compress them in an efficient way, or we recognise that another format would be better and so we want to convert between them.


ImageOptim is my go to tool for getting good image reduction on jpg and png files. It is free and easy to use.

Google have released a WebP converter that runs on the Mac using MacPorts.


I’ve heard Trimage being referred to as the ImageOptim equivalent for Linux operating systems.

You can convert images to WebP by using cwebp, this is the same tool that I mentioned in the Mac section.


I should say I don’t personally run any Windows machines so this is based purely on research. If you have personal experience with any tooling you would like to share, please let me know in the comments.

PNGQuant has a Windows GUI for getting the most out of your PNG images.

I’ve heard good things about FileOptimizer as well.

There is a Windows tool for converting to WebP available on the Google Developers page.


Clearly I think that reducing image sizes is important, it will help provide your users with a better experience and save you some headaches along the way.

If you have any questions or comments please leave them below, I will try and keep this article as up to date as possible.


Whilst researching this article I came across many resources, here are some great ones.


If you’re a Mac user you may be interested in my very quick guide to compressing PDFs into much smaller sizes.

Recent posts View all


The best way to test model scopes in Rails

Learn about Rails scopes and how to best test them with both Rspec and Minitest


Finding out what called a Ruby method

A quick way to understand what is calling your code using the caller method