我正在接管rails 3.2应用程序的开发，并正在寻找改善页面加载时间的最佳方法。该网站本身更像是一个大型动态网站，而不是一个实际的网络应用程序（该网站http://korduroy.tv/，一个冲浪生活方式社区网站），虽然有几个小部分因用户而异，但该网站的大部分内容对每个人来说都是相同的体验。
页面加载时间相当慢，从服务器日志来看，这似乎是因为每个页面都加载了太多动态内容（例如，大多数页面都加载来自10多个模型的资源）。虽然我希望尽我所能进行重构，但我正在寻找一些基本的性能优势。知道大多数网站对每个用户来说都是一样的，他们是否可以在服务器上积极缓存内容，甚至提供通过某种后台工作生成的静态内容？
我最初的想法是创建一个使用静态站点生成器的作业，可能像Jekyl一样，基本上创建站点的静态副本，然后可以在cdn上提供。我的直觉告诉我，这可能不是解决问题的方法，而且还有一些页面（如用户配置文件页面）需要动态提供。
任何建议都很好。免责声明，我来自前端，对服务器端优化的最佳实践知之甚少。谢谢
根据您所写的内容，我相信您最大的收获将是使用memcache存储实现片段缓存。看见http://guides.rubyonrails.org/caching_with_rails.html作为rails缓存的权威指南。
对于一些不依赖于用户的内容（如主页），你可能可以使用页面缓存或动作缓存，但除非你每天处理数百万个请求，否则我不确定这是否有必要。
我注意到，虽然javascript和css似乎是根据rails资产管道编译的，但图像缺少允许浏览器对资源进行积极缓存的sha1哈希（因为你不必担心内容会发生变化，因为当你更改图像时，它们会得到新的哈希）。这里的关键是启用资产管道，确保将资产编译为部署的一部分（rake assets:precompile），并使用image_tag和asset_path助手（或image-url-sass助手）。此外，在刷新页面时，请确保nginx对浏览器的响应为代码304（未修改）。这不会影响rails服务器上的负载（除非nginx和rails都在同一台服务器上运行），但会减少平均页面加载时间。
您可以研究更高级的技术，如缓存sql查询或优化这些技术，但这可能会导致复杂性增加，从而使维护代码库变得更加困难。首先尝试视图缓存，看看这是否能将加载时间提高到可接受的水平。