Serverless-next.js: Static HTML Pre-rendered pages are not cached in Cloudfront

[krtkeyan]

Describe the bug
Whenever I request for html file inside static-pages, cloudfront hits the origin and returns Miss-From-Cloudfront header. Not sure it was a expected behaviour, hitting origin each time for a static html and having higher TTFB.

To Reproduce
Request for any html inside static-pages, inspect the response header for the html. I have been using out of box solution provided

Expected behavior
Request should Hit cache from cloudfront. These are static pages should be served from edge, shouldn't send each requests to s3 origin.

Screenshots

[danielcondemarin]

@krtkeyan This hasn't been implemented yet, but you are correct, it makes sense for serverless-next.js to do this out of the box.

A solution I have in mind is to:

• Set HTML pages cache control to public, max-age=0, s-maxage=86400, must-revalidate. This will prevent the page from being cached in the browser but using s-maxage CloudFront will cache it at the edge locations for 86400secs (1 day, this is an arbitrary value, maybe could be configurable).

• Create an invalidation request on each deployment. CloudFront supports up to 3000 files being invalidated at once, plus you can do up to 15 invalidation paths that use a wildcard that could be used for dynamic pages.

@thiagozf Recently submitted a PR to add no-store cache control to static pages. CC'ing him as I'm interested to hear his thoughts 🙂

Also, let me know if you want to contribute to this, I'm more than happy to provide any assistance.

[thiagozf]

@danielcondemarin I agree. Vercel's Edge Network works exactly like this. I'm happy to submit a PR. We would need to invalidate all paths (/*) after a new deployment, right? On #421 I was worried about some weird corner-case scenarios, like a client hitting a cached page on CF before the invalidation, then moving to another page that was not cached, but public, max-age=0, s-maxage=86400, must-revalidate should also handle this while using CF effectively.

[danielcondemarin]

@danielcondemarin I agree. Vercel's Edge Network works exactly like this. I'm happy to submit a PR. We would need to invalidate all paths (/*) after a new deployment, right? On #421 I was worried about some weird corner-case scenarios, like a client hitting a cached page on CF before the invalidation, then moving to another page that was not cached, but public, max-age=0, s-maxage=86400, must-revalidate should also handle this while using CF effectively.

@thiagozf A PR would be super appreciated thank you!
In terms of invalidation I think /* is probably OK.
If this turns out not to be viable for whatever reasons, we could just invalidate the static page routes.

[krtkeyan]

@danielcondemarin That's great. I was just thinking of things need to make next.js work in serverless and this package saves me a lot.

I had a another issue thought to mention it. The S3 bucket defaults to us-east-1. Since I am hitting the origin from my edge location in India, I was getting a larger TTFB. When I tried to change my bucket to Mumbai origin, I got access denied when I tried to hit the cloudfront. As far as I can see, only thing I added is a bucketName to serverless.yml which is in mumbai origin. Between, thanks for this great work @danielcondemarin. Myself considering contributing to this while I had time.

[thiagozf]

@danielcondemarin Hey! Created draft PR #435 to handle this issue. Can you review it and let me know your thoughts about the implementation details?

[danielcondemarin]

@danielcondemarin That's great. I was just thinking of things need to make next.js work in serverless and this package saves me a lot.

I had a another issue thought to mention it. The S3 bucket defaults to us-east-1. Since I am hitting the origin from my edge location in India, I was getting a larger TTFB. When I tried to change my bucket to Mumbai origin, I got access denied when I tried to hit the cloudfront. As far as I can see, only thing I added is a bucketName to serverless.yml which is in mumbai origin. Between, thanks for this great work @danielcondemarin. Myself considering contributing to this while I had time.

@krtkeyan I have plans to add another input to the component s3BucketRegion which can be passed to the S3 component as region here. Let me know if you'd like to PR it 👍

[krtkeyan]

@danielcondemarin That's great. I was just thinking of things need to make next.js work in serverless and this package saves me a lot.
I had a another issue thought to mention it. The S3 bucket defaults to us-east-1. Since I am hitting the origin from my edge location in India, I was getting a larger TTFB. When I tried to change my bucket to Mumbai origin, I got access denied when I tried to hit the cloudfront. As far as I can see, only thing I added is a bucketName to serverless.yml which is in mumbai origin. Between, thanks for this great work @danielcondemarin. Myself considering contributing to this while I had time.

@krtkeyan I have plans to add another input to the component s3BucketRegion which can be passed to the S3 component as region here. Let me know if you'd like to PR it 👍

Cool @danielcondemarin . Would love to. I could get some time at the end of this week and would do this.

[danielcondemarin]

This is now available in: [email protected] 🥳 the static pages will be cached for 31 days and invalidated on every deploy. Credits to @thiagozf 🙌