Why modern image formats speed up a website
If your website is slow, images are the usual suspect, not the code. On most pages, photos and graphics outweigh the HTML, CSS, and JavaScript combined — and they're still served as JPG and PNG, formats over 25 years old, when better alternatives exist that compress noticeably harder at the same visual quality: WebP, and more recently, AVIF.
What WebP and AVIF actually are
WebP was created by Google in 2010 specifically to replace JPG and PNG on the web. It compresses lossy (like JPG) or lossless (like PNG) depending on what you need, and today every modern browser supports it without exception.
AVIF is newer (2019) and borrows its compression from the AV1 video codec. On complex photographs it can beat WebP by another 10-20%, but it takes noticeably longer to encode, and its support — while already wide — still has a few gaps on older Safari versions and in apps that render images with their own engines (some RSS readers, certain in-app WebViews).
For most sites, WebP is the better starting point: nearly all of AVIF's benefit, without its compatibility headaches or encoding cost.
Why image weight matters for speed
When a browser loads a page, it has to download every byte before it can show it. If images make up 60-80% of a page's total weight (very common), they also account for 60-80% of the download time. That directly affects LCP (Largest Contentful Paint), the Core Web Vitals metric that measures how long it takes for the largest visible element on screen — almost always an image — to appear, and which Google uses as a ranking signal, on top of being the single factor that correlates most with a visitor leaving before the page finishes loading.
Cutting image weight is, by a wide margin, the performance optimization with the best effort-to-result ratio there is: it doesn't touch code, doesn't change the design, and the savings scale directly with the weight you remove. You can start right now: convert your JPG and PNG files to WebP in the browser, with nothing uploaded to a server.
The test: the same batch of images, before and after
Rather than leave this at theory, we converted a batch of 5 images at the sizes a real website actually uses — a homepage hero, a blog photo, two product shots, and a thumbnail — using the same ImageMagick and PowerShell process from the previous article, at quality 82.
| Image | Typical use | JPG (before) | WebP (after) | Reduction |
|---|---|---|---|---|
| Hero | Homepage, 1600×900 | 145.2 KB | 68.1 KB | -53% |
| Blog photo | Post, 1200×800 | 138.3 KB | 70.4 KB | -49% |
| Product 1 | Listing, 800×600 | 74.6 KB | 41.4 KB | -45% |
| Product 2 | Listing, 800×600 | 71.7 KB | 38.7 KB | -46% |
| Thumbnail | Grid item, 400×300 | 22.3 KB | 14.0 KB | -37% |
| Total | — | 452.0 KB | 232.6 KB | -48.5% |
What that means in real download time
Applying that weight difference to realistic connection speeds (this is transfer time for these images only — it doesn't include HTML, CSS, JS, or connection latency, which vary by site):
| Connection | Before (452 KB) | After (233 KB) | Savings |
|---|---|---|---|
| Congested/slow mobile (15 Mbps) | 0.25 s | 0.13 s | 0.12 s less |
| Average 5G/LTE+ (150 Mbps) | 25 ms | 13 ms | 12 ms less |
| Home broadband (500 Mbps) | 7 ms | 4 ms | 3 ms less |
On today's fast connections, the raw download-time gap has shrunk to milliseconds under normal conditions. Where the saving is still very noticeable is the still-common case of degraded mobile coverage (rural areas, indoors, a congested cell tower at peak hours) — and, more importantly, in what this table doesn't measure: a real page doesn't have 5 images, it has 20-50, and that's where the same 48.5% saving genuinely shows up, on top of the direct effect on LCP, mobile data usage, and battery spent decoding fewer bytes.
How to apply this to your own site
- Large batches (your whole media library): convert them on your own computer with ImageMagick and PowerShell before uploading, without spending your host's CPU — full walkthrough in the previous article.
- One-off or occasional images: nothing to install, this site's converter does it directly in the browser.
- Any CMS works the same: WordPress, PrestaShop, or a static site — the WebP file uploads just like any image, only the extension changes.
Convert them right in the browser, nothing gets uploaded to any server.
Convert WebP to JPG now
FAQ
WebP or AVIF, which should I use?
For most sites, WebP: it compresses nearly as well as AVIF, every modern browser has supported it for years, and it encodes far faster. AVIF can shave another 10-20% off complex photographs, but it takes longer to encode and some older Safari versions and embedded renderers still have gaps in support.
Do I need a fallback to JPG or PNG?
For a general audience, barely. WebP support is above 97% of browsers in active use. If your site gets traffic from very old systems or specific embedded apps, use a picture tag with JPG as a fallback; for the vast majority of sites it isn't necessary.
Does image weight affect SEO?
Yes, indirectly but really: image weight is usually the biggest driver of a slow LCP, one of the Core Web Vitals Google uses as a ranking signal, and it also correlates directly with bounce rate.
How much smaller can WebP make my images?
In the test in this article, a batch of 5 typical website images went from 452 KB to 233 KB, a 48.5% reduction, at quality 82 with no visible loss. That's a normal range: 25% to 50% depending on the image content.
How do I convert my website's images to WebP?
For large batches, on your own computer with ImageMagick and PowerShell, without spending your host's CPU. For one-off conversions, this site's WebP to JPG converter does the reverse process right in the browser, nothing to install.