Image Optimization for Websites: Formats, Sizing, Lazy Loading and Caching

Images are usually the heaviest files on a web page, so optimizing them is one of the most direct ways to make a site load faster. The short version: serve the right format, at the size it is actually displayed, compressed sensibly, and only when the visitor needs it. This guide walks through each step in the order that tends to save the most bytes, with the HTML you need. For the search side of images (file names, alt text, image sitemaps), see the companion post on how to optimize images for SEO.

Why Image Weight Affects Page Speed

Every image is a download. A phone photo straight from the camera can be several megabytes, and a page with a handful of them makes mobile visitors wait. The cost shows up in Google's Core Web Vitals, especially Largest Contentful Paint (LCP), which on many pages is the hero image. web.dev's guidance treats an LCP of 2.5 seconds or less as "good", and missing image dimensions also hurt Cumulative Layout Shift (CLS). The web.dev overview of Web Vitals explains each metric and its thresholds.

The work below falls into three groups:

1. Make each file smaller – format, dimensions, compression, metadata.
2. Send the right file to each device – responsive images.
3. Deliver it efficiently – lazy loading, priority hints, caching and CDNs.

Step 1: Choose the Right Format

Format choice often matters more than any other setting.

The most common mistake is publishing photographs as PNG. PNG is lossless, so a detailed photo saved as PNG is typically many times larger than the same photo as JPG or WebP, with no visible benefit. Existing PNG or JPG photos can be converted with the JPG to WebP converter or its PNG equivalent.

WebP is supported by all current major browsers, and AVIF support is now broad as well; check caniuse for AVIF if you must support older devices. For a deeper comparison of the four main formats, read PNG vs JPG vs WebP vs AVIF.

Serving Modern Formats With a Fallback

The <picture> element lets the browser pick the first format it understands:

<picture>
  <source srcset="team-photo.avif" type="image/avif">
  <source srcset="team-photo.webp" type="image/webp">
  <img src="team-photo.jpg" alt="Three colleagues reviewing a design on a laptop"
       width="1200" height="800">
</picture>

Older browsers ignore the <source> lines and fall back to the JPG.

Step 2: Resize to the Size You Actually Display

A 4000-pixel-wide photo shown in an 800-pixel column still downloads all 4000 pixels; the browser just scales it down after the fact. CSS changes how big an image looks, not how big the file is.

A practical rule: make the largest version no wider than the biggest slot it appears in, multiplied by the screen density you want to support (often up to 2x for sharp results on high-density phones and laptops). Typical starting points:

• Full-width hero: around 1600–2000 px wide
• Image inside a blog column: around 1200 px wide
• Card thumbnails: around 400–600 px wide
• Avatars: 200–400 px square

Your own layout decides the real numbers. Measure the rendered width in your browser's developer tools and work from that. For one-off files, the Resize tool lets you set exact pixel dimensions with the aspect ratio locked. If you need to shrink without visible softening, see how to resize images without losing quality.

Step 3: Compress With a Sensible Quality Setting

For lossy formats (JPG, WebP, AVIF), quality is a trade-off you control.

Quality scales differ between encoders and formats, so treat these as starting points. The reliable test is visual: compare the compressed file and the original at the size it will really be displayed. Look at faces, text, gradients and fine texture, where artifacts appear first.

For lossless PNG there is no quality slider, but you can still shrink files by reducing the colour palette (8-bit PNG works well for simple graphics) and stripping metadata.

The image compressor shows a before/after preview with a quality slider, and Bulk Compress handles up to 100 images at once. Both run in your browser, so files are not uploaded. More technique is in how to compress images without losing quality.

Step 4: Strip Unneeded Metadata

Camera and phone photos carry EXIF data: camera model, capture time and often GPS coordinates. Visitors never see it, it adds bytes, and location data on a published photo can be a privacy problem. Remove it before publishing with the metadata remover, which also lets you view what a file contains first. Many compressors and build tools strip it automatically; check your settings.

Step 5: Always Set Width and Height

If the browser does not know an image's dimensions, it cannot reserve space, so text jumps down when the image arrives. That movement is layout shift and counts against CLS.

<img src="kitchen.webp" alt="Renovated kitchen with oak cabinets"
     width="1200" height="800">

Use the image's intrinsic pixel size. Modern browsers use the ratio to reserve the right box even when CSS makes the image responsive (max-width: 100%; height: auto;). For CSS background images or embeds, aspect-ratio in CSS does the same job.

Step 6: Serve Responsive Images With srcset and sizes

A phone with a narrow screen does not need the desktop hero. srcset lists the available widths, and sizes tells the browser how wide the image will be in the layout:

<img src="hero-1200.webp"
     srcset="hero-480.webp 480w,
             hero-800.webp 800w,
             hero-1200.webp 1200w,
             hero-1800.webp 1800w"
     sizes="(max-width: 700px) 100vw, 1200px"
     alt="Sunrise over the Rann of Kutch salt flats"
     width="1800" height="1000">

The browser combines sizes with the device's pixel density and downloads the smallest file that will still look sharp. Frameworks such as Next.js, Astro and WordPress generate these variants automatically; on a hand-built site you export each width once. The web.dev Learn Images course covers srcset, sizes and <picture> in detail.

Step 7: Lazy-Load Below the Fold, Prioritise the Hero

Native lazy loading tells the browser to wait until an image is near the viewport:

<img src="gallery-3.webp" alt="..." width="800" height="600" loading="lazy">

It is supported in all modern browsers and costs nothing to add. But do not lazy-load the hero or anything visible on first load. That image is often your LCP element, and lazy loading delays it.

For the main above-the-fold image, do the opposite and raise its priority:

<img src="hero-1200.webp" alt="..." width="1800" height="1000"
     fetchpriority="high">

If the hero is a CSS background, the browser discovers it late; a <link rel="preload" as="image"> in the <head> helps, but using a normal <img> element is usually simpler.

Step 8: Cache Images and Use a CDN

Images rarely change, so let browsers keep them. If your build adds a content hash to file names (for example hero-a1b2c3.webp), you can cache them for a year:

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

immutable tells the browser not to re-check the file on repeat visits. When the image changes, the hash and URL change too, so nobody gets a stale copy. For files without hashed names, use a shorter lifetime such as a week (max-age=604800) so updates still reach visitors.

A content delivery network (CDN) keeps copies of your images on servers around the world, so each visitor downloads from a nearby location instead of your origin server. Several providers have free tiers, and many also offer on-the-fly resizing and format conversion. That is the automated version of Steps 1–3 and worth considering on sites with large image libraries.

Step 9: Find the Problem Images

Do not guess. Run Lighthouse (Chrome DevTools, Lighthouse tab) or PageSpeed Insights on your key pages. The report names specific images that are oversized for their display, served in older formats, missing dimensions, or slowing LCP. Fix the heaviest pages first: your homepage, top landing pages and highest-traffic articles.

Things that usually are not worth the effort for small sites: icon sprite sheets (SVG icons replaced them), a custom image server, and blur-up placeholder effects before the basics are done.

A Repeatable Workflow for Every Image

1. Start from the best original you have and keep it untouched.
2. Crop to the aspect ratio of the slot it will fill.
3. Resize to the largest size needed (display width × density).
4. Export as WebP or AVIF for photos, PNG or SVG for graphics.
5. Compress and compare against the original at display size.
6. Strip metadata.
7. Give it a descriptive file name and useful alt text.
8. Add width, height, srcset/sizes, and loading="lazy" for anything below the fold.
9. Publish, then re-check the page in Lighthouse.

Frequently Asked Questions

What is the best image format for website speed?

For photos, WebP or AVIF usually gives the smallest file at a given visual quality, with JPG as a fallback. Use PNG only for graphics that need lossless detail or transparency, and SVG for logos and icons.

What JPG or WebP quality setting should I use?

A quality of roughly 75 to 85 is a sensible starting point for most web photos. Compare the result with the original at its real display size and only go higher if you can see artifacts.

Should I lazy-load every image?

No. Lazy-load images below the fold, but load the main above-the-fold image, usually the hero and often the LCP element, normally. Lazy-loading it delays the most important paint on the page.

How large should website images be in pixels?

Make the largest version about as wide as the biggest slot it appears in, multiplied by the screen density you want to support, often up to 2x. Then offer smaller versions through srcset for phones.

Do I need a CDN for images?

Not always, but a CDN serves images from a server close to each visitor and handles caching for you. It helps most when your audience is spread far from your origin server.