Serverless-next.js: Gzip document

[oste]

Is your feature request related to a problem? Please describe.
When I run watchtower it is suggesting that the main document be gzipped or compressed as seen in this screenshot.

Describe the solution you'd like
Ability to gzip or compress the document root

Describe alternatives you've considered
After a bit of research, I wasn't able to determine if this is even possible with lambad@edge.

[oste]

Here is a forum post https://forums.aws.amazon.com/thread.jspa?messageID=893421

Currently unanswered and points to this guide that seems to only suggest its possible with static pages https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html#lambda-examples-generated-response-examples

[barrysteyn]

Looking at the example, this is essentially zip'ing the resulting content sent back to the client, and ensuring that the correct headers are set for the client to interpret the payload as being zipped. This does not seem to be too difficult to implement, perhaps put it in the lambda handler. What do you think @danielcondemarin

[danielcondemarin]

This should be easy to implement via CloudFront.

Looks like we just need to pass compress: true in the CloudFront defaults:

https://github.com/danielcondemarin/serverless-next.js/blob/master/packages/serverless-nextjs-component/serverless.js#L347

defaults: {
    ...
    compress: true // this should enable gzipped responses 
 }

Also probably need to bump to the latest cloudfront version @6.0.0.

Relevant docs: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html

[barrysteyn]

Interesting, I thought the document was really just "passed through" cloudfront (meaning that there is no caching). I didn't know that one can zip this as well.

BTW: Can you confirm that the document should not get cached.

[danielcondemarin]

@barrysteyn Currently the Server Side rendered pages and api routes are cached for 5 seconds. https://github.com/danielcondemarin/serverless-next.js/blob/master/packages/serverless-nextjs-component/serverless.js#L348

I was hoping that by enabling compression in CloudFront the document would be automatically compressed whenever the client browser supported it but this might not be the case as per @oste's comment https://forums.aws.amazon.com/thread.jspa?messageID=893421

As a starting point I think we should enable compression in Cloudfront regardless. This should at the very least gzip /next/* and /static/*. If it doesn't work for ssr page documents or even api route responses we can do manually do these in the lambda@edge handler like in this example https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html#lambda-examples-generated-response-examples

[barrysteyn]

Yes exactly. The lowest hanging fruits are definitely enabling cloudfront zip compression for the build assets. That should be easy for you to do, right? I will tackle (if you want) the gzip on the handler.

[oste]

Excited that this seems possible. Let me know if I can chip in

[kartikag01]

In cloudfront CacheBehaviors Compress is true but still, the main request to the page is not gzipped.

[Enalmada]

Could would be nice to have a flag which adds a gzip function to the default response behavior...something like this.

As a workaround, consider using Cloudflare as a proxy. It does brotli, http3 and other things. Just remember to enable full ssl encryption to avoid infinite redirects.

[kartikag01]

what if we add another header Content-Encoding in

https://github.com/danielcondemarin/serverless-next.js/blob/af17d7101164fae6eb24cb3ec2d51ebb890a221f/packages/serverless-nextjs-component/next-aws-cloudfront.js#L3

I think that will fix this issue @Enalmada @danielcondemarin

[kartikag01]

@danielcondemarin Hey, I have created PR for gzip response. https://github.com/danielcondemarin/serverless-next.js/pull/272
It's working perfectly for me.

[richardwillars]

^^ was just about to weigh in on how gzipping works across lambdas and cloudfront, but danielcondemarin's implementation is correct. Hope this gets merged asap!

[snowsea-dev]

Any updates?

[danielcondemarin]

I wanted to give an update on this issue as folks may be wondering why I've not merged https://github.com/danielcondemarin/serverless-next.js/pull/272 yet.

I think merging https://github.com/danielcondemarin/serverless-next.js/pull/272 as the project currently stands may be a bad idea. Let me explain why:

1 - Gzip comes with a cost, is not all performance gain as some folks may think. More specifically there is a tradeoff between CPU and Bandwidth. It would be super interesting to see some benchmarks of this in Lambda@Edge using different memory size configurations as AWS scales the lambda CPU as memory increases.

2 - Server Side Rendered pages and API requests have a TTL set to 0 seconds. This is bad news for GZIPping because it would mean we have to gzip on every request to a ssr page or api req. which _will incur in more lambda@edge costs_.

3 - Less important but still worth mentioning, I believe there will be changes coming to Lambda@Edge that may leverage some of this stuff for us, therefore this problem may be mitigated or solved altogether.

Having said all that I can see a LOT of benefit in combining GZIP (or other compression algorithms) with powerful caching policies in the component. I am particularly interested in an approach similar to ZEIT's serverless pre-rendering. I'll keep digging ... watch this space 😎

[hlodver]

If I still want to Gzip the response what is the recommended way to do so?

Some context:
The content is not changing regularly and there are no dynamic changes on the server side. So my plan is to extend the cache TTL settings and use invalidations when needed.

[SarKurd]

@danielcondemarin any info regarding gzip?

[danielcondemarin]

If I still want to Gzip the response what is the recommended way to do so?

Some context:
The content is not changing regularly and there are no dynamic changes on the server side. So my plan is to extend the cache TTL settings and use invalidations when needed.

In that case there is value in gzipping. I’ll try and get the proposed PR merged this week and add some documentation around it how it should be used.

[hlodver]

Having said all that I can see a LOT of benefit in combining GZIP (or other compression algorithms) with powerful caching policies in the component. I am particularly interested in an approach similar to ZEIT's serverless pre-rendering. I'll keep digging ... watch this space

I really love the idea of SPR (serverless pre-rendering) :) This would solve so many issues. It would almost eliminate all invalidations and boost the speed of dynamic pages fetching data from APIs by a lot. Thanks for pointing this feature out, I had not seen it before! I am almost inclined to switch to the Zeit platform :)

[danielcondemarin]

Hi folks! After reading more on gzip I am now convinced it is fine to merge https://github.com/danielcondemarin/serverless-next.js/pull/272 as it is.

This is now available in version @1.9.4. Every next page rendered at the edge, either SSR or API is now gzipped by default 🚀

Thanks to @kartikag01 for the great work 🙏