feat(adapter-node): precompress (gzip & brotli) assets

[sastan]

sirv supports using precompressed assets but they are not generated during the build. This PR allows to precompresses html, js, json, css, svg, and xml assets and prerenderd pages using gzip and brotli during the adapt phase which allows sirv to use these.

It introduces a new option precompress?: boolean to enable to precompression. It defaults to false - i.e. you must opt-in to generate precompressed assets.

This PR adds support for precompressed pre-rendered pages as well.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts

[changeset-bot]

🦋 Changeset detected

Latest commit: 37dc6d9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/adapter-node	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[dominikg]

have you seen this PR that was recently merged? #1672 The discussion mentions how to add precompression with a custom script or other plugins.

If automatic pre-compression was added to sveltekit i think it should be configurable and default to disabled
as it adds significant overhead to the build.

[sastan]

Yes I saw that PR and it is the reason for this PR. I currently use an additional script after the build but I think it would be nice to have it included in the build because precompressed assets are supported during runtime (sirv) but not within the build step.

I agree that it should be configurable and will adjust the PR accordingly.

[dominikg]

There are a lot more options/settings that could be considered when pre-compressing:

• are there other adapters that would benefit from pre-compression
• which files get compressed (filters, extensions, additional files?)
• size limits (min, max filesize to skip compression, omit result if not smaller by X)
• enable br, gz or both
• advanced algorithm options
• zopfli for gzip
• parallelization of compression (max concurrent)
• are there other compression methods that could be useful (eg svgo, png optimization)

This is of course too much to add to adapter node and a simple boolean with sensible defaults is ok imho. What those defaults are and if it should live somewhere else i'm not sure.
Maybe some documentation for how to use custom scripts / plugins would be sufficient too?

other compression plugins:
https://github.com/alloc/vite-plugin-compress
https://github.com/anncwb/vite-plugin-compression

[sastan]

I agree. They are a lot of possible options. I believe a sensible default like proposed in this PR would make sense as it covers the most common case – text file compression using gzip and brotli.

As it is opt-in users could implement their own advanced solution or enable the 80% solution provided by the plugin.

Do you think this PR has a chance of merging?

If that is the case should I add the following?

• files smaller than 1501 bytes are not compressed, since the MTU of a TCP packet is 1500 bytes

[lukeed]

fwiw, i dont think we need to implement a p-map-like throttler

[bjon]

Brotli and GZ don't seem to be enabled for prerendered_handler. Maybe you should fix that as well?

[sastan]

Brotli and GZ don't seem to be enabled for prerendered_handler. Maybe you should fix that as well?

I'll take a look.

[sastan]

Brotli and GZ don't seem to be enabled for prerendered_handler. Maybe you should fix that as well?

Done.

[lukeed]

Just an FYI – it's much harder to follow/track PR updates when you force-push

[sastan]

Just an FYI – it's much harder to follow/track PR updates when you force-push

Sorry. Don't know what I was thinking. You are totally right.

PS Did the last commit just before I read your comment.

[benmccann]

@sastan it looks like this PR will need to be rebased

[sastan]

@benmccann Rebased.