Are there more people who think that this is a good request for upstream? I have no idea about this topic, and I can tell you in advance that I don't feel equipped to defend it upstream. If someone else want to to take it...

Upstream's instance is not affected http://www.webpagetest.org/result/150115_TM_16EC/3/performance_optimization/#compress_text , it looks like a matter of configuration here.

Sounds like lower level server configuration (like Apache's mod_deflate)?

This would save mobile users time and money.

sort of relateable T56291

Added

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript

to Apache conf file on phab08. (from http://httpd.apache.org/docs/2.2/mod/mod_deflate.html)

Test results here:
http://www.webpagetest.org/performance_optimization.php?test=150326_HN_JNS&run=1&cached=0

Upstream sort of recommends using GZIP here https://secure.phabricator.com/T2226

I guess that the next step would be to add it to phabricator-default.conf.erb in the puppet module.

This needs the go in varnish and is more complicated indeed

OK, varnish, right. The apache deflate conf change does not change anything even on labs as it turns out. (with or without, gzip compression is still enabled)
FYI: I am interested in this task because of the comparatively "fat" static resource requirements of the Sprint extension (jquery, etc.)

For what it is worth, I did a comparison of production load time of a burndown chart versus labs load time of a burndown chart (with compression enabled).
http://www.webpagetest.org/result/150326_TE_12TH/1/details/ (labs) = 9.562s
http://www.webpagetest.org/result/150326_7H_135H/1/details/ (production) = 9.354s

I suppose that these server configurations are completely different, so it is surprising to see such a similar result.