serverless-next.js
serverless-next.js copied to clipboard
serverless-nextjs
Use Cloudfront's new cache policy and origin request policy
Recently AWS added a new way to configure Cloudfront's cache policy, instead of declaring min/max/default TTLs you can create policies (or use predefined ones).
With cache policies we can finally use gzip and brotli compression at the same time (based on accept-encoding header). Brotli is superior in terms of the compression rate, which in end gives us better pagespeed.
Describe the solution you'd like
For start it would be enough to support CachePolicyId and OriginRequestPolicyId as cloudfront inputs. When those parameters are declared, TTLs won't be required anymore.
In the future cloudfront component could take care of creating predefined policies.
Additional context You can learn more about this in AWS reference:
- CachePolicyId: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-defaultcachebehavior.html#cfn-cloudfront-distribution-defaultcachebehavior-cachepolicyid
- OriginRequestPolicyId: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-defaultcachebehavior.html#cfn-cloudfront-distribution-defaultcachebehavior-originrequestpolicyid
And here's the AWS brotli-support announcement: https://aws.amazon.com/about-aws/whats-new/2020/09/cloudfront-brotli-compression/
Ya, this one is in the cards. I think @danielcondemarin is working on it.
However, we are thinking of moving deployment to using CDK to be more maintainable/configurable and solve a couple of pain points, so we wouldn't probably don't want to do too much throwaway work managing cache policies with the existing aws-cloudfront deployment code via the AWS SDK (though it will be kept for legacy purposes). I think the solution you gave should be good enough for now as a temporary solution. @danielcondemarin any thoughts?
Yeah I'm working exactly on this. Should have something ready this week.
I think it would be easy to predefine new cache policies for some of the behaviours we've got as they're fairly static. If ends up being too much effort I'll go with a happy medium until we move over to cdk.
@danielcondemarin Hi, i'm new with this serverless enviroment, first of all it is an amazing tool!
I did some researching about brotli "Specifically compatibility" , and wow, it is incredible!
Benchmark
So i would like to know if, once these features get implemented in the amazing serverless-next.js component
Do i need to take additional steps for activating Brotil compression?
@otekdo you won't need to take any extra steps. Brotli will be enabled by default 🙂
@danielcondemarin We're massively excited about Brotli too, is it likely to make the next release?
Here's a question also if we're using pre-rendered pages we use brotli at the highstest level of compression right(11 or something at the expense of build time)? If so that's a real game-changer.
Here's a question also if we're using pre-rendered pages we use brotli at the highstest level of compression right(11 or something at the expense of build time)? If so that's a real game-changer.
Compression will happen in the CloudFront edge servers not at build time, so build time should remain unaffected 👍
Hi @danielcondemarin, Any update on this?
I started a while back https://github.com/serverless-nextjs/serverless-next.js/pull/783 but haven't had much time lately. I'll happily give some pointers if anyone would like to contribute to it, otherwise might need to wait a bit before I can look into it.
