Est. reading time: 7 minutes

Image problems on a WordPress site announce themselves in two opposite ways. Either the photos look soft and cheap, or they look fine and the pages crawl. Plenty of sites manage both at once, because the causes are related. Someone uploaded whatever came off the camera or out of the design tool, WordPress did its best, and nobody checked the result on a real phone.

This matters more than cosmetics. Images are usually the heaviest thing on the page and the most common Largest Contentful Paint element, which puts them at the center of your Core Web Vitals and therefore your page load speed. And on an ecommerce site, soft product photos read as low quality product, a connection we’ve traced directly in how to tell if your product photos are costing you conversions. The fixes below run from diagnosis to handoff, in the order we’d work them in an audit.

Blurry images: the file was wrong before WordPress touched it

Blur has three usual causes. The uploaded file was smaller than the space it displays in, so the browser stretched it. The file was large enough but compressed too aggressively. Or the layout forces the image into dimensions it wasn’t made for. The same failure shows up in ad creative too, and we covered the platform version in why your TikTok ads look blurry and how to fix them. On your site, at least, you control every variable.

Start with source size. An image should be uploaded at least as wide as the largest size it will ever display, and ideally 1.5 to 2 times that width, because high-resolution phone and laptop screens pack multiple physical pixels into every CSS pixel. A hero image displaying at 1200 pixels wide needs a source closer to 2400. Upscaling a small file adds pixels but never adds detail, which is why enlarged images always look soft.

Then check compression. Quality settings around 75 to 85 for JPEG and WebP are the working range where files shrink substantially and the eye can’t find the loss. Below that range, photos develop visible smearing and artifacts. If your optimization plugin was set aggressively at some point, the damage is already baked into the generated files, so fix the setting and regenerate.

Two more specifics worth knowing. WordPress scales down very large uploads by default (the threshold sits around 2560 pixels), which is a sensible safety net, but it means your pristine 6000-pixel original may not be what’s actually serving. And logos or icons that look fuzzy at any size should be SVG, a format that scales with perfect edges because it’s drawn rather than pixel-based.

Oversized delivery: the file is sharp and everyone pays for it

The opposite failure is serving the full-resolution original everywhere. A 4000-pixel photo inside a 300-pixel product card looks fine, and every visitor downloads more than ten times the data the slot required. Multiply that across a category page of 24 products and the page weight explains itself.

WordPress already has the machinery to prevent this. Every upload generates multiple sizes, and the srcset markup WordPress outputs lets each browser pick the smallest file that looks sharp at the visitor’s screen size. When that system works, phones get small files and 4K displays get large ones automatically. When it fails, it’s usually because someone inserted the “Full size” option in the editor out of habit, or because the theme reports wrong size hints to the browser, or because the right generated sizes don’t exist.

The operational fixes are simple. In Image, Gallery, and Cover blocks, choose the size that matches the container instead of defaulting to full size. After any theme switch or change to image dimensions, run a thumbnail regeneration so every image has a freshly generated set of sizes to serve from. And keep crops consistent, since WordPress supports fixed-ratio sizes with focal points, so product cards can hold a uniform 4:5 while the hero runs wide, without anyone squeezing one file into every role.

Whether the theme handles its side correctly (accurate size hints, width and height attributes on every image, no styling that scales images past their natural width) is developer territory, and it’s a fair test of whoever built the site. We put it on the checklist in how to tell if your WordPress developer is using best practices, because a build that gets images wrong usually gets other fundamentals wrong too.

Slow loading: the right files arriving in the wrong order

Once sources are clean and sizing is right, speed comes down to sequencing. The browser should fetch the image the visitor is looking at first, defer everything below the fold, and never make the page reflow when images arrive.

WordPress lazy-loads images by default, which handles the deferral. The mistake we find repeatedly is that the hero image gets lazy-loaded along with everything else. That’s backwards. The hero is usually the Largest Contentful Paint element, and delaying it delays the moment the page appears finished. The hero should be excluded from lazy-loading and flagged as high priority so the browser fetches it immediately. That single change is often the largest LCP improvement available on the page, and it’s a one-line fix for whoever maintains the theme.

Layout shift is the other sequencing failure. When images load without declared dimensions, the page assembles, then jumps as each image claims its space. Width and height attributes on every image reserve the space in advance, which is why they show up twice in this post. They serve both sharpness and stability.

Compression strategy belongs here too. Standardize on one optimization plugin (ShortPixel, Imagify, EWWW, and Smush all do the job) rather than stacking two, set the quality range from the first section, strip metadata, and convert animated GIFs to video files, which deliver the same motion at a fraction of the size.

Formats and delivery: the last third of the savings

Modern formats are the cheapest remaining win. WebP is supported essentially everywhere and cuts file size meaningfully against JPEG at the same visual quality. AVIF frequently cuts further. The practical approach is to let your optimization plugin or CDN generate these formats and serve them automatically with fallbacks, so you never manage format decisions by hand and older browsers still get a working image.

A CDN closes the distance. Serving images from a network of edge locations instead of a single origin server shortens the trip for every visitor, and image-specific CDNs (Cloudinary, ImageKit, imgix) add on-the-fly resizing and automatic format selection, which can replace much of the plugin work above. For a content site, a general CDN like Cloudflare or Bunny is usually enough. For an image-heavy catalog, the image CDN earns its cost by making sizing and format problems structurally impossible.

Then verify on real conditions. Test the site through device emulation and on an actual midrange phone, check that heroes are sharp on a high-resolution screen, and confirm in PageSpeed Insights that LCP is landing where it should. The reported numbers are the scoreboard, but the phone in your hand is the experience your customers are grading.

The order of operations

Worked as a sequence, this is an afternoon of configuration and a short list for a developer. Fix sources and compression first, because everything downstream serves copies of whatever you uploaded. Then match sizes to containers and regenerate thumbnails. Then correct the loading order, hero first, everything else deferred. Then let a plugin or CDN handle formats and delivery permanently. Sites that work the list in this order get sharper pages and faster ones from the same photos, because the two problems were never in tension. They were the same problem, unmanaged.