Image CDN vs Local Compression vs Server-Side Optimization: A Controlled WordPress Test
When it comes to comparing image optimization techniques, most discussions revolve around various features. While those features can be insightful, they often overlook a critical query: Should you generate each image variant on your own site, or would it be better for an image CDN to transform and serve images at the moment they’re requested by visitors?
A controlled test on a live WordPress setup yielded responses that were less straightforward than typical product reviews. The manually precompressed WebP files proved to be the smallest across all test scenarios. Nevertheless, these files didn’t always provide the highest visual fidelity, and they demand more upkeep than other methods.
This guide delves into the payload size, image quality, delivery speed, and operational pros and cons associated with three different approaches. The aim is to assist you in selecting an architecture rather than merely a plugin.
Optimole belongs to the ThemeIsle product family.
The concise answer
There is no absolute winner in this matter. The optimal choice hinges on whether you prioritise having the tiniest prepared file, the least editorial work, or the most straightforward possible infrastructure.
| Method | Ideal for | Key benefit | Main drawback |
|---|---|---|---|
| server-side stack (your WordPress site) | Small or straightforward websites | Fewer components to manage | Produces the largest files in all four tests |
| Precompressed static WebP | Sites controlled by developers with set layouts | Produces the smallest files across all tests | Requires all sizes and formats to be created and maintained |
| Optimole image CDN | Content-rich sites with frequently changing material | Adapts size, format selection, and delivers via CDN | Dependent on cloud resources and less control over encoded files |
Conclusion: Opt for static variants if you can manage a comprehensive image workflow. Select adaptive delivery when the convenience of avoiding that workflow outweighs the need to minimise every byte.
Details of the test
The benchmark utilised two source images already present in ThemeIsle’s media library: a richly detailed photograph and a flat user interface screenshot, complete with text, lines, and expansive blocks of solid colour. Each image was requested at widths of 300 pixels and 1,024 pixels, preserving their aspect ratios.
This set up four combinations of fixture and width, each processed through three delivery methods:
- server-side stack: The image derivative generated by WordPress served from the ThemeIsle site—this means optimization is handled at your server level. Response headers indicated that Cloudflare Polish also optimised this route, meaning it isn’t purely a WordPress core baseline.
- Precompressed static WebP: A static file produced using
cwebp1.6.0 at quality 75, method 6, with precise target dimensions and metadata. - Optimole: The same source was requested at the same dimensions, automatically selecting quality and optimal format. The response was WebP in all measured instances.


Quality assessments involved decoding each delivered file and comparing them with a standard reference at the same dimensions. The test used a structural similarity index (SSIM) to gauge this, which is valuable for rate-distortion comparisons, though not a complete substitute for human review.[7] Minor differences in a photo may still impact the perception of interface text.
Payload sizes were gathered directly from the response body. Remote timing followed five warm-cache requests for each site-stack and Optimole instance. Since precompressed files were encoded locally, they were not included in network timing comparisons.
Test parameters: Timing was collected from a singular runner in Zurich on August 21, 2026. It reflects conditions at that moment for these warm endpoints, rather than global CDN performance.
Test Results
The static WebP path was the victor in terms of payload size. Nonetheless, Optimole consistently provided lower file sizes compared to the current site stack across the board while also maintaining superior SSIM scores for the interface layouts.


Payload findings
| Fixture | Width | Current stack | Static WebP | Saving | Optimole | Saving |
|---|---|---|---|---|---|---|
| Photo | 300 px | 11,246 B | 6,690 B | 40.5% | 7,572 B | 32.7% |
| Photo | 1,024 px | 74,895 B | 39,410 B | 47.4% | 46,778 B | 37.5% |
| Interface | 300 px | 9,615 B | 2,180 B | 77.3% | 8,134 B | 15.4% |
| Interface | 1,024 px | 52,862 B | 13,336 B | 74.8% | 35,288 B | 33.2% |
The statically compressed WebP files showcased a significant size advantage. They reduced the photo payload by 40.5% at 300 pixels and by 47.4% at 1,024 pixels compared to the existing stack. For the interface, the reductions were even greater at 77.3% and 74.8%, respectively.
However, this does not imply that quality matched across the board. The 300-pixel interface file was down to just 2,180 bytes, yet its SSIM fell to 0.9619, while Optimole’s version weighed in at 8,134 bytes with an SSIM of 0.9933. Simply put, the most extreme size reduction also involved noticeable quality trade-offs.
Visual quality assessments
| Fixture | Width | Current stack | Static WebP | Optimole | Highest score |
|---|---|---|---|---|---|
| Photo | 300 px | 0.9382 | 0.9491 | 0.9266 | Static WebP |
| Photo | 1,024 px | 0.9616 | 0.9606 | 0.9565 | Current stack |
| Interface | 300 px | 0.9800 | 0.9619 | 0.9933 | Optimole |
| Interface | 1,024 px | 0.9824 | 0.9832 | 0.9941 | Optimole |
In terms of quality outputs, static WebP exhibited the highest score for the smaller photo, while the current stack marginally surpassed for the larger photo. Optimole excelled in both interface scenarios. It is essential to note that varying quality metrics were employed: a fixed quality setting for static WebP against an automatic quality selection for Optimole. These scores are simply observations and do not suggest that the two encoders were calibrated identically.
Warm-cache timing
| Fixture | Width | Current stack median TTFB | Optimole median TTFB |
|---|---|---|---|
| Photo | 300 px | 46.6 ms | 31.9 ms |
| Photo | 1,024 px | 44.9 ms | 32.9 ms |
| Interface | 300 px | 44.5 ms | 31.9 ms |
| Interface | 1,024 px | 53.6 ms | 32.7 ms |
In every warm-case scenario, Optimole recorded a lower median time to first byte. This information can serve as valuable diagnostic evidence, but it shouldn’t solely dictate your decision-making. Factors such as geography, cache state, origin behaviour, and routing within the network can influence results.
How to evaluate your own images
A benchmark becomes significant when it mimics the images and workflows on your own site. Simply reproducing the figures above wouldn’t accomplish that. Follow a similar structure, but replace the images with those from your own media library.
- Select a variety of image types: Include at least one detailed photograph, one text-rich interface image or diagram, and, if applicable, one transparent graphic. A format that performs well in landscapes may not suffice for fine text or could mishandle transparency.
- Match rendered dimensions: Ensure that you are comparing outputs at the width and height displayed in the browser, preserving the crop and aspect ratio. If this isn’t maintained, the test might favour smaller images rather than assessing better delivery pathways.
- Document the delivered file: Capture the final URL, content type, decoded dimensions, response bytes, and pertinent cache headers. Opt to use browser developer tools for this, as they provide more reliable information than a plugin dashboard regarding what was sent across the network.
- Assess quality separately from size: Examine each output at standard size and zoom in on edges, gradients, and text. While an automated score might identify discrepancies, a manual review ought to determine whether those differences are acceptable.
- Disentangle cold and warm timing: On-demand services may perform additional work on the first request and then serve subsequent requests from cache. It’s best to assess each condition multiple times and label them clearly. Testing from diverse relevant regions is preferable to treating a single location as universal.
- Calculate workflow costs: Account for the time necessary to create new variants, update markup, manage format fallbacks, invalidate caches, and instruct editors. This maintenance estimate should be included alongside byte savings, rather than in isolation.
Store the resulting worksheet with your site documentation. If your theme, CDN, or image plugin changes, the same fixtures can indicate whether the delivery has improved or regressed unnoticed.
Understanding Each Approach
1. server-side: Your WordPress Site Architecture
WordPress auto-generates multiple image sizes, adding srcset and sizes attributes to the image markup. This setup enables the browser to select a suitable derivative for its viewport.[1] This foundation adeptly manages responsive delivery without requiring editors to manually create every thumbnail.
On the tested site, the procedure didn’t end within WordPress. Cloudflare Polish optimised the public derivative before delivery. This makes the baseline practical for this specific site, yet not universally applicable to all WordPress installations.
This method is appealing when images are reasonably sized and traffic levels are low. It introduces a new image service, supplementing the existing infrastructure of the site. However, WordPress’s registered sizes may not match every rendered container, leading to the largest payloads among the three methods tested.
2. Precompressed Static WebP
The manual option prepares precise image variants prior to a visitor’s request. A developer can specify dimensions, format, encoder, quality, metadata policies, and filenames, and can then reference these files using picture or srcset markup.
This meticulous control accounts for the payload advantage, but also creates maintenance responsibilities. A design update might necessitate new target sizes. Adjusting an image would require generating a fresh set of outputs, while browser format fallbacks necessitate thoughtful markup. Any shortcuts in this pipeline could result in oversized images later.
This remains an excellent choice for a static marketing website, a meticulously controlled theme, or for build processes that already produce responsive assets. For a broader selection of WordPress plugins that manage more of the workload internally, refer to the comparison of WordPress image optimisers.
3. Optimole Image CDN
Optimole moves transformation tasks to a cloud-based service and delivers the results via its CDN.[2] Rather than retaining a manually prepared set, the service can create an output customised for requested dimensions and cache it close to visitors.
The best-format selection can cater to browser compatibility, delivering WebP or AVIF where appropriate.[3] The original image remains hosted on the WordPress site unless the optional offloading feature is activated.[4] This allows for the disabling of delivery and switching back to local originals while still depending on the cloud for the service to operate.
The practical benefit is operational: editors can upload images in their original form while the service customises variants and manages delivery. The benchmarks illustrate the cost of this convenience. While Optimole produced smaller files than the current stack, the precompressed static encoder produced smaller files in every scenario tested.
The free plan allows for up to 2,000 visits per month with no meter on the number of images.[5] Each visit counts as a unique visitor daily, which differs from a pageview.[6]
Selecting the Right Approach
Opt for Static WebP When Control is Economical
Choose the static route when your design features a known set of image slots and you have someone overseeing the build pipeline. This option is particularly compelling for a limited number of high-traffic landing pages, where even marginal data reductions on repeated assets can be impactful and where each output can undergo visual assessment.
However, don’t select this method solely because it resulted in the smallest files here. The approach becomes costly when numerous editors begin adding new images, themes are frequently altered, or responsive variants fall out of synchronization. The actual image files may be minimal, while the surrounding processes may become troublesome.
Consider an Image CDN with Frequent Content Changes
Think about adaptive delivery when high editorial volume and diverse devices render a managed variants pipeline more practical. News portals, e-commerce sites, and multi-author WordPress platforms often face this scenario, given the constant influx of new uploads and the challenge of ensuring manual variant coverage. An offering like Optimole transforms this recurring task into a request-driven operation.
The trade-off involves dependency: delivery, quotas, cache behaviour, and transformation rules are dictated by an external service. Sites with stringent data-location criteria or established asset workflows might favour localized control. For evaluating offloading storage as part of your decision, refer to the guide on hosting WordPress images externally which elaborates on this additional layer.
Preserve the Current Stack When Issues Aren’t Confirmed
A small promotional website featuring a limited number of appropriately sized images might not require an additional service or custom encoding pipeline. Evaluate actual image dimensions, payloads, and performance metrics from real users prior to complicating the architecture.
Remember that image delivery only represents one facet of page performance. Variables such as fonts, scripts, server response, caching, and layout stability may significantly influence overall results. For a broader analysis, the Core Web Vitals guide offers important diagnostic insights.
Five Pitfalls That Can Nullify Your Gains
- Comparing Different Dimensions: A 300-pixel image should not be hailed for outperforming a 1,024-pixel one. Verify decoded dimensions, not just the URLs.
- Layering Optimisers Without Validating Outputs: A plugin, hosting provider, proxy, and CDN may all impact the same image. The current baseline revealed this issue since Cloudflare Polish modified the WordPress derivative.
- Employing a Single Quality Setting for All Image Types: Photographs can disguise compression artifacts that can make text and line graphics appear blurry. Scrutinise both photographic and flat graphic outputs.
- Blindly Lazy-Loading the LCP Image: The principal above-the-fold image requires different treatment compared to gallery images. Optimole’s own guidelines highlight hero and LCP sizing as cases needing careful configuration.[8]
- Measuring Cold Transformations Just Once: First-time processing and warm delivery answer different queries. Record cache conditions and repeat assessments frequently.
Practical tip: Always check the final URL, content type, decoded dimensions, payload, and a zoomed visual check. A dashboard endorsement cannot verify that the browser received the appropriate file.
Final Verdict
The benchmark does not anoint a singular image architecture suitable for every WordPress site. It highlights the costs accompanying each convenience type.
- Static WebP offered the least payload across all scenarios, establishing it as the prime selection when precise variants and ongoing maintenance are integral to the workflow.
- Optimole decreased bytes against the current stack in each instance, excelled in interface quality assessments, and alleviated much of the work involved in adaptive delivery.
- The existing stack continues to be the simplest option, yet it resulted in the largest file sizes within this controlled analysis.
For a heavily editorialised WordPress site, contemplate using an image CDN where its data limits, storage location mandates, and external dependencies align with your operations. For a developer-controlled fixed design, precompressed variants might yield leaner results. The best approach is the one that incurs reasonable maintenance costs half a year later.
What image delivery path suits your site? Please share your thoughts in the comments below!
References
FREE GUIDE
4 Essential Steps to Boost Your WordPress Site Speed
Follow our straightforward steps in this four-part mini series to decrease your loading times by as much as 50-80%.
Congratulations! You’ve reached the end of the article!
Share this content:
Discover more from Qureshi
Subscribe to get the latest posts sent to your email.

