🚀 Feature Request: increase client-side `gzip` compression level

[jkomyno]

Describe the solution

Hi! Alberto from @prisma here 👋🏻

Currently, wrangler deploy seems to be using gzip with the default compression level (6) for compressing a Workers project bundle. In Edge app development contexts with large-ish bundle sizes, the current compression level used by Wrangler can prevent deployments to free tier Workers instances due to surpassing the 1 MiB bundle size threshold by just ~20 KiB.

Of course, we realise that deploying slightly larger projects can have an impact on the allocation of serverside resources you provide. We're fans of Cloudflare Workers, and we're reaching out to assess whether you'd be inclined in supporting this :)

We're ready to provide PRs on our side to increase the gzip compression level of wrangler to 9. Please let us know what you think, thanks!

[penalosa]

Thanks for the issue and associated PR @jkomyno! Unfortunately I don't think Wrangler is the right place to solve this issue—Wrangler gzips your bundle to report the compressed size to the user, but the actual compression of the bundle happens server-side in the Cloudflare API (and that compression is used to determine the 1MB limit).

If at all possible, I'd definitely encourage trying to slim down the size of your worker, which will improve cold start times and general performance (or to use the paid tier, which allows for workers up to 10MB in size).

cc @admah for visibility

[petebacondarwin]

I'm afraid that increasing the compression here in Wrangler will make no difference to the uploaded Worker. In the backend our system computes the size of the Worker using zlib compression at Z_DEFAULT_COMPRESSION level, which according to the docs corresponds to 6.

http://www.zlib.net/manual.html#:~:text=Z_DEFAULT_COMPRESSION%20requests%20a%20default%20compromise%20between%20speed%20and%20compression%20(currently%20equivalent%20to%20level%206).