Image optimization plugins are one of the most popular categories of WordPress plugins. ShortPixel, Imagify, Smush, EWWW Image Optimizer, and Kraken.io collectively have tens of millions of installations. They are widely recommended, broadly reviewed, and genuinely useful. They compress images, convert to WebP, strip metadata, and resize large originals. For many sites, installing one of these plugins is the first performance improvement that produces a visible PageSpeed score change.
The problem is that most WordPress site owners treat image optimization as the complete solution to their image performance problem rather than one layer of a complete solution. After installing ShortPixel and converting everything to WebP, they check PageSpeed Insights, see the score went from 45 to 58, and conclude the image problem is solved. Then they are confused when LCP is still 3.8 seconds, when their hosting storage warning emails keep arriving, and when migrations are still slow.
Image optimization addresses one layer of the image stack: the file itself. It does not address where the file is stored, how it is delivered, or what TTFB the server serving it produces. This guide explains the complete image stack, what each optimization plugin addresses, and what the offload layer addresses that optimization plugins cannot touch.
The complete image stack: four layers, four problems
A complete WordPress image optimization stack has four distinct layers. Each layer addresses a different aspect of image performance. An optimization plugin operates on Layer 1. Offloading to FTP with CDN delivery operates on Layers 2, 3, and 4. Understanding the separation makes it clear why each is necessary and why neither alone is sufficient.
This layer is about the file itself: how many bytes it contains, what format it uses, and whether its dimensions are appropriate for its display context. Compression reduces bytes by 60 to 80% without visible quality loss. WebP conversion reduces bytes by a further 25 to 35% compared to JPEG at equivalent quality. Dimension scaling prevents a 4000px wide image from being served to a 400px wide display context.
After an optimization plugin compresses and converts your images, those optimized files still live on your hosting server’s disk. The hosting server still accumulates inodes. The hosting server’s uploads directory still grows. Backups still take hours. Migrations still include all the files. An optimized 50KB WebP file still occupies one inode and still contributes to the backup archive. Optimization does not move files.
This is the layer that determines LCP. When a browser requests an image, the TTFB of that request depends on which server responds. A compressed WebP image served from a shared hosting server has a TTFB of 200 to 600ms. The same compressed WebP image served from a CDN edge node has a TTFB of 10 to 25ms. The file is identical. The difference is entirely which server the request goes to. Image optimization has zero effect on which server responds.
Even a fast hosting server in US-East has 80 to 150ms of network latency for visitors in Europe or Asia-Pacific, purely from the physical distance that data must travel. A CDN with edge nodes in Frankfurt, London, Singapore, and São Paulo reduces this to 5 to 20ms for visitors in those regions. Image optimization has no effect on network latency. Only changing where the image is delivered from affects this layer.
Why LCP still fails after optimization: the numbers
To understand exactly why a well-optimized image can still produce a failing LCP, let us trace the full LCP timeline for two scenarios: an optimized image on a hosting server, and the same optimized image served from a CDN.
The calculation above uses ideal conditions: a fast server with low concurrent load, a visitor on broadband in the same region as the hosting server. In the real world, the same page measured by Google’s CrUX data captures the 75th percentile across all real visitors including mobile users, international visitors, and visitors hitting the server during peak load. For those visitors, the image TTFB from a hosting server is not 420ms — it is 600ms, 800ms, or more. The CrUX LCP for the same page is 3.4 seconds even with the optimized image because the 25% of visitors on slower connections or in distant regions are dragging the 75th percentile above 2.5 seconds.
The four scenarios tell the complete story. The biggest LCP improvement comes from switching delivery from hosting server to CDN edge — this changes image TTFB from 420ms to 18ms, a 95% reduction. Compression then reduces download time from 1,400ms to 65ms, which is a meaningful further improvement. Both matter. But the CDN move is the larger lever, and it is the one that optimization plugins cannot pull.
What optimization plugins claim to do with CDN — and the reality
Some image optimization plugins include a CDN delivery feature as part of their premium plans. ShortPixel has an Adaptive Images CDN. Imagify has an option to serve images from a CDN. Jetpack Boost includes image CDN functionality. These features are worth understanding carefully because they address some of the delivery problem while introducing their own constraints.
They serve your images from edge nodes, reducing TTFB significantly. They often include real-time format conversion (serving WebP to supporting browsers, AVIF to supporting browsers) without requiring you to pre-generate those formats. They can handle responsive image sizes dynamically. For sites that want the simplest possible setup, a plugin with built-in CDN is a legitimate all-in-one option.
They do not move the images off your hosting server. The original files still live on the hosting server’s disk. The hosting server still accumulates inodes. Backups still include all the files. The storage warning problem persists. They serve images from CDN but the origin remains the hosting server — so the CDN is pulling from the same server you are trying to relieve of image serving. And their pricing includes a per-image processing credit model that can become expensive for large libraries.
Plugin CDN is right when: you want a single plugin to handle compression, format conversion, and delivery; your library is small enough that credits are not a cost concern; storage accumulation on the hosting server is not a problem you are trying to solve. FTP offload is right when: you need images physically removed from the hosting server; your library is large and growing; backup size and migration time are real problems; you want flat-rate predictable infrastructure cost.
How to combine optimization and offload correctly
The correct approach is to use both optimization and offload, with the right tool for each layer. Here is the workflow that produces the best results from both.
Compress and convert to WebP using ShortPixel, Imagify, EWWW, or your plugin of choice. This handles Layer 1. Do this before setting up FTP offload so that the files transferred to FTP are already optimized, minimizing FTP storage usage.
Once you configure WP FTP Media’s CDN URL rewriting, having the optimization plugin also attempt to rewrite URLs creates conflicts and double-CDN situations. Disable the CDN feature of the optimization plugin while keeping its compression and WebP conversion active.
This handles Layers 2, 3, and 4. Files move to FTP (Layer 2 — storage location). Image requests go to CDN (Layer 3 — delivery origin). CDN edge nodes serve images close to visitors (Layer 4 — geographic proximity).
Going forward, new uploads are automatically optimized by the plugin (Layer 1) and then automatically transferred to FTP by WP FTP Media (Layers 2, 3, 4). The workflow is: upload to WordPress, plugin compresses, WP FTP Media transfers to FTP, URL rewriting serves from CDN. All four layers handled automatically for every new image.
Do you still need an optimization plugin after implementing FTP offload?
Yes, for two reasons.
First, compression and WebP conversion genuinely reduce LCP download time, as the four scenarios above show. Even with CDN delivery reducing TTFB to 18ms, a 800KB image takes 650ms to download versus 65ms for an 80KB WebP equivalent. Both improvements compound. Implementing CDN delivery without optimization leaves 580ms of improvement on the table per image request.
Second, smaller optimized images reduce CDN storage and delivery costs. BunnyCDN charges per GB delivered. An unoptimized library transfers 10x more data than an optimized one for the same number of image requests. The combination of optimization and CDN delivery provides both the performance benefit and the cost efficiency that neither alone fully achieves.
According to Google’s LCP optimization guide, the two largest contributors to LCP failure are TTFB and resource load duration. TTFB is addressed by CDN delivery (FTP offload). Resource load duration is addressed by file compression (optimization plugin). The complete stack requires both. WP FTP Media’s WordPress image infrastructure completion plugin provides the delivery and storage layers that image optimization plugins cannot, completing the stack that starts with compression and WebP conversion.
Your optimization plugin did the easy part. Here is the part it could not do.
WP FTP Media handles the three layers your ShortPixel or Imagify plugin cannot: moving images off your hosting server, routing delivery through CDN edge nodes, and serving images from geographic locations close to your visitors — completing the image stack that optimization alone leaves unfinished.
Got this for my friend's blog, but the inode problem is still hanging around. Compression helps, but his host keeps nagging about storage limits. Offload might work, but now I'm not sure he even needs ShortPixel at all
Got this after struggling with slow load times. My images were optimized but LCP was still terrible
I've been using image optimization plugins for years and always wondered why my LCP scores never quite hit where I wanted them, even after compressing everything. This guide finally made it all click for me turns out, just optimizing images isn't enough if they're still slowing down your server
Finally got my LCP under control!