Object Versioning Instead of Cache Invalidation
One of the most common questions we get in WP Offload Media support is something along the lines of …
Why is there a bunch of random numbers in my URLs, and how can I remove them?
The short answer is because WP Offload Media’s Object Versioning setting is turned on by default.
However, this only invites the questions; “Why?”, “What if I don’t want those extra numbers in my URLs?”, and “Is it safe to turn off Object Versioning?”
Let’s answer those questions.
What is Object Versioning?
When WP Offload Media offloads a Media Library item to a storage provider’s bucket, it constructs a “Key” (a.k.a. path) for the files using various settings.
The obvious settings are “Path” and “Year/Month“.
They might give us something like “wp-content/uploads/” and “2020/01/” respectively, meaning a file called “puppies.jpg” uploaded to the Media Library on January 29th 2020 might end up with a key in the bucket like so:
wp-content/uploads/2020/01/puppies.jpg
However, if Object Versioning is turned on, that key might instead be something like:
wp-content/uploads/2020/01/29173059/puppies.jpg
That extra “29173059” segment in the file’s key comes from WP Offload Media’s Object Versioning setting. It’s simply a timestamp, in this case we can tell that puppies.jpg was offloaded to the bucket on the 29th day (of Jan), at 17:30 and 59 seconds.
If that file was then served via a CDN such as Amazon CloudFront using a custom domain (CNAME) of “cdn.example.com”, the final URL seen on a page for that image might be:
https://cdn.example.com/wp-content/uploads/2020/01/29173059/puppies.jpg
If that puppies.jpg was then removed from the bucket, and re-offloaded a few days later, it could end up with a different key in the bucket, such as:
wp-content/uploads/2020/01/04132435/puppies.jpg
Now the Object Version is “04132435”, it has changed because WP Offload Media generates a new version when a file is offloaded to ensure that the object’s key is unique for that file’s re-offload.
Now the image’s URL is:
https://cdn.example.com/wp-content/uploads/2020/01/04132435/puppies.jpg
Because WP Offload Media takes care of rewriting the local URLs for offloaded Media Library items when a site visitor views a page, nothing breaks, the visitor sees the updated puppies.jpg image, unaware that it has been moved to a different path in the bucket.
Why Use Object Versioning?
Why do we do this by default? Why muck about with the URL for an offloaded Media Library item? Why can’t our updated puppies.jpg file be offloaded to the same path every time?
Content Delivery Networks (CDNs), that’s why!
When you use a CDN such as Amazon CloudFront, Cloudflare or KeyCDN, they cache the files they serve for a set period of time, usually somewhere between a day to a year, and don’t refresh the cache until that time is up.
Let’s say you upload a photo of a cute puppy with key wp-content/uploads/2020/01/puppies.jpg, publish, and people visit your post. But shortly afterward you find an even cuter puppy photo. You upload the new one using the Enable Media Replace plugin so the image keeps the same key wp-content/uploads/2020/01/puppies.jpg. Since the CDN has already cached the first less cute puppy, it will continue to serve that one. Your site visitors may not see the cuter puppy for a year!
If you have Object Versioning turned on and replace that puppies.jpg photo, WP Offload Media generates a new key for the file to be offloaded, starts using that new path in all content, and removes the old less cute puppies photo from the bucket.
Because WP Offload Media’s Object Versioning generates a new key for an offloaded file when it is re-offloaded, the CDN sees it as a new file and pulls it into its edge server caches.
The method of avoiding cache invalidation is recommended by Amazon CloudFront:
When you update existing files in a CloudFront distribution, we recommend that you include some sort of version identifier either in your file names or in your directory names to give yourself better control over your content. This identifier might be a date-time stamp, a sequential number, or some other method of distinguishing two versions of the same object.
Why Would We Need to Update the Offloaded File Anyway?
There are all kinds of reasons that you might need to update an offloaded Media Library item and therefore need those CDN edge servers to notice the new file and start serving it.
Maybe you’ve just updated to a new theme that has different image thumbnail size requirements.
You’ve noticed a whole bunch of images were uploaded that hadn’t been optimized for web delivery.
Perhaps Bob has finally got around to providing a more up to date head-shot for the staff index page that you’re eager to use in place of the old creepy one.
That embedded PDF report needs replacing to fix a problem with its formatting.
There’s always even cuter puppies! 😂
Either way, after you’ve used something like the Regenerate Thumbnails, EWWW Image Optimizer or Enable Media Replace plugins to fix up your media, you need your CDN to re-cache and serve the newly offloaded files.
Is it Safe to Turn Off Object Versioning?
No.
Well, if you’re not using a CDN then I guess you’re ok. But honestly, you really should be using a CDN.
And then again, what about the browser cache? If you have repeat visitors and update an important image that you want them to see changes to when returning, Object Versioning will help with that. WordPress has a built in `?ver=x.y.z” param that it adds to deliverables such as CSS and JS files, but that doesn’t extend to media in themes and plugins, let alone in content.
If you offload your media and use Object Versioning you get the ability to emergency update your site visitor’s extremely distributed extended and super localized content delivery network edge location that is their browser!
Is There an Alternative?
No.
Seriously? No alternative?
Not really.
You could use a scheme such as CloudFront suggests for Updating Existing Content Using the Same File Names, and simply set a pretty short Maximum Time To Live in the CDN distribution. The problem is though, objects are given a Cache-Control header equal to one year, and CloudFront will respect that header, believing that the object at that path is good for a year before it should be re-fetched.
You could adjust that Cache-Control header to something much shorter via WP Offload Media’s “as3cf_object_meta” filter by overriding the $args['CacheControl'] value. However, using S3/CloudFront as our example, because each CloudFront edge server situated in different regions now needs to re-fetch any requested object more often, you’ll incur much higher S3 requests costs, even though there are no data transfer costs to CloudFront.
You also no longer have control of when the object is re-fetched, it’s purely based on the interval that CloudFront performs its checks, whereas with Object Versioning the new object has to be re-cached and served on first request by each CDN edge server.
You could I suppose rig up some convoluted mechanism that uses the as3cf_post_upload_attachment filter to trigger an Invalidation of the files path in the CDN distribution. But that is relatively slow, and could get expensive fast seeing as CloudFront gives you just 1,000 free invalidations per month, and then charges $0.005 per invalidation path requested.
You can of course manually invalidate any path in a CDN distribution via the provider’s console. In our doc for how to fix CORS issues with web fonts we show how to invalidate an entire Amazon CloudFront distribution with a path of “/“, but you could invalidate just “/wp-content/uploads/2018/” if you’ve just re-offloaded some Media Library items from 2018.
Besides, it’s pretty clear that CloudFront recommends Object Versioning over Invalidation…
If you’ll want to update your files frequently, we recommend that you primarily use file versioning
Summary
As you can see, by far the easiest and cheapest method of making sure your latest and greatest files are being served as quickly as possible via a CDN is with WP Offload Media’s Object Versioning setting turned on. This is why it is turned on by default and we very much recommend you use it.