Images are typically the largest assets on any page and the easiest performance wins to capture. On most WordPress sites, images account for 60–80% of total page weight. Most sites are serving images that are 3–10x larger than they need to be, wrong format, no compression, and displayed at a fraction of their upload dimensions. Here's how to fix each lever without sacrificing visible quality.
Image file size is controlled by three things: the format (JPEG, PNG, WebP, AVIF), the compression applied to that format, and the pixel dimensions of the image. Each lever is independent. You can have a WebP image that's still enormous because it's 4,000px wide. You can have a correctly-sized image that's bloated because it was exported at 100% quality. All three need to be addressed.
Uploading a 4,000px wide JPEG to a layout slot that displays at 800px wide means you're transferring 25x more pixel data than the browser can actually use. The browser downloads all of it, then scales it down during rendering. That wasted transfer time shows up directly in your Largest Contentful Paint measurement.
WebP should be your default for nearly everything. All modern browsers support it, and it produces files 25–35% smaller than JPEG at equivalent perceptual quality. WordPress 5.8+ supports WebP natively for uploads. If you're still uploading JPEGs, either convert your workflow or configure an optimization plugin to generate WebP versions automatically and serve them via the <picture> element with a JPEG fallback.
AVIF is a newer format offering 50% smaller files than JPEG, but browser support is still not universal (notably, Safari's support arrived with iOS 16). ShortPixel supports AVIF output if you want to serve it to supported browsers with WebP as the fallback.
JPEG remains appropriate for photographs where you need broad compatibility. Quality settings of 75–85 are visually indistinguishable from 100 for web display. Most tools export at 85 by default; dropping to 75 produces a measurable file size reduction with no visible quality loss for most photography.
PNG for images requiring transparency or flat-colour areas, logos, icons, illustrations. Use PNG-8 (256 colours) rather than PNG-24 where the colour palette allows. For logos and icons, SVG is almost always better: infinitely scalable, typically single-digit kilobytes, and styleable with CSS.
The most efficient approach is compressing images before they reach WordPress. When you upload a large unoptimized source file, WordPress creates multiple size variants (thumbnail, medium, large, full) from that source. If the source is 3MB, all variants are derived from that 3MB file and will be larger than necessary. Start with a clean source and all variants benefit.
Useful tools for pre-upload compression:
For images already in your media library, an optimization plugin handles bulk recompression and automatic optimization of new uploads. The three most commonly used are ShortPixel, Imagify, and Smush.
ShortPixel is worth noting for its AVIF support and consistently strong compression ratios. The free plan includes 100 image credits per month; the paid plans are inexpensive and credit-based (you buy a block of credits that don't expire). It processes all registered image sizes including thumbnail and medium variants, not just the full-size upload.
Imagify integrates tightly with WP Rocket if you're using that caching plugin, and offers three compression levels (Normal, Aggressive, Ultra) so you can tune the quality/size tradeoff. The free plan covers 25MB of image data per month.
Smush has a generous free tier (unlimited images, but limited to lossless compression only). The Pro version adds lossy compression and WebP conversion. For sites with large existing libraries, the free bulk optimization feature alone makes it worth installing.
WordPress has added loading="lazy" to images automatically since version 5.5. This tells the browser not to download images below the viewport until the user scrolls toward them, reducing initial page weight and bandwidth for users who don't scroll the full page.
Verify that your hero and above-the-fold images are not lazy-loaded, they should load immediately. WordPress 5.9+ intelligently sets the first image in the content to loading="eager", but custom themes and page builders may override this. Check your LCP image in Chrome DevTools (Network tab, filter by Img) to confirm it isn't being deferred.
WordPress automatically generates srcset attributes for images processed through the media library, listing multiple size variants. The browser selects the most appropriate size for the current viewport and device pixel ratio, so a mobile visitor on a 375px-wide screen downloads the small variant rather than the full-size image.
This only works when you insert images through the WordPress media library and your theme uses wp_get_attachment_image() or outputs images via standard WordPress template functions. Hardcoded <img src=""> tags bypass this system entirely. If you're building a custom theme, always use wp_get_attachment_image() for content images so WordPress can manage the srcset output automatically.
Your Largest Contentful Paint image, usually a hero banner or featured post image, deserves specific attention beyond general optimization. In addition to format and compression, preload it so the browser discovers it as early as possible:
<link rel="preload" as="image" href="/wp-content/uploads/hero.webp"
imagesrcset="/wp-content/uploads/hero-800.webp 800w,
/wp-content/uploads/hero-1600.webp 1600w"
imagesizes="100vw">Add this to your theme's <head> section. The preload hint tells the browser to fetch the image in parallel with HTML parsing, before it discovers it in the body. For pages where LCP is the primary performance concern, this single tag can shave 200–400ms off LCP.
Optimised images on a slow server still produce slow pages. LiteSpeed serves optimised images at full speed. Both matter, get the hosting right first.
View Hosting Plans