Run puma plugin in debug mode

[bogdan]

As far as I understood, puma plugin is only designed for development, so it makes sense to avoid CSS minification in this env.

tailwindcss-rails/lib/tailwindcss/commands.rb

Line 16 in 08486ae

command << "--minify" unless (debug || rails_css_compressor?)

[flavorjones]

Would the TAILWINDCSS_DEBUG environment variable from #504 meet your needs here?

I would prefer not to have the default behavior in development change depending on whether you ran rails server or rails tailwindcss:build.

[bogdan]

Would the TAILWINDCSS_DEBUG environment variable from #504 meet your needs here?

Yes, it is fine.

I think the correct way to make rails tailwindcss:build behave consistently.

I am not a big fan of env variables to configure rails app because there are separated dev, test and production environments.
Most rails options don't support ENV variable on top.
So I think ideally, it should be configurable via config.assets.css_compressor or maybe other option.

I was initially trying to configure it like that, but it didn't work. I understand that it might be different subsystems that control compression in tailwind and in pipeline, but I don't want to know about it if it can just work.

[flavorjones]

make rails tailwindcss:build behave consistently

Well, currently it is consistent. The default for this gem, since the first release, has been to generate unminified CSS by default. When you need to examine unminified CSS then the command rails tailwindcss:build[debug] will generate unminified.

The environment variable was accepted in #504 specifically to allow this "debug" behavior to be injected into the puma plugin (see #400 for discussion), it's not intended to be a permanent project configuration. As the name implies, it's meant for debugging.

I think the current behavior is the right default for most people, and so I'm inclined to close this PR without merging. But maybe I'm misunderstanding why you want unminified CSS by default. Can you explain a bit more about your use case? Is examining the generated CSS something you do often?

[bogdan]

I think the current behavior is the right default for most people, and so I'm inclined to close this PR without merging. But maybe I'm misunderstanding why you want unminified CSS by default. Can you explain a bit more about your use case? Is examining the generated CSS something you do often?

In my experience css compression is a thing that brings more problems than it solves.

Why?

The page we are currently at is loading https://github.githubassets.com/assets/global-21a7f868f707.css.

It is compressed and takes 277KB. If we decompress it takes 319KB. So it is 13% reduction.
You can check download speed of both files with ab:

# compressed
ab -n100 -c3  https://silver-naval-alligator-759.mypinata.cloud/ipfs/bafybeih4g2e5z4zmuwkvhr6lumbg4k24rdeokstuj3iabdsimm46ms7vxu 
# uncompressed
ab -n100 -c3  https://silver-naval-alligator-759.mypinata.cloud/ipfs/bafybeiflwjjoogudwof25l5rpakbnghl3fupcdcimwilds4mkba64v3j7a 

This is ApacheBench, Version 2.3 <$Revision: 1913912 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking silver-naval-alligator-759.mypinata.cloud (be patient).....done


Server Software:        cloudflare
Server Hostname:        silver-naval-alligator-759.mypinata.cloud
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-ECDSA-CHACHA20-POLY1305,256,256
Server Temp Key:        ECDH X25519 253 bits
TLS Server Name:        silver-naval-alligator-759.mypinata.cloud

Document Path:          /ipfs/bafybeiflwjjoogudwof25l5rpakbnghl3fupcdcimwilds4mkba64v3j7a
Document Length:        326284 bytes

Concurrency Level:      3
Time taken for tests:   7.252 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      32728230 bytes
HTML transferred:       32628400 bytes
Requests per second:    13.79 [#/sec] (mean)
Time per request:       217.548 [ms] (mean)
Time per request:       72.516 [ms] (mean, across all concurrent requests)
Transfer rate:          4407.47 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       53   65   5.1     64      90
Processing:    92  147  24.8    147     232
Waiting:       44   91  23.7     92     182
Total:        158  211  26.5    210     303

Percentage of the requests served within a certain time (ms)
  50%    210
  66%    219
  75%    223
  80%    226
  90%    247
  95%    259
  98%    281
  99%    303
 100%    303 (longest request)



This is ApacheBench, Version 2.3 <$Revision: 1913912 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking silver-naval-alligator-759.mypinata.cloud (be patient).....done


Server Software:        cloudflare
Server Hostname:        silver-naval-alligator-759.mypinata.cloud
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-ECDSA-CHACHA20-POLY1305,256,256
Server Temp Key:        ECDH X25519 253 bits
TLS Server Name:        silver-naval-alligator-759.mypinata.cloud

Document Path:          /ipfs/bafybeih4g2e5z4zmuwkvhr6lumbg4k24rdeokstuj3iabdsimm46ms7vxu
Document Length:        283604 bytes

Concurrency Level:      3
Time taken for tests:   7.573 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      28461180 bytes
HTML transferred:       28360400 bytes
Requests per second:    13.20 [#/sec] (mean)
Time per request:       227.192 [ms] (mean)
Time per request:       75.731 [ms] (mean, across all concurrent requests)
Transfer rate:          3670.14 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       54   65  23.2     60     281
Processing:    87  146  64.4    140     725
Waiting:       37   93  63.0     85     656
Total:        142  212  70.1    202     791

Percentage of the requests served within a certain time (ms)
  50%    202
  66%    211
  75%    222
  80%    229
  90%    241
  95%    263
  98%    462
  99%    791
 100%    791 (longest request)

People might think that compression:

1. Decreases page load speed

• it is not, network request/response roundtrip is way longer than downloading additional 13% unless your CSS is 10MB+.

3. Reduces traffic bill from hosting provider

• it is not, downloading CSS once for your entire website when HTML and images are downloaded constantly. CSS is a tiny fraction of traffic.

All of that makes even less sense when there is a gzip compression support for HTTP:

-rw-r--r--  1 bogdan  staff   277K Mar  2 22:12 tmp/compressed.css
-rw-r--r--  1 bogdan  staff    41K Mar  3 09:39 tmp/compressed.css.gz
-rw-r--r--  1 bogdan  staff   319K Mar  3 09:38 tmp/uncompressed.css
-rw-r--r--  1 bogdan  staff    44K Mar  3 10:10 tmp/uncompressed.css.gz

I am not sure why we are not using it out of the box yet.

My conclusion

CSS compression doesn't make my app better. I disable it for all environments whenever I encounter the need to disable it for the first time (like for debugging).

So what I need is a consistent way to disable CSS compression. That is why config option makes sense.