我在生产环境中使用rails资产pipe道function。我已经写了一些设置在nginx中发送gzip格式的文件，文件以gzip格式正确地出现。我猜浏览器正在自动解码，所以我无法find看看这些js文件是否以gizp格式进行configuration。
我已经把下面的命令，我得到的“内容编码：压缩”在响应。
curl -v -H 'Accept-Encoding: gzip' -o /dev/null http://www.example.com/assets/style.css 2>&1 | grep -i Content-Encoding 我已经在nginx中写下了以gzip格式发送文件的设置，并且文件以gzip格式正确显示。
location ~ ^/(assets)/ { root /home/webuser/app/woa/public; gzip_static on; expires max; add_header Cache-Control public; # access_log /dev/null; }
我将如何知道文件是否以gzip格式发送？
另外请build议任何其他可以帮助改善网站性能的选项。
不是直接回答你的第一个问题（如果你解决了这个问题，请做解释），但是为了改善现场表现，请记住Perfomance Golden Rule ：
最终用户响应时间的80-90％用于前端。 从那里开始。
下面是Rails应用程序中提高性能的非穷举列表：
识别性能问题的一个有用的diagonsis工具是Yslow或Google Page Speed它们是浏览器扩展，可以诊断和识别减慢应用程序速度的常见问题（尤其是在前端）。
对于您的Rails后端，我建议直接将Bullet和NewRelic等工具整合到您的开发过程中，这样在开发过程中，您可以立即发现错误的查询，同时还可以轻松修复。
检查您的服务器日志是诊断Rails应用程序的哪些组件时间最长的有效方法。 例如，下面是在我的本地开发环境中运行的两个不相关的生产Rails应用程序的示例日志：
# app1: slowish Rendered shared/_header.html.erb (125.9ms) Rendered clients/details.html.erb within layouts/application (804.6ms) Completed 200 OK in 3655ms (Views: 566.9ms | ActiveRecord: 1236.9ms) # app2: debilitatingly slow Rendered search/_livesearch_division_content.js.erb (5390.0ms) Rendered search/livesearch.js.haml (34156.6ms) Completed 200 OK in 34173ms (Views: 31229.5ms | ActiveRecord: 2933.4ms)
App1和App2都遇到性能问题，但是App2的性能问题显然非常缓慢。 （34秒！）但是对于这些服务器日志，我知道App1应该查看clients/details.html.erb ，而对于App2，我绝对需要调查search/livesearch.js.haml 。
为了保持快速加载时间，您需要减少页面资源（JS / CSS / Images）的数量/大小。 所以想想你的页面大小就像一个预算。 例如，Hootesuite最近宣布他们的主页现在有一个严格的页面大小预算 1 MB。 没有例外。 现在检查他们的页面。 不是很快吗？
轻松获得减少页面大小包括剥离未使用的JS或CSS文件，包括只在需要的地方，并将静态图像更改为更小的向量。
图像加载是导致页面加载速度较慢的主要原因。 在您的初始页面的背景中使用一个大的5MB图像可以很容易地被降低到200kb-400kb的大小，仍然是高质量足以与高分辨率原始图像几乎无法区分。 页面加载时间的差异将是显着的。
你也应该对用户上传的图像做同样的改进。 例如，如果您的网站的用户头像大小为50×50像素，但是用户上传5mb图像作为他的头像，那么您必须以较低的文件大小和分辨率来提供图像，以准确地显示网站上的图像。
Carrierwave ， Fog和rmagick是Amazon S3使用的流行宝石，可以实现更好的图像加载。 有了这些包，您可以根据每个用户的屏幕大小动态地提供较小的图像分辨率。 然后，您可以使用媒体查询，以便与使用Retina屏幕的用户相比，移动设备的图像尺寸更小。
再加上最后一点，您可以使用Cloudfront等内容交付网络（CDN）加速资产/图片加载时间。 CDN在许多服务器上分发资产，然后通过位于距离提出请求的用户最近的服务器向用户提供资产。
当静态资产被指纹识别时，当用户访问你的页面时，浏览器会缓存这些资源的副本，这意味着他们不再需要为下一个请求重新加载。
放置在页面底部的Javascript文件将在页面加载后加载。 如果javascript资源放置在页面的顶部，那么当用户的浏览器尝试加载您的JavaScript文件时，该页面将保持空白。 幸运的是，如果您使用资产管道或使用javascript_include_tag指定JavaScript文件，Rails会自动将JavaScript文件放置到页面底部。
编辑：大多数现代浏览器现在自动优化Javascript加载，所以你可以大多忽略这个建议。
在所有后端性能优化中，缓存是最有效的性能提升之一。 一个良好实施的高速缓存机制可以极大地降低高可伸缩性期间后端内部低效查询的损害。 频繁访问的内容，相对而言较少发生变化，从缓存中获益最大。
缓存功能非常强大，使得上面提到的App2的页面加载时间从34秒缩短到了不到1 秒的时间 。 在后端，没有其他的性能提升可以达到我们从缓存获得的水平。
总的来说，当使用缓存进行性能优化时， 从高开始然后降低 。 你将得到的收益将会更大，更少的努力。
从高到低，有些类型的缓存可供您使用：
要了解有关缓存的更多信息，请点击这里http://guides.rubyonrails.org/caching_with_rails.html
如果您正在为数据库层使用SQL，请确保在连接表上指定索引，以加快查找频繁使用的大型关联。 您必须在迁移过程中明确地添加它们，因为Rails中默认不包含索引。
使用关系（SQL）数据库的Rails应用程序的主要性能杀手是N + 1查询 。 如果您在日志中看到您的应用正在为单个请求进行多次数据库读取/写入操作，那么通常会显示您有N + 1个查询。 在开发过程中，N + 1个查询很容易被忽略，但是随着数据库的增长，它可能会快速地使你的应用程序瘫痪（我曾经处理过一个有12个N + 1查询的问题，只积累了大约1000行的生产数据， 分钟加载）。
子弹是一个伟大的宝石， 捕捉N + 1查询，因为你开发你的应用程序。 在您的Rails应用程序中解析N + 1查询的一个简单方法是在必要时加载相关的模型。 如Post.all更改为Post.includes(:comments).all如果您正在加载页面上的每个帖子的所有评论。
较新版本的Rails包含许多性能改进，可以加速您的应用程序（如Turbolinks）。
Ruby 2.1.x +包含比老版本的Ruby更好的垃圾收集。 到目前为止，人员升级的报告显示升级后的性能有显着的提高。
我错过了许多改进，但是这些是我可以推荐的一些性能改进。 有空的时候我会补充更多。