WebP for Website Speed: Faster Loading and Better SEO

Why images, specifically, slow a site down

Open any modern website and look at what makes up its weight. Scripts, fonts and styles all matter, but in most cases the page's biggest heavyweight is its images. According to the Web Almanac project (HTTP Archive), images account for a large share of the median page's weight — on a mobile homepage, images alone come to roughly 900 KB on average.

Why is that a problem? Every kilobyte has to travel over the network. On fast Wi-Fi you won't notice. But on a phone in a subway or a rural area, an extra megabyte of images easily turns into several seconds of staring at a blank screen. And the data is consistent: the longer a page takes to load, the more people close it before they ever see it.

What WebP delivers: −25–35% in weight

WebP is an image format from Google, built specifically for the web. Its whole job is to deliver the same picture in a much smaller file. Google's own studies put numbers on it:

• 25–35% lighter than JPEG at equivalent visual quality (measured by the SSIM index). This covers photos and any busy, detailed images.
• 26% lighter than PNG in lossless mode. So logos, icons and screenshots get smaller too, with no degradation.
• Roughly 3× lighter than PNG for images with transparency (an alpha channel) when light compression is acceptable.

Where does the saving come from? WebP supports lossy compression (like JPEG), lossless (like PNG), transparency and even animation — but uses more modern algorithms. In plain terms, it's "one format instead of three" that packs the data more tightly.

The practical effect is what matters. If a page carries 1.5 MB of images, switching them to WebP can cut 400–500 KB. For the visitor that means the page feels ready noticeably sooner — and you didn't touch the design or the layout to get there.

LCP and Core Web Vitals: the SEO link

Site speed isn't only about comfort. Google officially factors it into rankings through a set of metrics called Core Web Vitals. And the one that matters most for images is LCP (Largest Contentful Paint).

LCP measures how many seconds it takes for the largest visible element above the fold to render. On most sites, that element is a large image — the hero banner, an article cover, the main product photo. In other words, how fast your main image loads becomes one of Google's key metrics directly.

The logic is simple: a heavy 600 KB JPEG hero image loads slower than the same image as a 400 KB WebP. Switch to WebP → LCP drops → Core Web Vitals improve. Which means the page has a better shot at ranking and a better shot at keeping the visitor.

Adding WebP via <picture> with a fallback

WebP is supported by around 95–96% of browsers — practically every current version of Chrome, Firefox, Edge, Safari and the mobile browsers. But so the remaining few percent (very old iPhones, say) still see your images, you use the <picture> tag with a fallback.

The principle: inside <picture> you list several sources, and the browser takes the first one it can open. If WebP isn't supported, it silently falls back to a regular JPEG or PNG.

<picture>
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg" alt="Image description"
       width="1200" height="630" loading="lazy">
</picture>

What's important here:

• The <source> with type="image/webp" is the preferred option. A WebP-capable browser will take it.
• The <img> inside is the mandatory fallback. An old browser ignores the <source> and shows the JPEG.
• width and height reserve space for the image and prevent layout "jumps" (this improves another Core Web Vital, CLS).
• loading="lazy" defers images below the fold. But don't put lazy on your LCP image — that one should load as early as possible.

srcset and retina: one image for every screen

The other half of the job is serving an image at the right size. There's no point sending a 2000 px-wide image to a phone with a 400 px screen. That's what the srcset attribute is for: you prepare a few versions of the image, and the browser picks the right one for the screen size and pixel density (yes, "retina").

<picture>
  <source
    type="image/webp"
    srcset="/img/photo-480.webp 480w,
            /img/photo-800.webp 800w,
            /img/photo-1200.webp 1200w"
    sizes="(max-width: 600px) 480px, 800px">
  <img src="/img/photo-800.jpg" alt="Description"
       width="800" height="533" loading="lazy">
</picture>

The sizes attribute tells the browser how big the image will be in the layout, and srcset with its 480w / 800w / 1200w values gives it the choice. A phone grabs the lightweight 480w version; a retina desktop takes 1200w. WebP plus srcset is essentially the most you can squeeze out of your images without losing quality.

Automation: CDNs and plugins

Hand-writing <picture> for every image is fine for a small landing page, but tedious for a blog with hundreds of posts. For those cases there are automated options:

All three approaches share one idea: the server decides which format to send to each browser. You don't change anything in your templates — the optimization happens at the delivery layer.

Converting a whole site to WebP in bulk

Before you wire up any automation, you need the WebP files themselves. If you already have a folder of images (or you're doing this as a one-off), the fastest route is a batch online converter: upload a dozen JPEG/PNG files, download the WebP versions as a ZIP, no software to install.

For screenshots, logos and graphics with transparency, use the PNG → WebP converter — it keeps the sharp edges and the alpha channel. And if you later need a universal format back (for an editor that won't open WebP, for instance), the reverse WebP → JPG conversion has you covered. The full list lives on the all formats page.

Rollout checklist

Here's everything as a short plan you can work through point by point:

• Find the LCP element. Use PageSpeed Insights or DevTools to identify the main above-the-fold image and start there.
• Convert images to WebP. Photos from JPEG, graphics and transparency from PNG. Batch it through an online converter.
• Wire it up with <picture>. Always include an <img> JPEG/PNG fallback for compatibility.
• Add srcset and sizes for responsive and retina screens where it makes sense.
• Set width/height on every image to avoid layout shift (CLS).
• Use loading="lazy" for below-the-fold images — but not for the LCP image.
• Turn on automation. A CMS plugin or a CDN that serves WebP via the Accept header.
• Verify. Re-run PageSpeed Insights — LCP and total page weight should both drop.

This is that rare optimization where the effort-to-payoff ratio is almost perfect: one format, a few lines of markup, hundreds of kilobytes gone, and a win for speed, UX and SEO all at once.