結論
どちらか好きな方読め。
読んだら好きな方の gem を入れろ。
-糸冬-
追加でやった方が良いこと
heroku がオリジンサーバの場合、assets 内のリソースファイルのリクエストは可能な限り減らしたいところです。
そのためにブラウザのキャッシュを利用しましょう。
こちらも参照してみてください。
herokuでブラウザのキャッシュを利用する | Qiita
周辺事情
Web サービスがブラウザに返却するリソースは、HTML、CSS、JS、そして画像ファイルが大勢を占めます。
HTML,CSS,JS はご存知のようにテキストデータで、こいつを圧縮して送信できるとレスポンスタイムを削減することが出来ます。
heroku のようにサーバが遠い場合は特にその恩恵にあずかることが出来ます。
asset_sync を使ってる場合、この gem の機能で asset なファイルの gzip 圧縮をやってくれるので、これですましている方も多いと思います。
しかし heroku をオリジンサーバにして S3 を経由せずに直に CloudFront を使う場合（参考：heroku+CloudFrontで静的ファイルを配信する（Webフォント対応） | Qiita）や、rails 本体が返す HTML の圧縮までやるとなると、最初に挙げた gem を使う必要が出てきます。
厳密に言うとどちらも Rack::Deflate という gem を利用しているのですが、このベースとなる gem は普通に使うと画像なども gzip 圧縮してしまうため、より使い勝手を向上させ、gem の導入以外の手間を省くことも目的としているようです。
実際、これらの gem を使用しない場合は、下記のブログに解説されているような対応が必要になってきます。
herokuでMIME type別にgzip圧縮する方法 | satooshi@blog
heroku の仕様も含めて分かりやすく解説されているので、一読することをお勧めします。
以前は Rack::Deflate とこのブログで紹介されている gist を組み合わせる必要があった訳ですが、それがオールインワンになった感じでしょうか。
Job-Hub では heroku-deflater を使用しています(heroku_rails_deflateの方は未確認)。
単に gzip 圧縮を利用する目的であれば、gem の追加だけですみます。
group :staging, :production do
gem 'heroku-deflater'
end
環境によると思いますが、Job-Hubでは 1ページの容量と応答時間が最大で2割くらい減ってます。
あと、Chrome の Pagespeed や FireFox の FireBug の YSlow で警告が減るのが地味に嬉しいです。
ところでこれらの gem、名前も説明も heroku で使うこと前提ですが、heroku 以外では使えないんですかね？
まあ普通は Apache や nginx などを設置してリバースプロキシとしてリクエストを処理させるので、gzip 圧縮はそっちでやるとは思いますけれど。