Short answer: images are the heaviest thing on almost every WordPress page, and fixing them is the single cheapest performance win there is. Serve WebP or AVIF, at the size the layout actually displays, lazy-loaded below the fold and eager above it, with width and height set so nothing jumps. In 2026 you do not need a dedicated plugin for this; the optimisation plugin you already run should do it, and if it does not, that is the plugin to replace.
An earlier version of this article recommended a standalone conversion plugin. We used it for years and it did its job. This year we moved our standard WordPress builds from WP Rocket to FlyingPress, which handles image conversion, sizing and lazy loading alongside caching, and we retired the separate plugin. Fewer moving parts, and the scores went up a little rather than down. The advice below is what we apply on every site, whichever tool does the work.
Format: WebP by default, AVIF where it is safe
A JPEG photo converted to WebP is typically 25 to 35 percent smaller at the same visual quality; AVIF saves a further 20 to 30 percent on top of that. Every current browser supports WebP. AVIF is supported by all major browsers as of this year, but encoding is slower and some image pipelines still produce visible artefacts on flat graphics, so we use AVIF for photography and WebP for logos, illustrations and anything with hard edges. Keep the original upload as the source of truth and let the server serve the modern format; never replace the original.
Size: the file should match the slot
A 4,000 pixel wide photo in a 400 pixel wide card is the most common mistake we see, and no format will save it. WordPress generates several sizes on upload; the theme or builder must ask for the right one and output a srcset so the browser picks the smallest file that fits the screen. A quick test: open the page, right-click an image, open it in a new tab, and compare its pixel width with the width it is displayed at. More than twice the displayed width is waste.
Uploads themselves should be capped. We resize anything over 2,560 pixels on the way in, and photographers’ 25 MB originals never reach the media library.
Loading: lazy below the fold, eager above it
Lazy loading is on by default in WordPress and that is right for everything the visitor has to scroll to. It is wrong for the hero image, which is usually the Largest Contentful Paint element. That image should load eagerly with fetchpriority="high", and ideally be preloaded, so the browser starts fetching it before it has parsed the rest of the page. A lazy-loaded hero is the most common reason a site with good scores everywhere else fails LCP on mobile.
Dimensions: stop the page jumping
Every image needs width and height attributes, or an aspect ratio in CSS, so the browser reserves the space before the file arrives. Without them the text jumps as images load, which is what Cumulative Layout Shift measures and what visitors experience as a page that will not hold still. WordPress adds the attributes when the size is known; builders sometimes strip them.
Delivery: cache and CDN
Images should be served with a long browser cache lifetime, a year is normal, and from a CDN when the audience is spread across regions. On LiteSpeed hosting the cache plugin handles both; we covered the hosting side in what to look for in WordPress hosting.
What one plugin should do for you
| Job | What to look for |
|---|---|
| Format conversion | WebP and AVIF generated on upload or on first request, originals kept, served by rewrite rules or the picture element |
| Responsive sizes | Correct srcset on every image the theme outputs, including builder and gallery images |
| Lazy loading | On by default, with an easy exclusion for the hero and above-the-fold images |
| LCP handling | Preload of the largest above-the-fold image, fetchpriority high |
| Dimensions | Missing width and height added automatically |
| Bulk processing | Existing library converted in the background without timing out |
| CDN | Optional, with cache headers set correctly |
If your current setup needs three plugins to cover that table, it is time to consolidate. On our standard builds FlyingPress covers all of it; on headless builds the front end handles images itself and WordPress only stores the originals.
A ten-minute audit
- Run PageSpeed Insights on the home page and a product or blog page, on mobile.
- Open the “Serve images in next-gen formats” and “Properly size images” audits. Both should be empty.
- Check which element is reported as LCP. If it is an image, confirm it is not lazy-loaded.
- Check CLS. Anything above 0.1 usually means images without dimensions.
- Open the network tab, filter by images, sort by size. Anything over 300 KB on a normal page needs a reason.
Image work is part of every website and shop we deliver, and it is usually the first thing we fix when we take over a slow site.
Frequently asked questions
Should I upload WebP directly?
You can, but uploading a high-quality JPEG or PNG and letting the server generate WebP and AVIF keeps a lossless source for future formats. Upload the best original you have.
Does image optimisation affect SEO?
Indirectly and measurably. Core Web Vitals are a ranking signal, and images decide LCP and CLS on most pages. Alt text and descriptive file names matter for image search on top of that.
What about SVG?
Use it for logos and icons; it scales without weight. WordPress blocks SVG uploads by default because an SVG can contain scripts, so only allow it for trusted editors or sanitise on upload.
