How to Use WebP Images to Improve Website Speed

WebP can reduce the bytes your site transfers for images, which can shorten image download time. To use it well, convert the images that matter, inspect the result at an acceptable visual quality, serve dimensions suited to each display, provide a fallback when needed, and measure the actual page. Smaller files do not guarantee a particular page-load or Core Web Vitals improvement.

WebP supports lossy and lossless compression, transparency, and animation. Google reports lossy WebP files 25–34% smaller than comparable JPEGs at equivalent SSIM quality, and lossless WebP files 26% smaller than PNGs. Those are reported comparisons, not guaranteed savings for every image. [Google’s WebP overview; RFC 9649]

1. Find images worth converting

Start with image assets that are large or requested often. Use your site analytics or a performance audit to identify likely candidates; there is no universal priority list. Compare each converted image with its actual JPEG or PNG source at the dimensions and quality your site needs.

Keep the original source files so you can regenerate variants later.
Include photographs, graphics with sharp edges, images with transparency, and any animated assets that matter to your site.
Record the original and output byte sizes. A format change is useful only if the output is smaller enough to justify its visual and operational trade-offs.

2. Convert images with cwebp

Google’s cwebp command-line tool converts common image formats to WebP. Install it using the instructions for your operating system in the official WebP documentation. The following commands assume cwebp is available on your PATH.

Lossy conversion for photographs

cwebp -q 80 photo.jpg -o photo.webp

-q sets the quality level from 0 to 100. Higher values generally retain more visual detail and can produce larger files. Treat 80 as a starting point, not a universal setting: inspect the output and adjust for the image and its display size.

Lossless conversion

cwebp -lossless graphic.png -o graphic.webp

Lossless mode preserves the image pixels while changing the encoding. It is useful when pixel fidelity matters, but it may not produce a smaller file for every source. Check the result rather than assuming it will beat PNG.

Convert a directory in a shell

This Bash example converts JPEG files in one directory to lossy WebP. It leaves source files untouched and uses the same quality setting for each file.

mkdir -p webp
for file in images/*.jpg; do
  [ -e "$file" ] || continue
  name=$(basename "$file" .jpg)
  cwebp -q 80 "$file" -o "webp/$name.webp"
done

For PNGs, choose lossless mode when preserving exact pixels is required, or test lossy encoding when a controlled quality trade-off is acceptable. Make conversion part of your publishing or build pipeline if repeated manual work would be error-prone. Preserve source assets so a future quality or dimension change does not require recovering originals from compressed output.

3. Choose an image mode and inspect the output

Need	Starting approach	Check
Photographs or other images where a visual trade-off is acceptable	Lossy WebP with a quality setting such as `-q 80`	Inspect fine detail, gradients, edges, and artifacts at the rendered size.
Exact pixel preservation	Lossless WebP with `-lossless`	Compare output bytes with the original PNG; lossless does not guarantee a smaller file.
Transparency	WebP can encode transparency	Inspect edges against the backgrounds where the image will appear.
Animation	WebP supports animation	Check the animation in the browsers and delivery pipeline you support.

WebP is defined as a RIFF-based image format with lossy and lossless compression, alpha, and animation support in RFC 9649. If the image looks wrong or the file is larger, keep the original format or try another encoding and quality setting.

4. Serve WebP with a fallback

For HTML pages, <picture> lets the browser use WebP when it supports that source and fall through to the regular <img> otherwise. Keep meaningful alternative text on the fallback image.

<picture>
  <source srcset="/images/hero.webp" type="image/webp">
  <img src="/images/hero.jpg" alt="A cyclist riding along a coastal road">
</picture>

Google’s WebP overview lists native support in Chrome, Safari, Firefox, Edge, and Opera. Support details can change, and unusual or older clients may still need a fallback. See the WebP FAQ for its browser history and delivery guidance. Avoid relying on old minimum-version lists as a current compatibility guarantee.

Server or CDN content negotiation is another option: deliver WebP to requests whose Accept header indicates support, and a compatible format otherwise. Follow the chosen server or CDN’s current configuration guidance, and make sure caches vary their response appropriately by the accepted format. The WebP FAQ describes Accept-header negotiation; web.dev’s image performance guide also covers modern format sources with legacy fallbacks.

5. Send responsive dimensions too

Changing the encoding does not fix oversized pixel dimensions. Use srcset and sizes so the browser can choose an image variant suited to the display and layout. For example, provide 640- and 1280-pixel versions in each format:

<picture>
  <source
    type="image/webp"
    srcset="/images/hero-640.webp 640w, /images/hero-1280.webp 1280w"
    sizes="(max-width: 700px) 100vw, 700px">
  <img
    src="/images/hero-1280.jpg"
    srcset="/images/hero-640.jpg 640w, /images/hero-1280.jpg 1280w"
    sizes="(max-width: 700px) 100vw, 700px"
    alt="A cyclist riding along a coastal road"
    width="1280"
    height="720">
</picture>

Generate variants from a suitable source image and ensure each URL actually serves the declared width. Choose breakpoints and dimensions to match your layout and audience. Responsive markup adds variants to store and maintain, so start with the sizes your pages need. See Google Chrome Developers’ responsive image guidance.

6. Measure bytes and page behavior

Compare the WebP output size with its original at acceptable visual quality.
Verify the browser receives the intended format and dimensions, including the fallback path.
Measure the actual page on representative mobile and desktop conditions before and after the change.
Interpret page metrics alongside other contributors such as layout, scripts, network conditions, and caching.

Smaller image files mean fewer image bytes to transfer, which can reduce download time. The cited sources do not establish a guaranteed page-load or Core Web Vitals gain for a particular site. Measure your pages instead of treating a format-level comparison as a site-performance promise.

7. Common problems and fixes

Symptom	Likely cause	Fix
WebP output is larger than the source	The source content or chosen mode does not compress well at the selected settings.	Compare byte sizes and try a different quality or mode. Keep the source format if it is smaller at acceptable quality.
Visible artifacts or softened details	Lossy quality is too low for the image or display size.	Raise the quality setting, use lossless where appropriate, or retain the original format. Inspect fine edges and gradients.
Transparent edges look wrong	The output or page background makes edge artifacts visible.	Inspect the transparent image against its actual backgrounds; try lossless or a higher quality setting.
The browser shows a broken image	A URL, file, MIME type, or negotiation rule may be wrong; the client may also lack the delivered format.	Check the requested URL and response content type, verify the WebP file exists, and test the fallback or Accept-header path.
Fallback never appears	The `<picture>` source or server negotiation is misconfigured, or the browser accepts WebP.	Test with a client that does not accept WebP and inspect the selected request. Confirm the fallback `<img>` URL works.
Mobile still downloads a very large image	Only the format changed; the page still points to an unnecessarily large dimension.	Generate responsive variants and provide accurate `srcset` widths and `sizes`.
Some users receive the wrong cached format	A shared cache may not distinguish negotiated responses.	Configure cache variation according to the server/CDN’s content-negotiation guidance, or use explicit format URLs with `<picture>`.

8. Performance, reliability, and cost considerations

WebP is a delivery-format choice, not a substitute for right-sizing images. Responsive variants can reduce unnecessary pixel transfer but increase storage and pipeline work. Automated conversion reduces repeated manual steps, while preserving originals makes quality changes and regeneration safer. Verify both supported and fallback delivery paths after changing a build or CDN configuration.

Google’s reported compression results are useful context, not a budget forecast. Actual savings depend on source image, encoding mode, quality, and dimensions. Estimate storage and transfer effects from your own outputs and traffic, and measure page behavior under conditions representative of your visitors.

Or skip the browser setup

If your task is capturing a website rather than changing its image pipeline, ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a screenshot or PDF. Here is the direct request in the requested client styles; the API options are documented at ScreenshotNeo’s API docs.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners are accepted and removed before the shot; 60+ known consent platforms, newsletter popups, and chat widgets can be removed, and each step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing. Responses identify the page verdict and billing status in headers.
An MCP server gives AI agents tools to take screenshots, inspect page information, and capture PDFs.
The free plan includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000 shots.

FAQ

Does WebP make a website faster?

It can reduce transferred image bytes and image download time. Whether that changes page speed or Core Web Vitals depends on the site and should be measured.

Can WebP replace both JPEG and PNG?

It supports lossy and lossless encoding, transparency, and animation, so it covers many common image roles. Compare actual output quality and size before replacing a source format.

Should I delete the original images after conversion?

No. Keep originals as the source for future conversions, quality adjustments, and responsive variants.

Do I need both WebP and a fallback?

Use a fallback when your audience or delivery pipeline may include clients that cannot use WebP. The <picture> pattern is a straightforward browser-side option.