Generating GZip and Brotli compressed versions of assets about propshaft HOT 5 CLOSED

Thanks, @brenogazzola.

We initially missed this change when migrating from Sprockets to Propshaft and were serving uncompressed assets by default in production with Heroku. We’re now using Rack::Deflate and Rack::Brotli::Deflate to compress responses (without introducing other buildpacks) but wondered if there was a way to restore the build-time compression and let ActionDispatch::Static serve the best version to clients.

Given it seems cheap to do compression on the fly, I can better see why compression is not considered a responsibility of Propshaft.

from propshaft.

Propshaft delegates to CDNs (or NGINX) the responsibility of compressing files.

NGINX has a cost to do compression since it takes CPU time to do compression on the fly, especially if it's maxed out. This is objectively worse than having your digester compress the files for you beforehand, then you can configure NGINX to say the files are already compressed and serve them as they are without compute time.

Tools like Tailwind and esbuild do not compress files either which leaves performing this action up to the user. That means every user will need to invent their own way to do this and also apply it for every deployment. Would it be fair to say this goes against the grain of what Rails tries to provide? Especially so with Rails pushing hard to use import maps and drop front-end toolchains.

Just throwing this out there to maybe reconsider adding compression support.

from propshaft.

In the Propshaft setup, it is the job of the JavaScript/css bundling tool to generate the compressed version of the assets. Propshaft should copy them, and keep the digest, but I don't think it should compress.

Of course the problem is that in the current implementation, Propshaft modify CSS files to change the image paths, the compressed version would be incorrect.

If we implement compression on Propshaft I don't think there is any feature that Sprockets had that Propshaft doesn't have, so I don't see the point of implementing a new library.

from propshaft.

Thanks, @rafaelfranca.

To ensure I understand:

• Ideally, it is the responsibility of the JavaScript and CSS bundling tool to generate compressed versions of assets in app/assets/builds which Propshaft would then copy and digest appropriately

• However, this would break CSS files that load relative URLs, e.g. background images, as they need their paths updating to the digested version (e.g. my-image-8ec6a47d28e43287bbe86c88ca83468d728ac84a.jpg) and Propshaft will not update any compressed CSS files (as they will be opaque .gz and .br files rather than .css which would need decompressing and recompressing)

As for the scope creep of Propshaft vs Sprockets: is there an argument here that this still maintains Propshaft's strict delegation of compiling/bundling assets (viz. you should still use JavaScript and CSS Bundling for Rails to compile your assets with Sass, Tailwind, esbuild, Webpack, etc.) but the compression of copied, digested assets is an acceptable responsibility as it requires knowledge of the final version of the assets, something only Propshaft knows?

from propshaft.

Early versions of Propshaft had brotli compression by default. This was removed when we noticed that CDNs provide this feature on their free plans, and are capable of doing feature detection to decide if they should serve gzip or brotli.

Propshaft delegates to CDNs (or NGINX) the responsibility of compressing files.

from propshaft.