Why is your site's TTFB good but the page still takes 4 seconds to load?
You've changed your hosting, caching is active, you've even set up a CDN. But PageSpeed Insights still shows that same score of 60, and the Lighthouse report says "Properly size images." The problem isn't your server; it's the images sitting on it in old PNG or JPEG formats. A 2MB JPEG photo taken with a phone, when converted to WebP, drops to 150KB. This single change can reduce page load time on mobile internet in Iran from 4 seconds to 1.5 seconds.
This article is for someone who has a website right now and wants to know exactly which command, which format, and which HTML structure to use to get this done. No theory, no history.
The real state of browser support in 2024
WebP has been supported in all modern browsers since 2020. Chrome, Firefox, Safari, Edge, and even Android mobile browsers. AVIF, however, is a different story. Safari has supported AVIF since version 16.4 (March 2023). This means a user with an iPhone 8 running iOS 15 won't see AVIF.
Check the real browser usage statistics in Iran. If the share of older Safari or older WebView-based browsers on your site is above 5%, you can't serve only AVIF. This is where people make a mistake: they see that Chrome displays AVIF, then rewrite the entire site with AVIF, and a month later an iPhone user calls saying "the images on the site aren't loading." The symptom is that the image is completely absent, not that the quality is low. The older browser simply doesn't recognize the format and renders nothing.
The solution is the <picture> tag. Not just using <img src="image.avif">.
Correct picture tag structure for serving both AVIF and WebP
<picture>
<source type="image/avif" srcset="image.avif">
<source type="image/webp" srcset="image.webp">
<img src="image.jpg" alt="image description" width="800" height="600" loading="lazy">
</picture>
The browser selects the first <source> it recognizes. If it doesn't recognize any, it falls back to the <img> tag. This means a Chrome user gets AVIF, a Firefox user gets WebP, and an older Safari user gets the original JPEG. No one sees anything broken.
One important note: be sure to include width and height in the <img> tag. Without these, the browser doesn't know the image's space before it loads, and your CLS (Cumulative Layout Shift) will increase. This number is recorded in your Core Web Vitals report.
Real size comparison: WebP vs. AVIF vs. JPEG
The numbers below are from a real test on a product photo with dimensions of 1200×800 pixels and quality 80:
| Format | File Size | Perceived Quality | Conversion Time |
|---|---|---|---|
| Original JPEG | 480 KB | Reference | — |
| WebP (quality 80) | 120 KB | Nearly identical | 0.8 seconds |
| AVIF (quality 40) | 65 KB | Slightly lower | 3.2 seconds |
AVIF produces roughly half the size of WebP, but it has a cost: conversion time. If you have an archive of 10,000 images, converting them all to AVIF with a standard server CPU might take 8 to 10 hours. WebP, on the other hand, finishes in under 2 hours with the same hardware.
Don't convert images with text or logos using either of these formats. PNG is still the best for graphics with text. The compression algorithms of both formats cause artifacts on sharp text edges, and the result looks ugly.
Exact conversion commands with cwebp and avifenc
Google's official tool for WebP is cwebp. On Ubuntu, it's installed with apt install webp. The basic command:
cwebp -q 80 input.jpg -o output.webp
The -q 80 flag specifies the quality. For product photos, 75 to 85 is a safe range. Below 70, you'll see banding (color stripes) on human skin or gradient skies.
For AVIF, the tool is avifenc from the libavif project. Install with apt install avifenc or compile from source. The command:
avifenc --min 20 --max 40 --speed 6 input.jpg -o output.avif
The --speed 6 flag balances speed and quality. Speed 10 is very fast but quality drops. Speed 2 gives excellent quality but takes 5 seconds for one image. For bulk production, I recommend speed 6 to 8.
If you're working with PHP and don't want to install command-line tools, the imagick extension works with WebP from version 6.7.0 onwards. AVIF is supported in ImageMagick from version 7.0.27, but if you have shared hosting, you probably don't have that version. Check with php -m | grep imagick.
Automating conversion in WordPress and Laravel
In WordPress, optimization plugins like ShortPixel or Imagify do this automatically. But if you don't want to install another plugin, you can convert uploaded images with a simple hook:
add_filter('wp_handle_upload', function($upload) {
if (strpos($upload['type'], 'image/') !== 0) return $upload;
$path = $upload['file'];
$webp = preg_replace('/\.(jpg|jpeg|png)$/i', '.webp', $path);
exec("cwebp -q 80 " . escapeshellarg($path) . " -o " . escapeshellarg($webp));
return $upload;
});
This code is simple and doesn't handle potential errors. In production, you should check that exec is available and log error output.
In Laravel, the spatie/laravel-medialibrary package has generated WebP internally since version 10. You just need to configure the output format in the config file.
Responsive images: format alone isn't enough
Converting the format is only half the job. If you serve a 2000-pixel image to a 360-pixel mobile screen, you're still transferring 5 times the necessary data. Combining srcset with sizes solves this:
<img srcset="image-360.webp 360w,
image-768.webp 768w,
image-1200.webp 1200w"
sizes="(max-width: 600px) 100vw, 50vw"
src="image-1200.webp" alt="description">
The browser selects the most appropriate version based on viewport width and pixel density. A mobile user with a 360-pixel screen gets the 360-pixel version, not the 1200-pixel one.
This is where people make a mistake: many add srcset but forget sizes. Without sizes, the browser assumes the image takes up the full viewport width and therefore always selects the largest version. The result: you save nothing and think the tag doesn't work.
Measuring the result: what number you should see
After applying the changes, test your site's speed again with the SEO and webmaster tools. The number you should see: the total weight of images on the homepage should be under 500 KB. If it's above 1 MB, you've still missed something.
Also, in PageSpeed Insights, the LCP (Largest Contentful Paint) metric should be under 2.5 seconds. If the main image on the page (usually the hero or the first content image) is served in the new format, this number typically drops by 0.5 to 1 second.
To check whether your browser is actually receiving the new format, open Chrome's developer console (F12), go to the Network tab, and click on the image. If the file type is image/avif or image/webp, you're doing it right.
What to do with old images? A migration strategy
If your site is 5 years old and has 20,000 images in its archive, converting everything overnight isn't possible. Prioritize:
- Convert images on the homepage and top-selling landing pages first. These get the most traffic.
- Convert images on high-traffic blog posts second.
- Convert the rest in the background with a cron job, 500 images per day.
For bulk conversion, run the following script with find and xargs:
find /var/www/html/wp-content/uploads -name "*.jpg" -mtime +30 | xargs -P 4 -I {} sh -c 'cwebp -q 80 "$1" -o "${1%.jpg}.webp"' _ {}
The -P 4 flag runs four parallel processes. If your server CPU is weak, reduce this number to 2 to avoid slowing down your website.
If instead of manual migration, you'd prefer to hand the entire process to a team that can both serve the formats correctly and manage URL structure and indexing, SEO services are designed exactly for this scenario. But if you have technical staff, the manual path described in this article is entirely feasible.
Images and SEO: what changes in Google
Google announced in 2019 that it indexes WebP in image search results. AVIF was added to this list in 2021. But the important point: Google does not consider the format as a direct ranking signal. What matters is the page load speed, which the format affects.
A technical note: if you upload a WebP image with the same filename as the old JPEG (for example, product.jpg which is actually WebP), Google might get confused. It's better to change the filename or use the picture tag so both the browser and Google's crawler see the correct format.
Also, write alternative text (alt) for new images. This text is essential both for accessibility and for image indexing in Google. A full sentence that accurately describes the image content, not three repetitive words.
Frequently Asked Questions
Does WebP reduce image quality?
At quality 80, the difference from the original JPEG is nearly imperceptible. At quality 70, if you look closely, you'll see banding on gradient areas (like skies). For product photos, quality 80 is a safe choice. For artistic photos where quality is critical, set it to 90 and the final size will still be smaller than JPEG.
Is AVIF worth the extra conversion time?
If your site is image-heavy (a product store, a news portal with lots of photos) and has high traffic, then yes. Halving image size means a noticeable reduction in bandwidth costs and improved LCP. But if you have a small site with few images, WebP is sufficient and avoids the complexity of serving two formats.
How do I know if my user's browser supports AVIF?
With the picture tag, you no longer need to know. The browser decides on its own. If it recognizes AVIF, it takes it. If not, it falls back to WebP or JPEG. The browser does this, not you.
Does converting old site images to WebP negatively affect SEO?
No, if you don't change the image URL and only change the file format, Google sees the same URL and the previous index is preserved. If you do change the URL, be sure to set up a 301 redirect from the old address to the new one so link equity isn't lost. To check indexing status and the technical health of your domain, you can use the domain and DNS technical check.
Comments 0
No comments yet — be the first!