Documention around deployment may want to recommend compression more strongly for equiv with standard Rails

[jrochkind]

So the documentation around deployment does mention compressing assets. And the linked discussion did work well for me for adding output of gzip and brotli compression.

But I think it could make the case more strongly that if you are migrating an existing app, and aren't totally sure what's going on, you probably want to start with .gzip (and sure brotli) output, for compatibility with other standard rails mechanisms. i think an argument could even be made that vite-rails ought to generate with gzip and brotli output for default.

Let me explain what I understand of what's going on in other Rails paths, to make sure we are on the same page.

Sprockets, webpacker, as well as cssbundling-rails sass, and jsbundlingrails-esbuild -- in standard default configurations, they all produce .gz variants of any produced assets.

If your Rails app itself is delivering assets directly, then the Rails code itself will automatically notice these .gz variants, and respond to a request for simple, eg, https://hostname/assets/application-[fingerprint].js, with a response with content-encoding: gzip and the gzip response. (In cases where client will accept-encoding gzip).

This is the case on heroku for instance -- generally with a CDN in front of your Rails app, but it's the Rails app delivering the response. It may also be the case in any other setup that has a CDN in front of Rails app directly providing assets.

Other people with web servers providing assets may already have them configured to notice the presence of the .gz variant, and return that with content-encoding gzip too -- that's a standard Rails pattern.

Anyone that has any of those setups, everything will work with other standard Rails solutions -- webpacker, sprockets, cssbundling-rails or jsbundling-rails. But will break with vite. I suspect there are some people using vite-rails who don't realize that they are not delivering gzip'd content to their users.

(I noticed when running Lighthouse against my in-progress migration to vite, and comparing to my existing sprockets/webpacker app, to make sure I wasn't introducing any performance regressions -- and noticing this big one!)

I think an argument could be made that vite-rails (at least) should by default install vite with gzip and brotli compression, as the default path, to be turned off if a developer does not want it. This would make it behave consistently with other Rails solutions.

Alternately, I think the language should probably be much stronger in the vite-ruby documentation. That, at least for Rails, if you aren't sure what's going on in your setup, you do want to turn on gzip/brotli compression per the instructions in that discussion, to get consistent behavior with other Rails solutions.

(While other rails solutions don't produce the brotli variant -- I confirmed the Rails app actually will serve a content-encoding: br when it's present, already, automatically! So that's nice).

[ElMassimo]

Hi Jonathan!

I like the idea of emphasizing this in the Deployment section, and adding rollup-plugin-gzip to the Recommended Plugins.

---

Some deployments won't use compressed assets. Adding it by default would add overhead to the build time.

I'd prefer the user to make that decision, as vite-plugin-ruby is used in very different contexts.

---

See the following PR regarding future plans to bring "omakase" to vite_rails:

• feat: create vite-plugin-rails, an opinionated version of vite-plugin-ruby #282

[jrochkind]

Then maybe vite-plugin-rails "omakase" might somehow configure gzip/brotli just for rails?

I get your point, whatever you think makes sense!

But one of the nice things about vite-ruby used for rails in general is it is kind of "just works out of the box without you having to think about it or configure anything" -- the defaults will really do the right thing.

This gzip/brotli thing is one current exception. I checked with a friend using vite-ruby for rails, and they indeed hadn't noticed that their current setup was delivering vite-built assets uncompressed in production. :( This is one case where all the other non-vite solutions "just work" out of the box better.

But definitley just more prominent documentation would be one step. The current documentation sort of suggests to me that you probably don't need it, whereas if you have a rails app that was set up for sprockets/webpacker/jsbundling-rails, you are likely to need it, unless/until you change other parts of your infrastructure to handle it.

[jrochkind]

Although re vite-plugin-rails plan... I don't think I actually need/want any of those plugins, despite using rails! Is it currently meaning to link specifically to https://vite-ruby.netlify.app/guide/plugins.html#environment ? Is that something you think people in Rails need or are likely to want? I don't think I do! I reviewed the list of Recommended Plugins, and for myself decided that I didn't think I needed/wanted any of them, actually, despite being in Rails. (But I'm not yet using stimulus in my Rails app, so). Stimulus is kind of recommended for rails... but tailwind is I think a lot more optional... I would be wary of by default blowing up the size of someone's package for things they might not be using, not sure.

[ElMassimo]

Updated the wording of the Compressed Assets section.

I don't think I actually need/want any of those plugins

I feel the same way when deploying to services that already serve compressed assets, and it's why vite-plugin-ruby won't include rollup-plugin-gzip by default.

Users are responsible for their production deployments.