To optimize images for the web, do three things: serve them in a modern format (usually WebP or AVIF), compress them to the smallest size that still looks right, and load them at the correct dimensions with lazy loading below the fold. That sequence cuts page weight, speeds up loading, and improves the scores that Google uses in ranking. Below is the working playbook — formats, compression, sizing, and the tools to do it — with the trade-offs spelled out.
Key takeaways
- Format first. WebP lossy images are 25–34% smaller than comparable JPEGs, and WebP lossless is about 26% smaller than PNG, according to Google’s WebP documentation (as of 2026).
- Compress to “good enough,” not “perfect.” Past a certain point, extra quality adds bytes no one can see.
- Size images to their display box. Serving a 4000px photo into a 800px slot wastes most of the download.
- Lazy-load offscreen images so the browser fetches them only when needed.
- Images are the usual cause of a slow Largest Contentful Paint — Google’s “good” threshold is 2.5 seconds or less (web.dev, as of 2026).
Why does image optimization matter?
Because images are typically the heaviest thing on a page, and page weight directly drives load time. The hero image is very often the element that defines your Largest Contentful Paint (LCP) — the Core Web Vital that measures when the main content becomes visible. Google’s guidance is that a good LCP is 2.5 seconds or less at the 75th percentile of loads (web.dev, as of 2026). An unoptimized image can blow past that on its own, which hurts both the visitor’s experience and, since is a mobile ranking signal Google confirmed in 2018, your search visibility. Optimizing images is the highest-leverage speed fix on most sites because the wins are large and the work is mechanical.
Which image format should you use?
Default to WebP for photos and graphics; it is broadly supported and meaningfully smaller than the older formats. Per Google’s WebP documentation (as of 2026), lossy WebP runs 25–34% smaller than an equivalent JPEG and lossless WebP is roughly 26% smaller than PNG — real bandwidth saved at the same visual quality. Reach for AVIF when you want the smallest files and can accept slightly less universal support; it often beats WebP on compression. Keep SVG for logos, icons, and line art — it is vector-based, so it scales to any size without getting heavier or blurry. The legacy formats still have narrow uses: JPEG as a fallback for photos, PNG when you need lossless raster with transparency, GIF only for the simplest animations (a short video file is smaller for anything longer).
Lossy vs lossless compression: which do you need?
Use lossy compression for photographs and rich imagery, and lossless for graphics where every pixel matters, such as screenshots with text or crisp-edged logos. Lossy compression permanently discards data the eye is unlikely to miss, which is why it produces dramatically smaller files; the art is stopping before the discarding becomes visible as blockiness or muddy detail. Lossless compression preserves every pixel exactly and shrinks files by storing them more efficiently, so the savings are smaller but the image is untouched. For most website photos, well-tuned lossy WebP is the right answer — the file is a fraction of the size and the difference is imperceptible at normal viewing.
How do you compress without visibly hurting quality?
Aim for the smallest file that still looks right at its display size, and judge quality at that size — not zoomed to 300%. In practice that means exporting photos at a mid-to-high quality setting (many tools land in a sweet spot where further quality gains stop being noticeable but keep adding bytes) and eyeballing the result on the actual page. Strip metadata such as camera EXIF and embedded color profiles you do not need, since those add weight for no visual benefit. If you batch-process, spot-check a few images with fine detail or gradients, because those reveal compression artifacts first. The goal is a deliberate quality-versus-size decision, not a blind “maximum quality” export.
Right-sizing and responsive images: serve the correct pixels
Compression shrinks the file; sizing shrinks how many pixels you send in the first place, and it is the step people skip. Never ship an image larger than the space it displays in — a photo shown at 800 pixels wide should not be a 4000-pixel original. For layouts that render at different widths on phones and desktops, use responsive images (the srcset and sizes attributes) so the browser downloads a version matched to the device instead of one giant file for everyone. Getting dimensions right often saves more bytes than compression does, because you are eliminating data rather than squeezing it.
Lazy loading: fetch images only when they are needed
Lazy loading defers loading images that are below the fold until the visitor scrolls toward them, so the initial page paints faster and bandwidth is not spent on images no one may see. Modern browsers support it natively with a single attribute — loading="lazy" — on offscreen images. The one rule: do not lazy-load your LCP image (usually the hero), because deferring it delays the very element Core Web Vitals is timing. Lazy-load everything below the fold; eager-load the hero.
Which tools help you optimize images?
Pick by where the work happens. For manual, one-off exports, image editors and dedicated compressors let you convert to WebP or AVIF and tune quality with a live preview. For bulk work, command-line tools such as cwebp (Google’s official WebP encoder) and ImageMagick convert and resize whole folders in one pass. For a live site, the durable answer is automation: most content management systems and image CDNs can generate WebP/AVIF versions, resize to the requested dimensions, and serve them automatically, so optimization happens on every upload without a human in the loop. Manual tools are fine to start; automation is what keeps a growing site fast.
How does image optimization affect SEO?
Two ways. First, speed: optimized images improve LCP and overall load time, and page speed is a confirmed Google ranking signal on mobile (Google Search Central, 2018). Second, comprehension: descriptive alt text and sensible file names give search engines — and screen readers — a way to understand what an image shows, which supports image search and at once. Write alt text that states what the image depicts in plain language; skip keyword stuffing, which helps no one. Optimized, well-labeled images are a rare case where the same work serves users, accessibility, and rankings simultaneously.
Frequently asked questions
What is the best image format for websites in 2026?
WebP is the safe default for photos and graphics — well supported and clearly smaller than JPEG or PNG per Google’s own figures. Use AVIF when you want maximum compression and can accept slightly narrower support, and SVG for logos and icons. Keep JPEG or PNG only as fallbacks.
How small should my images be?
Small enough that they are not the bottleneck for your Largest Contentful Paint. There is no universal kilobyte target, but if a hero image is pushing your LCP past Google’s 2.5-second “good” threshold, it is too big. Right-size to the display dimensions first, then compress.
Does lazy loading hurt SEO?
No, when done correctly. Lazy-loading offscreen images speeds up the initial load, which helps. The mistake is lazy-loading the main above-the-fold (LCP) image, which delays it — eager-load that one and lazy-load the rest.
Is WebP better than JPEG?
For most website use, yes. Google’s documentation puts lossy WebP at 25–34% smaller than an equivalent-quality JPEG (as of 2026), so you get the same look for fewer bytes. Keep a JPEG fallback only for the rare browser that needs it.
Do I need to optimize images if I use a page builder or CMS?
Check what it does automatically. Many platforms and image CDNs now convert to modern formats and resize on the fly — if yours does, lean on it. If it does not, you still need to right-size and compress before upload, because the platform will serve exactly what you give it.