Compressing Wordpress content with Cloudfront - wordpress

I've spent quite a bit of time reading through Cloudfront documentation and updating configurations.
I have Cloudfront pointing to my nginx instance which proxies my Wordpress site. All static assets are getting compressed as expected. However, non static assets such as the index or blog pages are not getting compressed at all.
My presumption was that since the content-length header is not being sent back from the origin in those requests for non-static content (and is for the static content) that Cloudfront would reject compressing those responses as per the documentation.
I'm wondering if my understanding is correct, and if there is any way I can configure this set up to have Cloudfront gzip/brotli compress these pages.
I tried disabling chunking on nginx, enabling and disabling compression on nginx, as well as trying to downgrade from http/2 to http/1.1 or lower in hopes to prevent nginx from chunking the content when Cloudfront requests it.

Cloudfront will not compress again if your origin returns response with header Content-Encodin. You can tell cloudfront to compress objects by mentioning that in cache behaviour , have a read of this document https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html

Related

How to ensure my CDN caches CORS requests by origin?

I currently use Akamai as a CDN for my app, which is served over multiple subdomains.
I recently realized that Akamai is caching CORS requests the same, regardless of the origin from which they were requested.
This of course causes clients that make requests with a different Origin than the cached response to fail (since they have a different response header for Access-Control-Allow-Origin than they should)
Many suggest supplying the Vary: Origin request header to avoid this issue, but according to Akamai's docs and this Akamai community post, this isn't supported by Akamai.
How can I force Akamai to cache things uniquely by Origin if an Origin header is present in the request?
I did some research, and it appears this can be done by adding a new Rule in your Akamai config, like so:
Note that if you do this - REMEMBER - this changes your cache key at Akamai, so anything that was cached before is essentially NOT CACHED anymore! Also, as noted in the yellow warning labels, this can make it harder to force reset your cache using Akamai's url purging tools. You could remove the If block, and just include Origin header as a similar Cache ID Modification rule too, if you were ok with changing the cache key for all your content that this rule would apply to.
So in short, try this out on a small section of your site first!
More details can be found in this related post on Stack Overflow
We have hosted an API on Akamai. I had similar requirement, but we wanted to use the cached response on Akamai for all the touchpoints. But without CORS settings, it used to cache the response from first origin, and then keep it in cache, and the following requests from other touch points use to fail due to cached origin header.
We solved the problem with using API Gateway feature provided by Akamai. You can find it under API Definition. Custom cache parameters can also be defined here. Please see the screen shot for the CORS settings. Now it cached the response from backend and serve to the requester as per the allowed origin list.
CORS Setting in API Definition

Can we use etags to get the latest version of image from a CDN

We have a use case where we are storing our images in a CDN. Let's say we are storing a.jpg in the cache and if the user uploads a newer version of the file, then it will flush the cache and overwrite the a.jpg. Now the challenge is that the browser might have cached the file. Since we cannot flush the cached image in the browser we are thinking of using one of the 2 approaches mentioned below :
Append a version a_v1.jpg, a_v2.jpg (version id is the checksum) this will eliminate the need for flushing the browser and CDN cache. I found a lot of documentation about this on the internet and so many people are using this.
Use the etag of the file to find eliminate the stale cache in the browser. I found that CDN's support etags but I did not find literature that etag is used for images.
Can you please share your thoughts about using etag header for cache busting ? Is this a good practice to use it ?
well i wouldn't suggest etag. This might have its advantage but has its setbacks as well. Say you are running two servers then the etag when content served from each of these servers might change.
Best thing i would suggest is control what the browser is caching and how long.
What i mean is send expiry headers when sending response from cdn to client browser say 5min TTL. This way browser will respect the expiry header. And once expired browser will send a fresh request to cdn when the page is refreshed.

CloudFlare - Multiple requests to origin server during the max-age period

I'm new to CloudFlare and I want to server images through them. (adserver).
Looking at my nginx access logs I'm getting multiple requests per hour.
But in the page-rules I've put:
and doing curl -svo /dev/null https://.... I get the right answer.
If you are wanting CloudFlare to serve and cache images, there's an easier way than using page rules.
By default, CloudFlare will cache static content, which includes images, CSS and JS files.
Knowing this, go to dashboard > domain > caching
The caching level will probably be standard, but read the details from the help dropdown.
Set the browser cache expiration to 1 month and then you are done.
Good luck!

How can I avoid zero-byte files on Cloudfront edge locations?

We've just discovered that one of Cloudfront's edge locations is returning a zero-byte file for one of our javascript assets. The invalidation is running right now, but I'm beginning to think this phenomenon may be the source of widespread but strangely un-reproducible bugs that our customers have been reporting for months now.
We're using Cloudfront with a Custom Origin (Nginx serving static files from an EC2 server). It would appear that with every deploy to our application that introduces new asset names (e.g. changed file version), we have a non-zero chance of one or more Cloudfront edge locations getting a 0-byte file.
Is there any way to avoid this?
Is there any way to detect this?
[sentiment redacted]
There is a very similar problem which has been discussed on the AWS forum. It seems to boil down to your server not sending a Content Length header with your custom origin.
Note the excerpt from the forum, which may be related:
Unfortunately your origin doesn't appear to provide a Content-Length
header. Without a Content-Length header CloudFront can't determine
that a truncated object was received and will cache it. If your origin
can send a Content-Length header any truncated objects will not be
cached. See the Developer Guide for more details.
Try adding the ContentLength header, that should do the trick.

AWS CloudFront, `Vary` header and content negotiation

I'm trying to implement content negotiation based on client Accept headers so that clients that accept image/webp get webp images while clients that don't get plain old jpeg. webp and jpeg image are served from the same url, i.e. /images/foo-image/ and the content returned varies on the Accept header presented by the client. This now works great on my site.
Next challenge is to get this working AWS CloudFront sitting in front of my site. I'm setting the Vary header to Vary: Accept to let CloudFront know that it has to cache and serve different content based on the client Accept headers.
This doesn't seem to work unfortunately, i.e. CloudFront just serves up whatever it first gets it's hands on, Vary and Accept notwithstanding. Interestingly, CloudFront does seem to be able to vary content based on Accept-Encoding (i.e. gzip).
Does anyone know what gives?
It turns out this is documented as not supposed to work:
The only acceptable value for the Vary header is Accept-Encoding. CloudFront ignores other values.
UPDATE: AWS now has support for more sophisticated content negotiation. I wrote a blog post on how to take advantage of this.
Just to update this question, CloudFront now supports caching by different headers, so you can now do this

Resources