How can I reduce slow image loading on a WordPress website?

Question

I’m working on a WordPress website with quite a few images on the main pages. I’ve already compressed the images and converted some of them to WebP, but the pages can still feel slow when they first load, especially on mobile.

I’m trying to figure out whether the problem is mainly coming from the website itself or the hosting/server configuration.

I’ve checked the site with a speed-testing tool and noticed that the initial response takes some time before the page content starts loading. The images also seem to load one after another rather than appearing quickly.

The website is RentCrown, and I’m considering moving it to a DigitalOcean Droplet. However, I don’t want to move it and then discover that the real problem is poorly optimized WordPress or image delivery.

For a relatively small WordPress website, what would you check first to identify the bottleneck? Would you look at server response time, PHP configuration, caching, CDN, or something else?

I’m managing the website myself, so I’d like to understand what’s actually causing the slowdown before making a hosting change.

KFSys · Answer

Hi there, You’re asking exactly the right question, and I think the answer is going to make you feel good about the move — but for a different reason than you’d expect. It’s not that your server is slow . It’s that it’s inconsistent , and that’s a problem you can’t optimise your way out of on shared hosting. I ran some measurements against the live site. Here’s what I found. ## The measurement that settles it I hit your homepage 12 times — same cached URL, same connection, back to back — and hit digitalocean.com 12 times in the same moment as a control, to rule out my own network: min median max spread std dev rentcrown.com (shared host) 0.327 s 0.382 s 2.622 s 8.0× 0.644 digitalocean.com (control) 0.090 s 0.098 s 0.124 s 1.4× 0.009 Raw numbers for your site: 1.158 0.327 0.335 0.749 0.414 0.349 2.622 0.361 0.403 1.069 0.332 0.359 Look at that spread. Your median is a respectable 0.38 s — but one in four requests took over a second , and one took 2.6 s. Same URL, same cached page, no code difference between them. The control proves it isn’t my connection: DigitalOcean’s std dev across the same window was 9 milliseconds . Yours was 644 ms , seventy times higher. That is the classic signature of CPU contention on shared hosting — noisy neighbours. Your site is fine when it gets a time slice and stalls when it doesn’t, and you have no control over which it gets. This is also why the slowness feels random and hard to pin down: you’re not measuring your site, you’re measuring whoever else is on that box. No amount of WordPress optimisation fixes this. You could get your PHP render to 50 ms and still eat a 2.6 s stall when a neighbour spikes. This is a hosting problem, and dedicated resources are the actual fix. So yes — move. ## What the Droplet genuinely gets you Concretely, against what I measured: Predictable TTFB. Dedicated vCPU means your p95 stops being 6× your median. Honestly this matters more than the median: users forgive a consistently okay site, they bounce off one that randomly hangs. A faster floor. Your uncached PHP render is ~1.0–1.3 s right now. With OPcache properly sized, Redis object caching, and tuned PHP-FPM workers, a small WordPress site like yours should land at 200–300 ms . That’s a 3–4× improvement on the dynamic path. Redis object caching at all. This is the big one people underestimate. WordPress hammers the options table and plugin queries on every request; a persistent object cache collapses that. Shared hosts usually don’t give you Redis, or give you a crippled version. On a Droplet it’s apt install redis-server plus a plugin. Control over the whole stack — which, as you’ll see below, is exactly what you need to fix your remaining front-end issues properly. For a site your size: a 2 GB / 1 vCPU Premium Droplet is plenty, and gives you headroom to grow. Premium (NVMe + newer CPUs) is worth the few extra dollars over Regular for a database-backed site. Region: there’s no Middle East region, so BLR1 (Bangalore) or FRA1 (Frankfurt) are your realistic picks — Bangalore is physically closer to the UAE. But see the Cloudflare point below: once HTML is cached at the edge, origin location stops mattering much for most visitors, so don’t agonise over this. The 1-Click WordPress image on the DO Marketplace gets you a sane LEMP stack out of the box rather than building it by hand — worth using unless you specifically want to configure it yourself. ## Set it up so you actually get the benefit A few things to do during the migration, because they’re much easier on a Droplet than where you are now: 1. Turn on edge caching at Cloudflare. You already have Cloudflare in front of the site, but it’s caching nothing: cf-cache-status: DYNAMIC cache-control: public, max-age=0 DYNAMIC means every request goes all the way to origin. Add a Cache Rule that makes HTML eligible for cache , with bypasses for wordpress_logged_in* / woocommerce_* cookies and /wp-admin/*, /cart*, /checkout*. Pair it with a plugin that purges on publish. This is free, takes about half an hour, and combined with the Droplet it takes most visitors to a ~40 ms TTFB globally. Do it as part of the move. 2. Add Redis + OPcache from day one. Don’t migrate and then wonder why it’s only a bit faster. redis-server plus the Redis Object Cache plugin, and bump opcache.memory_consumption to 256 MB. 3. Consider Spaces + CDN for your media. Offloading /wp-content/uploads to DO Spaces with its CDN keeps image serving entirely off the Droplet’s CPU and disk. Your images are already well optimised (more below), so this is about isolation rather than compression — your PHP workers stop competing with image requests. 4. Set up snapshots and monitoring. A weekly snapshot and a DO Monitoring alert on CPU > 80% gives you the safety net shared hosting was implicitly providing. ## Two things to fix regardless — they’d follow you to any host I want to be straight with you here, because you specifically said you didn’t want to move and then discover something else was wrong. The migration fixes your server. It does not fix these, and they’re a real part of what makes it feel slow on mobile: Your pages inline 189 KB of CSS and JS. The homepage carries 143 KB of CSS across 17 <style> blocks and 46 KB of inline JS across 28 blocks , with zero external stylesheets — a “combine and inline everything” plugin setting. That CSS can’t be browser-cached, so returning visitors re-download all of it every page, and the browser must parse the lot before it paints anything. On a mid-range Android that’s hundreds of ms of main-thread work that a faster server cannot touch. Switch the plugin from “inline all CSS” to critical CSS + deferred external stylesheet . Same first-paint benefit, but the bulk becomes cacheable. Your HTML should drop from 360 KB to under 100 KB. This is genuinely easier on a Droplet where you control the cache layer instead of fighting a shared host’s. 37 of your 57 images load eagerly. Only 20 carry loading="lazy", so everything below the fold downloads immediately and competes for mobile bandwidth with your hero image — which is precisely the “images load one after another” symptom you described. Something (usually a slider or page-builder module) is stripping the lazy attribute. Also: your fetchpriority="high" is currently sitting on a data:image/svg+xml placeholder rather than your real LCP image (birthday-party-planner-dubai.webp). Move it. And your logo is a 35 KB PNG at 350×350 referenced twice — convert to WebP. ## The good news on images Your compression work paid off, so stop worrying about this part: 25 unique images, ~431 KB total , nearly all WebP. That’s lean. cache-control: public, max-age=31536000 — correct. Brotli on, HTTP/2 with HTTP/3 advertised, PHP 8.3.31. Your image delivery is genuinely not the problem. The instinct that made you check it first was reasonable, it just isn’t where the time is going. ## Suggested order Provision the Droplet — 2 GB Premium, BLR1 or FRA1, 1-Click WordPress. Migrate with Redis + OPcache configured from the start , not bolted on later. Add the Cloudflare Cache Rule for HTML during the cutover. Fix the CSS inlining and the lazy loading once you’re on the new stack and can actually control it. Re-run the variance test below and compare. ## How to verify the win Run this before and after — it’s the same test I used, and the spread is the number to watch, not the average: for i in $(seq 1 12); do curl -s -o /dev/null -w "%{time_starttransfer}
" https://rentcrown.com/ done On shared hosting you’re seeing 0.33–2.62 s. On a properly configured Droplet you should see a tight band with a much smaller max. Also watch this flip from DYNAMIC to HIT once the Cloudflare rule is live: curl -sI https://rentcrown.com/ | grep -i cf-cache-status To answer your original question directly — server response time is your real bottleneck, but it’s the consistency of it rather than the raw number, and that’s a hosting problem you’ve correctly identified. The move is the right call. Just do the CSS and lazy-loading cleanup too, so you get the full benefit instead of half of it. Hope that helps, and good luck with the migration.

alexdo · Answer

Hi there, One small correction worth flagging on the stack details: the current DigitalOcean WordPress 1-Click Droplet doesn’t actually run Nginx. Per DigitalOcean’s own Marketplace docs, the image ships with Caddy as the web server and reverse proxy (with automatic HTTPS), PHP 8.3-FPM, MySQL 8.0, and WP-CLI, rather than the classic LEMP stack. Functionally it gets you to a similar place, and everything else above, Redis, OPcache, the Cloudflare Cache Rule, applies the same way regardless of which web server is in front. The one place it matters practically is if you go looking for Nginx-style page caching (fastcgi_cache) after the migration. There’s no /etc/nginx to configure, since Caddy’s config lives in a Caddyfile instead, and Caddy doesn’t have a built-in FastCGI cache directive the way Nginx does. For a site this size that’s not really a gap though, since the Cloudflare Cache Rule KFSys already recommended handles full-page caching at the edge for your anonymous visitors, which is most of your traffic anyway. Just worth knowing before you go hunting for config files that won’t be there. Regards

Mark Johnson · Answer

When optimizing the Bodyworks Bahrain website , I checked TTFB first—if it’s high, review caching, plugins, PHP, and server resources before migrating. Then lazy-load below-the-fold images, preload only the hero image, and serve properly sized WebP files through a CDN.

Become a contributor for community

DigitalOcean Documentation

Resources for startups and AI-native businesses

The developer cloud

Start building today

Report this

How can I reduce slow image loading on a WordPress website?

Related questions

Best way to configure Nginx caching for a WordPress site on a DigitalOcean droplet?

How can I improve the loading speed of my WordPress travel website?

Problem on wordpress Digital Ocean Droplet One-Click

Website redirecting to another site on same droplet after moving droplets

Load and CPU Spikes

What’s the best way to secure a DigitalOcean Droplet running WordPress against brute-force attacks?

How to update PHP version to 8.3 on a droplet?

New cloud hosting solution

how to access droplet console for wordpress 1click install

Move DigitalOcean WP site to another DigitalOcean WP site

How do you set up a development and test server for staging production server changes?

We have around 20 WordPress websites. Which plan would be good?

Report this

How can I reduce slow image loading on a WordPress website?

Related questions

Best way to configure Nginx caching for a WordPress site on a DigitalOcean droplet?

How can I improve the loading speed of my WordPress travel website?

Problem on wordpress Digital Ocean Droplet One-Click

Website redirecting to another site on same droplet after moving droplets

Load and CPU Spikes

What’s the best way to secure a DigitalOcean Droplet running WordPress against brute-force attacks?

How to update PHP version to 8.3 on a droplet?

New cloud hosting solution

how to access droplet console for wordpress 1click install

Move DigitalOcean WP site to another DigitalOcean WP site

How do you set up a development and test server for staging production server changes?

We have around 20 WordPress websites. Which plan would be good?