To optimize images for faster page load, resize every image to the size it actually displays, compress it, convert it to WebP or AVIF, set explicit width and height, and lazy load anything below the fold. Images are usually the heaviest thing on a page, so this one cleanup usually does more for your load time than anything else you can do today.
None of it needs coding. If you can upload a file to WordPress, you can follow the whole workflow, and most of it takes about an hour for a typical post.
Table of Contents
- What You Need
- Step-by-Step: How to Optimize Images for Faster Page Load
- 1. Measure the current image performance first
- 2. Resize images to the size they actually display
- 3. Compress images without making them look bad
- 4. Choose the right image format
- 5. Set explicit width and height and write useful alt text
- 6. Lazy load below-the-fold images only
- 7. Serve images through a CDN or cache
- 8. Retest and keep images updated
- Common mistakes that undo all of this
- Frequently Asked Questions
- Start with the biggest five files
What You Need
Four things, and you probably already have all of them.
The original image files. Whatever you exported from your camera, phone, or design tool. Keep them somewhere safe, because you will want to re-export rather than re-compress an already compressed file.
A way to measure. Google PageSpeed Insights is free and needs nothing installed. Chrome DevTools is better if you want to see individual file sizes, and both are free.
An image editor or compressor. Anything that exports at a size you choose works. Squoosh, TinyPNG, ShortPixel, and ImageOptim cover most cases, and if you run WordPress a plugin can do the whole library at once.
Access to the place the images live. For most people that is the WordPress media library. For others it is a page builder, a theme, or hand-written HTML in a code editor.
Step-by-Step: How to Optimize Images for Faster Page Load
1. Measure the current image performance first
Open PageSpeed Insights, paste the URL of the page you want to fix, and wait for both the mobile and desktop runs. It finishes in about a minute.
Write down two numbers: the Performance score and the LCP number, which is how long the biggest visible element takes to appear. On an image-heavy page that element is almost always a photo, which makes it yours to fix.
Scroll to Opportunities or Diagnostics and look for anything mentioning image sizing, image file size, or properly size images. Then open the Network tab in Chrome DevTools, sort by size, and note the biggest five files on the page. That list is your to-do list.
One caution from people who test this regularly: PageSpeed scores swing a lot between runs. Test the same page three times before you decide anything is broken or fixed.
2. Resize images to the size they actually display
This is the single biggest win, and most sites skip it. A 4000-pixel camera photo dropped into a 600-pixel-wide content slot still downloads at 4000 pixels wide. Nobody ever sees 3400 of them.
Work out the real display width of each slot before you export anything:
- Hero or banner image: about 1920 pixels wide on desktop, and export a separate smaller file for phones rather than letting the browser shrink one huge file.
- In-content images inside a post: roughly 700 to 800 pixels wide is plenty, because the text column itself is rarely wider than that.
- Thumbnails and gallery grids: 300 to 400 pixels wide.
- Icons and logos: usually fine at 100 to 200 pixels, or better still, use SVG.
Do not make every image the same size. An icon and a hero banner have nothing in common, and forcing them into one rule just recreates the original problem in the other direction.
For a sharper image on high-density screens, export about twice the display width and let the browser scale it down. That is still a fraction of the pixels you started with.
3. Compress images without making them look bad
Compression comes in two flavours. Lossless keeps every original pixel and shrinks the file by stripping data the viewer never sees, which is why text and logos stay crisp. Lossy throws away some detail permanently, which is why a heavily compressed photo can look blotchy up close.
For ordinary web photos, lossy compression at a quality setting somewhere around 70 to 80 percent is the sweet spot. Most people cannot tell the difference from the original at that level, and the file often drops by half or more.
Here are reasonable size targets to aim for:
- Hero or above-the-fold image: under 150 KB
- In-content photos: under 100 KB each
- Thumbnails and grid images: under 30 KB each
- Icons and logos: under 10 KB
To compress, drop a file into Squoosh or TinyPNG and compare the before and after previews side by side at full size. Squoosh also has a lossless mode worth trying on screenshots and graphics with flat colour. ImageOptim handles whole folders on a Mac, and ShortPixel does batches in the browser.
If you are on WordPress, a compression plugin will handle existing and future uploads for you. Pick one, not five. Running two compression plugins at once is a reliable way to break images.
4. Choose the right image format
Format choice is a quick win because newer formats do the same job with far fewer bytes.
| Format | Compression | Best for | Transparency | Browser support |
|---|---|---|---|---|
| JPEG | Lossy | Photographs | No | Universal |
| PNG | Lossless | Screenshots, logos, line art | Yes | Universal |
| WebP | Lossy or lossless | Almost everything, with smaller files than JPEG | Yes | All current browsers |
| AVIF | Lossy or lossless | Smallest files, best quality at low sizes | Yes | Current Chrome, Edge, Firefox, Safari |
| SVG | N/A, vector | Icons, logos, simple shapes | Yes | Universal |
A practical default: serve WebP or AVIF when you can, fall back to JPEG for very broad compatibility, keep PNG only when you truly need transparency, and use SVG for anything drawn with lines and shapes. An image CDN can convert formats on the fly per visitor, which removes the guessing.
5. Set explicit width and height and write useful alt text
When an image has no declared dimensions, the browser downloads it with zero space reserved, then shoves everything below it down the page when the file finally arrives. That jump is layout shift, and Google scores it as CLS. The fix is cheap: declare the dimensions.
Add width and height in pixels matching the image file, or set an aspect-ratio in CSS if you are letting the image scale fluidly.
<img
src="kitchen-renovation.webp"
width="800"
height="533"
alt="Freshly tiled kitchen counter with a white island">Alt text is a separate job. Describe what the picture shows in plain words, using the topic once where it fits naturally. Screen readers read it aloud to people who cannot see the page, and search engines use it to understand the image. Skip it and you lose both. Avoid keyword stuffing, and skip alt entirely on a purely decorative image rather than describing it badly.
6. Lazy load below-the-fold images only
Lazy loading tells the browser to skip images that are off screen and fetch them when they scroll into view. It works well for anything a visitor has to scroll to reach.
Do not lazy load the hero image or anything in the first screen. Those images are the ones people are waiting for, and delaying them makes the page feel slower even when the numbers look better. Modern browsers lazy load images below the fold by default, so you may need to do nothing at all here.
The other half of this step is background images. A CSS background image is never lazy loaded by the browser, and on a page with several full-bleed section backgrounds that alone can be megabytes of downloads before the first paint. Where you can, replace a background image with an <img> and use object-fit: cover to keep the same visual result.
<img src="banner.webp" width="1600" height="600"
loading="lazy" decoding="async"
alt="Wide view of the workshop bench"
style="width:100%;height:400px;object-fit:cover">For the one image that matters most, do the opposite and tell the browser to prioritise it:
<img src="hero.webp" width="1920" height="1080"
fetchpriority="high" decoding="async"
alt="Renovated kitchen with island seating">Add decoding="async" to images under the fold so the browser decodes them off the main thread and keeps scrolling smooth.
7. Serve images through a CDN or cache
A content delivery network keeps copies of your image files on servers around the world and hands each visitor the nearest one. On a page with dozens of images, that difference in round-trip time adds up quickly.
Most hosts offer basic image caching at no extra cost, and most caching plugins include it. Cloudflare is the common free option for a small site. For automatic resizing and per-visitor format conversion, paid services such as Cloudflare Images, imgix, and ImageKit do the whole job, and you upload your original once.
Whatever you choose, enable long-lived caching headers for image files. An image file rarely changes, so there is no reason for a returning visitor to download it twice.
8. Retest and keep images updated
Run PageSpeed Insights again on the same URL and compare the Performance score, LCP, and total page weight against your starting notes. Then check the Network tab again to confirm the biggest files really are smaller now.
Run it on mobile first. Most of your traffic is on phones, and mobile is where the throttling exposes problems that desktop hides.
Change one thing, then retest. Changing compression, format, and dimensions all at once tells you nothing about which one worked, and you will end up guessing.
Images also go stale. When you redesign a layout and the content column gets wider, every old image is now the wrong size. Re-export rather than upscaling a small file, which produces a soft, blurry result.
Common mistakes that undo all of this
- Uploading full-resolution camera files. A 12-megapixel phone photo has no place in a blog post. Export at display size and keep the original offline.
- Using an image far larger than its display slot. Fix: match the export width to the slot, roughly twice it for high-density screens.
- Lazy loading the hero image. Fix: remove lazy loading there and use
fetchpriority="high"instead. - Converting every file to one format. Fix: photos to WebP or AVIF, transparency to PNG or WebP, line art to SVG.
- Omitting width and height. Fix: declare the pixel dimensions or set an aspect-ratio so the browser reserves space.
- Writing generic alt text like “photo” or “image”. Fix: describe what is actually shown in one short sentence.
- Optimising once and never rechecking. Fix: retest after every change, and again after a redesign.
- Stacking five performance plugins. Fix: one compression plugin and one caching plugin is plenty. Conflicting plugins cause broken images and caching problems.
Frequently Asked Questions
How to make images on a website load faster?
Resize each image to roughly twice its display width, compress it to a quality around 75 percent, convert it to WebP or AVIF, declare width and height, and lazy load anything below the fold. Serve the files through a CDN so visitors download them from a nearby server. Most sites see the biggest gain from resizing alone, because full-resolution photos are usually far wider than the slot they sit in.
Why do images load so slowly on my site?
Usually one of five causes: the file is much larger than its display slot, it is still a JPEG or PNG when WebP would be smaller, every image loads at once including those far below the fold, the files are served from a slow origin server with no CDN, or missing width and height cause the page to reflow while images arrive. PageSpeed Insights Diagnostics names the specific culprit on your page.
What image format is fastest to load?
AVIF produces the smallest files at a given quality, with WebP a close second and far wider in support. JPEG is the safe fallback when you need universal compatibility, and PNG stays the right choice for screenshots with text. SVG is best for logos and icons because vector graphics scale without carrying pixel data. In practice, WebP is the sensible default for most sites.
Do lazy loaded images hurt SEO?
No. Googlebot renders pages and loads lazy-loaded images, so content below the fold is still indexed. The risk is not indexing but user experience: lazy loading a hero image delays the largest visible element and pushes your LCP number up. Keep lazy loading for below-the-fold images and leave the first screen to load immediately with fetchpriority set to high.
What file size should a website image be?
Aim for under 150 KB for a hero image, under 100 KB for in-content photos, under 30 KB for thumbnails, and under 10 KB for icons. Those are targets rather than rules, and a text-heavy screenshot might reasonably sit under 40 KB while a busy photograph needs closer to 120 KB. Measure the transfer size in your browser Network tab rather than trusting the size shown in your editor.
Do CSS background images slow down a page?
Yes, and they are never lazy loaded automatically. Every background image is fetched as soon as the CSS applies, so a page with several full-bleed section backgrounds can start downloading megabytes before anything appears. Compress and resize them like any other image, or replace them with an img element using object-fit to cover, which can then be lazy loaded like normal.
Start with the biggest five files
Open PageSpeed Insights, find the five heaviest images on your slowest page, and resize them to match their display slots. That single afternoon usually does more than a month of fiddling with settings.
After that, compress them, convert them to WebP, and set their width and height. Everything else on this list is a refinement on top of those three fixes.