Why images decide your page speed
On most pages, images account for the largest share of the bytes a browser downloads. That makes them the number one target for a faster site — and the main reason a page fails Core Web Vitals, because the largest image is often the LCP (Largest Contentful Paint) element Google measures. Optimizing images does not mean lower quality; it means shipping the same picture in far fewer bytes. Get this right and everything else — LCP, mobile scores, data usage — improves at once.
Right-size and go responsive
The most common waste is serving a huge image into a small space — a 4000px photo displayed at 800px still downloads all 4000px. Export images close to the size they are actually shown. Then serve different sizes to different screens with srcset and sizes, so a phone gets a small file and a desktop gets a larger one.
Responsive images with srcset
<img
src="/hero-800.jpg"
srcset="/hero-400.jpg 400w, /hero-800.jpg 800w, /hero-1600.jpg 1600w"
sizes="(max-width: 600px) 400px, 800px"
alt="Product hero"
width="800" height="500">Switch to next-gen formats: WebP and AVIF
WebP, and AVIF where supported, produce 25-50% smaller files than JPEG or PNG at the same visual quality. This is the change that clears PageSpeed Insights' 'Serve images in next-gen formats' recommendation. Serve them with a picture element so browsers that support the new format get it and older ones fall back to the original automatically.
Serve AVIF/WebP with a fallback
<picture>
<source srcset="/photo.avif" type="image/avif">
<source srcset="/photo.webp" type="image/webp">
<img src="/photo.jpg" alt="Photo" width="1200" height="800">
</picture>Lazy-load — but not your main image
Lazy-loading defers images until they are about to enter the viewport, so a long page does not download everything up front. Most platforms do this by default. The one exception is your hero or main image, which is usually the LCP element: load it eagerly (and consider fetchpriority="high") so the most important pixel paints as fast as possible. Lazy-load everything below the fold, prioritize the one thing above it.
Deliver from the edge — and convert automatically
Even a perfectly compressed image is slow if it travels from a distant server. A CDN caches your images at the edge and serves each visitor from the nearest location, so the bytes arrive fast wherever they are. cdn.com.tr does this for every asset, over modern HTTP/2 and Brotli, with automatic SSL in front.
And you do not have to convert formats by hand. For WordPress, the free CDNTR plugin creates WebP (and AVIF where your server supports it) on your own server and serves them from the CDN via a picture element, with the original as an automatic fallback. It only serves a converted file when it is genuinely smaller, so a well-compressed photo is never made bigger, and it can bulk-convert your whole media library.
Measure and confirm
Run your page through PageSpeed Insights before and after. You are looking for two things: the 'Serve images in next-gen formats' and 'Properly size images' recommendations to disappear, and your LCP to drop. If the largest image is still slow, check that it is not lazy-loaded and that it is served in a next-gen format from the CDN. A quick before/after keeps you honest about what actually helped.
Where it pays off most
Product pages are image-heavy; smaller, next-gen images load faster and lift conversions.
Article heroes and galleries dominate page weight; optimizing them fixes LCP and mobile scores.
Phones on slower networks feel every extra kilobyte; right-sized next-gen images help the most there.
Image optimization FAQ
Does WebP or AVIF reduce image quality?
No. At the same visual quality they simply produce a smaller file. AVIF usually compresses best, WebP is close and more widely supported; a picture element lets you offer both and fall back to the original for old browsers.
Do I have to convert every image myself?
No. On WordPress the free CDNTR plugin converts and serves WebP/AVIF automatically and can bulk-convert your library. On other stacks, build-time tooling or an image pipeline can do the same; the key is that visitors receive the smaller format.
Which matters more, format or size?
Both, but right-sizing usually comes first: shipping a 4000px image into an 800px slot wastes far more than the format ever saves. Right-size, then convert to a next-gen format, then deliver from the CDN.