WordPress CDN: What It Does and When You Need One
Sometimes a WordPress site is slow, but not for everyone. It loads fine for you. Then a customer in another country says the images take forever. A speed test from your city looks…
Read
WordPress performance can suffer when images are too large, use the wrong format, or load at the wrong time. WordPress image optimisation helps by reducing image data, serving the right size and format, and loading each image when visitors need it.
Done properly, it creates faster pages without blurry photos, missing product details, or content that jumps as images appear. This guide will show you how to keep WordPress’s responsive image features, delay images below the visible area, and let the main image load early.
If an image is slowing down an important page or failing to appear, you’ll also learn how to fix the problem without changing settings across your entire site.
TL;DR: Resize oversized images and compress them for their purpose. Use WebP or AVIF with a fallback when your setup supports it. For bulk processing, compare WordPress image optimisation plugins or use AirLift to manage image compression, caching, and CDN delivery under a single setup.
Fix The Image That Matters First
Start with the page that brings traffic, leads, or sales. Find its largest visible image and check the file the browser actually downloads. This is usually more useful than processing an entire Media Library without knowing what is slowing the page.
Images often affect Largest Contentful Paint (LCP), the time it takes for the main visible image or block to appear. On a blog, this may be the featured image. On a shop, it may be the main product image.
To improve LCP on WordPress, start with that image rather than changing every setting on the site. Use this short workflow:
- Choose one high-value page before changing site-wide settings: Prioritise a page that matters to visitors, not an old page with little traffic.
- Find the image the visitor waits for: Check its displayed width, file size, format, and loading priority on mobile and desktop.
- Change one image decision at a time: Resize or change the format first, then retest the same URL so you can see what helped.
📝 Note: A fast desktop test can hide a problem on a phone. Check both when the page matters to mobile visitors.
The next decision is usually size. Compression cannot make an image efficient if the file contains far more pixels than the page can display.
Resize Before You Compress
Resizing and compression do different jobs. Resizing changes an image’s pixel dimensions. Compression reduces the data needed to store those pixels. When an original is much larger than its display area, resize it first, then compress it.
For a content area 800 pixels wide, an image around 1200 to 1600 pixels wide is often enough for a sharp display on high-density screens, which pack more pixels into the same space. Full-width banners, product galleries, and images that need zooming may need more. Small thumbnails need less.
WordPress helps with oversized uploads, but it does not finish the whole job. In a fresh WordPress test with no image optimisation plugin active, uploading a 3200 x 1800 JPEG produced a 2560 x 1440 scaled image and smaller versions at 2048, 1536, 1024, 768, 300, and 150 pixels wide. A 1600 x 1000 PNG produced 1536, 1024, 768, 300, and 150 pixel versions. A 900 x 900 transparent PNG produced 768, 300, and 150 pixel versions.
Those generated files help WordPress serve a closer match to the display size, but they do not replace compression or modern-format conversion. The original upload can still use storage and processing time, and a theme or page builder can request a file that is too large for the visible space.
- Set the largest realistic display width before uploading: Resize camera photos and design exports when you know how large they will appear.
- Keep extra size only where the page needs it: Leave room for full-width images, zoomable products, and sharp text, but do not use that rule for every thumbnail.
Keep Responsive Images Working
WordPress normally gives the browser a selection of image widths and a hint about the image’s display width. The browser can then choose a smaller file for a phone instead of downloading the desktop-sized file.
In the test page, image tags included width and height values, plus srcset, a list of available image files, and sizes, a hint about how wide the image would appear. This is useful only if the theme, page builder, or custom block leaves those instructions intact. Check the finished page, not only the Media Library:
- Confirm the displayed width matches the chosen file: An image shown at 600 pixels wide should not normally download a 2400-pixel source.
- Check the browser’s selected file: The file in the page code is not always the file the visitor receives.
- Inspect custom image layouts carefully: Sliders, background images, visual builders, and custom templates can remove the normal responsive choices.
Do not replace a normal image with a background image just to control its position. Background images often need separate sizing and loading rules, which makes them easier to get wrong.
Choose The Format And Quality
There is no best format for every image. Choose it based on the image’s purpose and check the result at its real display size.
- Use JPEG for photographs and complex scenes: It is a practical choice when the image has many colours and textures.
- Use PNG for transparency, screenshots, and sharp graphics: It keeps crisp edges, but it is often too heavy for photographs.
- Use WebP for a practical modern default: It works well for many photos and graphics and has broad browser support.
- Test AVIF when smaller files matter: It can be smaller than WebP, but serve a fallback for browsers or tools that do not support it reliably.
- Use SVG for simple logos and icons with care: SVG is a scalable image format, but use a sanitised workflow because an unsafe file can contain harmful code.
- Replace large animated GIFs with video when suitable: Video is usually more efficient for substantial animation.
Compression also has choices. Lossy compression removes some image data for a larger size reduction. Lossless compression preserves the data but usually saves less space. A moderate lossy setting works for many web photos, while screenshots, product images, charts, diagrams, and portfolio work need a visual check.
- Test representative images before automating: Use a photograph, a text-heavy screenshot, and a transparent or product image.
- Judge the file at its real display size: A smaller file is not a win if text becomes muddy, edges develop halos, or transparency changes.
- Keep original backups during bulk work: Restore the original if a new setting harms important details.
📝 Note: The best target is the smallest file that still serves the image’s purpose. A higher compression percentage is not automatically a faster or better result.
The format and quality are only half of delivery. The page must also decide which images should load immediately.
Load Images At The Right Time
Lazy loading delays an image until the visitor is close to it. It helps long articles, galleries, product grids, and archives with many images below the visible area.
Do not lazy-load the hero, featured, or main product image when it is the LCP image. That image should start loading early. In the WordPress test, the featured image received high loading priority and was not lazy-loaded. A later transparent PNG was lazy-loaded.
- Keep the main visible image available early: Delaying it can make the page feel slower and can worsen LCP.
- Lazy-load images below the visible area: Give the browser less work before the visitor reaches those images.
- Review automatic settings on real templates: A blanket setting can treat a hero image like a thumbnail.
⚠️ Note: If a speed tool says to lazy-load every image, check which image is the main visible element before applying that advice.
Reserve Space For Each Image
Keep image width and height values so the browser knows the image’s shape before it loads. This helps prevent Cumulative Layout Shift (CLS), the unexpected movement of page content while images, ads, or embeds appear.
These values describe the image’s shape. They do not stop the image from shrinking on a phone. Reserving this space helps prevent layout shifts so you do not see a Core Web Vitals assessment failed error in PageSpeed Insights.
- Keep dimensions on normal image blocks: Let the browser reserve the correct space before the file arrives.
- Check sliders, ads, embeds, and background images separately: They may need their own reserved space.
- Watch the page while it loads on a slower connection: A stable layout matters even when the final image looks correct.
Handle Existing And Future Uploads
An established site needs a repair plan for existing images and a publishing rule for new ones.
- Repair important pages before processing the whole library: Start with pages that have traffic, poor speed results, leads, or sales.
- Use a tool that handles generated image sizes: WordPress may store several versions of one upload, not just the original.
- Set automatic rules only after testing real files: Check photos, screenshots, transparent images, and product images before applying one quality setting to every upload.
- Check quotas and restore options before a bulk run: Tools may count credits, image data, page views, bandwidth, file size, or generated versions in different ways.
A CDN, or content delivery network, serves files from locations closer to visitors. Adaptive delivery can also send a smaller image to a phone than to a large desktop screen. These options can help global audiences, image-heavy shops, and high-traffic sites, but they add another service and another layer to test.
Local processing uses hosting resources. Cloud processing can reduce that load, but it may add quotas, bandwidth limits, another account, and dependence on a third party. Choose the trade-off that fits the site’s traffic, hosting capacity, and publishing workflow.
Prevent Tool Conflicts
Give each performance task one clear owner. A plugin, an add-on that extends WordPress, or a service can handle bulk processing, modern formats, backups, lazy loading, caching, or CDN delivery. Problems begin when several tools handle the same task.
- Assign one tool to each image transformation: Avoid duplicate WebP conversion or repeated resizing.
- Assign one tool to loading rules: Multiple lazy-loading or loading-priority settings can delay the important image.
- Assign one tool to caching and delivery: Overlapping page caches or CDN rewriting can create stale or broken files.Learn more about how caching layers interact in our guide on page cache vs object cache.
- Disable the old feature before switching tools: Then clear relevant caches and test the rendered page.
Two image optimisation tools can work together when their responsibilities are separate and the final page is checked. More tools do not guarantee a better result.
Measure The Same Page Before And After
Record a baseline before changing the image, then measure website speed using the same URL, device, location, and network settings when possible. Record the main image, its file size and format, LCP, total image data, request count, and visual quality.
- Retest the identical page after each meaningful change: Clear relevant caches so you are not comparing an old copy with a new one.
- Check delivery first: Confirm that the main image is smaller, starts early, and uses the expected format and source size.
- Check stability next: Make sure content does not move while images load.
- Check quality last: Inspect text, edges, transparency, and product details on the real template.
Performance scores can change because of network conditions, server load, cache state, test location, and the delay before real visitor data updates. Use the score with the page’s actual loading behaviour, not as the only verdict.
If image changes do not help, inspect the server, saved page delivery, page styles, scripts, font file size, hosting, third-party services, and theme or plugin overhead. Compressing a logo will not fix a slow server or a delayed page style file.
When AirLift Makes Sense
Image optimisation is one part of WordPress performance optimization. If you do not want separate tools managing images, caching, CDN delivery, page styles, scripts, and fonts, AirLift is a broader performance option to consider.
AirLift is most relevant when you need to:
- Coordinate several performance layers: Keep image optimisation, caching, CDN delivery, page styles, scripts, and fonts under one broader workflow.
- Work on more than file size: Address image delivery alongside the other settings that can affect loading speed, response to interaction, and visual stability.
- Keep measuring after changes: Use the same-page testing process to check that the combined settings improve the real page without delaying its main image.
AirLift brings those areas together with image optimisation and optimization settings aimed at Core Web Vitals, which measure loading speed, response to interaction, and visual stability. It does not remove the need to choose sensible image dimensions or check important pages after a change. Keep the main visible image out of lazy loading when it is the LCP element, then test the result on the real site.
FAQs
What is WordPress image optimisation?
It is the process of reducing image data, choosing suitable dimensions and formats, and controlling when images load. The goal is faster pages without visible damage or unstable layouts.
Should I resize images before uploading to WordPress?
Yes, when the original is much larger than its display area. A useful starting point is 1.5 to 2 times the content area’s width, with more room for images that need full-width display or zooming.
Which image format is best for WordPress?
Use JPEG for photos, PNG for transparency and sharp graphics, WebP for a practical modern option, and AVIF when testing shows a benefit and your setup provides a reliable fallback. The image’s purpose matters more than the format name.
Should I lazy-load every WordPress image?
No. Lazy-load images below the visible area, but let the hero, featured, or main product image load early when it is the main visible element. Delaying it can make LCP worse.
Do I need an image optimisation plugin?
Not always. Careful resizing and compression may be enough for a small site. A plugin or service becomes useful when you need bulk processing, automatic uploads, modern formats, backups, adaptive delivery, or consistent settings for several editors.
Conclusion
Good WordPress image optimisation starts with the image that slows an important page. Resize it to a sensible display size, compress it for its image type, use a suitable modern format when practical, preserve responsive image choices, and keep the main visible image out of lazy loading.
Then measure the same page again. If images are no longer the bottleneck, move to caching, delivery, page styles, scripts, fonts, hosting, or other causes instead of compressing harder. For the broader troubleshooting path, see slow-loading WordPress diagnosis. This focused workflow keeps pages fast, visuals useful, and future uploads easier to manage.If you run a shop with heavy product galleries, see our guide on Ecommerce website performance to optimize high-traffic store pages.
