A Guide to Image Optimisation for the Web

Images make up on average 50-70% of a website's weight. So if your page is slow, the cause is most likely not your code but the photos you've uploaded. The good news: image optimisation is the easiest and most rewarding thing you can do to speed up your site.

Why are images slowing down my site?

Images make up on average 50-70% of a website's weight. While a photo uploaded straight from the camera can be 3-5 MB, the same image drops to 100-200 KB when converted to WebP and scaled to its real display width. On most slow-opening pages the cause is not the server but unoptimised images.

Why it matters

Among Google's page experience metrics is LCP (Largest Contentful Paint): how long the largest visual element on the page takes to appear. On most sites that element is a photo. So your image's load time turns into a metric that directly affects search ranking.

Beyond that:

• Mobile data: most visitors are on mobile. A 4 MB page is expensive for a user with a limited data plan.
• Conversion: every second of delay in page load increases the abandonment rate. If your product page is slow, the purchase doesn't complete.
• Crawl budget: search engine bots spend limited time on your site. Heavy pages get crawled less.

Which format to use when

Format choice is the optimisation step that brings the biggest gain. When you pick the wrong format, however much you compress you won't get the result you want.

Practical rule: WebP for photos, SVG for logos and icons. WebP again for images that need transparency but can't be vectorised.

The most common mistake we see is logos used as PNG. If your logo is a vector drawing, save it as SVG: it's 10 times smaller and looks sharp at every screen resolution.

The right size: the most common mistake

This alone is the source of the biggest waste. The photo you take with your phone is 4000 pixels wide. The area where that photo will appear on your site may be 800 pixels. The browser downloads 4000 pixels and shrinks them to 800 — meaning you waste five times the data unnecessarily.

The right approach:

1. Determine how many pixels wide the image will appear on your site.
2. Aim for twice that value for retina screens.
3. Reduce the image to that size, then compress.

Example: if an image inside a blog post will appear in an 800-pixel area, save it at 1600 pixels wide. For a full-screen hero image 2560 pixels is usually more than enough.

To do resizing and format conversion in a single step you can use our Image Converter tool; it converts and scales up to 30 images at a time.

Where to stop with compression

Compression quality is a value between 0 and 100 and the choice here is made entirely by eye. General tendencies:

• 90-95: Not noticeable to the eye. For places where detail matters, like product photos and portfolio images.
• 80-85: The ideal balance for most cases. Blog images, backgrounds, card images.
• Below 70: Visible degradation begins. Blotching appears especially in flat-colour areas.

The critical point: every re-save loses quality. JPG and WebP are lossy formats. If you re-save an image saved at quality 85 at 85 again, you suffer a second loss. So always work from the original file and don't re-optimise an optimised file.

To shrink many images at once, the Bulk Image Compression tool does the job.

Loading behaviour: lazy loading

There's no point downloading the image at the very bottom of the page if the visitor will never get there. A single attribute in HTML solves this:

<img src="foto.webp" loading="lazy" width="800" height="600" alt="Açıklama">

Three details matter:

• loading="lazy" should be applied only to images off screen. If you apply it to the hero image at the top of the page you worsen your LCP.
• width and height must be written. If not, the page jumps while the image loads; this lowers your CLS (Cumulative Layout Shift) score.
• alt is needed for both accessibility and SEO. Write what the image shows; don't stuff keywords.

Different images for different screens

You don't have to send the same image to both desktop and phone. With srcset you offer the browser choices:

<img
  src="foto-800.webp"
  srcset="foto-400.webp 400w, foto-800.webp 800w, foto-1600.webp 1600w"
  sizes="(max-width: 768px) 100vw, 800px"
  alt="Açıklama">

The browser looks at screen width and pixel density and downloads the most suitable file. The mobile user gets the 400-pixel file, retina desktop gets the 1600.

This is the step that takes a bit of effort to implement but makes the biggest difference to mobile speed.

A practical workflow

The order to follow when putting a new image on the site:

1. Keep the original. Don't use the optimised file as your archive.
2. Crop. Cut away the image's unnecessary edges; the best compression is a pixel that isn't there.
3. Resize. Twice the width of the area it will appear in.
4. Convert format. WebP if it's a photo.
5. Compress. Start between 80 and 85, check by eye.
6. Name it. Not IMG_2847.jpg but antalya-hotel-website.webp. The file name is also an SEO signal.
7. Write alt. Describe the image's content in one sentence.

Common mistakes

• Re-compressing a compressed file. Quality doesn't come back; you only lose more.
• Applying lazy loading to everything. The hero image must load immediately.
• Saving photos as PNG. The same photo is 5-10 times larger as PNG.
• Skipping dimension attributes. The page jumps while loading and the user clicks the wrong place.
• Uploading screenshots as they are. A 2560-pixel screenshot usually does the same job at 1200 pixels.
• Stuffing keywords into alt text. Search engines notice this and view it negatively.

A numerical example

Suppose a typical corporate site's home page has 12 images. Before and after optimisation:

Total: roughly 10.4 MB → 0.7 MB. On a mobile connection this is the difference between the page opening and not opening.

These ratios may look exaggerated, but this is usually the picture we see in the field; because on most sites the images have been uploaded untouched, straight from the camera.

Beyond uploading images: caching

If even an optimised image is downloaded again on every visit, the job is half done. Define a long browser cache for images:

Cache-Control: public, max-age=31536000, immutable

A year may look long but it's safe — because when you change the image you change the file name too. If you use logo-v2.webp instead of logo.webp, or a name carrying a content hash, even if the old file stays in the cache the new name means a new download.

If the file name never changes, a long cache is dangerous: the user sees the old image for months.

Forgotten images

Apart from those within pages, your site has other images and these need optimising too:

• Favicon. The icon in the browser tab. With the Favicon Generator you can produce all sizes from a single file.
• Social share image (OG image). The card that appears when your site is shared on WhatsApp or LinkedIn. 1200×630 pixels is the standard. Without it your share appears as a bare link.
• Apple touch icon. The icon used when added to the home screen on an iPhone.

You can check how your page looks when shared with the Meta Tag Preview tool.

Frequently asked questions

What if old browsers don't support WebP? In practice this is no longer a problem; all current browsers support it. If you still want a guarantee you can define a JPG fallback with the <picture> tag.

Should I switch to AVIF? It produces smaller files, but encoding is slow and tool support isn't as settled as WebP. WebP is enough for most sites.

Should I serve images from a CDN? Useful if your visitors are geographically scattered. For a business serving a single city your priority should be size first, then CDN.

Which format for a product photo with a transparent background? WebP. It supports transparency and is much smaller than PNG.

Image optimisation is the step that brings the most gain in page speed with the least effort. Once you've set up the routine, repeating the same steps for every new image is enough.

You can shrink your existing images in one go with the Bulk Image Compression tool.