-
Notifications
You must be signed in to change notification settings - Fork 160
suggestion: add explanation about the disabled compress
option of server-adapter to workarounds section
#35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Are you unable to compress responses using CloudFront? |
Looks like the original ticket on vercel was closed due to not being reproducible on the latest version. I'll give this a shot. |
@MattFerreira18 do you know the performance hit of not compressing? |
I was able to deploy a successful app w/ compression turned on (default value). I've include the change in #30 |
@Gregory-Ledray Ohh thanks, I didn't know that cloudfront had a option to configure gzip. |
@khuezy sorry but I don't know the performance hit of not compressing in a app using open-next and I can't now create a benchmark with the open-next 😕. But I already saw in other stacks that the gzip is enabled, a small increase of CPU usage in exchange for a reduction more than 10% of the served files size (and consequently reducing the bandwidth usage). |
@MattFerreira18 The CF distribution already encodes the response via Broli. If you look at the response headers, |
There are a couple of issues with compression on CloudFront level:
|
Feel free to reopen if you still have issues |
Hey, what's up everyone?!
Today, when the server-adapter creates a NextJS server, the open-next disables the
compress
option and in the code is mentioned a bug in the bundledcompression
package, this being the cause of the option being disabled.https://github.com/serverless-stack/open-next/blob/265acefeaeac5511cee84089a71d79412a3aad21/src/adapters/server-adapter.ts#L22-L24
With this option disabled, the server don't compress rendered content causing a decrease performance in the network transfers between server to the client.
I would particularly like to see a better explanation and a possible recommendation to make a alternative solution about this in the Limitations and workarounds of readme, to turn this limitation of open-next more evident to other developers that want to use this lib.
The text was updated successfully, but these errors were encountered: