Most WordPress Business Sites Are Slow Because of the Photos. Not the Hosting. Not the Plugins. The Photos.

That is the hot take. After two decades of running hosting infrastructure and reviewing thousands of slow-site complaints, the single biggest cause of "my WordPress site is slow" is the images. Not the host. Not the theme. Not the page builder. The photos the business owner uploaded straight from their phone.

I am going to show the receipts.

The Pattern We See Every Week

Reviewing the bandwidth reports this morning across our customer base, the shape is identical week after week. A site loads in under two seconds. The owner adds a gallery of new product photos from their phone. The page weight jumps from 1.2MB to 38MB. The Core Web Vitals score falls off a cliff. The owner blames the host.

We have made this diagnostic mistake ourselves more than once. An owner rings to say their site has got slower after a relaunch. We assume it is the database. We spend an hour digging through query logs. The actual cause is a fresh gallery of phone-camera photos on the homepage, each over 5MB. The lesson took.

The Numbers Most Owners Do Not See

A modern iPhone photo, saved as JPEG, lands somewhere between 3MB and 8MB. An iPhone 15 Pro shooting in 48-megapixel mode can produce a single photo of 20MB to 30MB. According to the HTTP Archive Web Almanac 2024, the median desktop homepage on the entire internet loads about 1,054 KB of images, which is already roughly half of total page weight. Call it one megabyte of images for the whole page.

One uncompressed iPhone photo is five to thirty times that.

Put six of those photos on a homepage and you have built a page that weighs anywhere from 30MB to 180MB. On a fast fibre connection that takes seconds to load. On a busy 4G cell, it takes long enough for the customer to give up and try a competitor.

Why "I Have an Image Optimisation Plugin" Is Not the Whole Answer

The most common reply when I point this out is: "But I am running Smush" or "I installed ShortPixel". Good. Those plugins help. They are not the whole answer.

Most image optimisation plugins compress at upload time. They do not always convert uploads to modern formats by default. They do not always serve different image sizes to different devices. They do not always set the correct fetch priority on the Largest Contentful Paint element. They sit inside WordPress, which means they run on PHP, which means every optimisation happens after a request hits your server.

That works. It is just doing the work in the wrong place.

The right place is the server, before WordPress ever sees the request. WordPress 6.5, released by the project in February 2024, added AVIF support as a core feature, but only if your hosting environment has the AVIF libraries installed and the right MIME types configured. Many cheap shared hosts do not. So even when WordPress is ready to do the right thing, the server underneath cannot deliver it.

The Core Web Vitals Cost

Google measures three Core Web Vitals: LCP, INP, and CLS. For the average business site, the largest element on the page is an image. Which means Largest Contentful Paint is almost always an image metric in disguise.

A "good" LCP score is 2.5 seconds or less, according to web.dev. A homepage carrying 30MB of phone photos will not hit that number on a mobile connection. Not even close.

The business consequence is not abstract. Sites that fail Core Web Vitals are demoted in mobile search results and lose conversions at every step of the funnel. We saw this with a café owner on the Galway Quays last quarter, who could not understand why her Google Business Profile clicks were not converting into table bookings. The Profile was sending traffic. Her menu page took roughly nine seconds to load on mobile because every dish photo was a 6MB JPEG. That is the cost.

What a Properly Configured Stack Does, Automatically

Here is what a properly configured WordPress hosting environment does with images, without the owner touching a plugin:

• Generates modern formats from the original upload, where the server has the right image libraries. Google's WebP compression study found WebP delivers files roughly 25% to 34% smaller than equivalent JPEG at the same perceived quality. WordPress 6.5 added native AVIF support on top of that.
• Serves the responsive image size the browser asks for. WordPress already builds multiple sizes on upload and emits a srcset by default; the server just has to deliver the right one quickly.
• Applies cache headers and CDN-style delivery so the second visitor on the same page never re-downloads the image.
• Sets a high fetch priority on the LCP element so the largest above-the-fold image deploys first.

Web60 runs the WordOps stack with Nginx, PHP-FPM, Redis object caching, and FastCGI page caching, configured to support WordPress's native modern format handling and aggressive cache delivery. In practice, that means a business owner can upload a 6MB phone photo, walk away, and the visitor sees a far smaller WebP rendered fast, without anyone configuring anything. The site stays fast even when the marketing manager has a busy upload day.

Where This Advice Has a Limit

If you are a professional photographer, a high-end portrait studio, or a design firm whose product is image fidelity, automatic server-level conversion is not enough. You want pixel-level control. A dedicated image CDN such as Imgix or Cloudinary, with custom transformation rules and lossless delivery, will serve that workload better. The premium image pipeline is worth the money when the image is the product.

But that is not the average local business site. For a café, an accountancy practice, a trade service business, or an independent retailer, automatic optimisation at the hosting layer is more than enough. It is also included rather than a separate monthly bill.

The Honest Limit

One thing automatic image handling will not fix is a photo that is wrong for the page in the first place. A blurry shot. A photo with bad framing. A picture taken in poor light. The server can shrink it, convert it, compress it, deliver it fast. The server cannot decide your menu photos look unappetising. That is still on the owner.

What This Means in Practice

If your WordPress site feels slow, run this exercise before you blame the host. Open your homepage in Chrome's developer tools. Look at the Network tab. Sort by file size. If the top six files are all images over 500KB, you do not have a hosting problem. You have a photo problem. The fix is either upload smaller photos, install a serious optimisation plugin, or move to a host where the optimisation happens automatically below WordPress.

For the broader picture of what shapes a fast WordPress site beyond just images, our complete performance guide for Irish business owners walks through every layer. And if you want the business case for fixing this in the first place, the cost of a slow site quietly losing customers is already made there.

If you would rather stop wrestling with image plugins entirely, Web60's all-inclusive Irish managed WordPress infrastructure ships with the server stack already configured to handle modern image delivery, so the photos your team uploads stop being the thing that breaks your performance score.

Conclusion

The story of slow WordPress sites is rarely the host, the theme, or the plugins. It is the 6MB photos the business owner does not realise are 6MB. The honest first step is to look at what has been uploaded, and at what the server underneath is set up to do with it. From there the fix is straightforward.

Frequently Asked Questions

How big should a photo on a business WordPress site actually be?

For a typical business website, photos rarely need to be larger than 1,500 pixels wide. File sizes generally sit between 100KB and 300KB for full-width images, and 30KB to 100KB for smaller thumbnails. If you are uploading photos straight from a phone, they are almost certainly five to twenty times too large for the role they are doing on the page.

Will an image optimisation plugin fix my slow WordPress site?

It will help. It is unlikely to be the whole answer on its own. Plugins compress images inside WordPress after the request reaches your server. The biggest performance gains come from server-level image handling, including WebP and AVIF conversion, responsive sizing, and proper cache delivery, which many cheap shared hosts do not configure properly.

What is the difference between WebP and AVIF?

Both are modern image formats designed for web delivery. WebP is older and more widely supported, and is typically 25 to 34 percent smaller than equivalent JPEG. AVIF is newer, supports a wider colour range, and can be roughly half the size of JPEG at equivalent quality, but requires more recent browser and server support. WordPress 6.5 added AVIF support to core, but the hosting environment also needs the right image libraries installed for AVIF generation to work.

Why does my site feel slow on mobile but fine on my laptop?

Two reasons. First, mobile networks are slower and more variable than home broadband, especially outside city centres. Second, mobile browsers have less memory and processing power to render heavy pages. A 30MB page might load in seconds on a fibre connection but stall on a phone with a weak signal. The fix is to reduce page weight at the source.

Does Web60 handle image delivery automatically?

The Web60 WordPress stack is configured to support WordPress's native modern format handling, responsive sizing, and cache delivery at the server layer, so the heavy lifting happens automatically below WordPress instead of inside another plugin. It is included in the €60 per year all-inclusive plan.

Sources