Why most WordPress sites are either slow or ugly (and how to avoid both)
Every designer has had this conversation. The developer says the images are too heavy. You compress them. The client opens the homepage on a 27-inch Retina display and says the hero photo looks “muddy”. Nobody is happy.
The good news is that this is a false trade-off. In practice, you can strip 70 to 90 percent of the weight from a typical photo before anyone with a trained eye notices anything at all. The trick is knowing where the visual breaking point sits for each type of image, and doing the resizing work before compression rather than after.
This guide walks through exactly how to compress images for WordPress using both plugins and a manual pre-upload workflow, with the specific quality values we use at PixelBright and real before/after file sizes from our own test set.
The short answer
- Resize first. Never upload an image wider than it will ever be displayed. This single step usually removes more weight than compression does.
- Pick the right format. WebP for almost everything, AVIF for hero images, SVG for logos and icons, PNG only for true transparency edge cases.
- Compress to quality 75 to 82 for JPEG, 72 to 80 for WebP. That is the sweet spot where the file collapses but the pixels hold.
- Automate the rest with a plugin so that client uploads never break the system.
Step 1: Resize before you compress (the step everyone skips)
Compression settings get all the attention, but dimensions matter more. A 6000 x 4000 px photo straight from a camera can be 8 MB. Resized to 1800 px wide it drops to around 900 KB before you touch a single quality slider.
What widths do you actually need in 2026?
| Usage | Recommended max width | Notes |
|---|---|---|
| Full-width hero / banner | 1920 to 2400 px | 2400 only if the image sits behind large text on Retina screens |
| Blog post inline image | 1200 to 1600 px | Most content columns are 700 to 800 px wide |
| Product / portfolio thumbnail | 600 to 800 px | Let WordPress generate the smaller variants |
| Team photo / avatar | 400 to 600 px | Square crop, saves a lot of noise |
| Logo, icon, simple illustration | SVG (no pixels at all) | Usually under 10 KB |
WordPress helps a little on its own. Since version 5.3, core scales down any upload wider than 2560 px and stores the scaled copy as the version it serves. That is a safety net, not a strategy. A 2560 px JPEG is still far heavier than it needs to be for a 1200 px content column.
You can lower that threshold in your child theme functions file:
add_filter( 'big_image_size_threshold', function() {
return 2000;
} );Step 2: Choose the right format
Format choice can save more bytes than any compression slider. Here is how the formats compare from a designer’s point of view.
| Format | Best for | Weakness | Browser support |
|---|---|---|---|
| WebP | Almost everything: photos, UI shots, graphics with transparency | Slight smoothing on very fine texture at low quality | Universal |
| AVIF | Large hero photos, gradients, dark scenes | Slower to encode, some older devices still need a fallback | Very good, keep a WebP fallback |
| JPEG | Universal fallback, photography | No transparency, larger than WebP at equal quality | Universal |
| PNG | Flat graphics, screenshots with crisp text, hard transparency | Enormous when used for photos | Universal |
| SVG | Logos, icons, charts, line illustrations | Not for photos, needs sanitising on upload | Universal |
Is PNG or JPEG better for WordPress?
For photographs, JPEG wins every single time, usually by a factor of five to ten. For screenshots, logos, diagrams and anything with flat colour or sharp text edges, PNG wins because JPEG puts visible fuzz around high contrast lines. In 2026 the honest answer for both cases is WebP, which handles photos and flat graphics well and supports transparency. Source: https://wordpress.org.
Step 3: The quality settings that keep visuals sharp
This is the part designers actually care about. We ran a blind test with three of our clients: same image, five compression levels, no labels. Below is where they started to notice a difference, translated into practical settings.
| Image type | JPEG quality | WebP quality | Why |
|---|---|---|---|
| Hero photo with text overlay | 65 to 72 | 62 to 70 | Overlay and darkening hide artifacts |
| Editorial / blog photo | 75 to 80 | 72 to 78 | Viewed at moderate size, safe zone |
| Portrait, skin tones | 80 to 85 | 78 to 82 | Smooth skin gradients band early |
| Product shot on white | 82 to 88 | 80 to 85 | Halos around edges are very visible on white |
| Flat illustration, gradients | Avoid JPEG | 85 to 92 or lossless | Banding shows immediately |
| Screenshot with UI text | Avoid JPEG | Lossless WebP or PNG-8 | Text must stay crisp |
| Fine texture: fabric, foliage, sand | 80 to 85 | 78 to 84 | Aggressive settings turn texture into mush |
The rule of thumb we teach juniors: below quality 60 everything looks compressed, above quality 90 you are paying for pixels no human will ever see.
Where WordPress sets its own quality
WordPress recompresses every derivative size it generates. Core defaults to a quality of 82 for the scaled JPEG versions it creates. If your source file is already optimised, that recompression can be a second lossy pass. You can control it:
add_filter( 'jpeg_quality', function() {
return 82;
} );
add_filter( 'wp_editor_set_quality', function() {
return 82;
} );Do not push this below 75 globally. Site-wide values apply to product shots and portraits too, and those are the images that break first.
Real file size comparisons from our test set
All tests run on the same source: a 3000 x 2000 px architectural photo, 4.8 MB straight out of camera. Every version below was resized to 1800 px wide first. A comparable breakdown sits on hostpapa.com.
| Version | File size | Saving vs original | Visible difference? |
|---|---|---|---|
| Original, unresized JPEG | 4.8 MB | Baseline | Reference |
| Resized 1800 px, JPEG q100 | 1.42 MB | 70% | None |
| JPEG q85 | 348 KB | 93% | None |
| JPEG q78 | 231 KB | 95% | None at 100% zoom |
| JPEG q60 | 142 KB | 97% | Yes, sky banding |
| WebP q75 | 158 KB | 97% | None |
| AVIF q55 | 94 KB | 98% | None, slight softening in foliage |
And the same exercise on a 1600 x 1000 px UI screenshot, originally exported as a 24-bit PNG at 890 KB:
| Version | File size | Text still crisp? |
|---|---|---|
| PNG-24 original | 890 KB | Yes |
| PNG-8 palette (TinyPNG style) | 124 KB | Yes |
| WebP lossless | 98 KB | Yes |
| WebP q85 lossy | 52 KB | Mostly, faint fuzz on small labels |
| JPEG q80 | 147 KB | No, visible ringing |
Notice the pattern: for the screenshot, JPEG is both bigger and worse. Format choice beats compression level.
Method 1: The manual pre-upload workflow
This is what we use for anything that appears above the fold or in a portfolio. It takes about 40 seconds per image and gives you total control.
In Photoshop
- Open the image and use Image > Image Size to set the target width. Keep resampling on “Bicubic Sharper (reduction)”.
- Apply a light unsharp mask after downsizing: amount 40 to 60%, radius 0.4 px. Downsizing always softens edges slightly, and this recovers the bite.
- Go to File > Export > Export As, choose WebP or JPEG, and drag the quality slider while watching the preview at 100%.
- Convert to sRGB on export. Wide-gamut files often look washed out or oversaturated in browsers.
- Strip metadata unless you need copyright fields. Camera EXIF can add 40 to 80 KB per file.
In Affinity Photo, Figma or Sketch
All three export WebP directly now. Export at 1x for the display width you calculated, not at 2x, unless the image is a hero. Retina exports double the pixel count and roughly triple the file size for a difference most visitors never register on a scrolling page.
Free browser tools worth bookmarking
- Squoosh: side by side comparison with a slider, per-format controls, runs locally in your browser. The best tool for finding your personal quality threshold.
- TinyPNG: excellent palette reduction for PNG, drag and drop, no settings to think about. Handy for handing off to non-designers.
- ImageOptim (macOS): drop a folder in, it strips metadata and runs lossless passes. Zero visual change, typically 5 to 20% smaller.
Naming and alt text while you are there
Rename files to something descriptive before uploading, for example brass-kitchen-tap-detail.webp rather than IMG_4821.jpg, and fill the alt text in the media library. It costs seconds and it is one of the few image SEO signals that still moves the needle.
Method 2: Compressing images inside WordPress with a plugin
Manual work is fine for a site you control. It falls apart the moment a client starts uploading their own product photos. That is what plugins are for: they catch everything, convert formats, and regenerate old library items.
| Plugin | Best for | Processing | Free tier |
|---|---|---|---|
| Imagify | Agencies wanting a set-and-forget setup with three clear levels | Cloud | Monthly quota in MB |
| ShortPixel | Fine control, glossy mode, excellent WebP and AVIF output | Cloud | Monthly credit allowance |
| Smush | Beginners, safe lossless compression, bulk cleanup | Cloud | Generous, with a per-file size cap |
| EWWW Image Optimizer | Sites that must keep processing on their own server | Local or cloud | Unlimited local compression |
| Optimole | Heavy media sites, real time resizing per device via CDN | CDN, on the fly | Visit-based limit |
| TinyPNG / TinyJPG | Simple, predictable results, no dashboard to learn | Cloud | Monthly compression count |
Free tiers and pricing change often, so check the current numbers on each vendor’s site before you commit a client project. A comparable breakdown sits on themeisle.com.
Our recommended plugin configuration
- Choose lossy or “intelligent” mode, not lossless. Lossless typically saves 10 to 20%. Well tuned lossy saves 60 to 80% with no visible difference.
- Turn on WebP conversion with automatic delivery, ideally through the picture element or rewritten rules rather than a redirect hack.
- Enable AVIF if the plugin offers it and keep WebP as fallback. Test your hero images visually afterwards.
- Set a maximum upload dimension (2000 px is a sensible ceiling) so client uploads get resized automatically.
- Keep original files as a backup for the first few months. Storage is cheap, re-shooting a product catalogue is not.
- Run a bulk optimisation on the existing library, then check a random sample of 10 images at full zoom.
- Disable image sizes your theme never uses. Every registered size multiplies storage and processing time.
add_filter( 'intermediate_image_sizes_advanced', function( $sizes ) {
unset( $sizes['medium_large'] );
unset( $sizes['1536x1536'] );
unset( $sizes['2048x2048'] );
return $sizes;
} );Plugin or manual: which should you use?
Use both. That is not a cop-out, it is how professional sites are built.
- Manual for hand-picked visuals: homepage hero, portfolio pieces, campaign landing pages, anything a client will scrutinise. You decide the exact quality per image.
- Plugin for everything else: blog images, product uploads, whatever the marketing intern adds at 5 pm on a Friday. It is your insurance policy.
A plugin applied on top of an already optimised file will normally find only a few extra percent, which is fine. What matters is that nothing heavy ever slips through.
Checking your work: did it actually help?
- Open the page in Chrome DevTools, go to the Network tab, filter by Img and reload. Sort by size. Any image over 200 KB needs a reason to exist.
- Run PageSpeed Insights and look at the Largest Contentful Paint value. On most content sites the LCP element is an image, so image work is the fastest way to move that number.
- Check the total page weight. A well built page with several photos should land between 800 KB and 1.5 MB.
- Confirm WebP is really being served: in DevTools the Type column should say
webp, notjpeg. - Do the visual check on a good screen at 100% zoom, and on a phone in daylight. Those are the two conditions that matter.
Do not forget lazy loading and dimensions
WordPress adds loading="lazy" automatically, but you should exclude the hero image from lazy loading and give it fetchpriority="high". Lazy loading the LCP image delays it and hurts your score. Also make sure width and height attributes are present on every image so the browser reserves the space and your Cumulative Layout Shift stays near zero.
Five mistakes we still see on client sites
- Uploading straight from the camera or phone. A single 6 MB upload can outweigh the rest of the page combined.
- Using PNG for photographs. Five to ten times heavier than it needs to be, with zero visual benefit.
- Double compression. Exporting at quality 60, then letting a plugin compress again. Artifacts stack and cannot be undone.
- Applying one global quality value to every image. A texture-heavy fabric shot and a dark hero with a text overlay do not need the same setting.
- Optimising new uploads but never the existing 4,000 image library. Run the bulk process once, then forget about it.
FAQ
How do I reduce image size for WordPress?
Resize the image to its maximum display width first, export it as WebP or JPEG at quality 75 to 82, then upload. If you would rather automate it, install an optimisation plugin such as Imagify, ShortPixel, Smush or EWWW, enable lossy mode plus WebP conversion, and run a bulk optimisation on your existing media library.
What is a good free image compressor for WordPress?
For manual work, Squoosh and TinyPNG are both free and excellent. Inside WordPress, EWWW Image Optimizer offers unlimited compression processed on your own server, and Smush has a generous free tier for lossless compression. Most cloud based plugins provide a free monthly quota that comfortably covers a small blog.
What is the best image size for a WordPress website?
There is no single answer, it depends on where the image appears. As a guide: 1920 to 2400 px wide for full-width heroes, 1200 to 1600 px for in-content images, 600 to 800 px for thumbnails. In terms of file weight, aim for under 200 KB per content image and under 300 KB for a hero.
Does compressing images hurt SEO?
The opposite. Faster loading improves Core Web Vitals, which feed into ranking, and reduces bounce on mobile connections. The only way image compression hurts you is if you push quality so low that the page looks cheap and visitors leave.
Should I use WebP or AVIF in 2026?
Serve AVIF where your tooling supports it, with WebP as a fallback. AVIF is typically 20 to 40% smaller than WebP at the same perceived quality, which is significant on large hero images. For small graphics the difference is negligible, so WebP alone is fine.
Will compressing images break my existing pages?
No, if you keep backups of the originals and your plugin regenerates rather than replaces destructively. Always enable the “keep original” or backup option before running a bulk optimisation, and spot-check a handful of pages afterwards.
Final thoughts
Compressing images for WordPress is not a fight between speed and design quality. It is a fight against lazy defaults: unresized uploads, the wrong format, and a single global quality value applied to everything. Fix those three things and you will typically cut page weight by 80% while your client never notices a single pixel has changed.
If you would rather hand the whole thing over, the PixelBright team audits and rebuilds media pipelines on WordPress sites of every size. Get in touch and we will tell you exactly how many megabytes are sitting in your library right now.