Why Images Slow Down Your Website and How to Fix It

A page can have clean code and a sensible layout and still feel slow, because the biggest thing the browser has to fetch is usually a picture. Photos are often the heaviest files on a page by a wide margin, and they are also the easiest thing to get wrong without noticing: the page looks fine on a fast connection, so nobody sees the problem. This guide explains what actually makes images expensive, which fixes matter most, and how to check the result yourself.

File weight and displayed size are two different things

An image has two sizes that people tend to blur together. The first is its pixel dimensions, such as 4000 by 3000. The second is its file weight, the number of bytes the browser must download. Both matter, but they cause different problems.

Imagine a phone photo that is 4000 pixels wide, placed in a blog column that is 800 CSS pixels wide. The browser downloads every byte of the 4000-pixel file, decodes it into memory, and then scales it down to fit the slot. The reader sees an 800-pixel image and pays for a much larger one. Since the pixel count grows with width times height, a file five times wider than needed carries twenty-five times as many pixels as a correctly sized one. File size does not scale exactly with pixel count because compression varies with content, but the direction is clear: oversized dimensions are the most common cause of oversized files.

There is one legitimate reason to serve more pixels than the slot width: high-density screens. On a display that uses two device pixels per CSS pixel, an 800-pixel slot can use a 1600-pixel image and look sharper. That is a reason to go to about twice the slot width at most, not to ship the original camera file.

Choose the format that fits the image

Format affects weight at the same visible quality. A short decision list:

• Photographs with smooth gradients and lots of colour: JPEG or WebP. Both are lossy, so they discard detail the eye is unlikely to miss.
• Screenshots, logos, line art and anything needing transparency: PNG (lossless, supports alpha) or WebP, which also supports transparency.
• Newer formats such as AVIF can compress well, but browser support differs, so check what your audience's browsers can display.

PNG is a poor choice for photographs because lossless storage of noisy, detailed pixels produces large files. If you have a photo saved as PNG, converting it to JPEG or WebP is often a large saving, at the cost of the lossy trade-off described below. The image format comparison goes deeper on when each one wins.

Compression: trading detail you will not miss

Lossy compression works by throwing information away. JPEG, for example, divides the picture into 8x8 pixel blocks and stores each block in a simplified form. Lower the quality setting and more detail is discarded, which shrinks the file but eventually produces visible blockiness and smearing around edges. Lossless compression, as in PNG, keeps every pixel exactly but cannot shrink noisy photographic data very far.

The practical approach is to lower quality in steps and stop when you can first see a difference at the size the image will actually be displayed. Viewing at 100 percent of the displayed size, not zoomed in, is the fair test.

Resize first, then compress

The order matters. Reducing dimensions removes pixels outright, which is usually a bigger lever than turning the quality dial. A sensible workflow is:

• Decide the largest width the image will be displayed at, and double it if you want to support high-density screens.
• Resize the image to that width.
• Compress it, checking the result at display size.

In your browser, both steps can be done without installing anything. Image Resizer lets you type exact width and height in pixels or click a quick scale preset such as 50 percent, keeps the aspect ratio if you ask it to, and accepts up to 50 images at once. Its advanced options let you pick JPEG, PNG or WebP output and a quality value. Image Compressor handles one image at a time: choose to keep the original format or switch to JPEG or WebP (AVIF appears only if your browser can encode it), set a quality slider, and optionally cap the maximum width and height. Both tools run in your browser, so the image is not uploaded anywhere.

Lazy loading and responsive images

Once files are the right size, the next question is when and which version the browser fetches.

Lazy loading defers images that are off screen. Adding the attribute loading="lazy" to an img element tells the browser it may wait to fetch that image until the reader scrolls near it. It suits images further down the page. Do not use it on the main image at the top of the page, because that one should load as early as possible.

Responsive images let the browser choose among several sizes of the same picture. You provide a srcset attribute listing the files and their real widths, for example a 400-pixel, an 800-pixel and a 1600-pixel version, each marked with a w descriptor. You add a sizes attribute that tells the browser how wide the image will be displayed in the layout. The browser combines that with the screen's pixel density and picks a candidate. Two details are often misunderstood: the w values describe the file's intrinsic pixel width, not the display width, and sizes describes the layout slot, which the browser needs before the CSS has finished loading. If sizes is missing, the browser assumes the image fills the viewport width and may fetch a larger file than needed.

Stop the page jumping: set width and height

Layout shift happens when an image arrives and pushes text down. If the img element has no width and height attributes, the browser cannot reserve space until the file has downloaded and its dimensions are known. Adding the image's intrinsic width and height as attributes lets the browser calculate the aspect ratio in advance and hold a correctly proportioned space. Combined with CSS that lets the image scale to its container, the layout stays put while pictures load.

How to measure it yourself

You do not need outside numbers to see where your page stands. Use the tools already in the browser:

• Open developer tools and go to the Network tab. Reload the page and filter by Img. Sort by size to find the heaviest images, and compare each one's transferred size to how big it appears on the page.
• Hover over an image in the Elements panel, and the browser shows its rendered size next to its intrinsic size. A large gap between them means you are shipping pixels nobody sees.
• Run Lighthouse from the browser's developer tools. Its report includes audits about properly sized images, modern formats, deferred off-screen images, and layout shift, each naming the specific files involved.

What to do

Work through this order for each image on a page: resize to no more than about twice its display width, pick a format that suits the content, compress until you first notice a difference, give the img element width and height, add loading="lazy" for anything below the fold, and use srcset with sizes if you serve many screen sizes. If you are handling a whole folder of pictures, see batch processing images without desktop software. Then reload with the Network tab open and confirm the heaviest image on the page is one you chose to make heavy.