This will be long, but I’ll probably pin this so that others can see my position on full offloading, why it’s not perfect with Cloudflare Images and how I see the future of the plugin.
With offloading, if you want to physically move the files away from the server – the safest option is one that allows you to have a one to one file mapping. For example, AWS S3 or Cloudflare R2 do this. The reason why Cloudflare Images are not great for offloading, is because it transforms the images in a way that it becomes complicated to track the mapping between the original vs offloaded.
Let’s use your example:
example.com/wp-content/uploads/buddypress/groups/5/cover-image/67068ba17ca38-bp-cover-image.webp
When it is offloaded to Cloudflare R2, it is accessible via a custom mapped domain on R2:
<custom domain>/wp-content/uploads/buddypress/groups/5/cover-image/67068ba17ca38-bp-cover-image.webp
Besides the domain, the URLs are identical. It’s very easy to do a search and replace on the site and switch over back and forth. If you wanted to restore the image, you’d just download it.
Cloudflare Images, on the other hand, will use unique IDs and make the mapping extremely difficult. The default offloaded image URL will look something like this:
https://imagedelivery.net/baIq1hwqwNPaTgiq1wy2LA/22d036a9-70cb-4151-a1a8-465c184e4200/public
This is especially a big issue for the WordPress media library, because the images have different attachment sizes, and if at some point the plugin is not able to “parse” the page and find an image – you’ll get a 404. Moreover, there are various limitations on image sizes.
I have attempted to mitigate this by using custom paths instead of IDs (you can already toggle this feature on in the plugin settings), which will convert URLs to a better suited format for offloading, which looks something like this:
https://imagedelivery.net/baIq1hwqwNPaTgiq1wy2LA/example.com/2024/01/image.jpeg/public
Still not ideal, but much better. I have taken this even further, and created a service that will create a Cloudflare worker that will convert the URL to something like this:
https://example.com/images/example.com/2024/01/image.jpeg/public
Yes, the double example.com is not a mistake – Cloudflare Images don’t have a folder structure, so images need to be prepended with the origin domain name to be able to identify it (another issue, which I have solved in the plugin).
But even with all this, the problem with various attachment sizes has not yet been resolved (when WordPress generates a bunch of smaller images for the original). I thought about moving away from flexible variants and use physical ones, which Cloudflare definitely allows. But at the time of initial development, the variants were capped at something like 20 (don’t remember the exact number), point is – it wouldn’t have been enough for a lot of the sites. The other problem with variants is that flexible variants allow dynamic resizing, which in some cases allows the plugin to serve exactly the image size that is required by the browser. No other plugin on the market is able to do this (don’t quote me on this). That’s why I’m hesitant to switch away from flexible variants.
However, flexible variants also have drawbacks – the image is cached only for an hour, which is visible on some page loads, where an image takes its time to appear on the page, and some users have reported this, which, unfortunately, I can’t address as it’s a Cloudflare limitation.
Ideally, at some point I want to add an option that allows the user to setup either flexible variants or the normal ones, or add support for Cloudflare R2. But all this takes time.
Hope this explains everything. And to answer your question on which plugin to use, sorry that it’s buried under a wall of text, use the one that you have access to. They all do pretty much the same thing packaged under a different brand.
Best regards,
Anton
