Optimize images for the web: WebP, AVIF and sizing

To optimize images for the web, serve each image in a modern format (WebP or AVIF, with a fallback), at the pixel size it is actually displayed, with sensible compression, and load it at the right moment: early for the main image, lazily for everything below the fold. Get those four things right and images stop being the heaviest part of your pages. This guide explains each step, what WebP and AVIF really change, and how to check the result.

Why images matter for speed

On many content sites and shops, images are the largest share of the bytes a page downloads. They also decide one of the three Core Web Vitals: on many pages, the Largest Contentful Paint element is an image, usually a hero banner or a product photo. The LCP article on web.dev lists image download time as one of the four parts that make up the metric.

Images also affect layout stability. An image without reserved space pushes text down when it arrives, which counts against Cumulative Layout Shift. If you want the full picture of how these metrics interact, read Core Web Vitals explained.

The good news: image problems are usually easy to spot and fix, and the fixes don't touch your application logic.

Choose the right format

Each format has a job. Picking the wrong one is a common cause of oversized files.

A few rules of thumb:

• Never use PNG for photos. A photo saved as PNG is often much larger than the same photo as JPEG, with no visible benefit.
• Use SVG for logos and icons instead of PNG sprites. Make sure SVGs come from a trusted source, since they can contain scripts.
• Replace animated GIFs with video. A short MP4 or WebM loop is far smaller than the same animation as GIF.

What WebP and AVIF actually change

WebP and AVIF are newer compression formats. For the same visual quality, they generally produce smaller files than JPEG and PNG, and AVIF often goes further than WebP, especially on photos with smooth gradients. How much you save depends on the image and the quality setting, so there is no reliable universal number.

What they don't change: the pixel dimensions. A 4000 pixel wide AVIF shown in a 600 pixel column is still wasteful. Format and sizing are separate problems, and you need to solve both.

Older browsers that don't understand a format need a fallback. You can handle that in markup with <picture>, or on the server by looking at the browser's Accept header and choosing the format per request.

<picture>
  <source srcset="/images/team.avif" type="image/avif">
  <source srcset="/images/team.webp" type="image/webp">
  <img src="/images/team.jpg" alt="Our team at the office" width="1200" height="800">
</picture>

Serve the right size

Uploading a photo straight from a camera or phone and letting CSS shrink it is the classic mistake. The browser still downloads every pixel.

Resize to the display size

Find out how wide the image is actually shown. On a desktop layout with a 1200 pixel content column, a full-width image rarely needs to be wider than about twice that, to stay sharp on high-density screens. Thumbnails in a product grid need far less.

Use srcset and sizes

Responsive images let the browser pick the right file for each screen:

<img
  src="/images/product-800.jpg"
  srcset="/images/product-400.jpg 400w,
          /images/product-800.jpg 800w,
          /images/product-1600.jpg 1600w"
  sizes="(min-width: 1024px) 50vw, 100vw"
  alt="Blue running shoe, side view"
  width="800" height="800">

srcset lists the available widths, and sizes tells the browser how wide the image will be in the layout. The browser combines that with the screen's pixel density and downloads only one file. Most CMSs, including WordPress, generate several sizes on upload and output srcset automatically, as long as the theme uses the standard image functions.

Compress sensibly

For lossy formats, a quality setting in the middle to upper range is usually indistinguishable from the original at normal viewing size. Compare a few settings side by side on a real screen rather than trusting a single default. Also strip metadata such as camera EXIF data, which adds bytes and can reveal location data you did not mean to publish.

Load images at the right time

Not every image is equally urgent. The browser should fetch the one above the fold immediately and leave the rest until the visitor scrolls.

Lazy-load below-the-fold images

Native lazy loading needs no JavaScript:

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

Never lazy-load the LCP image

This is the mistake that undoes everything else. If the hero image has loading="lazy", the browser deliberately waits before fetching it, and LCP gets worse. Some plugins and themes lazy-load every image by default, so check the hero specifically.

Prevent layout shift

Always give images width and height attributes (or a CSS aspect-ratio). Modern browsers use them to reserve the right amount of space before the file arrives, even when CSS makes the image responsive with width: 100%; height: auto. The CLS article on web.dev explains why unsized images are one of the most frequent causes of layout shift.

The same applies to images injected later, like carousels or ad slots: reserve their space in CSS so the rest of the page does not jump.

Cache images properly

Images rarely change, so browsers and CDNs should keep them for a long time. Send long-lived Cache-Control headers and change the file name (or add a version query) when you replace an image. You can check what your server sends:

curl -I https://www.example.com/images/hero.webp

Look for cache-control with a long max-age. If you serve different formats from the same URL depending on the browser, the response must also vary on the Accept header, or a cache might give a WebP file to a browser that cannot display it.

How fast.site helps

fast.site sits in front of your existing hosting, so your images stay where they are and your CMS keeps working as before. You point your domain's nameservers to fast.site, and from then on requests run through its edge network.

Image optimization converts JPEG and PNG to WebP on the fly for browsers that support it, and AVIF transcoding is available depending on your plan. Browsers that don't support a format receive the original, so you don't have to maintain <picture> fallbacks for every image. Like other static files, images are cached by the Fast Edge Cache™, so a cache HIT is served from the edge nearest to the visitor without contacting your server.

The optional HTML optimization setting preloads the detected hero image and adds width and height to images to reduce layout shift.

What fast.site does not do: resize oversized uploads or decide which images to lazy-load. Those stay in your theme and content workflow.

Measure the effect on your own site before and after: compare transferred image bytes in the browser's network panel and check LCP on corewebvitals.page. You can try it with a free 7-day trial, no credit card required. See plans for what each plan includes.

FAQ

Is WebP or AVIF better?

AVIF often produces smaller files than WebP at similar quality, particularly for photos, but it takes longer to encode. WebP is a safe default with broad support. Many sites serve AVIF where possible and WebP or the original as fallback.

What size should images be for a website?

Match the largest size at which the image is displayed, and provide about twice that width for high-density screens. Use srcset so smaller screens download smaller files. Uploading full camera resolution is almost never necessary.

Does lazy loading hurt SEO?

Native lazy loading with loading="lazy" is supported by Google and does not hide images from search. The real risk is performance: lazy-loading the main image above the fold delays LCP. Use it only for images further down the page.

How do I check whether my images are optimized?

Run the page through corewebvitals.page and check LCP for mobile and desktop. To see which element is the LCP element, open the Performance panel in Chrome DevTools. In the browser's network panel, filter by images and compare file sizes and formats. Our guide on measuring website speed shows how to run a reliable before-and-after test.

Do I still need an image optimization plugin in WordPress?

It depends on your setup. A plugin that resizes and compresses uploads still helps, because format conversion alone does not fix oversized dimensions. If your CDN already handles WebP or AVIF conversion, you can usually disable that part of the plugin to avoid doing the work twice. See why WordPress sites get slow for the bigger picture.